《人月神话》第2章：人月神话

美酒的酿造须要年头，美食的烹调须要时间；片刻等待，更多美味，更多享受。

Good cooking takes time, if you are made to wait, it is to serve you better, and to please you...

在众从软件项目中，缺少合理的进度安排是形成项目滞后的最主要缘由，它比其余全部因素加起来的影响还要大。致使这种灾难如此广泛的缘由是什么呢？

一、乐观主义。咱们对估算技术缺少有效的研究，但都基于不真实的假设 - 一切都将动做良好。

二、人月互换。估算时隐含地假设人和月能够互换，错误地将进度与工做量相互混淆。

三、因为对本身的估算缺少信心，没有耐心持续地进行估算并不断更新，调整

四、对进度缺乏跟踪和监督。

五、重复产生的进度灾难。当意识到进度偏离时，下意识的反应是增长人力，但只是火上浇油，让事情更糟。

乐观主义

进度安排背后的第一个错误假设是：一切都将运做良好，每一项任务仅花费它所“应该”花费的时间。

《创造者的思想》一书中将创造性活动分为三个阶段：构思、实现和交流。对于创造者，只有在实现的过程当中，才能发现咱们构思的不完整性和不一致性。所以总会发现bug。

单个任务中，“一切都将运转正常”的假设在进度上具备可实现性。

然而大型的编程工做，或多或少包含了不少任务，某些任务间还具备先后的次序，从而一切正常的几率变得很是小，甚至接近于零。

事实上，我发现不少的项目，在项目管理中都没有识别出关键路径，这样的进度计划很难说是合理的。

人月

第二个谬误的思考方式是在估计和进度安排中使用的工做量单位：人月。它暗示着人员数量和时间是能够相互替换的。

成本随人数和时间呈线性变化，但进度却并不是如此。

当任务因为次序上的限制不能分解时，人手的添加对进度没有任何帮助。遗憾的是，不少软件开发工做都具备这种特征。即使工做可分解，也会增长相互沟通的工做量：培训和相互的交流。

系统测试

在进度安排中，顺序限制所形成的影响，没有哪一个部分比单元调试和系统测试所受到的牵涉更完全。系统测试进度的安排经常是软件项目中最不合理的部分，这也每每是由于开发人员的盲目自信和乐观主义。

软件任务的进度安排，经验法则：

• 1/3 计划

• 1/6 编码

• 1/4 构件测试和早期系统测试

• 1/4 系统测试，全部的构件已完成

为调试和测试，分配了一半的时间。由于延迟发生在项目快完成的时候，直到接近项目的发布日期，才有人发现进度上的问题。所以，坏消息没有任何预兆，很晚才出如今客户和项目经理面前。更严重的是，项目后期的进度延误，成本很是高昂。

空泛的估算

为了知足顾客指望的日期而形成的不合理进度安排，在软件领域中比其余任何工程领域要广泛得多。

重复产生的进度灾难

当一个软件项目落后于进度时，一般的作法是什么呢？天然是加派人手。

向进度落后的项目中增长人手，只会使进度更加落后。这也是前面讲到的“人月”不能简单互换，增长了人手，须要考虑培训的时间，任务从新划分和额外的系统测试。

更重要的是，项目落后的真正缘由是什么？若是是由于估算过于乐观，那还未完成的任务一样也太乐观估计。如仅仅按当前节点来评估未来的人力，并非聪明的作法。

项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。