经典软件工程著作《人月神话》经典语录摘抄和笔记

1、一切都将运作良好，每项任务仅花费它所“应该”花费的时间

 

        我常想，每个人都有良好的希望，或者说有梦想，但是梦想归梦想，现实归现实。脚踏实地，认清现实，是做好任何事情的基本要求。

 

2、用“人月”来衡量一项工作的规模，是一个危险和带有欺骗性的神话。

 

       想来惭愧，之前拿微软的project做工作量评估，可不都是用人月来报告工作量的？可是想想，在一个公司、一个团队，A的一个人月和B的一个人月是等同的吗？再有，一个人做四个星期，和4个人做一个星期，又怎么能等同呢？之所以Brooks博士说“带有欺骗性”就是从具体的工作时间安排中提取工作量的“人月”数时，实际上忽略了其它重要信息，如果略去这些，仅看“人月”，可能会受到蒙蔽，被欺骗。

     

       还有一个领导意愿的问题，领导当然希望能够按照预期的人月数来开展工作，一是可以根据需要，通过增加人手提高速度（这个问题后续再细说）；二是与不同的人之间可以呼唤（忽略了人员个体的差异）。从哪个角度来看，这样当然都很好很理想，但又是不现实的，所以叫“神话”。

 

3、在落后的项目中增加人手，只会使进度更加落后。

 

我认为，加上前后的语境，这句话应该这么理解：“（试图简单的通过）在落后的项目中增加人手的方法（来追赶进度），（通常反而）只会使进度更加落后”。这句话，就是第2条的一个补充。

 

原因很简单，就是临时加入人，培训和沟通需要代价；当然，某些特殊的项目，无需培训，加入的人又超强，自然是另外一回事。之所以领导会有向落后项目增加人手的打算，也是因为认为“人月”中，人和月可以互换，3个人5个月等同与5个人3个月。

 

所以最好是在一开始，对工作的量进行仔细的评估（包括认真分析隐形需求和额外工作量等），对工作量有清晰的认识，对工作时间，取得相关人等的同意，来开展工作。

 

当然，如果一定要提高进度，除了增加人手外又没有别的方法，那么晚加不如早加，虽然不能达到预期追赶和提高进度的目标，长远来看，也会比不加人好，另外，总比项目里中途有成员被调离要好多了吧！

 

4、在系统设计中，概念完整性应该是最重要的考虑因素，为了反映一系列连贯的设计思路，宁可舍弃一些不规则的改进和特性，也不提倡独立和无法整合的系统，哪怕它们包含了许多很好的设计。概念完整性的缺乏，将导致系统开发和修改上付出更昂贵的代价。

 

这里我的体会，就是产品和项目不能变成大杂烩。萝卜白菜、牛羊鱼肉都在其中。一道菜是水煮鱼，就别放牛肉在里边。产品经理们，请慎之慎之！

 

 

 

 5、管理人员要参加技术课程，高级技术人员要进行管理培训。项目目标必须在高级人员整体中得到共享。只要管理人员和技术人员的天赋许可，老板必须对他们的能力培养给予极大的关注，使管理和技术人才具有互换性。

 

我的理解：

管理人员如果不懂技术，那么对工作量评估、可行性分析都会带来极大的不便，没有威信和个人魅力使团队有很强的凝聚力和战斗力，和技术人员的沟通也会不是很畅通；

技术人员不懂管理，就不能从整体上考虑问题，因为对高级技术人员（例如架构师）来讲，技术问题也有很大一部的是人的问题，需要把技术和设计交给后面的环节来进行后续的工作，评价其它环节人的工作，能否做好这些，有没有良好的管理意识，能否顺畅沟通是关键。

 

6、系统软件开发是减少混乱度（减少熵）的过程，因此，它本身是处于亚稳态的。

 

7、系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配是大多数致命和难以察觉bug的主要来源。

 

我的理解，所以要有正规的需求分析过程、需求文档、设计过程、设计文档和设计评审，很大程度上是为了使参与人员都有一致的假设，这样避免错误。质量保证人员要测试一个产品或项目，在这些地方多花点时间，下点功夫是最有价值的。

 

8、项目的进度，经常以一种难以察觉，但是残酷无情的方式慢慢延后。必须关注每一天的滞后，它们都是大灾祸的基本组成元素。

 

9、软件开发中最困难的部分是规格说明，设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度的验证。

 

10、人们通常希望项目接近结束时，能收敛得快一些，然而情况确实越接近完成，收敛得越慢。

 

古语：行百里者半九十，真是非常有道理啊。