美酒的酿造需要年头，美食的烹调需要时间；片刻等待，更多美味，更多享受。
Good cooking takes time, if you are made to wait, it is to serve you better, and to please you...
在众从软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。导致这种灾难如此普遍的原因是什么呢？
1、乐观主义。我们对估算技术缺乏有效的研究，但都基于不真实的假设 - 一切都将动作良好。
2、人月互换。估算时隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
3、由于对自己的估算缺乏信心，没有耐心持续地进行估算并不断更新，调整
4、对进度缺少跟踪和监督。
5、重复产生的进度灾难。当意识到进度偏离时，下意识的反应是增加人力，但只是火上浇油，让事情更糟。
乐观主义
进度安排背后的第一个错误假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
《创造者的思想》一书中将创造性活动分为三个阶段：构思、实现和交流。对于创造者，只有在实现的过程中，才能发现我们构思的不完整性和不一致性。因此总会发现bug。
单个任务中，“一切都将运转正常”的假设在进度上具有可实现性。
然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于零。
事实上，我发现很多的项目，在项目管理中都没有识别出关键路径，这样的进度计划很难说是合理的。
人月
第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月。它暗示着人员数量和时间是可以相互替换的。
成本随人数和时间呈线性变化，但进度却并非如此。
当任务由于次序上的限制不能分解时，人手的添加对进度没有任何帮助。遗憾的是，很多软件开发工作都具有这种特征。即便工作可分解，也会增加相互沟通的工作量：培训和相互的交流。
系统测试
在进度安排中，顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到的牵涉更彻底。系统测试进度的安排常常是软件项目中最不合理的部分，这也往往是因为开发人员的盲目自信和乐观主义。
软件任务的进度安排，经验法则：
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成
为调试和测试，分配了一半的时间。因为延迟发生在项目快完成的时候，直到接近项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。更严重的是，项目后期的进度延误，成本非常高昂。
空泛的估算
为了满足顾客期望的日期而造成的不合理进度安排，在软件领域中比其他任何工程领域要普遍得多。
重复产生的进度灾难
当一个软件项目落后于进度时，通常的做法是什么呢？自然是加派人手。
向进度落后的项目中增加人手，只会使进度更加落后。这也是前面讲到的“人月”不能简单互换，增加了人手，需要考虑培训的时间，任务重新划分和额外的系统测试。
更重要的是，项目落后的真正原因是什么？如果是因为估算过于乐观，那还未完成的任务同样也太乐观估计。如仅仅按当前节点来评估将来的人力，并不是聪明的做法。
项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。