项目滞后的的原因总结如下：

1. 对技术的估算缺乏研究，所有的时间估算都严重的依赖于一个假设 —— 一切都将良好的运行。显然这个假设并不总是成立的。
2. 我们的估算单位人月是有问题的，它错误的将进度和工作量互相混淆了。简单的说，在项目开发过程中并不是投入的人力越多，项目进度就会越快的，这是因为随着人力的投入，相关的培训时间、管理成本都随之增大，而程序功能的最小单元并不能像摘棉花那样细分。
3. 由于对评估缺乏信心，项目经历通常不会耐心的进行进度评估。这是人之常情，项目进度评估是一项永远也不可能正确的工作，因此在此付出的辛苦都将白费，鉴于此，谁还会耐心的去干好呢。
4. 对进度缺少跟踪和监督。跟踪和监督的界限没有办法划分清楚，完成编码算是完成了，当测试出bug的时候算是编码未完成，还是算作bug修改呢？由于缺乏明确的界限划分，使得跟踪和监督变得不太现实。
5. 当项目进度发生延期的时候，下意识的反应的增加人力。这是不太可取的，原因参见第二条。另外，在项目中期新加入的程序员更难融入到项目中，所花费的时间代价会更大。

所有的程序员都是乐观主义，可能是因为程序员都比较年轻，而年轻人都是比较乐观的。所有项目进度的评估背后都有一个假设：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。

编程是一件创造性的活动，而创造性活动分为三个阶段：构思、实现和交流。软件最初只是作者脑子里的一个构思，然后通过代码等来讲它实现，最后，当别人用到这个程序的时候通过文档、注释等可以与作者进行思想上的沟通。

项目进度的评估发生在构思和实现之间，在项目构思完成之后，项目实现之前。这个时侯，我们无法得知自己的构思是否存在缺陷（似乎说存在多大的缺陷更为合理），我们只能依赖于一切都将运作良好的假设。

由于假设并不成立，因此项目延期似乎是不可避免的。

在项目延期之后，我们下意识的反应是增加人力，这必然是一个错误。

测试可以帮我们找出项目存在的bug，理论上我们的bug数量应该为零，但是bug数量会很多，并且永远也不会有最后一个。

我们认为，越早的找出bug，对项目整体进度越有好处。因此项目的测试应该随着开发工作的开始而开始，这也许就是现在测试驱动开发的理论吧。

软件开发工程中各部分占的比重：

• 1/3    计划
• 1/6    编码
• 1/4    单元测试和早期的测试
• 1/4    系统集成测试

项目的测试工作占用了一般的工作量，由此可见测试的重要性。但实际开发过程中很少有为测试分配这么多时间的，这导致测试所花费的时间往往占去一多半的工作量，因为由于对测试的不够重视，通常会导致许多bug不能被及早的发现。

在系统开发过程中，除了测试，进度都能够基本保证。

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

本文转自齐师傅博客园博客，原文链接：http://www.cnblogs.com/youring2/p/3416155.html，如需转载请自行联系原作者