读《人月神话》有感

                                                                                                                                                                                                                       中国科学技术大学软件肖勇 原创作品转载请注明出处

       在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。

     《人月神话》的作者Freder ick P.Brooks，Jr.曾荣获美国计算机领域最具声望的图灵奖（A.M.TURINGAWARD）桂冠。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献”。Brooks博士是北卡罗莱纳大学KENAN-FLAGLER商学院的计算机科学教授。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理，以及360系统项目设计阶段的经理。凭借在此项目中的杰出贡献，他与BobEvarls和Erich BIocll在1985年荣获了美国国家技术奖（NationalMedal of TecPlnoIogy）。Brooks博士早期曾担任IBM公司stretcPl和Harvest计算机的体系结构设计师。Brooks博士创立了北卡罗莱纳大学的计算机科学系，并在1964-1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。Brooks博士的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计。

    在《人月神话》一书中，Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验，该项目堪称软件开发项目管理的典范。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。它对于软件开发人员、软件项目经理、系统分析师等IT从业者都有着深远的指导意义。

    作为经典著作，《人月神话》提出了一些关于软件开发过程的几个重要关键点的独特的见解： 

　　（1）提倡团队组织上借鉴外科手术式的方法

　　 在软件开发过程中的人员组织上，如果过份民主，常常会导致效率低下，而且责任分散，因为参与其中的人想法太多，层面参差不齐。因此，可以借鉴外科手术式的方法，有一个主要的负责人，其他人作为副手去分工协作他，这样一来，效率和结果会提高很多。

　　（2）在软件开发过程中的必要的沟通手段

　　 对于软件开发过程，技术的缺陷往往不是最大的风险，最大的风险来自于缺少沟通。

　　（3）为保证概念的完整性，项目的核心概念应该由很少的人来完成

　　 少就是多，项目的定位需要和功能多少的权衡。太多的想法，使项目没有焦点，什么都要放进去，结果什么都做不象。

　　（4）文档的编写要适度

　　 在软件开发中，要保持适度的文档。喜欢过度多的文档的人，忘记了文档不是最终的产品，不是用户需要的，文档写得好，不一定就是好的开发。

　　（5）没有包治百病的银弹，只有适度改进

　　 采用了什么工具在软件开发的过程中其实并不是非常重要，重要的是不论用何种工具，都要达到项目本身的客户需求。任何方法论之前，先要探求问题的来源，否则，对各种方法论的依赖或滥用，有害无益。 

 

   

《人月神话》之焦油坑（转载自http://blog.sina.com.cn/s/blog_493a8455010088sl.html）

 

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

通过编程系统的演进可以看到简单的程序已经不能称作为系统，编程系统+编程产品才构成了编程系统产品，编程系统产品的复杂度将是一般程序的9倍。复杂度的增加就更好的说明了规模和工作量，工作量和项目周期之间都不是简单的线性增长关系，和第二章人月神话打下伏笔。回头再看大型系统复杂度和工作量成倍增长的原因：

1.对于复杂的事物我们需要去描述清楚，需要自顶向下逐层细化，这个系统分析和建模的过程需要耗费我们大量时间。当系统被分解为子系统->模块->组件后，后续我们为了完成产品还需要将它们集成在一起，这个集成过程仍然需要花费大量的时间。系统越复杂前期分析建模和后期集成的时间越多。

2.系统越复杂越涉及到更多的人参与来共同完成，人员的分工也会更加细化，这一方面人员增加导致的沟通效率的降低，一方面工序的增加使我们更加强调过程管理，我们会花费更多的时间来保证概念完整性。

 

职业的乐趣

兴趣是最好的老师，软件开发是一项相互协作的游戏，大家必须有兴趣为共同的目标而奋斗。对于软件开发职业乐趣首先体现在程序员在创造产品，而且自我创造的产品会被用户使用，为客户带来价值。因此要尽量避免项目中途夭折，或者最终开发出的产品被抛弃的厄运，这会打击到程序员的积极性和对创造的渴望。

一个软件产品如果是一个人被封闭在一个孤立的环境里面做，他可能是体会不到更多的快乐的，职业的乐趣也来源于团队成员间的沟通和交流，相互协作。不管是自己的问题被解答，或者解答了他人的问题，程序员都会感到快乐。

 学习的过程可能是枯燥的，但是学习后的成果能够帮助你解决实际的问题，你能够通过学习来创造软件产品，从这个意义上讲学习的是快乐的。学习的过程就是自我提高的过程，也是自我价值得以展示的过程。

从职业的乐趣这个意义上讲，IT项目管理者需要去激发团队成员意识到这点，这里涉及到沟通，团队建设活动，学习和培训诸多内容。让每个人都感受到他们被重视，而且共同在做一件有意义的事情，通过做这个事自己得到乐趣，得到了提升。

 

 职业的苦恼

程序员往往不喜欢受到太多的依赖和约束，也不喜欢繁琐的规程和文档，特别是这些文档没有体现出真正的价值的时候。还有他们可能并不喜欢修改自己的Bug，更不细化修改他人遗留下来的Bug,因此这种重复性的工作让他们体会不到创造性的乐趣。还有最大的苦恼往往更在于辛苦开发出来的系统不能真正使用而被抛弃。

还是有太多的程序员和管理者认为编码是一种无价值和创造性的活动，他们理想化的认为需求和设计可以做的足够详细，编码仅仅是一种体力劳动，这是对每一位程序员的不尊重。处于最后一道工序的编码人员，他们产出的代码最终形成的形成了软件系统和产品，当他们的价值往往并不能得到相应的承认。

 类似帕金森定律中的金字塔上升想象，每个人都很忙但组织效率确越来越低，每个人都在往上走，导致在每个岗位角色上都难得到技能过关高效率的人员。IT项目管理者需要致力于改善这些苦恼，这里面一方面是绩效机制的改善，一方面是适当的过程保证。项目管理者带领项目取得成功不仅仅是体现了自我价值，也让团队每个团队成员意识到他们存在的价值和贡献的力量。

 

  《人月神话》之没有银弹（转载自http://blog.sina.com.cn/s/blog_493a84550100bhp9.html）

 没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。-没有银弹

 一个相互牵制关联的概念结构，是软件实体必不可少的部分，它包括：数据集合、数据条目之间的关系、算法、功能调用等等。这些要素本身是抽象的，体现在相同的概念构架中，可以存在不同的表现形式。尽管如此，它仍然是内容丰富和高度精确的。我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多数系统中的概念错误相比，它们是微不足道的。如果这是事实，那么软件开发总是非常困难的，天生就没有银弹。然后具体从软件开发的复杂性，一致性，可变性和不可见性进行了详细分析。

1.复杂性

软件系统与计算机、建筑或者汽车大不相同，后者往往存在着大量重复的部分。由于软件产品特有的复杂度导致了成员之间的沟通非常困难，带来了软件产品的进度，质量和成本多方面的问题。特别是在软件规模增加的时候复杂度往往成倍上升。同时复杂度不仅仅导致技术上的困难，还引发了很多管理上的问题。它使全面理解问题变得困难，从而妨碍了概念上的完整性。(在软件产品开发工厂化的过程中，我们要注意到仍然解决的是次要因素，比如加大公用组件开发，加大平台和框架的建设，而业务功能本身导致的复杂性是无法避免的。)

2.一致性

某些情况下，因为是开发最新的软件，所以它必须遵循各种接口。另一些情况下，软件的开发目标就是兼容性。在上述的所有情况中，很多复杂性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂特性。

3.可变性

系统中的软件包含了很多功能，而功能是最容易感受变更压力的部分。所有成功的软件都会发生变更。现实工作中，经常发生两种情况。当人们发现软件很有用时，会在原有应用范围的边界，或者在超越边界的情况下使用软件。功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。简言之，软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着，这些变化无情地强迫着软件随之变化。(软件开发的过程必须要考虑如何适应变化，在需求，设计和编码过程中都需要考虑如何快速响应变化，如何提高软件产品的可扩展性。我们在软件开发生命周期模型上强调增量迭代的思路，强调测试驱动的思路其根本目的就是为了快速响应变化，降低变化带来的风险。)

4.不可见性

除去软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。(我们推荐快速原型法仍然是为了进来去解决软件不可见性的问题。

 

对没有银弹的感触

1.现在有很多快速开发平台，但是真正能够不写代码就完成业务功能的开发平台基本上没有成功的，特别是在业务场景比较复杂情况下，编程自动化基本是不可能的事情。唯一看到有所突破的是关于统一框架和技术平台等方面的建设，在原有的框架基础上我们来构建一个产品开发平台，将跟业务关系不大的权限模型，工作流引擎等集成进去，将常用的可复用组件集成进去，加快开发速度。

2.不要在追求自动编程平台上下功夫，可以在加强组件复用和技术平台建设上下功夫。

3.要多从开发模式的改进上来解决没有银弹所提出的各种实际问题，虽然不能够彻底解决，但是可以通过努力来改进。比如增量迭代的开发模型，快速原型法，测试驱动，高级语言和图形化编程等。

通过《人月神话》的阅读，我体会了软件开发团队中沟通的重要性。最后的没有银弹，让我深刻体会到了软件开发工作是一种高智力的脑力工作。《人月神话》将对我的未来的软件开发道路产生深远的影响。