[人月神话]读书笔记1--程序员的苦恼&&人月不可互换

第一章　焦油坑（The Tar Pit）

　编程是什么？
　一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。
　用焦油坑来比喻大型系统软件开发是再形象不过了。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。
　编程系统产品是什么呢？

图１：编程系统产品的演进
　□编程产品（Programming Product） 水平边界以下
　（通用化，测试，文档，维护）经验数据表明，相同功能的编程产品的成本，至少是已经过测试的程序的三倍。
　□编程系统（Programming System）垂直边界的右边
　相同功能的编程系统构件的成本至少是独立程序的三倍。如果系统有大量的组成单元，成本还会更高。
　□编程系统产品（Programming Systems Product）。 
　只有它才是真正有用的产品，是大多数系统开发的目标。
从图上可以看到，程序只是编程系统产品的九分之一。而这个编程系统产品才是我们想要的。

程序员职业有什么苦恼？
1）必须追求完美。学习编程的最困难部分，是将做事的方式往追求完美的方向调整。
2）是由他人来设定目标，供给资源，提供信息。编程人员很少能控制工作环境和工作目标。
3）依靠其他人的程序，而往往这些程序设计得并不合理，实现拙劣，发布不完整（没有源代码或测试用例），或者文档记录得很糟。
4）概念性设计是有趣的，但寻找琐碎的bug却只是一项重复性的活动。伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的劳动。
5）人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。
6）当投入了大量辛苦的劳动，产品在即将完成或者终于完成的时候，却已显得陈旧过时。

第二章　人月神话（The Mythical Man-Month）

在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。
1)我们对估算技术缺乏有效的研究,反映了一种悄无声息，但并不真实的假设——一切都将运作良好。
2)采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
3)由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
4)对进度缺少跟踪和监督。
5)当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。

□人月
用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。

当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。
对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。
沟通所增加的负担由两个部分组成，培训和相互的交流。因此这部分增加的工作量随人员的数量呈线性变化。
相互之间交流的情况更糟一些。如果任务的每个部分必须分别和其他部分单独协作，则工作量按照n(n-1)/2递增

□系统测试
1/3计划、
　分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索
1/6编码、
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成
　对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。

很少项目允许为测试分配一半的时间，但大多数项目的测试实际上是花费了进度中一半的时间。
但是不为系统测试安排足够的时间简直就是一场灾难。因此在早期进度策划时，允许充分的系统测试时间是非常重要的。

□空泛的估算
同厨师一样，某项任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。
为了满足顾客期望的日期而造成的不合理进度安排，在软件领域中却比其他的任何工程领域要普遍得多。

□重复产生的进度灾难
向进度落后的项目中增加人手，只会使进度更加落后。
（Adding manpower to a late software project makes it later）
项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。
分派较多的人手，计划较短的时间，将无法得到可行的进度表。

第一个里程碑没有达到、这个时候有下面四个解决方案。
1）在原来的基础上加人。(分第一个任务偏低和整个任务偏低两种情况)
2）重新安排进度。
  避免小的偏差（Take no small slips）。也就是说，在新的进度安排中分配充分的时间，
  以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。
3）削减任务。一旦开发团队观察到进度的偏差，总是倾向于对任务进行削减,当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。