人月神话

周博明

《人月神话》是软件工程方面的一本经典著作，书名《人月神话》中的人指的是人力，月指的是工作时间，主要的意思是人指的是一个人一个月能完成的工作量。其作者布鲁克斯（Frederick P. Brooks）被誉为“IBM System/360之父”，他曾是这一系统的项目经理，后来在设计期任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。上世纪七十年代开始，他开始撰写文章，讲述在软件开发中如何更有效的进行项目管理，其中有一些名篇“没有银弹”，“外科手术团体“至今被封为经典”，后来他将文章集结整理，初版了这本《人月神话》。
一、焦油坑

一头大象悠然自得地在草原上散步。夕阳的余晖洒下，大象觉得有些口渴了，它看到旁边有一个水洼，于是它慢悠悠地走到水洼前饮水。当它喝足准备离开时，突然发现自己被陷住了，这竟是一个蓄有一点水的沥青湖！大象抬起笨重的象腿想要抽身，却发现越是挣扎，越是下陷得厉害。大象预感到了死亡的来临，它的眼中渐渐浮现出惊恐与绝望。

第一章作者将软件系统开发比作吞噬了恐龙、剑齿虎等史前巨兽的焦油坑。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢且很难看清问题的本质。
二、人月神话

第二章作者主要介绍了软件开发项目在进度安排上经常出现的问题。
首先，编程人员都是乐观主义者，总是理想地想象一切都将运作良好，每项任务仅花费它所应该花费的时间。 而实际上，我们在实现过程中总会碰到各种各样的困难，可能是我们构思的缺陷，也可能是程序其他部件带来的错误影响，修复这些错误将占用我们大量的时间。
其次，估算进度时，我们错误地假设人和月可以互换，以人月为单位去衡量开发工作的规模是一个危险和带有欺骗性的神话。
就好比无论有多少个母亲，孕育一个生命都需要十个月。人月仅适用于完全可以分解的任务，这在割小麦和收棉花的工作中是可行的。当任务由于次序上的限制不能分解时，人手的添加对进度是没有帮助的。在开发工作中，添加更多的人手，意味着不得不花费时间去培训新人，并且随着开发人员的增多，沟通、交流的时间成本也越大。第三，系统测试的时间总是被预估得很低。 理论上，bug 的数量应该为 0，但由于我们的乐观主义，实际的 bug 数量比预料得要多得多，系统测试的进度安排常常是编程中最不合理的部分。
对于软件的进度安排，作者以自己多年的管理经验总结出如下法则：

• 1/3 计划
  
• 1/6 编码
  
• 1/4 构件测试和早期系统测试
  
• 1/4 系统测试，所有的构件已完成
  

与大多数传统进度安排相比，这份进度安排显得计划时间过长，测试更是占用了一半的时间，编码是最容易估算的部分，仅分配了 1/6 的时间。但如果不为测试安排足够的时间简直就是一场灾难，因为 bug 会没有任何预兆，很晚才出现在客户和项目经理面前。
第四，项目进度落后时，人们的第一反应是加派人手。这样的应对方案好比用汽油灭火，只会让火势更大，而更大的火势又需要更多的汽油，从而陷入循环的灾难之中。
三、外科手术队伍

200 个平庸的程序员组成的队伍很可能不如 25 个优秀程序员组成的队伍效率高。

那么，问题来了，什么样的队伍才是合适的呢，小团队固然高效，但是你不能指望一个 20 人的小团队在合理的时间内去开发一套完整的操作系统吧？作者在这一章里给出了解决方案：将大项目合理地划分成更小的系统，各个外科手术队伍分别开发这些更小的系统。
Harlan Mills 提供了一个解决方案：大型项目的每一个部分由一个团队解决，但是该队伍并不是一拥而上，而是以类似外科手术队伍的方式组建。
如今的外科手术已经相当成熟，通常来说，一个外科手术队伍中有五种角色：

• 一位外科医生
  
• 一位或多位助手
  
• 一位麻醉师
  
• 一位器械护士
  
• 一位巡回护士
  

其中，主刀的外科医生负责整台手术的操作部分，他必须经验丰富且能力出色。助手是外科医生的后备，他能完成任何一部分工作，但是相对具有较少的经验。麻醉师、护士为外科医生提供必要的帮助。
在系统开发中也可以采用类似的人员结构：
程序的总架构师担任外科医生的角色，负责程序的整体架构，并输出产品文档。保障程序的概念完整性，在整个团队中具有权威性。
助手需要了解程序的所有代码，负责与架构师讨论程序的结构，但不具有架构师的权威，他充当了外科医生的保险机制。
将程序员按照专业化分工，承担自己擅长领域的代码部分，他们创造了团队最有价值的财富 —— 工作产品。
测试人员负责编写测试用例，为外科医生搭建测试平台，保障程序的可靠性。
外科手术队伍与传统队伍的区别就在于：传统的团队将工作进行划分，每人负责一部分工作的设计和实现。在外科手术团队中，实际设计完全由外科医生完成，其他人负责填充实现细节与提供必要的帮助。
外科手术队伍的好处在于：他减少了沟通的成本，在传统的队伍中大家是平等的，出现观点的差异时，不可避免的需要讨论和妥协，在外科手术队伍中，观点的不一致由外科医生单方面来统一，它保证了程序的概念完整性。
四、画蛇添足

这一章主要是告诫系统设计师们，不要过度设计，尤其是在第二个系统(第一个系统完成后开发的第二个系统)中，不要过度自信，保持警觉，避免初始的概念和目标得到充分的体现，而不让一些次要的功能喧宾夺主。
五、巴比伦塔的教训

大洪水过后，全人类仅剩下诺亚一家，他们因躲在方舟中幸存了下来。诺亚一家人在新土地上重新繁衍生息，成为全人类共同的祖先。心有不安的子孙后代们为了防止大洪水再次发生，提议共同修建一座通天塔，这样，人们以后便不再需要流离失所。  不料这件事引起了上帝的注意，上帝开始担心：“如果这件事他们都能共同完成，以后便没有什么难得倒他们了。”上帝决定阻挠他们。他到人间转了一圈之后发现：“现在他们都是同一个种族，都说同一种语言。”于是上帝决定从语言下手，他创造了许多种语言，导致人们互相不能听懂。果然，没过多久，人们便无法继续合作修建通天塔了，不得不散落到世界各地。 ——《旧约圣经》，《创世纪》篇。

巴比伦塔计划虽然有充足的人力物力，但由于无法沟通，不得不走向失败的结局。它的教训告诉我们：沟通是合作的必要条件。
大型软件项目中也面临这样的情况，因为左手不知道右手在做什么，所以进度灾难、不合理的功能实现、系统缺陷纷纷出现。随着工作的不断进行，许多小组开始慢慢地修改自己程序的功能、规模和速度，当他们组合在一起时，新的程序就显得与原定目标渐行渐远。
团队之间如何有效的沟通呢？通常有三种途径：

• 电话、交谈等非正式沟通：这些途径非常方便、有效，并且随时发生在日常生活中
  
• 会议沟通：虽然谈到会议总是有些恼人，但会议是最正式的明确需求的途径。如果小组氛围足够和谐，会议沟通将非常有用
  
• 工作手册：在项目开始时，就应提纲挈领，准备好项目工作手册。指派专门的人手来维护工作手册，保证它们可以随着项目实时更新。工作手册应保持树状的索引结构，工作人员可以很方便的使用索引来检索他所需要的信息。
  

巴比伦塔可能是第一个失败的工程，但它不是最后一个。沟通与交流是成功的关键。这项技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。
六、未雨绸缪

大多数软件项目都是一开始设计好算法，然后将算法应用到待发布的软件中，接着根据进度安排，将第一次开发的产品发布给客户。
然而，对于大多数项目，第一次开发的系统往往并不好用。它可能太大、太慢，或者难以使用。许多原型设计上的痛点总是在项目落地之后才显现出来。要解决所有的问题，开发出一个更灵巧或者更好的系统，除了重新开始之外，没有其他办法。旧系统的丢弃可以一步完成，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。
七、干将莫邪

这一章一言以蔽之：磨刀不误砍柴工。好的开发工具和开发环境可以极大地提高开发效率。
八、祸起萧墙(进度管理和监控的方法)

慢性的进度偏离是士气杀手，这里核心思想就是要意识到进度滞后往往如温水煮青蛙一样让我们难以应付，最重要的就是要防微杜渐。重大灾害是比较容易处理的，它往往和重大的压力、彻底的重组、新技术的出现有关，整个项目组通常可以应付自如。 但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。
进度对于杰出的软件开发团队，同优秀的棒球队伍一样，是不可缺少的必要品德。 为了加强我们对进度的监控，里程碑的定义就至关重要了。里程碑的选择只有一个原则，那就是，里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。以下是一些反面的例子
例如编码，在代码编写时间达到一半的时候就经90％完成了；调试在大多时候都是99％完成的；计划完毕是任何人只要愿意，就可以声明的事件。里程碑有明显边界和没有歧义，比它容易被老板核实更为重要。如果里程碑定义得非常明确，以致于无法自欺欺人时，很少有人会就里程碑的进展弄虚作假。但是如果里程碑很模糊，老板就常常会得到一份与实际情况不符的报告。毕竟，没有人愿意承受坏消息。这种做法只是为了起到缓和的作用，并没有任何蓄意的欺骗。
在进度跟踪和管理上，必须要在整个团队中树立这种观念，就是要尽可能早的完成相关的任务，而不是拖到了最后在来做。类似于关键链进度管理中始终强调的一个重点内容就是要压缩前面的开发周期而在项目后期预留缓冲。
当进度出现偏差后，项目经理往往把问题掩盖起来，而且经常主观的认为可以通过各种赶进度的手段来挽回进度损失，但是往往情况并不是这么简单。因为很多时候 引起进度的偏差往往存在一些问题的根源，而这些根源往往是需要老板提前介入并采取一些行动，因此老板必须仔细区分状态报告、毫无惊慌地接收报告、决不越俎代庖，将能鼓励诚实的汇报。
九、没有银弹 —— 软件工程中的根本和次要问题

在未来的十年内，无论是在技术还是管理方法上，都看不出有任何突破性的进步，能够保证在十年内大幅度地提高软件的生产率、可靠性和简洁性。

在古老的西方传说中，月圆之夜，受感染的人狼将会由人变狼。人狼出没，凶恶残暴，唯一能杀死他们的武器便是银制子弹。在软件开发行业，我们一直渴求一颗消灭软件复杂度的银弹。
其一，计算机技术的发展太快了。从房子大小的第一台计算机面世，到今天的智能手机，计算机技术的硬件与软件都有了迅速而巨大的发展，为了不被新技术抛弃，工作人员需要不断学习新的知识技能，同时也要应对社会的其他因素带来的软件需求变化。每一次的新技术学习都是一次不小的挑战。
其二，软件研发的本身内在特性也制约了软件工程的进展，作者用四个词概括了这种特性。

• 复杂性：没有哪两个软件是一模一样的，复杂是软件的根本特性
  

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

• 一致性：大型软件开发中，界面、接口常常会不一致，并且随着时间的推移会变得越来越不一致
  

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

• 易变性：软件构成的因素随时都在变化
  

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

• 不可见性：程序是看不见的，即使用图示方法，也难以充分表现其结构，使得人们沟通面临极大的困难。
  

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

• 使用新技术，比如高级语言
  
• 快速开发原型，再做增量开发，而不是采用线性的瀑布模型。
  
• 聘用人才。寻找卓越的人，并给他们最优厚的待遇。
  

简言之，软件的复杂体现在它是纯思维的产物，是一个纯抽象的概念。具体语法层面上的实现只是软件开发中的次要问题。除非次要问题能占到开发活动的 9/10 以上，否则即使全部次要任务的时间缩减到零，也不会带来生产率数量级上的提高。
总结

作者首先提出人月神话的概念与项目管理的困境，然后说明尽管人月神话无法达到，但仍可以通过一系列的方法无限逼近这一神话，帮助软件开发者进行项目管理。为什么人月神话无法达到？为什么软件工程的项目管理无法一帆风顺？这一方面是由于计算机技术的飞速发展，人们不得不时刻更新自己的知识与技术，另一方面，是来着软件开发这项工作本身具有的特性，所以作者给出了”没有银弹“论断，并针对性的提出了改善这种情况的建议：采用新技术、快速开发原型、聘用卓越人才。正如作者所说的那样，软件工程可能是人类创造出的最错综复杂的一项工作，甚至，这种复杂度还在不断增加，人们能做的，只有不断学习更新的技术，探索更好的管理方法。

地的西瓜

在撸一遍。。。