软件工程日报十三——《人月神话》观感

今天阅读了建民老师推荐我们看到书——《人月神话》

有以下观感

焦油坑

1.1 编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。

我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。

1.2 编程为什么会有趣？作为回报，它的从业者期望得到什么样的快乐？

首先，这种快乐是一种创建事物的纯粹快乐。
其次，这种快乐来自于开发对他人有用的东西。
第三，快乐来自于整个过程中体现出的一股强大的魅力。
第四，这种快乐是持续学习的快乐，它来自这项工作的非重复特性。
最后，这种快乐还来自于在易于驾驭的介质上工作。

1.3 职业的苦恼

首先，苦恼来自追求完美，这是学习编程的最困难部分
其次，苦恼来自由他人来设定目标、供给资源和提供信息。
下一个苦恼——概念性设计是有趣的，但寻找琐碎的bug却只是一项重复性的活动。
最后一个苦恼，人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢，而产品在即将完成时总面临着陈旧过时的威胁。

这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。

人月神话

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

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

软件开发的过程中时间精力的投入和人力的投入并不成线性相关。我们每一次对项目的估算都应该谨慎，把握好“人”与“月”之间的关系。

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

任务重新分配本身和所造成的工作中断；

培训新人员；

额外的相互沟通。

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

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

特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。

在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进行削减。当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。