【人月神话】第二章：人月神话

最近在看《人月神话》，分享一下自己的读书笔记个人的感受。希望能对大家有所帮助。

---

第二章主要就是讲项目滞后的最主要原因是：缺乏合理的进度安排。

1.乐观主义

大部分程序员都是乐观主义者，项目的管理者在做项目进度安排的背后往往都隐含着一个错误的假设“一切都将运行良好”，这就会导致整个进度安排的不合理。

编程工作不同于其他的工作，由于其工作介质（代码）的易驾驭性，所以缺陷一般不会再工作介质本身上（不会像一个制造者没做好工作那样，把错误归结为原材料质量不好），所以缺陷只存在于程序员的构思上面，所以我们不应该是个乐观主义者。

更何况，对于大型的编程工作，其包含许多的任务（各任务间相互联系、相互依赖），所以一切都正常的概率就会变得非常小（接近于零）。

2.人月

一个欺骗性的神话：用“人月”作为衡量一项工作的规模是一个危险和带有欺骗性的神话。

项目可分解且各部分相对独立 ===> 加派人手 ===> 可以加快进度

但是：

项目不可分解 ===> 加派人手 ===> 使进度更加落后
(分派给个人手工作之间联系较大，沟通交流工作量大，得不偿失)

3.系统测试

通常情况下，系统测试进度的安排常常是编程中最不合理的部分。

经验法则：

1/3 — 计划
1/6 — 编码
1/4 — 构件测试和早期系统测试
1/4 — 系统测试，所有构件已完成

如果在项目开发的过程中不为系统测试安排足够的实践将会是一场灾难。

不安排足够的时间系统测试 —> 在项目的最后阶段导致延期 —> 代价更大 —> 导致二次商业代价(某些商业时间依赖此项目)

所以，在进度安排时，允许充分的系统测试时间。

4.空泛的估算

不要为了满足客户期望的日期，而造成不合理的进度安排。

5.重复产生的进度灾难

向进度落后的项目中增加人手，会使进度更加落后。

项目进度落后 —> 加派人手 —> 进度更加落后 —> 加派人手 —> 进度更加落后 —> 加派人手 —> ……

因为在一个进行的项目中加派人手，需要对新加入的人进行培训，需要对任务重新分解，增加最后系统测试的工作量，分解的部分增多导致各部分之间的交流工作增加，从而会导致整个项目的更加落后。

如果此时再加派人手，又导致进度更落后，以此重复产生进度灾难。

总结：项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。