第2章：人月神话（The Mythical Man-Month）

一、导读

1.1 本章学习目标

第2章提出了软件工程中最著名的定律之一——Brooks 定律：向一个已经延期的软件项目增加人手，只会使其更加延期。

1.2 为什么第二章如此重要

"人月"是一个危险的度量单位。它暗示人和月可以互换，但事实上，软件项目中的人和时间是不可互换的。

1.3 核心问题引导

为什么人月是一个神话般的度量？

Brooks 定律的本质是什么？

沟通成本如何随团队规模增长？

如何正确估算软件项目的工作量？

二、核心概念详解

2.1 人月的谬误

"人月"暗示人和月可以互换：10个人1个月 = 1个人10个月。但这在软件项目中是错误的，因为：

某些任务不可并行：9个女人不能让怀孕时间缩短到1个月。

培训成本：新成员需要老成员花时间培训。

沟通成本：团队越大，沟通渠道越多。

2.2 Brooks 定律

向一个已经延期的项目增加人手，只会使其更加延期。

原因：

培训开销：新成员需要时间上手。

沟通成本增加：$n$ 个人的沟通渠道为 $n(n-1)/2$。

任务分解限制：很多任务不可并行。

2.3 沟通成本模型

团队规模    沟通渠道    相对效率
  5           10         100%
  10          45          80%
  20         190          55%
  50        1225          30%
 100        4950          15%

三、实战案例

3.1 项目加速的陷阱

场景：项目延期 3 个月

管理层方案：增加 50% 人手

实际结果：
- 新成员培训：4 周
- 沟通成本增加 2 倍
- 代码合并冲突增加 3 倍
- 最终：又延期了 2 个月

四、本章小结

Brooks 定律揭示了软件项目管理的核心悖论：人月不可互换，增加人手往往适得其反。正确的项目管理应该关注任务分解、风险控制和团队效率。

五、思考与练习

什么类型的任务可以并行？什么不可以？

如何估算沟通成本？

如何在不增加人手的情况下加速项目？

Brooks 定律在敏捷开发中是否仍然适用？

如何正确估算软件项目的工作量？