《人月神话》经典观点整理（之一）：哪些过时了，哪些还有效？

 

下面的文章是第一章和第二章的主要观点，后续章节的我回头再发。看这篇文章能够迅速了解Brooks的思想。

 

另外一个需要大家仔细考虑的就是，Brooks的《人月神话》是在几十年前写的，在软件行业发展这么多年后，各方面的情况都发生了翻天覆地的变化，那么，Brooks的哪些观点已经不符合当前的情况了呢？我们又能提出哪些新问题，作为对《人月神话》的一个与时俱进的补充呢？

 

 

第1章 焦油坑 

1.1 编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。 

 

<我自己的拙见：在现在这个时代了，已经不止是9倍了，业务的复杂度大大提升，产品和程序的距离也是越拉越大>

 

1.2 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，提供了五种乐趣： 

• 创建事物的快乐 
• 开发对其他人有用的东西的乐趣 
• 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力 
• 面对不重复的任务，不间断学习的乐趣 
• 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体 

1.3 同样，这个行业具有一些内在固有的苦恼： 

• 将做事方式调整到追求完美，是学习编程的最困难部分 
• 由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任 （我的拙见：一言道尽编程里最困扰人的事情）
• 实际情况看起来要比这一点好一些：真正的权威来自于每次任务的完成 ?? 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外 
• 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢 （我的拙见：无奈吧，这是规律）
• 产品在即将完成时总面临着陈旧过时的威胁 （我的拙见：这一句说得真好）

第2章 人月神话 

2.1 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。 

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

 

2.3 所有的编程人员都是乐观主义者：“一切都将运作良好”。 

2.4 由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中不会碰到困难。 

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

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

（这是这本书的一个核心观点）

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

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

2.9 作为一个学科，我们缺乏数据估计。 

 

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

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

（这是这本书的一个核心观点）

2.12向软件项目中增派人手从三个方面增加了项目必要的总体工作量：

• 任务重新分配本身和所造成的工作中断；
• 培训新人员；
• 额外的相互沟通。