美酒的酿造需要年头，美食的烹调需要时间；片刻等待，更多美味，更多享受。
- 新奥尔良 Antoine 餐厅的菜单
Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.
- MENU OF RESTAURANT ANTOINE, NEW ORLEANS
导致项目延期的主要原因
- 错误的预估，或者说过于乐观的预估。
- 以为人月可以互换
- 未坚持持续估算
- 未坚持进度跟踪
- 失控之后无脑堆人月，导致更加失控
关于乐观主义
实践出真知
对于创造者，只有在实现的过程中，才能发现我们构思的不完整性和不一致性。
任务数量趋近于无穷大，正常概率趋近于0
在单个的任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
关于人月
一言蔽之
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流（图 2.1）。这在割小麦或收获棉花的工作是可行的；而在系统编程中近乎不可能。
计算公式
$$ \begin{matrix} n(n-1)/2 \end{matrix} $$
一对一交流的情况下，三个人的工作量是两个人的三倍，四 个人则是两个人的六倍。而对于需要在三四个人之间召开会议、进行协商、一同解决的问题， 情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作 用。
关于测试
测试一定要未雨绸缪，不然就是掩耳盗铃
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
1/3 计划 (33.3%) 1/6 编码 (16.6%) 1/4 构件测试和早期系统测试 (25%) 1/4 系统测试，所有的构件已完成 (25%)
关于估算
这主要需要老道的经验、充足的勇气和不变的坚持
在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，
确信自己的经验和直觉总比从期望派生出的结果要强得多。
关于救灾
灾难发生后如何应对
介于堆人月已经被否决，比较行之有效的有以下两点
- 重新安排进度。我喜欢 P.Fagg，一个具有丰富经验的硬件工程师的忠告：“避免小 的偏差（Take no small slips）”。也就是说，在新的进度安排中分配充分的时间，以确保 工作能仔细、彻底地完成，从而无需重新确定时间进度表。
- 削减任务。在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进 行削减。当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。项目经理的相 应措施是仔细、正式地调整项目，重新安排进度；或者是默默地注视着任务项由于轻率的设 计和不完整的测试而被剪除。