缺乏合理的进度安排是造成项目滞后的最主要原因
导致这种灾难的原因
-
对估算技术缺乏有效的研究
-
估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆
-
软件经理通常不会有耐心持续地估算这项工作
-
对进度缺少跟踪和监督
-
当意识到进度的偏移时，下意识的反应是增加人力
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。
十个母亲不能一个月孕育一个生命
相互之间交流的情况更糟一些。如果任务的每个部分必须分别与其他部分单独协作,则工作量按照n(n-1)/2递增。在一对一交流的情况下,3个人的工作量是2个人的3倍,4个人的工作量则是2个人的6倍。而对于需要在三、四个人之间召开会议、进行协商、一同解决的问题,情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用,此时我们会被带到如图2-4所示的境地。
在许多重要的方面,它与传统的进度安排方法不同:
-
(1)分配给计划的时间比平常的多。即便如此,其只是勉强产生详细和稳定的计划规格说明,并不足以容纳对全新技术的研究和探索;
-
(2)对所完成代码的调试和测试投入近一半的时间,这比平常的安排多很多;
-
(3)容易估计的部分,如编码,仅仅分配了1/6的时间
通过对传统项目进度安排的研究,我发现很少有项目允许为测试分配一半的时间,但大多数项目的测试实际上是花费了进度中一半的时间
它们中的许多项目,在系统测试之前还能保持进度。或者说,除了系统测试,进度基本能够保证。
特别需要指出的是,不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快完成的时候。直到接近项目的发布日期,才有人发现进度上的问题。因此,坏消息没有任何预兆,很晚才出现在客户和项目经理面前
另外,此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。
在此之前,项目已经配置了充足的人员,每天的人力成本也已经达到了最大的限度。更为严重的是,在用软件支持其他的商业活动(计算机硬件运送、新设备操作等)的情况下,若在即将发布时出现延误,所付出的二次商业代价是非常高昂的。实际上,上述的二次成本远远高于其他开销。因此,在早期进度策划时,允许充分的系统测试时间是非常重要的
重复产生的进度灾难
当一个软件项目落后于进度时
现在假定两个月之后,第一个里程碑没有达到(见图26)。项目经理面对的选择方案有哪些呢?
(1)假设任务必须按时完成。假设仅仅是任务的第一个部分估计不得当,如图2-6所示,则剩余了9个人月的工作量,时间还有两个月,即需要4.5个开发人员,所以需要在原来3个人的基础上增加2个人。
(2)假设任务必须按时完成。假设整个任务的估计偏少,如图2-7所示,那么还有18个人月的工作量,这样就需要2个月的时间和9个人,比原来计划的3人多了6人。
(3)重新安排进度。在新的进度安排中分配充分的时间,以确保工作能仔细、彻底地完成,从而无需重新确定时间进度表。
(4)削减任务。在现实情况中,当开发团队观察到进度的偏差时,总是倾向于对任务进行削减。当项目延期所导致的二次成本非常高时,这常常是唯一可行的方法。项目经理的相应措施是仔细、认真地调整项目,重新安排进度;或者默默地注视着任务由于轻率的设计和不完整的测试而被剪除。
在前两种情况下,坚持把不经调整的任务在4个月内完成将是灾难性的。考虑到重复生成的工作量,以第一种为例(见图28)不论在多么短的时间内,聘请到两名多么能干的新员工,他们都需要接受一位有经验的职员的培训。如果培训需要一个月的时间,那么3个人月将会投入到原有进度安排以外的工作中。另外,原先划分为3个部分的工作,会重新分解成5个部分;某些已经完成的工作必定会丢失,系统测试必然被延长。因此,在第3个月的月末,仍然残留着7个人月的工作,但此时只有5个有效的人月。如图2-8所示,产品交付还是会延期,如同没有增加任何人手(见图2-6)。
期望在4个月内完成项目,仅仅考虑培训的时间,不考虑任务的重新划分和额外的系统测试,在第2个月末需要增添4人,而不是2人。
如果考虑任务划分和系统测试的工作量,则还需要继续增加人手。到那时所拥有的就不是3人的队伍,而是7人以上的团队;并且小组的组织和任务的划分在类型上都不尽相同,这已经不是程度上的差异问题。
Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后