乐观主义
所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的
人；也可能是成百上千琐碎的挫折赶走了大多数人，只剩下了那些习惯上只关注结果的人；
还可能仅仅因为计算机还很年轻，程序员更加年轻，而年轻人总是些乐观主义者——无论是
什么样的程序，结果是勿庸置疑的：“这次它肯定会运行。”或者“我刚刚找出了最后一个错
误。”
所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花
费它所“应该”花费的时间。
对这种弥漫在编程人员中的乐观主义，理应受到慎重的分析。Dorothy Sayers 在她的
“The Mind of the Maker”一书中，将创造性活动分为三个阶段：构思、实现和交流。书
籍、计算机、或者程序的出现，首先是作为一个构思或模型出现在作者的脑海中，它与时间
和空间无关。接着，借助钢笔、墨水和纸，或者电线、硅片和铁氧体，在现实的时间和空间
中实现它们。然后，当某人阅读书本、使用计算机和运行程序的时候，他与作者的思想相互
沟通，从而创作过程得以结束。
计算机编程基于十分容易掌握的介质，编程人员通过非常纯粹的思维活动——
概念以及灵活的表现形式来开发程序。正由于介质的易于驾驭，我们期待在实现过程中不会
碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有 bug。也就
是说，我们的乐观主义并不应该是理所应当的。
系统测试
在时间进度中，顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到
的牵涉更彻底。而且，要求的时间依赖于所遇到的错误、缺陷数量以及捕捉它们的程度。理
论上，缺陷的数量应该为零。但是，由于我们的乐观主义，通常实际出现的缺陷数量比预料
的要多得多。因此，系统测试进度的安排常常是编程中最不合理的部分。
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
1/3 计划
1/6 编码
- 10 -
月1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成
在许多重要的方面，它与传统的进度安排方法不同：
1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说
明，也不足以容纳对全新技术的研究和摸索。
2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。
通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大
多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还
能保持进度。或者说，除了系统测试，进度基本能保证 2。
特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生
在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有
任何预兆，很晚才出现在客户和项目经理面前。
另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前，项目
已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更重要的是，当软件用
来支持其他的商业活动（计算机硬件到货，新设备、服务上线等等）时，这些活动延误出现
即将发布前，那么将付出相当高的商业代价。
实际上，上述的二次成本远远高于其他开销。因此，在早期进度策划时，允许充分的
系统测试时间是非常重要的。
空泛的估算
观察一下编程人员，你可能会发现，同厨师一样，某项任务的计划进度，可能受限于
顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。就像约好在两分钟内完成一个
煎蛋，看上去可能进行得非常好。但当它无法在两分钟内完成时，顾客只能选择等待或者生
吃煎蛋。软件顾客的情况类似。
厨师还有其他的选择：他可以把火开大，不过结果常常是无法“挽救”的煎蛋——一
面已经焦了，而另一面还是生的。
现在，我并不认为软件经理内在的勇气和坚持不如厨师，或者不如其他工程经理。但
为了满足顾客期望的日期而造成的不合理进度安排，在软件领域中却比其他的任何工程领域
要普遍得多。而且，非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的
直觉，这样的方式很难生产出健壮可靠和规避风险的估计。
显然我们需要两种解决方案。开发并推行生产率图表、缺陷率、估算规则等等，而整
个组织最终会从这些数据的共享上获益。
或者，在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，
确信自己的经验和直觉总比从期望派生出的结果要强得多。