第一、缺乏合理的进度安排
这是导致项目滞后的最主要的原因。首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。
第二.它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。
第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。
最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。
第二、需求的变化
从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。
文章来源于领测软件测试网 https://www.ltesting.net/
