《人月神话》经典观点整理（之一）：哪些过时了，哪些还有效？?下面的文章是第一章和第二章的主要观点，后续章节的
《人月神话》经典观点整理（之一）：哪些过时了，哪些还有效？
?
下面的文章是第一章和第二章的主要观点，后续章节的我回头再发。看这篇文章能够迅速了解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向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。?
?
