为什么软件项目普遍缺少合理的时间进度？
- 缺乏估算技术: 更严肃地说, 背后是一个悄无声息但不真实的假设--"一切都将运作良好";
- 单位错误: 估算技术隐含假设人和月可以互换, 把进度与工作量混为一谈;
- 缺乏信心: 因为对自己的估算没有信心, 经理没有耐心持续进行估算;
- 缺乏跟踪: 其他工程领域中经过验证的跟踪技术和监督程序, 在软件中常被视为无谓举动;
- 错误反应: 一发现进度偏移就加人, 像用汽油灭火, 进入灾难循环;
人月这个单位错在哪里？
- 可分解性差异: 人月互换只在"任务可分解且参与者无需交流"时成立, 例如割麦子、收棉花;
- 顺序限制: 调试、测试有次序特性, 无法分解; "无论多少个母亲, 孕育一个生命都需要十个月";
- 需要沟通时更差: 相同人月下, 靠加人缩短时间的最好情况, 也比不调整前更差;
- 结论: 项目时间依赖顺序限制, 人员数量依赖可并行子任务的数量, 两者共同决定进度表;
沟通成本如何随人数增长？
- 培训: 每个成员都要接受技术、项目目标和总体策略的培训, 不可分解, 随人数线性增长;
- 相互交流: 若每个部分都要与其他部分单独协作, 工作量按
n(n-1)/2 增长;
| 人数 n | 两两接口数 n(n-1)/2 | 相对 2 人 |
|---|
| 2 | 1 | 1× |
| 3 | 3 | 3× |
| 4 | 6 | 6× |
- 会议型协作: 需要三四人共同协商的问题更糟, 增加的沟通量可能完全抵消分解节省的时间;
- 结论: 软件开发本质是系统工作, 沟通量很快耗尽分解带来的收益, 加人反而延长进度;
为什么系统测试的进度最难安排？
- 依赖缺陷数: 所需时间取决于遇到的缺陷数量以及捕捉它们的程度;
- 乐观主义使然: 理论上缺陷应为零, 实际上通常远多于预料;
- 后果: 延迟发生在项目快完成时, 坏消息没有任何预兆;
- 二次代价: 此时人力已配足、日成本最高, 且延误会影响依赖软件的其他商业活动;
进度落后时加人为什么会更落后？
- 例子设定: 12 人月的任务, 3 人 4 个月, 每月末有里程碑 A、B、C、D;
- 情形一（局部低估）: 第 2 月末落后, 剩余 9 人月、2 个月, 需 4.5 人, 看似加 2 人即可;
- 真实成本: 新人要培训（若 1 个月, 消耗 3 人月）, 工作重新划分导致已完成部分丢失, 系统测试延长;
- 情形二（整体低估）: 剩余 18 人月, 需 9 人, 灾难更深;
- 结果: 到第 3 月末仍残留 7 人月而只有 5 个有效人月, 产品照旧延期, 且团队已变成 7 人以上、组织性质都不同;
Brooks法则的准确边界是什么？
- 法则: 向进度落后的项目中增加人手, 只会使进度更加落后;
- 加人从三方面增加总工作量: 任务重新分配本身及工作中断、培训新人员、额外的相互沟通;
- 20 年后的量化研究: Abdel-Hamid 与 Madnick 的结论是"总会增加成本, 但并不一定会使项目更加落后";
- 时机差异: 新成员立即带来需要数周弥补的负效应, 所以项目早期加人比后期加人安全;
- 作者态度: 仍然坚持这条简化法则, 作为警告经理避免"盲目、本能的修补措施"的经验法则;