人月神话有感3

人月神话—这个色彩斑斓的名字,勾起了童年对神话故事热情的回忆,它像一个巧克力甜品一样吸引着人们去品尝。翻开书目,却大吃一惊,它并非是潘多拉的盒子,也不是达摩克利斯之剑。细细品读,人月神话,这个时间和人力的博弈,描绘了工程项目的美丽神话。我想,这个名字也许是作者对于工程化处理我们面临工程项目的渴望。

在读这本书时,我们不妨站在一个项目经理的角度,我们手上有大大小小的项目要完成,我们有大量工程人员或者我们只有几个员工,我们也没有无限的时间和资金设备,面对那些大大小小的项目,面对这些诸多的人力,金钱,时间的限制,甚至是技术的制约,我们如何充分利用我们仅有的资源去有效的完成我们的项目,这对于项目经理来讲是一种挑战。然而人月神话给了我们多多少少一些答案,它虽然是几十年前著作,现在却同样影响着我们前进的步伐。

站在项目经理的角度上,我们首先了解任务分配中的一些基本问题,人月,即通常用来计算软件的工作量,假设我们要做一个软件,这个软件估计有10万行代码,如果说一个人一月可以完成1万行代码,那么我们推出这个人十个月将完成这个软件。也就是说假如我们投入十个人一月就可以完成这个软件。这个看似合理的计算方式,暗示项目经理人员数量和时间是可以互相替换的。然而我们忘记了一个致命的问题:任务是否可以分割。如果对于一个项目,每个人独立完成,没有交流,没有互相影响,那么这个计算方式是合理的。但对于软件开发工作而言,并非如此,如果没有交流,就会像巴比伦塔一样变成失败。在软件开发中,如果一个项目进度落后了,简单的增加人手,会使进度更加落后,因为新的人手需要让有经验的职员培训,然后要重新分配任务等等,都会对项目进度产生很大的影响。同时项目经理要知道祸起萧墙,项目进度拖后最大的原因往往不是重要的事情,而是琐碎的小事,每一件小事耽误半天或者一天,小事多了,将使得项目的进度严重后拖。

对于项目经理来讲,在安排任务过程中一个很多年的经验法则为:1/3计划,1/6编码,1/4构建测试和早期系统测试,1/4系统测试,所有的构建已完成。我们会惊讶的发现编码时间只有1/6,而测试时间占到了整个系统开发的一半。对于一个开发人员,在编写代码中,我们会假设我们的代码不会出现什么问题,但是实际情况却并不是这样,我们会花费大量的时间进行调试修改,对于一个大型项目,单元测试和系统测试会牵涉到很多问题,因此在早期进度策划时,预留充足的测试时间,才不会在即将交付产品时让问题出现在客户和项目经理面前。

在一个项目的团队中,众多的人员工作职责的划分是非常重要的,对于一个项目,一千个人可能有一千个人的想法完成实现,那么如何才能让所有的工作人员都朝着一个方向高效的完成一个项目,这里需要谈到系统概念完整性这个概念,它要求系统只反映唯一的设计概念,用户所见到的技术说明来自于少数人的思想。一个系统,必须有一个清晰明确的概念模型,大家都在这个框架下工作,所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念,但只有总设计者才有否定与发展基本概念的权力。概念的完整性要求设计必须由一个人或者非常少数互有默契的人员来实现。在整个软件开发过程中,困难的部分是概念的结构,如规格化、设计和测试等概念的结构,而不是概念的表述和实现概念,这就要就这些结构师们就有非凡的能力。邓小平是中国改革开放的总设计师,在他设计的这个框架下,千千万万的人民一起来实现,朝着富强的目标迈进。我们的结构师要学习他的才智,才能让我们的产品朝着优秀的方面发展。

假设一个项目经理已经拥有行事规范,富有经验的结构师和许多编程实现人员,那么,他如何确保每个人听到,理解并实现结构师决策?一个必要的工具:文档化的规格说明—手册。手册是产品的外部规格说明,他描述和规定了用户所看见的每一个细节,同样的,它也是结构师主要的工作产物。手册不但要描述包括所有界面在内的用户可见的一切,它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴,而这里他的设计和创造自由是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法,但是他不应该试图支配具体的实现人员,实现人员在贵族的支配下同样需要拥有民主。

那么到这里我们什么都已经准备妥当,现在需要开发工程师按照规格说明文档开发系统,我们不得不提到的是开发工具,项目经理应该制定一套策略,并为通用工具的开发分配资源,与此同时,他还必须意识到对专业工具的需求,对这样工具的开发不能吝啬人力和物力。之后,开发工程师就可以展示大展身手,高效的完成任务。

项目经理还应该知道,对于软件编程产品来讲,程序向用户所呈现的面貌(文档)与提供给机器识别的内容同样重要,我们可以采用流程图或者自动文档化程序等等向用户展现我们的产品。

最后,人狼是传说中的妖怪,只有银弹才能杀死他。软件项目具有人狼的特性,因为软件项目也可能变成一个怪物,一个落后进度、超出预算、存在大量缺陷的怪物。软件系统的内在特性复杂性、一致性、可变性和不可见性表明软件天生就没有银弹。在社会的发展中,人们不断思考发展产生了银弹----软件工程,但是还要继续发展,只有这样才能杀死传说中的人狼。

那么我们这些新一代的未来计算机领域的主力军,能否拥有银弹,需要我们不断的学习,思考,创新和发明。

原文地址:https://www.cnblogs.com/yang-qiu/p/10421731.html

时间: 2024-08-30 02:18:16

人月神话有感3的相关文章

读“人月神话”有感

在软件工程这门课中我们学到,一个软件的开发过程不是简单的一个选择编程语言编码实现的过程,而是一个要经过可行性研究分析.需求分析.形式化说明.总体设计.详细设计再到编码实现的过程,后期还需要对软件进行维护,整个软件的开发过程需要开发成员之间的密切而有效的合作. 这个学期,经同学的推荐,我读了一下<人月神话>这本书,一开始并不知道这是一本关于软件工程的书,毕竟这书名迷惑性太大,一般的人都会理解为是人跟月亮的神话,完全不会像软件工程的方向靠近.不过当你读了这本书之后会发现,整本书都是在以一种非常幽默

人月神话有感

初见书名时还在奇怪为什么老师要我们看一本这书,在我刚刚见到这本书时我以为说的是人类登上月球的书籍,后来明白了本书的名字并不是人类和月球之间的神话故事,而是软件工程的一些迷思,人月是一个人一个月的人力单位. 在这本书里作者提出软件工程中各个项目的比例应该如下: 1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand 初始时心中还在迷惑为什么编程的

读人月神话有感

人月神话书如其名一样震撼人心,它引起了许多别的领域的读者对此进行评价. 律师,医生,社会学家,心里学家,和软件人员一样对此书提出评论和建议.人们经常通过比较计算机软件开发生产率和硬件制造生产率来支持这个观点,后者在 20 年内至少翻了 1000 倍.正像第 16 章所解释的,反常的并不是软件发展得太慢,而是计算机硬件技术以一种与人类历史不相配的方式爆发出来.很多年后作者还是会被道“你现在认为哪些在当时就 是错误的?哪些是现在才过时的?哪些是软件工程领域中新近出现的?”很多年来人们对软件生产率和影

人月神话有感2

关于本书,即使很多没读过的人也能说出其中知名度最高的关于人月神话的观点.之前还在知乎上看过有人举了一个例子:一个人生孩子需要十个月,两个人去生孩子同样需要十个月.这一比喻虽不完全恰当,却也大致说出点内容.事实上,作者在书中这样来描述人月神话:软件开发项目常以人月来衡量工作量,这种度量暗示着人手和时间是可以互换的.这种"人多力量大"的想法是一种一厢情愿的虚妄神话,布鲁克斯法则:向滞后的软件项目追加人手会使得进度更迟缓(Adding manpower to a late software

《人月神话》有感

<人月神话>内容源于作者Brooks在IBM公司任System计算机系列以及其庞大的软件系统OS项目经理时的实践经验. Brooks最为一名项目经理写下了这本 <人月神话>,我觉得作为以编程为混饭吃的将来的It工种,很有必要去读一读这本书.Brooks详尽的借助了自己工作上的经验来为别人介绍了项目经理在一个项目上应当作的必要的事情:首先,必须要了解客户需要的是什么,要有什么样的功能:然后,还要了解成员之中能做到什么,对代码能够实现的功能必须了如指掌:最后要有详细的进程安排. 项目成

读《人月神话》有感

<人月神话>是IBM360系统之父布鲁克斯所著的经典,它为人们管理复杂项目提供了颇具洞察力的见解,既有很多发人深省的观点,也有大量的软件工程实践,读后受益匪浅,倍受启发. 本书分为15节,其中焦油坑,人月神话,外科手术队伍,贵族专制,民主政治和系统设计以及没有银弹是我最喜欢的几章,以下是我从这几个章节所获得的知识和见解:从(焦油坑)一节中,我认识到了 编程系统产品开发的工作量是供个人使用的.独立开发的构件程序的九倍:编程行业也存在一些苦恼:(1) 将做事方式调整到追求完美,是学习编程的最困难部

读《人月神话》一书有感

<人月神话>是一本不可多得的软件工程方面的经典著作.作者是被誉为IBM 360之父的Frederick P. Brooks,他在此项目中担任项目经理.他也因此获得美国国家技术奖和计算机领域的“诺贝尔奖”-图灵奖. 我觉得本书语言风趣幽默又不失严肃严谨.尤其是在The Mythical Man-Month和Calling the Shot两章,诙谐的语句间穿插图表和数据,发人深思. 书中给我印象最深的是Brooks提出这样一条定律.“所有的程序员都是乐观主义者,他们倾向于认为事情会如他们想象的那

成功需要一个好基石 ——读《人月神话》有感

历经了前面的种种困难,才懂得"成功"两字的分量是多么的重,不仅仅是来之不易,更是无法复制的.使得一个项目成功需要很多的因素,俗话说:"好的开始是成功的一半",读了<人月神话>也就明白了怎样让一个项目有一个好的开始.为了呼应主题,我将好的开始称作"基石". 效率高和效率低的 实施者之间具体差距非常大,经常达到了数量级的水平,这也就产生了一个最基本的问题:如何分工?这个问题看似简单,实则包含了人员数量,工作种类.管理结构.任务分配等,每一

读&lt;&lt;人月神话&gt;&gt;

这本书在软件领域知名度很高,每次看到年度推荐的文章里面都有这本书且强烈推荐.出版30年了,可谓经典. 但我在读的过程中并没有那么深的体会.书中很多章节都是基于大型项目或者大型系统的经验总结,至今为止我还没有参与大于30人的项目.只能说自己的境界还不够. 第一章,焦油坑 再也找不到一个词比焦油坑更能形容,软件开发的过程了.我们都在挣扎.计划,计划,不断计划,但还是拖延,拖延,拖延.... 职业的乐趣: 创造性,贡献助人为乐,过程的魅力或者解决问题的成就感或写代码的快感,持续学习新事物,驾驭感. 职