三、《人月神话》是预言了未来还是控制了未来？
事实是：我们现在的很多工程知识，——无论是从书上看到的，还是从实践中体验到的——大多未曾脱离《人月神话》之所言。
我在开篇中说《人月神话》“是一本可怕的书”。然而我认为真正的可怕之处在于：如今只要论及工程（且不要让人认为是离经叛道），那么所讲述的一定是Brooks的这样的经验以及由此推出的观点，或者在不违背这些经验和观点上的一些具体的实作方法！我们全然不顾书中所言是现象，还是本质的推论，或者只是现象归结的一个（未必正确的）答案。尽管这些答案大多数时候都如同预期地出现在你的现实工程中：
| **原文** | **基本含义** | **现实** |
| 规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要。(P46) | 重复所有基本要素，以便于单个的特性可能会被抽离出来进行讨论。 | RUP中的文档规范 |
| 将来的规格说明同时包括形式化和记叙性定义两种方式。(P46) | 用形式化来精确定义，用记叙性定义来补充说明。 | UML |
| 使用实现来作为一种定义的方式有一些优点……（但）可能更加过度地规定了外部功能。(P47) | 陈述实现并不是设计中规定外部功能的方法。 | UserCase不应指示或暗示实现的方法。 |
| 对软件系统的体系结构师而言，存在一种更加可爱的方法来分发和强制定义。对于建立模块间接口语法，而非语义时，它特别有用……(P48) | 寻求一种描述功能而不涉及实现的方法，来协助架构师陈述它们的设计。 | Interface |
| 项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分……(P54) | 项目工作手册应当有组织、有结构地陈述项目各个方面的细节。 | RUP中的文档规范 |
| 笨拙的文字归档工作确保了所有变更会被阅读，这正是工作手册要达到的目的。(P56) | 确保变更不会丢失。 | 需求管理系统或任务管理系统 |
| 是因为控制序更加复杂,所以需要更多的人员？或者因为它们被分派了过多的人员，所以要求有更多的模块？是因为复杂程度非常高，还是分配较多的人员，导致花费了更长的时间？没有人可以确定……(P64) | 随时关注生产率并控制它。 | 项目管理软件 |
| 但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金……(P75) | 以书面化的形式来制定计划，并且确保一些要素的准确性。 | 项目管理软件 |
| 试验性的系统必须被构建然后丢弃……(P77) | 做一个原型并准备好扔掉它。 | 原型过程 |
| 目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免……(P77) | 为变化而做出设计。 | 延长设计和迭代的周期。风险评估。 |
| 流程图是被吹捧得最过分的一种程序文档。事实上，很多程序甚至不需要流程图，很少有程序需要一页纸以上的流程图。 (P107) | 编程的结果产生流程图（以供讨论和分析），而不是对照着流程图进行编程。 | 代码回顾(review)与重构 |
| 试图把信息放在不同的文件中，并努力维持它们之间的同步，是一种非常费力不讨好的事情……(P108) | 文档应该与代码同步。 | 代码文档化。 |
| 没有银弹(P114) | 所有曾被认为是银弹的东西都被无情地否定了。 |
原文中还有许多类似的观点、现象和答案，都成为了现实工程中的既存现象。先民们所说的圣人以及通神者，皆因他们多数时候在正确地预言自己的现实。只有当这个“多数时候”变成少数的时候，先民们才会置疑圣人和通神者的能力。其实我们知道并没有预言未来的人，大多数时候是两种情形导致的假象：
- 他做出了正确的判断；
- 你主观地跟从了他对未来的设定。
后者是危险的。大师们预言了未来也就改变了未来，即便未来未必“应当”如同他所预言的那样。
但如果这种预言的前提不正确，那么未来必然脱离这种影响而回到它应该的状态上去。如同我们看到的另一些事实一样，有很多现象表明，我们正在回归工程本相的道路上摸索前进。我们也发现，在大多数情况下，先哲们的预言在实践中被印证着，只是偶尔“不太灵光”。下表则列出一些不同的例子：
|
**原Brooks所述相同的例子**
|
**不同的例子** | **注** |
| UML | AP：可以工作的软件重于求全责备的文档。 | 注1 |
| Interface | ||
| RUP | ||
| 需求管理系统／任务系统 |
代码走查，结对编程。
AP：人和交互重于过程和工具。
AP：客户合作重于合同谈判。
|
|
| 项目管理软件 | ||
| 质量管理／评估和工程化测量 | ||
| User Case要尽可能避免指示或暗示实现的方法 | 测试驱动从一开始就规定表现是什么，以及如何确认它。 | |
| 原型过程 | 迭代过程 | 注2 |
| 延长设计和迭代的周期 | 缩短周期使得变化来不及发生。 | |
| 编程的结果产生流程图（以供讨论和分析），而不是对照着流程图进行编程。 | 不强调具体代码实现方法的、设计过程中的流程图例。例如时序图。 | 注3 |
| 代码文档化。 | 通过工具来使代码与文档同步维护。 | |
| 所有曾被认为是银弹的东西都无情地否定了。 | 我们还是有成功的工程实践的。 |
注1：我例举了敏捷的一些观点，并不表明我是AP/XP的fans。AP/XP的问题另论，在这里，我只是说明存在一种不同的思想。
注2：Brooks后来承认“必须扔弃原型”是一个不太正确的观点。
注3：Brooks在这里没有犯错误，只是他所讨论的是狭义的流程图，而我们例举的时序图则更广义。
我们回顾上一小节，在《人月神话》中的那“31%的答案”的前提——也就是那7%的本质中，如下两项是明显存疑的（也是主要置疑）：
- 目标的本质：是大型工程，是系统项目，而不是程序
- 个体的本质：是私利性的
其实早就有人意识到个体的本质“未必全是私利的”，尊重这些个体就会带来一些效果。例如AP正是因为更尊重开发人员的个性与能力，以及相互间的合作而得到了效率的提升。
再进一步地说，既然Brooks设定了“大型工程或系统项目”这样的目标，并给出了一些答案。那么在“小那么一点点的”工程项目中，是不是这些答案就不必须了呢？例如Brooks的许多建议，对于某些目标——例如你要用为期三个月的时间开发一个的产品——就并不是很有效；或者根本无法实施——例如你的团队总共只有6个人，连“外科手术式的团队”都组织不起来。
Brooks的答案对于同样的目标，以及在他所述的“本质”未能发生改变时，还是比较有效（或有实施的可能性）。因此上述一些例外，总是在上述的“7%的本质”被否定或被改变的情况下获得的。因而我们提出的问题将是：“如何否定或改变”这些难以撼动的本质。然而在我看来，Brooks早已经在最佳位置上，给出了撬动它们的一个支点：
- Brooks认为构建“独立小型程序”与“编程系统产品”是不同的问题。
Brooks讨论的编程系统产品的规模到底有多大呢？我想至少应该是以IBM 360为参考的。不过书中在引用Joel Aron（IBM在马里兰州盖兹堡的系统技术主管）的例子时说，“大型意味着程序员的数目超过25人，将近30,000行的指令”。而按照《人月神话》的数据：人均效率800指令/人年，则这个“大型项目”应该需要1.5年才能完成。此外，还需要大约一倍的人工，来负责除开代码之外的测试、管理、文档和沟通等工作。
好的，如果你有一个“(至少)50人，开发一年半”的项目，那么你可以先接受Brooks的答案去实践一下：起码你可以有时间来讨论工程问题，也能够组建那样规模的团队。但是，难道只有这样的“大型工程”才算得工程，而“小那么一点点”的就不算吗？现实是，我们一方面在做着“小那么一点点的”工程项目，另一方面在听着整个业界喧嚣着“为更大规模的工程”而准备的工程理论。我们总在实践Brooks的“答案”或者“预言”，而忘却这些答案的前提：
- Brooks的经验源自对IBM 360等大型项目的实践与分析；
- Brooks所述的工程是要得到编程系统产品；
- Brooks认为编程系统产品的工作量可能是独立小型程序的9倍（在实现大致相同功能的情况下）。
事实上我们现在的软件工程的发展是被驾驭了，而不是被预言了。从本质上来说，Brooks在《人月神话》中只是讨论了大型工程的实施，以及相应规模下的团队建设。而我们，便按照这样的设定来铺开了整个软件行业的工程化实施。
促成这种现状的，并不仅仅是一本书的力量，还在于商业的力量。因为只有在这样铺展开来的行业环境中，才可能有商业机会。——即使那些工程顾问与实施专家从来没有实施过“50人，开发一年半”这样的项目，只要他们能报出Brooks的名字，能谈及某些工具在应对“大型项目”中的成功经验，他们就已经成功了一半了。
为什么“敏捷”之初颇受争议？为什么敏捷对一些中小型的团队显得有效和可实施？为什么当这些争议被摆在眼前的成功平息之后，传统工程的理论家们却不忘恨恨地评上一句：那是一种不能（或难以）应用于大型工程的方法呢？！
因为如果大家都很“敏捷”，都只做比这些大型工程“小那么一点点”的工程，那么传统工程的专家们就失业了。反过来，只有把工程做大，大到“敏捷”失去了意义，而“庞大”变成了实质的时候，传统工程就可以为任何失败找到借口：看啊，Brooks就说过“没有银弹”嘛。
