《人月神话》读书笔记

《人月神话》读书笔记

《人月神话》是一本经典的软件工程的巨作，作者布鲁克斯（FrederickP.Brooks）被誉为“IBMSystem/360之父“，他曾是这一项目的项目经理，后来在设计期担任360操作系统的项目经理。由于这一工作，他与BobEvans和ErichBloch1985年曾获美国国家技术奖。Brooks博士曾经早期担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。由于本书是他领导IBM/360软件开发经验的结晶，内容丰富而生动，成为软件工程方面的经典之作。

第一版序言

在很多方面，管理一个大型的计算机编程项目和其它行业的大型工程很相似。

在很多另外的方面，它又有差别。

全书的中心论点：我相信由于人员的分工，大型编程项目碰到的管理问题和小项目区别很大;我相信关键需要是维持产品自身的概念完整性。并探讨其中的困难和解决方法。

焦油坑

过去几十年的大型系统开发就犹如这样焦油坑，他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求，表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。

职业的乐趣

首先是一种创建事物的纯粹快乐。

其次，快乐来自于开发对其他人有用的东西。

第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。

第四是学习的乐趣，来自于这项工作的非重复特性。

最后，乐趣还来自于工作在如此易于驾驭的介质上。

职业的苦恼

首先，必须追求完美。

其次，是由他人来设定目标，供给资源，提供信息。

概念性设计是有趣的，但寻找琐碎的bug却只是一项重复性的活动。

调试和查错往往是线性收敛的。

产品在即将完成或者终于完成的时候，却已显得陈旧过时。

 

人月神话

缺乏合理的时间进度是造成项目滞后的最主要原因。

导致这种普遍性灾难的原因是什么呢?

我们对估算技术缺乏有效的研究，并不真实的假设——一切都将运作良好。

我们采用的估算技术隐含地假设人和月可以互换。

对自己的估算缺乏信心。

对进度缺少跟踪和监督。

增加人力。

乐观主义

所有的编程人员都是乐观主义者。

将创造性活动分为三个阶段:构思、实现和交流。

正由于介质的易于驾驭，我们期待在实现过程中不会碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有bug。也就是说，我们的乐观主义并不应该是理所应当的。

人月

成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。

它暗示着人员数量和时间是可以相互替换的。

沟通所增加的负担由两个部分组成，培训和相互的交流。

软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

系统测试

软件任务进度安排：

1/3计划1/6编码

1/4构件测试和早期系统测试

1/4系统测试，所有的构件已完成

除了系统测试，进度基本能保证。

空泛的估算

为了满足顾客期望的日期而造成的不合理进度安排，在软件领域中却比其他的任何工程领域要普遍得多。

重复产生的进度灾难

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

外科手术队伍

问题

最好的和最差的表现在生产率上平均为10:1;在运行速度和空间上具有5:1的惊人差异。

数据显示经验和实际的表现没有相互联系。

Mills的建议

Mills建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生