人月神话之第二章人月神话

在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他因素加起来的影响还要大。导致这种灾难如此普遍的原因又是什么？首先，我们对估算技术缺乏有效的研究，更加严肃地说它反映了一种悄无声息但并不真实的假设---一切都将运行良好。第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度和工作量互相混淆。第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续的估算这项工作。第四，对进度缺少跟踪和监督。在其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是大胆的革新。第五，当意识到进度的偏移的时候，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。

系统编程的进度安排背后的第一个错误假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。对于这种弥漫在编程人员中的乐观主义，理应受到慎重的分析。Dorothy Sayers在她的《创造者的思想》（The Mind of the Maker）一书中，将创造性活动分为三个阶段：构思、实现和交流。书籍、计算机或程序的存在，首先是作为一个构思或模型出现在作者的脑海中，它与时间和空间无关。接着，借助钢笔、墨水、纸张，或者电线、硅片和铁氧体，在现实的时间和空间中实现它们。然后，当某人阅读书籍、使用计算机和运行程序的时候，他与作者的思想互相沟通，创造过程从而得以结束。

当一件东西不顺应“我们”设定的思路，其实，这只不过是我们的骄傲使判断带上了主观主义色彩。在单个的任务中，“一切都将运行正常”的假设在进度上具有可实现性。因为所遇到的延迟是一个概率分布曲线，“不会延迟”具有限定的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工程，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于零。

成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。我们认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话，它暗示着人员数量和时间是可以互相替换的。人数和时间的互换仅仅适用于以下情况：某个任务可以分解为给参与人员，并且他们之间不需要相互的交流。这在割小麦或者收货棉花的工作中是可行的；而在系统编程中近乎不可能。软件开发本质上是一项系统工作----错综复杂关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间，从而，增加更多的人手，实际上是延长了而不是缩短了时间进度。

在进度安排中，由于顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到的牵涉更彻底。而且，需要的时间依赖于所遇到的错误、缺陷的数量及其难以捕捉的成程度。理论上，缺陷的数量比预料的要多得多。因此，系统测试进度的安排常常是编程中最不合理的部分。特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快要完成的时候。直到接近项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。另外，此时此刻的延迟具有不同寻常的、严重的财务和心理上的反应。在此之前，项目已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更为严重的是，在用软件支持其他商业活动（计算机硬件运送、新设备操作等）的情况下，若在即将发布时出现延误，所付出的二次商业代价是非常高昂的。实际上，上述的二次成本远远高于其他开销。因此，在早期进度策划时，允许充分的系统测试是非常重要的。

计划三分之一，编程六分之一，构件测试和早期系统测试四分之一，系统测试，所有的构件都已经完成四分之一。

简化的Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。

这就是去除了神话色彩的人月。项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。从这两个数值可以推算出进度表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度安排。总之，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他因素加起来的影响还要大。