目录
- 一、乐观主义（The Optimism）
- 核心观点
- Brooks 的判断
- 现实问题
- Brooks 的结论
- 二、人月（The Mythical Man-Month）
- 核心观点
- 为什么“加人反而更慢”
- 2️⃣ 沟通成本指数级增长
- 三、系统测试（System Testing）
- 核心观点
- Brooks 的关键论断
- 系统测试为何如此痛苦
- 1️⃣ 错误集中爆发
- 2️⃣ 修复成本极高
- 3️⃣ 进度被严重低估
- Brooks 的结论
一句话总结 Brooks：
软件工程失败，几乎总是因为人类对复杂系统的认知能力被高估。
| 主题 | 表面问题 | 本质原因 |
|---|---|---|
| 乐观主义 | 低估工期 | 低估系统复杂性 |
| 人月 | 加人无效 | 忽略沟通与依赖成本 |
| 系统测试 | 后期失控 | 早期概念不一致 |
一、乐观主义（The Optimism）
核心观点
软件项目的最大敌人不是技术，而是系统性的乐观偏差。
Brooks 的判断
软件工程师天然乐观，倾向于相信：
- 逻辑问题是“可以被完全理解的”
- 编码完成 ≈ 项目完成
- 剩余工作是线性的、可压缩的
现实问题
-
隐藏复杂性被严重低估
- 异常路径
- 边界条件
- 兼容性、集成、配置问题
-
“90% 综合症”
- 项目长期停留在“已完成 90%”
- 最后 10% 实际消耗与前 90% 相当甚至更多
-
进度计划建立在“最好情况”
- 计划假设“没有返工”
- 计划忽略沟通、测试、文档、部署成本
Brooks 的结论
软件项目延期，不是偶然事件，而是系统性必然结果。
管理启示
- 必须假设：设计会返工、实现会出错、测试会暴露结构性问题
- 计划应基于“最可能情况”，而非“理想情况”
二、人月（The Mythical Man-Month）
核心观点
“人月”不是可以任意线性叠加的资源单位。
Adding manpower to a late software project makes it later.
为什么“加人反而更慢”
因此我认为用人月作为
衡量一项工作的规模是一个危险和带有欺骗性的神话。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助（图 2.2）。无论多
少个母亲，孕育一个生命都需要十个月。由于调试、测试的次序特性，许多软件都具有这种
特征，
因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流
的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，
实际上是延长了，而不是缩短了时间进度。
2️⃣ 沟通成本指数级增长
- n 人团队，沟通路径为 n(n−1)/2
- 新人加入 → 老人被迫暂停生产力进行培训
三、系统测试（System Testing）
核心观点
在时间进度中，顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到
的牵涉更彻底。而且，要求的时间依赖于所遇到的错误、缺陷数量以及捕捉它们的程度。理
论上，缺陷的数量应该为零。但是，由于我们的乐观主义，通常实际出现的缺陷数量比预料
的要多得多。因此，系统测试进度的安排常常是编程中最不合理的部分。
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成
Brooks 的关键论断
系统测试阶段暴露的问题，往往不是实现错误，而是设计错误。
系统测试为何如此痛苦
1️⃣ 错误集中爆发
- 单元测试通过
- 模块测试通过
- 系统集成后大量失败
原因在于：
- 接口假设不一致
- 状态机理解不同
- 边界条件未统一定义
2️⃣ 修复成本极高
- 一个系统级 bug
→ 需求、设计、代码、测试全部返工
3️⃣ 进度被严重低估
- 测试与调试并非线性
- 修一个 bug 会引入新 bug
Brooks 的结论
- 系统测试是项目后期进度不可控的根源
- 测试阶段不是“尾声”，而是“第二次开发高峰”
管理启示
- 系统测试时间必须显著高估
- 尽可能早做集成（early integration）
- 通过清晰接口与文档减少系统级误解