人月神话读书笔记

第一篇：人月神话读书笔记

　人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。现在终于找到读他的理由了，可以感受一下大师的杰作。在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。

从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。下面就是一些读书的总结了。

焦油坑 1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。

2. 编程行业的一些内在固有苦恼：

l 将做事方式调整到追求完美，是学习编程的最困难部分。

l 由其他人来设定目标，并且必须依靠自己无法控制的事物。

l 真正的权威来自于每次任务的完成。

l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外

l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。

l 产品在即将完成时总面临着陈旧过时的威胁。 人月神话 1. 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。

2. 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。

3. 我们的构思是有缺陷的，因此总会有bug。

4. 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。

5. 在若干人员中分解任务会引发额外的沟通工作量--培训和相互沟通。

6. 关于进度安排，作者的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。

7. 因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。

8. brook法则：向进度落后的项目中增加人手，只会使进度更加落后。

9. 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。 外科手术队伍 1. 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。关于这一条我在极限编程里看到，sackman和humphrey分别做了实验发现优秀程序员工作效率比较差程序员的工作效率最高要高达28倍。

2. 小型、精干队伍是最好的。这一点在软件工艺和极限编程里都得到了充分的体现。

3. 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。

4. 对于真正意义上的大型系统，小型精干的队伍太慢了。

5. 实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。

6. 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法，既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。图1是10人的程序开发队伍沟通模式。 图1 10人程序开发队伍沟通模式

贵族专制、民主政治和系统设计 1. 概念完整性是系统设计中最重要的考虑因素。

2. 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。

3. 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。

4. 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。

5. 体系结构、设计实现、物理实现的许多工作可以并发进行。 画蛇添足 1. 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。

2. 结构师如何成功地影响实现：

i. 牢记是开发人员承担创造性的实现责任；结构师只能提出建议。

ii. 听取开发人员在体系结构上改进的建议。

3. 第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。关于这一点也许是正确的，但是这是一个回避不了的问题，如果没有开发第二个系统经验的人，就不可能有开发第三个系统经验的人了。 贯彻执行 1. 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。

2. 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。

3. 出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。

4. 允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。

5. 项目经理最好的朋友就是他每天要面对的敌人--独立的产品测试机构/小组。 为什么巴比伦塔会失败？ 1. 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果的组织。

2. 因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。

3. 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。 胸有成竹 1. 仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。

2. 构建独立小型程序的数据不适用于编程系统项目。

3. 程序开发与程序规模成指数增长趋势。

4. 当使用适当的高级语言时，程序编制的生产率可以提高5倍。 削足适履

这一章主要是要解决项目投资与磁盘空间和内存之间的矛盾，但是这个矛盾在电脑硬件发展到现在的层次已经可以忽略掉了 ……此处隐藏9495个字……下层的绝对把握能力。

二是“一个拿2倍工资的人，生产率可能是其他人的10倍。”不知道其他公司的程序员们如何看。我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。组建一个团队，最好的就是那种精英团队。微软就是这

种思路吧，把最聪明的人集中在一起，想不成功都难。

三是进度落后与增加人力。记得当年看《c＋＋编程思想》，bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？如果不想加班，不想削减功能，不想推迟发布日期，那么。。。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。

不同的社会经验，不同的思想状态，对读本书的心得也不一样。在此我说说书中许多非常好的观点。

1.外科手术队伍the surgical team

项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。

2.贵族专制，民主政治aristocracy,democracy,system

要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。

3.画蛇添足the second-system effect

讲述的基本都是基于ibm 360操作系统以及编译程序等方面的经验，讲述如何避免开发第二个系统的风险，作者认为开发第二个系统的设计师设计出来的系统是最危险的,因此要求他们自律。

4.贯彻执行passing the word

印象比较深刻的是"体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。"

5.巴比伦塔会失败why did the tower of babel fail?讲述巴比伦塔会失败的原因是缺乏交流。

6.胸有成竹calling the shot

主要讲述如何计算编程时间，以及提出几个人的经验算法。 讲述的各种算法可能都不太适合与现在的高级语言，但portman的观点仍然适合现在，即编程人员实际的编程时间只有50%，其他的时间都花在了无关的琐碎事情上。

7.削足适履ten pounds in a five-pound sack

主要讲述程序占用的空间等，在70年代比较突出，但现在好多了。

8.提纲擎领the documentary hypothesis

说明文档的作用

9.未雨绸缪plan to throw one away

唯一不变的是变化本身。 在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。

10.干将莫邪sharp tools

主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。

11.整体部分the whole and the parts

特别是这句话"bell实验室监控系统项目的v.a.vyssotsky提出,“关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方”,细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量。虽然这句话的意思只是说明精确定义产品将减少bug的数量，但我看到了系统分析的最重要的工作——产品定义。

12.祸起萧墙hatching a catastrophe

这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。 项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。

13.另外一面the other face

本章说明程序的另一面——文档。

不了解，就无法真正拥有——歌德，作者引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。想想，这种情况在现在仍然没有改变。于是作者提出了两个观点：

1.流程图：流程图是被吹捧得最过分的一种程序文档。许多程序甚至不需要流程图，很少程序需要一页以上的流程图

2.自动文档化（self-documenting）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。

14.没有银弹-软件工程中的根本和次要问题(no silver bullet-essence and accident in software engineering)

人狼是传说中的妖怪，只有银弹才能杀死他。作者认为软件项目具有人狼的特性，因为软件项目也可能变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。作者通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。 作者试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。他行动的第一步是将大块的“巨无霸理论”替换成“微生物理论”。这个变化的过程告诉你，进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。

15.再论《没有银弹》no silver bullet refired

看完再论《没有银弹》后，虽然作者说有不少人对他的观点持反对或不同意见，但我始终觉得他的观点是对的——根本和次要问题的划分以及定义。作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样。