《人月神话》(P2)错误的进度估计【转】

请注意,本文编写于 165 天前,最后修改于 165 天前,其中某些信息可能已经过时。

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

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

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

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

人月

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

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

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

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

系统测试

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

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

作者建议进度安排:

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

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

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

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

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

转自 fourn - learnku.com

添加新评论

评论列表