刘天北
2002年10月
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, 1995 Addison-Wesley, 322 pp
从尺寸说起
豆豆先生（Mr. Bean）赞许惠斯勒的《画家母亲的肖像》，首先谈的一点就是：“这幅画比较大（quite big），所以了不起（excellent）”。这种批评套路，中国古已有之：品茶时赞美“热得好”就是。今天我们谈谈Brooks的《The Mythical Man-Month》（中译为“人月神话”，下简称MMM），也效法英国来的专家，从尺寸说起：这本书的一个突出优点，在于它比较小。
小有两点，一是开本，一是页数。尼采说，我的野心是用十句话说完别人一本书才能说清的事（他还加了一句——甚或是，一本书都说不清的事）。可是对于出版工业，这样的野心家不要也罢。多数书长，还是因为所涉及的领域本身头绪众多，不过总可以用得上法国人的俏皮话：他没有时间往短里写。把书写短不是人人都可以办到的，这需要良好的分寸感和结构感——都是很难在匆忙的IT从业者中找到的素质。是以一般技术书籍，多为人高马大，卷帙繁浩（当然还有国内影印版的惯常做法，把原来的大开本缩印成小兄弟，但考虑到增加的阅读难度，结果并没有想象的那么经济）。“大”，对于书——尤其是技术书——来说，不见得就“了不起”。以我个人的阅读习惯，多于五百页、开本又超过“大32开”的技术专著，那就只能当字典查，又好比皇宫里的大龄宫女，偶一调情也可，若要三千宠爱集一身，不啻为非分之想。本来一卷在手，有如软玉生香在抱，总以“轻”、“薄”为妙，若是庞然巨物，体态狼伉，未免让人产生心理障碍（借此一角向通读了《C++ Primer》的各位致意：你们都可以去做《大内密探零零发》里艳福齐天的皇上）。眼下说的这本MMM，正是技术书中的赵飞燕，可作字面意义上的掌上舞：大32的开本，算上注释、索引共332页，要紧的是，每章前的大量篇幅留给题图和题记， 19章下来，实在要读的内容不到200页。
如果决定读这本书，你也许可以参照我个人的经验做出时间预算：并非出于固定的读书计划，而是为了谋杀早晨巴士上的无聊时间，我选中了这本相貌可人、插图众多的MMM（它的前任似乎是袖珍本的斯各特船长传）。在前一周的周日下午我兴味盎然地覆盖了书末的三章：后记（“The MMM after 20 years"）、作者著名的单篇论文《没有银弹（No Silver Bullet）》和《再论没有银弹（No Silver Bullet Refired）》；这之后，第1章以下的若干章大约以每次1章半到2章的速度平均分布在5次车中颠簸的早高峰时间（每次约35至40分钟，并有一次坐过站）；最后，一个睡眼惺忪的周六上午让我完成了其余部分——我没法相信，这种“休闲”的阅读形式适用于任何一本其他的技术“名著”（可能的例外是《Peopleware》，我们一会儿还会谈到它）——或许你明早会带上本《Planning XP》试试？。
美味的分析
那么，除了小，这书还有什么好处？对，再就是：它比较好读。我看书也纯粹是“以貌取人”，外表即是一切（法国人说：皮肤是人最深刻的部分）。就像饭菜， “好吃”就好，营养等等在我辈老饕看来，还是第二义，而出于“精神食粮”这话的本意，“好读”也该是对书的最高赞许。
好读有两层意思，读起来容易，和读起来可口。小书不都易读（听说过《逻辑哲学论》？），易读的书也不都可口（有些易读则易读矣，但就好像小儿止咳糖浆，来多了就是对你智力的侮辱——还用提余秋雨老师吗？）但对于一本技术书而言，把自己的主题讲清楚了，而且还易读，也是了不起的成就。好些人写书，一味在“内在美”上下功夫，殊不知，“可接近性”才是首要的一环：我们不也说“可口”、“可人儿”吗？“可”（也是accessibility里的ability）最要紧。
回到正题，谈谈全书的结构：我手上这本MMM的二十年纪念版（Anniversary Edition），共19章（另有简短的前言——初版和再版各一篇——和尾声）。其中，第1到15章是初版内容，最长的一章17页，最短的第五章刨去题图和题记，不过薄薄两张半纸而已。作者称这些章节为“随笔（essays）”，每章各自处理相对独立的主题（“人月”问题、软件项目的人员构成、开发中的交流、文档、排错等等），因而你基本可以不顾及章节间的联系，单独从你感兴趣的任何段落入手。书末的四章里，第18章“Proposition of MMM：True or False?”是对之前各章所有观点的一个列表——一个非常便于翻检和温习的设置；其他的三章（对于“银弹”的两篇讨论和后记）篇幅在二十到四十页，值得专门对待。对于一本初版于多年前的技术书籍，作者并没有逐条修订原有的内容，而选择了重印这些章节，同时在后记中根据二十年来的技术上和认识上的变化检讨得失。
现在，你大概能模糊地看到这本书的样子：很薄，随手翻上去每章很短，并包含大量整页的插图（从侧面看，书页的颜色黑白参差）。换言之，可读性首先来自于外表，你拿起它，马上就感到美味当前。
然后你会注意到书的风格。关于原版技术书的语言风格，我曾经在别处做过一个区分：可读的/可翻译的（对另一对为人熟知的法国概念的蹩脚模仿）。“可读的”风格主要出现在用母语写作的作家笔下。他们能够自如地使用语言中的元素，几乎总能找到对特定概念最合适的表达。这些表达，往往植根于该语言自身，因此很难转换为另一种语言。比如本书作者给讨论“系统空间限制”的一章的标题是“ten pounds in five-pound sack”。对任何具备高考英语水平的读者，这里的意思都非常直观，但是谁能轻易地给出它的中文等价物？“削足适履” ？（我碰巧知道中译本就是这么翻译的。） “五磅的麻袋装十磅”？另一方面，“可翻译的”文本则多为移民作家的产物。对于一个概念，他们缺乏“自然的”表达方式。他们在用别人的语言，一串串的词像临时借用的家具一样摆放那里。你可以简单地逐字翻译这样的文本，甚至可以采用机器翻译而不会犯大错误（从Jacobson et al的OOSE摘引随便一句：“When strong semantics are provided at the behavioral description level for all of these fundamental issues, they radically affect the selection of an appropriate resource structure.”），但是无论译或不译，都很难马上明白他说的是什么。当然，这只能是对实际情况的最简化的0阶模拟（一些喜欢在行文中加入俚语的本土作家几乎不能归入任何一边）。但是，当我说出“可读的”时，我首先想到的就是Brooks和另一位大师Martin Fowler。二者的风格具有不少共同之处：亲切、不卖弄，能用最普通的英语说明（有时是令我们的汉语绝望的）复杂问题。
本书的作者Brooks（也许应该说“小”布鲁克斯才对，因为他的全名是“Fredrick P. Brooks, Jr.”），曾担任IBM的大型机System/360及其操作系统OS/360的开发项目经理，被称为“S/360之父”，之后转入大学，执教多年，因而难能一见地在实际项目管理和教学上都具备世界级水平。在离开IBM近十年之后（1975年），他根据大量切身实践和教学经验写出了本书，在风格上，也兼具教师的醇厚耐心和工程师的技术素质。我个人最受益于书中随处可见的精彩的比喻。仅仅举几个例子：“焦油坑”、“大教堂”、“外科手术队伍”、“银弹”，就我记忆而言，几乎每一个都是对所指对象最贴切的形容。而这些隐喻的光彩，又通过众多题图、题记（有时不失幽默）的反射，获得了熠熠生辉的效果。
在很多情况下，过分追求“幽默感”也会产生止咳糖浆式的效果。典型的例子是Peopleware。与MMM相比，那本书总是给我一种推销员教材的印象。二书作者技术背景（我不认为DeMarco们曾参加过严肃的软件项目）、宗教背景的不同（Brooks是位虔诚的基督徒）也许可以解释卖弄和朴实、空洞和厚重之间的差距。
来自法式餐馆、手术台和狼人的启示
让我们回顾豆豆本人的批评实践。在我看来，它具备难以错认的形式主义特征：主要考虑“外在”的、形式的（比如画的大小）要素，而忽略作品实际再现的内容——我们记得豆豆唯一一次提及画中的那位老太太时的措辞：停在仙人掌上的、丑恶的老蝙蝠（"a hideous old bat who looks like she's got a cactus lodged up her backside"）。我也要采用这样的策略吗？读者们（我设想，看到这篇书评的各位多数是技术专家）恐怕会讥之为买椟还珠，另外，MMM的内容也远比“老蝙蝠”更有可谈之处。但即便如此，逐一考察书中的观点也是不现实的：首先，没有人比作者已经做过的更好，如果你确实需要，不如去看原书第18章；其次，全书并没有一个一以贯之的中心思想可以提取，对于比如说沟通、文档、排错、工具等领域，每一个都值得专文仔细讨论。经过考虑，我决定谈谈那些无需我重读原书就可以回想起来的内容——这也就是经过我的巴士阅读实践（基本上是一个高通滤波过程）幸存下来的精华成分。
人月
首先是“人月（man-month）”。熟悉软件项目管理的各位肯定清楚，人们常常根据人月来估计工作量（并相应收费），比如一个项目五人两月完成，那么总工作量就是10人月。本书以此命名，套用唱片工业的术语，可以说“人月神话”是本“专辑”中主打篇目，而除了以之为标题的第二章之外，并没有太多内容与此有关。
称之为“神话”，作者的用意也并非完全否定作为计量方法的人月，而是要厘清这个概念中隐含的种种错觉。根据我勤勉而不可靠的记忆，这里的主要论断包括：1. 人/月之间不能换算，换言之，两人做五个月完成，不等于说五人做两个月就能完成；2.（也是最有争议的一点）在项目后期增加人手，只能使工期进一步推迟；3.项目越大，单位工作需要的人月越多。或者说，归根结蒂，作者要粉碎的是“人月”概念可以线性把握的神话：无论是开发人员的人数上，还是工作量本身上的变化，都可能导致最终完成时间的非线性变化。作者的戏剧性表述是：Adding manpower to a late software project makes it even later. 这个观点事实上并非像它看上去那么有挑衅性，而作者在初版以及后记中，都表示这包含了合理的夸张，后记里甚至援引进一步的研究表示，增加人手不一定会使工期进一步推迟，不过肯定会使工程效率进一步降低——而如果一定要增加人手，越早越好。
得出这样的结论，主要的考虑是增加人手带来的隐性花费（人员培训、多人工作时的通信成本等等）以及项目进程中存在的无法逾越的关键路径（crucial path）。对于项目管理人员来说，这应该已经是一个不言而喻的真理。但由于最终决策者的压力，实际项目中却往往会发生与此违背的情况。作者把一份法式餐厅菜单塞进了书中作为题图，我也建议大家学会菜单上的那个句子：Faire de la bonne cuisine demande un certain temps. Si on vous fait attendre, c'est pour mieux vous servir, et vous plaire（做好菜需要一定的时间。如果人家让您多等会儿，那是为了让您最后吃得高兴。） 对于说法语的客户/老板，这会是一个好的搪塞。
概念完整性
如果一定要找到贯穿全书的概念的话，“概念完整性（conceptual integrity）”可能算是一个。宁可少添加一些七七八八的功能（anomalous features）,也应该保证，整个系统体现的是完整的一套设计理念 ：这是引入概念完整性的含义。概念完整性的受益者包括最终用户、系统开发者、培训员和服务人员。概念完整性保持得好的系统更易用，需要较短的培训时间和学习时间，同时也更易于开发。但是在软件生产的实践中，各级决策者都很容易产生强调 “功能”而忽视概念完整性的倾向。因此我们看到了太多包含大量“功能”，而就整体而言不知所云的系统，也出现过太多次由于一两个附加功能的实现难度而导致整个系统开发推迟、甚至难产的事例。
所以作者提出，概念完整性是系统设计中最重要的考虑。在保证概念完整性的各方面中，我认为作者提出的两点最为有趣。第一，要克服系统的“第二版效应（the second system effect）”。一个系统设计师在设计第一版系统时，往往出于较弱的自信心以及量力而行的考虑，会尽量剪裁要实现的功能数量。而当第一版系统成功发布，开始第二版的设计时，随着自信心的增强，大量以前被压制的提议都会重现，设计师在塞入新的功能时也会不再那么保守。这很可能导致一个臃肿而缺乏概念完整性的第二版系统（作者的1995年举的例子是Windows 31之后的Windows NT）。第二，整个项目团队的有效组织有助于保证概念完整性。首先，要区分产品人员和开发人员，architect和implementer。这里所说的architect相当于一般而言的产品经理。只有他以及少数的几个人能确定整个的产品需求，而不应把即使是最细微的需求留给开发人员确定。在需求确定的过程中，多次反复，包括来自开发人员的反馈都是必要的，但为确保概念完整性，做出决定的必须是少数，甚至一个人。另外，在开发中可以考虑“外科手术式的”开发团队，即，由唯一的“手术师”（技术大拿）以及多个助手、测试员、联络人员、文档/工具/配置管理员、秘书等组成的队伍。显然无论是产品/开发人员的区分，还是外科手术式队伍的引入，核心原则都是1）职能细分；2）将高要求的工作集中在少数人手中。事实上，作者在其他的章节里说过，提高软件项目的质量的最好办法之一，就是找到合适的人。“伟大”的设计师和普通设计师之间的差别，比采用任何先进工具/方法论/管理模式前后的差别都要大。
银弹和其他
另外，增补部分中的“银弹”是作者独创的又一个概念。在古代的狼人传说中，只有用银质子弹才能制服这些举止无常的怪兽。因此作者也用“银弹”一词，命名人们渴望找到的制服软件项目这头难缠的怪兽的法宝。“没有银弹”意味着，没有任何一种方法（无论技术上的或是管理上的），单单采取它就能将现有的软件开发生产率（可靠度/简洁度）提高一个数量级。
作者的论证是简洁而（在我看来）有效的：软件开发的困难来自两个方面：本质的和偶然的（类似于经院哲学中的本质/偶性的对立）。本质的困难是软件开发本身所固有的，无法用任何方式取消的，而偶然的困难是其中的非本质因素，可以通过引入新工具、方法论或管理模式来消除。关键在于，只要本质的困难在软件开发中消耗百分之十以上的工作量，则即使全部消除偶然困难也不可能使生产率提高10倍。
就像作者其他很多论证一样，读完关于银弹的部分我们或者会说“本来就是这样，这还用说”，或者会说“这么简单的事，我以前怎么没有想到”。正是这种介乎漠视和震惊之间的摇摆体现了这些论断的价值：它们也许在理论上已经是被过分强调、被超越、被唾弃的了，但即便如此，在实践中我们往往连这些基本的原则都会完全不顾。对我们而言，MMM或许首先是一本关于态度的书。它指认的问题首先是，对待软件开发工作时应采取怎样的态度。正是因为某种态度，我们才会热衷于寻找解决一切问题的银弹（RUP也好，CMM也好，XP/Agile也好）而从未诚心诚意地贯彻其中任何一个原则；我们才会急于在系统中塞入一个又一个的功能，无视用户使用时的实际效果；我们才会无法相信自己能够组成“外科手术式”的团队，无法找到不做产品设计的开发人员；我们才会一次次接受形形色色的人月调整，最后把一个个项目带进了“焦油坑”。
据我看来，软件工程首先是一种缓慢的艺术。在这中间，筹划、交流、冥想以及迭代占有很大比重，同样（如果不是更重要的），错位、反复甚至离题也应据有一席之地。即便强调工程的可控性，也难以排除这些必要的环节（记得法式餐馆的例子？）。我们所能做的，是给它们足够的时间和容忍（你知道我不是指纵容延期）。
Brooks在书中提出的两组时间比例也许值得留意：一个“能转（ready to run）”的程序（program）要变成程序产品（programming product）需要3倍于编程的时间；同样，能转的程序变成程序系统（programming system）也需要3倍的时间。准此，则要获得程序系统产品（programming systems product——有点拗口，但仔细想想，还可以？），需要9倍于编写“能转”的程序的时间。另外，他在提到工期规划时说，整个工期的三分之一给计划（planning），六分之一编码（coding），四分之一组件测试和早期系统测试（component test and early system test），最后四分之一系统测试。
类似的划分，远比我们常见的各种方法论中的“里程碑”粗糙得多，但是，有多少人在实践中相信编码应只占整个工期的六分之一甚至九分之一？是否仍是“态度”的原因使我们失去了缓慢工作的能力？我们能把这种态度命名为“浮躁”吗？当所有竞争者都许诺只用那六分之一就能完成整个项目的时候，你能坚持那个“一”吗？我们能像提高气功境界那样，从一种态度跃迁到另一种吗？软件开发是一种气功吗？外科手术、银弹和法国菜都是气功吗？狼人能用气功治好吗？气功也能用人月估计吗？豆豆和老蝙蝠，谁更像狼人？狼人也会浮躁吗？浮躁的狼人究竟更需要气功还是银弹？还是书评？一篇豆豆式的书评？
尾声
写到这里，我愿意介绍我手头这本MMM的由来。打开书皮，我能看到封底处“Low Price Edition (LPE) authorized for sales only in India, Bangladesh, Pakistan, Nepal, Sri Lanka and Maldives”的字样。原有的书店标签（我印象中是“Graham，250rs”）不知什么时候脱落了。但即使缺乏这个标签，仅仅“LPE”还是能让我回想起在班加罗尔Graham书店度过的那个匆忙的黄昏：第三或四层是技术专区——我开始只找到了Jacobson们的OOSE（有点困惑于复杂的书店布局）——看到另外一人手中的Software Project Survival Guide——我求助于一个店员，他立刻拿给我那本书，和一本MMM——另一个店员看到它们，又递来一本Peopleware...
本文的完成，主要与我一次偶然的阅读有关，与一些论坛中朋友们对MMM的热衷和猜想有关，而与该书中文版本的推出可能只有间接的关系。我无意以此给这个译本作任何广告（我在别处谈过我对中文翻译的态度），当然更无意作反广告。不过，如果现在手头没有这本书的话（一个不幸的假设），我会到书店翻翻那个译本，看看插图复制的质量（尤其是那些铜版画——LPE能让我数清狼人脚爪上的毛），再看看书后还有没有注释和索引。仍然是那些外在的、肤浅的因素会决定我是否购买，就像在任何一个豆豆式书评的作者那里一样。
参考资料
* The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, 1995 Addison-Wesley
* Peopleware : Productive Projects and Teams, 2nd Ed., by Tom Demarco, Timothy R. Lister, 1999 Dorset House
* Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar Jacobson et al, 1992 Addison-Wesley
* Bean: The Movie, by Mel Smith (Director), 1997
