在众多的项目中，缺乏合理的进度安排是造成项目延期最主要的原因，这比其他所有因素加起来影响还要大。这个灾难是怎么发生的呢？

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

所有系统的进度安排背后第一个错误的假设是：一切都将运作良好，每项任务仅需要花费它 “应该” 花费的时间。对于创造者，只有在实现的过程中，才能发现我们构思的不完整和不一致性。

编程人员通过非常纯粹的思维活动构思程序，所以很容易自信的认为实现过程中不会遇到困难。然而我们的思维是有缺陷的，项目越大，能够按照计划顺利进行的概率就越小。

人月

在估计和进度安排的过程中使用 “人月” 作为工作量单位是十分荒谬的，是一个带有危险和欺诈性的神话，他暗示着人员数量和时间可以相互替换。然而人数和时间的互换仅仅适用于，某个任务可以分解给参与人员，并且他们之间不需要相互交流的情况。

当不能分解时，人手的添加对进度没有任何帮助，大多数编程工作都具有这种特征。就像你无论找几个妈妈，孕育一个生命总是需要 10 个月的时间。

对于可以分解的情况，增加人手可以加快进度，但是会提高成本，2 个人的效率可能仅等于 1.5 个人。原因在于沟通、培训、交流等事物增加了工作量，而且所增加的工作量可能会完全抵消任务分解所产生的作用。

软件开发作为一项系统工作，沟通、交流的工作量非常大，它会快速消耗任务分解所节约下来的时间。

系统测试

系统测试进度的安排往往是编程中最不合理的部分，都过于短了。很少项目允许为测试分配一半的时间，然而大多数项目的测试实际上是花费了进度中一半的时间。

不安排足够的测试时间将会是一场灾难，由此造成的项目延期成本高昂，在早期规划时，保留充分的测试时间非常重要。

作者建议进度安排：

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

以上就是《人月神话》第二章 —— 人月神话，前三节所讲述的内容

在本章中，作者试图告诉我们，项目之所以延期，很大部分原因是因为项目在最初的计划阶段，就错误的估计了项目进度。

管理人员很容易会认为项目功能完成就意味着开发完成了，没有为测试阶段安排较长时间的意识，往往测试的时间只能占到项目周期的 1/8 甚至更少。这明显是犯了乐观主义的错误，项目管理人员甚至比开发人员更加乐观。

如果不是站在专业的角度上，似乎很难理解测试阶段所花的时间，更难理解的是为什么增加人手不能让项目进度加快。

转自 fourn - learnku.com