人月神话——我的理解

人月神话中第一章就提到了The Tar Pit ,在焦油坑种挣扎并且体验快乐并苦恼的编程过程,人月神话的开始就在讨论超级项目的合作与分工的矛盾以及内部模块的复杂交织。作者是IBM OS/360项目的项目经理和主要负责人,IBM/360所犯的错误以及给我们的启示成就了这本书,本书的目的是为身处焦油坑里的软件工作人员提供一点帮助和引导。依作者的观点,“人月神话”的出现和工程进度的不合理安排有很大关系,因此合理工程化体系的建立很有必要,盲目的软件生产心理和人员协调中存在的问题导致了软件工业的巨大失败率,这确实给了后继的软件开发人员很鲜明的指引。

由于事先不重视项目估计和规划,以及对项目的进行的掌握没有很大的信心,项目经理们在不合理项目估算和计划上面吃了不少苦头,这直接影响到最后的测试和交付。作者指出,一个很严重的问题是,我们总是假设人和月可以互换,这给工程带来了很大的隐患,主观地认为进度和工作量的等价,因此,当项目遇到问题时,比如不能按时交付,经理们最直接的想法就是增加人力。这是一个愚蠢的想法,作者认为其中增加的人力资源会被随之增加的信息交流开销和已进行工作的部分返工抵消甚至更糟。这也是所谓的火上浇油,此外,在监督管理上的欠缺和盲目乐观常常导致较晚的错误发现和随之而来的巨大错误损失。

年轻的编程人员都有乐观主义,总是相信自己的代码是肯定能运行的。所谓的估计和预协调往往建立在乐观主义的基础上,并且由于盲目自信,导致最后的完成与初期预计出入悬殊,隐藏着巨大的危险和经济损失。而现实往往不是乐观,在项目的进展过程中会存在各种不可预知的问题,并且这些问题的解决并不是单纯靠工作量的增加能得以缓解的。在这个时候对人月的盲目观念就会是项目经理犯下更严重的错误,项目经理就会为项目增加人员,然而增加人员反而导致项目进度越来越慢,导致在焦油坑中越陷越深。在投入了更多的人力的时候,经理发现项目进度反而更慢他就会投入更多的人力,这种恶行循环导致项目的失败和成本与进度的巨大反差。

Harlen Mills 指出,应该仍以团队划分的机制来进行分工,即大型项目的构建不能脱离人力,但是每个承担具体任务的团队宜建立外科手术式的体系。就我对这种体系的理解,贵族精英化的统领和具体实现的民主和创新会有一种比较好的效果,在许多大型工程项目中均有普遍性,在软件工程中尤为突出。这种不可预测的开发过程越具有完整性越会有较好的开发成绩,过度交织和缺乏统一划定往往会造成巨大的结构复杂性和错误率,导致难以预计的损失和难以挽回的失败。这样,沟通的成本就会降低,实现人员也会有的放矢,发挥出其工作范围内的创造性,同时,要使工作易于管理,必须清晰地划分体系结构设计和实现之间的界限,系统架构师——即“外科手术医生”必须一丝不苟地专注于体系结构。

概念完整性——很抽象的一个词汇,我的理解是,在宏观上可以整合,符合统一限定的规则并且思路上是连贯的,这就需要一个统一的协调机制,使不同模块的工作人员都能按照连贯的方式去协调工作并完善对接。书中说到“概念完整性要求设计必须由一个人,或者非常少数互有默契的人来实现”。这一点和外科手术式的队伍理念上一致,这同水平分割的论坛式团队组织相比,效率自然大大提高,这主要体现在它所代表的垂直分割所具有的人员沟通上的优势和相比之下在概念完整性上的明显优势。

第二个系统的危险性在于画蛇添足,由于有了第一个系统的经验,设计师对此类系统充满信心,同时,在对新系统的构思中,就会想着如何去润色和完善已有功能并且加入“额外的装饰”,这一点俗称“画蛇添足”。这就好比是促狭的进化路线,在某些方面发展地很好,令人大为称赞,但是却没有顾及到普遍的发展要求,不知不觉走进了一个误区,成为了“最后的最优秀的恐龙”。这一点往往成为了软件开发的阴云,这令我想起了曾经芬兰以及世界最著名的移动电话生产商——诺基亚,在发展如此迅速的电子行业中,在旧的体系中越做越好,精益求精;诚然,在通话手机和功能机上,他们达到了没有人能超越的水平,但是智能机迅速抢占的市场份额却没有给他们警示,依然沉浸在之前的成功中——这就好比是“第一个系统”。虽然,就我的理解,这个比喻不是特别恰当,但是却在一定程度上反映出了部分的事实和其中的危机。

手册和形式化的说明,会在一定程度上缓解开发和测试乃至维护上的棘手问题,这使整个开发有一个理解上的标准并且在交流和日常会议中以予贯彻和统一。测试人员和实现人员要有充分的沟通,以保证测试的标准性和完整性,在不同的方面都达成就手册说明的较为一致的理解。整本书在前面强调了文档和交流组织的重要性,即时这样的完成要花费代码实现的约三倍成本,但还是利大于弊的,特别在大型软件中,这是开发推进和后续开发的重要支撑。在后几章中,具体说明了其实现意义和实现指引,在人员组织上投入了大量笔墨,足以体现其重要性;任务的划分和人员的匹配与协调,是好的管理者应该认识到的,在软件工程的不同方面都有其意义。合理的解决方案应该是平衡和激励,依据工作的特点进行安排,以取得尽可能好的开发效果。

当然,这是我所认为的本书的核心理念和启示,在其中找到了一个落脚点进行阐释,也揉入了我对软件工程的理解,水平有限,望大家多指正。

2016年6月20日 于武昌珞珈山

符祖昊

时间: 2024-10-23 14:00:38

人月神话——我的理解的相关文章

读<<人月神话>>

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

人月神话阅读笔记07

第1章 焦油坑      焦油坑的意思说明了即使你足够强大,也无法摆脱束搏而沉到坑底.IT项目也是这样,不论是开发大型软件系统还是小型项目,都会遇到诸多复杂的问题和影响因素,项目本身就是一个足够复杂的动态系统,没有最优,只有满意.项目四要素,人员,组织环境,干系人,外部依赖和约束,风险和假设,团队,人等诸多问题都是你必须要考虑的问题,任何一个要素出现大的差错都可能导致项目失败,只有所有要素能够平衡好,团队能够协调一致才能够保证项目成功 第2章 人月神话      进度问题是IT项目管理最为关注的

人月神话读后感

书中应用焦油坑表示过去几十年的大型系统开发,很多大型和强壮的动物在其中剧烈挣扎.让我感觉到,软件开发过程中所遇到困难是多么的多,开发多么艰难.但是这本书同时告诉了我们软件的开发有苦也有乐,我们可以在编程过程中体会那份快乐.<人月神话>是为软件开发经验的天马行空总结.比<Beautiful code>更为有远见,把我从充实代码的清晰简介升华,拓展到软件开发的高层度, 一个周密,准确,明朗的开发需求分析,可行性研究,软件实现是软件开发的完美递进. 人与神话中讲述人力和时间并不体现线性关

初读《人月神话》

在平时的工作中,时常体会到消耗大量时间的往往不是一些难度很高的技术问题,而是一些由于工作流程管理不当及沟通不善造成的时间浪费,比如没有经过深入全面地分析和详细地设计就开始编码,事后常常要花大量的时间返工和修改:比如代码管理混乱,合并代码时常常出现各种小错误,耽误了进度:比如没有撰写清晰完备的文档,后续其他同事在维护之前的代码时,非常费时费力,等等.因此,学习一些项目管理方面的知识非常有必要.抱着这种心态,我翻开了<人月神话>,开始第一次阅读.下面摘录一些本次阅读过程中的一些笔记: 1.任何创造

《人月神话》阅读笔记--01

<人月神话>是为软件开发经验的天马星空总结.具有远见的见解,把我从充实代码的清晰简洁升华,拓展到软件开发的高层次,一个周密准确明朗的开发需求.可行性的研究和软件实现是软件开发的完美递进,他们相互辅助,相互促进,如同海浪一层的推着向前奔向远方,而<人月神话>如软件工程开发经济的精华.软件开发的多少人参与和完成时间不成正比的,过多的人参与并不一定能缩短开发时间.如战争,部队多,人多并不是关键,更多需要武器的先进,战术,兵多后方便的补给就得多.如是参与软件开发的人增加,软件的花费将提高,

人月神话读后感2

<人月神话>是为软件开发经验的天马行空总结.比<Beautiful code>更为有远见,把我从充实代码的清晰简介升华,拓展到软件开发的高层度, 一个周密,准确,明朗的开发需求分析,可行性研究,软件实现是软件开发的完美递进. 人与神话中讲述人力和时间并不体现线性关系.指出以大量人员和较短的时间,并不能缩短软件的开发进度.一窝蜂的作业方式无助于软件生产,且会制造麻烦,产生出更差的软件.向进度落后的项目追加人力,只会使进度更加落后.所有的编程人员都应该是乐观主义.人数和时间的呼唤仅仅适

人月神话第一篇阅读笔记

我先通读了全本书,对整书的大概内容进行了了解.第一遍的阅读中我知道了许多.软件开发的多少人参与和完成时间不成正比的,过多的人参与并不一定能缩短开发时间.如战争,部队多,人多并不是关键,更多需要武器的先进,战术,兵多后方便的补给就得多.如是参与软件开发的人增加,软件的花费将提高,参加这需要时间了解项目,给软件管理带来了不协调. 人月神话的核心法则是:概念完整性和架构师.Brooks认为,一个整洁.优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型,这个模型描述了实验应用的方法以及用来指明操

【最后的总结】人月神话读后感

人月神话读后感 这本300多页(中文新版)的神书,在经过了20多年的历史之后,仍然畅销不衰,究竟是什么让它有如此的魅力?过去的一个月,一点一滴的阅读之中算是初步的了解到了它的一部分吧. 人月神话的核心观点:概念完整性和架构师 Brooks认为,一个整洁.优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型,这个模型描述了应用,实现应用的方法以及用来指明操作和各种参数的用户界面使用策略.概念的完整性是易用性中最重要的因素.而架构师,则是负责保证产品所有方面的概念完整性的,架构师设计的是能够让

《人月神话》阅读笔记

一开始听到这个书名时,我的第一反应是人月神话?神话故事?嫦娥?吴刚?和玉兔?然后在有了大概的了解之后我有了阅读的兴 趣,而且一开始我看这本书时都是怀着非常崇拜的心情来拜读的,要知道一本1975完成的书,在多年后又开始流行,那必然是有他非 常成功的地方的.  作者布鲁克斯在书中为人们管理复杂项目提供了独到的见解,从自己的管理经验中总结,在网上也看到很多人拜读后的自己的见解 以及感受,可能是我水比较浅,所以我的理解可能不是太正确,但这就是我看完这书之后的感受...也许是最近一直在准备团队项 目所以在