人月神话

THE MYTHICAL MAN-MONTH 人月神话 FREDERICK P. BROOKS, JR. 翻译：Adams Wang 关于作者 Frederick P. Brooks，Jr . 是北卡罗来纳大学Kenan-Flagler 商学院计算机科学教育 北卡来罗来纳大学位于美国北卡来罗来纳州的查布尔希尔。Brooks 被认为是“IBM 36 0 系统之父”，他担任了360 系统项目经理，360 操作系统项目设计阶段的经理。 他、Bob Ev an s 和Erich Bloch 在1985 年获美国国家技术奖 （National Medal of Tec ho lo gy ）。早期，Brooks 曾担任I B M Stre tc h 和Harvest 计算机 系统结构师。 查布尔希尔，Brooks 博士在1号成立了计算机科学系 964 到1984年。 他曾在美国国家科技局和国防科技委员会任职。Brook s 目前的教学研究方向是计算 系统结构、分子模型绘图和虚拟环境。 1975年版献辞 两个人特别丰富我IBM 岁月的人： Thomas J. Watson, Jr. ， 他对人的关心在他的公司里仍然无处不在 和 Bob O. Evans， 他大胆的领导把工作变成了冒险。 1995年版献辞 致Nancy ， 上帝给我的礼物。 纪念版二十周年序言（Preface to the 20 th Anniversary Edition） 令我惊奇和高兴的是，《人月神话》在 20 年后继续流行，印数超过2.5万 。人 经常问，我在1 975 我仍然坚持哪些观点和建议，哪些观点已经改变， 它是如何改变的？尽管我在一些讲座中分析了这个问题，但我一直想把它写成一篇文章。 Peter Gordon 现在是A ddiso n- We sl ey 出版伙伴，他从1 980 年初和我一起工作。他不是。 耐心对我很有帮助。他建议我们准备一个纪念版。我们决定不修改原版， 只是原封不动地重印(除了一些小的修正)，用更新的想法来扩展。 第十六章重印一篇 986 年IF IP S 会议论文《没有银弹:软件工程的基础和次数》 问题。本文来自我在国防科学委员会主持军事软件研究时的经验。我当时的研究 合作伙伴，也是我的执行秘书，R obert L. P at rick 帮助我回忆和感受做过的软件项目 目。1987年，IEEE《计算机》杂志重印了这篇论文，使其传播得更广。 没有银弹被证明是煽动性的，它预测十年内没有任何编程技能可以给软件 生产率带来了数量级的提高。十年只剩下一年了，我的预测似乎很安全。没有银弹 文字上的激烈争论越来越多，比《人月神话》还要多。所以在第17章，我公开了一些 批评作了说明，并更新了在1986年提出的观点。 在准备《人月神话》的回顾和更新时，一直进行的软件工程研究和经验已经批评、证 真的否定了少数书中断言的观点，也影响了我。剥去辅助争论和数据后，粗略地看待这些观点 土地分类对我很有帮助。我在第18章列出了这些观点的总结，希望这些单调的陈述能够 引起争论和证据，然后得到证实、否炼。 第19 这篇文章是一篇更新的短文。读者应该注意的是，新观点不像原著那样来自我 个人经历。我在大学工作，不是在工业界，而是做小规模的项目，不是大项目。自1986年以来 多年来，我只教软件工程，不再做这项研究。我目前的研究领域是虚拟环境及其 应用。 在这次复习的准备过程中，我在软件工程领域找到了一些正在工作的朋友，征求他们的意见 - i - 以前的观点。他们愿意和我分享他们的想法，并仔细地对草稿提出意见，这让我再次受苦 启发Barry Bo eh m 、K en Broo ks 、Di ck Case 、Ja mes Coggins 、Tom Dema rc o 、J im McCarthy、Da vi d Pa rn as 、E ar l Wheeler 和Edward Yourdon 。感谢F ay Eard 对新的很好 技术加工了章节。 感谢我在国防科学委员会军事软件工作组的同事Gordon B el l 、B ru ce Buc ha na n 、R ick Hayes-Roth，特别是Da vi d Parnas，感谢他们的洞察力和生动的想法。Rebekah Bierly 对16 本章的论文进行了技术加工。我把软件问题分为基本和次要Nancy Greenwood Br oo ks 她在一篇文章中受到启发Su zu ki 这种分析方法应用于小提琴教育论文中。 在1 975 在年版的序言中，Addison-We sl ey s 出版社按规定不允许我向它的一些扮演了 感谢关键角色的员工。必须特别提到两个人的贡献:执行编辑Norm an Stanton 和美术 指导Herbert Boes。Bo es 设计了优雅的风格，他在评论中特别提到:页面的空白要宽，字要宽 身体和布局应该有想象力。更重要的是，他提出了至关重要的建议：在每一章的开头画一幅图片 电影(当时我只有焦油坑和兰斯大教堂的照片)。我花了一年时间才找到这些照片 但我总是感激这个建议。 Soli Deo gloria 愿神独得荣耀。 查珀尔希尔，北卡罗来纳 F . P . B . , J r . 1995年3 月 - ii - 第一版序言（Preface to the First Edition） 在许多方面，管理大型计算机编程项目与其他行业的大型项目非常相似——比大 大多数程序员认为它是相似的；在许多其他方面，它是不同的——比大多数专业经理认可的 差别更大。 这一领域的知识正在积累。AF IP S(美国信息处理协会联合会)有一些讨论 会议还出版了一些书籍和论文，但还没有形成系统阐述的方法。提供这样本书 反映个人观点的小书似乎是合适的。 虽然我原来从事计算机科学的编程方面的工作，但是在1956-1963 年间自动控制程序 当我开发高级语言编译器时，我主要参与硬件架构。 964 年，我 成为操作系统OS/360经理发现，前几年的进步改变了编程世界。 管理OS/360 虽然失败了，但发展是一个非常有帮助的经验。包括我的继任经理在内的团队 F. M. Tr apnell，有很多值得自豪的东西。那个系统包括了很多优秀的设计和实施，成功地 它被许多技术创新广泛复制，应用于许多领域，特别是与设备无关的输入。 现在很可靠，很有效，很普遍。 但并非所有的努力都是成功的。O S/360 用户很快就会发现它应该做得更多 好的。在控制过程中，设计和实现的缺陷尤其普遍，语言编译器要好得多。 这些缺陷发生在1964-196年 5 年的设计阶段，所以这一定是我的责任。此外，本产品发布推送 迟到了，需要的内存比计划多，成本是估计的几倍，第一次发布的时候也不是很好 地运行，直到发布了几次以后。 就像当初接受一样OS/360 协商任务时，1 965 年离开IBM 之后，我来到查珀尔希尔。 我开始分析OS /3 60 经验取决于你能否从中学到任何管理和技术教训。特别是，我想说 明System/360 硬件开发和OS/360 软件开发中的管理经验非常不同。Tom Wa tson 关 这本书是一个迟来的答案，为什么编程很难管理。 在这次探索中，我和 1964-65 年助理经理R.P.Case，还有1965-68 年的经理 F.M.Trapnell ，进行了长谈，从中受益良多。我对比了其他大型编程项目的经理的结论，包 括M.I.T. 的F.J.Corba to ，Bell 电话实验室V.Vyssots ky ，In te rnati on al Comput er s - iii - Limited 的Ch ar le s Po rtman ，苏联科学院西伯利亚分部计算实验室A.P.Ershov ，和IBM 的A.M.Pietrasanta 。 我自己的结论体现在以下文字中，给专业程序员、专业经理，尤其是程序员 业经理。 虽然写的是分离章节，但还是有一个中心论点，尤其是第二章- 7 章。简而言之，， 我相信由于人员分工，大型编程项目遇到的管理问题与小项目有很大的不同；我相信关键需求 它是为了保持产品本身的概念完整性。些章节讨论了困难和解决方案。后续章节讨论 其他方面的软件工程管理。 这一领域的文献不多，但传播广泛。因此，我试图给出参考资料来解释特定的知识 指导感兴趣的读者阅读其他有用的工作。许多朋友读过这本书的手稿，其中一些给了他们 出了很有帮助的意见。这些意见很有价值，但为了不打乱文字的流畅性，我把它们当作注解包 含在书中。 因为这本书不是课本，所有的参考文献和注释都放在书的末尾。建议读者在 第一次看的时候略去不看。 深切感谢S ara E lizabet h Moo re 小姐，David Wa gn er 先生，和Re be cc a Bur ri s 夫人， 他们帮助我准备了手稿。感谢Joseph C.Sloane 教授在图解方面的建议。 查珀尔希尔，北卡罗来纳 F . P . B . , J r 1974年10月 - iv - 目录（Contents） 二十周年纪念版序言（PREFACE TO THE 20 TH ANNIVERSAR Y EDITION）...................... I 第一版序言（PREFACE TO THE FIRST EDITION ）............................................................III 目录（CONTENTS）..................................................................................................................... V 焦油坑（THE TAR PIT）.............................................................................................................. 1 编程系统产品............................................................................................................................... 1 职业的乐趣............................................................................................................................... ....3 职业的苦恼............................................................................................................................... ....4 人月神话（THE MY THICAL MAN-MONTH）........................................................................... 6 乐观主义............................................................................................................................... ........7 人月............................................................................................................................... ................8 系统测试............................................................................................................................... ...... 10 空泛的估算............................................................................................................................... .. 11 重复产生的进度灾难................................................................................................................. 12 外科手术队伍（THE SURGICAL TEAM）............................................................................... 16 问题............................................................................................................................... .............. 16 M ILLS 的建议............................................................................................................................. 17 如何运作............................................................................................................................... ...... 20 团队的扩建............................................................................................................................... .. 21 贵族专制、民主政治和系统设计（AR IST OCRACY, DEMOCR ACY, AND SYSTEM DESIGN） ............................................................................................................................... ......................... 22 概念一致性............................................................................................................................... .. 22 获得概念的完整性..................................................................................................................... 23 贵族专制统治和民主政治......................................................................................................... 24 在等待时，实现人员应该做什么？......................................................................................... 26 画蛇添足（THE SECOND-SY STEM EFFECT ）...................................................................... 29 结构师的交互准则和机制......................................................................................................... 29 自律——开发第二个系统所带来的后果................................................................................. 30 贯彻执行（PA SSING THE WORD ）.......................................................................................... 33 文档化的规格说明——手册..................................................................................................... 33 形式化定义............................................................................................................................... .. 34 直接整合............................................................................................................................... ...... 36 会议和大会............................................................................................................................... .. 36 多重实现............................................................................................................................... ...... 38 - v - 电话日志............................................................................................................................... ...... 38 产品测试............................................................................................................................... ...... 38 为什么巴比伦塔会失败？（WHY DID THE TOWER OF BABEL F A IL? ）........................... 40 巴比伦塔的管理教训................................................................................................................. 41 大型编程项目中的交流............................................................................................................. 41 项目工作手册............................................................................................................................. 42 大型编程项目的组织架构......................................................................................................... 44 胸有成竹（CALLING THE SHOT ）.......................................................................................... 49 PORTMAN的数据........................................................................................................................50 ARON的数据.............................................................................................................................. 5 1 HARR的数据.............................................................................................................................. 5 1 OS/360 的数据........................................................................................................................... 53 C ORBATO 的数据........................................................................................................................53 削足适履（TEN POUND S IN A FIVE-POUND SACK ）.......................................................... 55 作为成本的程序空间................................................................................................................. 55 规模控制............................................................................................................................... ...... 56 空间技能............................................................................................................................... ...... 57 数据的表现形式是编程的根本................................................................................................. 58 提纲挈领（THE DOCUMENTA RY HYPOTHESIS）............................................................... 60 计算机产品的文档..................................................................................................................... 60 大学科系的文档......................................................................................................................... 62 软件项目的文档......................................................................................................................... 62 为什么要有正式的文档？......................................................................................................... 63 未雨绸缪（PLAN TO THROW ONE AWAY ）............................................................................64 试验性工厂和增大规模............................................................................................................. 64 唯一不变的就是变化本身......................................................................................................... 65 为变更计划系统......................................................................................................................... 66 为变更计划组织架构................................................................................................................. 66 前进两步，后退一步................................................................................................................. 68 前进一步，后退一步................................................................................................................. 69 干将莫邪（SHARP T OOLS）...................................................................................................... 71 目标机器............................................................................................................................... ...... 72 辅助机器和数据服务................................................................................................................. 73 高级语言和交互式编程............................................................................................................. 76 整体部分（THE WHOLE AND THE PA RT S）.......................................................................... 78 剔除BUG 的设计........................................................................................................................78 构件单元调试............................................................................................................................. 80 - vi - 系统集成调试............................................................................................................................. 82 祸起萧墙（HATCHING A CATA STROPHE ）........................................................................... 85 里程碑还是沉重的负担？......................................................................................................... 85 “其他的部分反正会落后”..................................................................................................... 86 地毯的下面............................................................................................................................... .. 87 另外一面（THE OTHER FACE）.............................................................................................. 92 需要什么样的文档..................................................................................................................... 93 流程图............................................................................................................................... .......... 95 自文档化（SELF-DOCUMENTIN G ）的程序................................................................................96 没有银弹－软件工程中的根本和次要问题（NO SILVER BULLET – ESSENCE AND ACCIDENT I N SOFTW A RE ENGINEERING ）..................................................................... 102 摘要 1 ............................................................................................................................... ......... 102 介绍............................................................................................................................... ............103 是否一定那么困难呢？——根本困难................................................................................... 103 以往解决次要困难的一些突破............................................................................................... 106 银弹的希望............................................................................................................................... 108 针对概念上根本问题的颇具前途的方法............................................................................... 113 NO............................................................................................................................. ............11 8 再论《没有银弹》 （“NO SILVER B ULLET”REFIRED）.................................................. 120 人狼和其他恐怖传说............................................................................................................... 120 存在着银弹－就在这里！....................................................................................................... 121 含糊的表达将会导致误解....................................................................................................... 121 HAREL 的分析.......................................................................................................................... 124 JONE的观点——质量带来生产率.......................................................................................... 127 那么，生产率的情形如何？................................................................................................... 128 面向对象编程——这颗铜质子弹可以吗？........................................................................... 129 重用的情况怎样？................................................................................................................... 130 学习大量的词汇——对软件重用的一个可预见，但还没有被预言的问题....................... 132 子弹的本质——形势没有发生改变....................................................................................... 133 《人月神话》的观点：是或非？（PROPOSITIONS OF THE MYTHICAL MAN-MONTH: TRUE OR FALSE ？）................................................................................................................134 第1 章 焦油坑......................................................................................................................... 134 第2 章 人月神话..................................................................................................................... 135 第3 章 外科手术队伍............................................................................................................. 136 第4 章 贵族专制、民主政治和系统设计............................................................................. 137 第5 章 画蛇添足..................................................................................................................... 137 第6 章 贯彻执行..................................................................................................................... 138 第7 章 为什么巴比伦塔会失败？......................................................................................... 139 第8 章 胸有成竹..................................................................................................................... 141 - vii - 第9 章 削足适履..................................................................................................................... 141 第10 章 提纲挈领................................................................................................................... 143 第11 章 未雨绸缪................................................................................................................... 143 第12 章 干将莫邪................................................................................................................... 146 第13 章 整体部分................................................................................................................... 148 第14 章 祸起萧墙................................................................................................................... 149 第15 章 另外一面................................................................................................................... 150 原著结束语............................................................................................................................... 152 20年后的人月神话（THE MYTHICAL MAN- M ONTH AFTER 20 YEARS）................. 153 为什么会出现二十周年纪念版本？....................................................................................... 153 核心观点：概念完整性和结构师........................................................................................... 154 开发第二个系统所引起的后果：盲目的功能和频率猜测................................................... 156 图形（WIMP）界面的成功....................................................................................................157 没有构建舍弃原型——瀑布模型是错误的！....................................................................... 160 增量开发模型更佳——渐进地精化....................................................................................... 162 关于信息隐藏，PARNAS是正确的，我是错误的................................................................. 165 人月到底有多少神话色彩？B OEHM 的模型和数据.............................................................. 167 人就是一切（或者说，几乎是一切）................................................................................... 168 放弃权力的力量....................................................................................................................... 169 最令人惊讶的新事物是什么？数百万的计算机................................................................... 171 全新的软件产业——塑料薄膜包装的成品软件................................................................... 173 买来开发——使用塑料包装的成品软件包作为构件........................................................... 174 软件工程的状态和未来........................................................................................................... 176 结束语：令人向往、激动人心和充满乐趣的五十年（EPILOGUE FIFTY Y E ARS OF WONDER, EXCITEMENT, AND JOY ）...................................................................................................... 178 注解和参考文献（NOTES AND REFERENCES ）................................................................. 180 第1 章............................................................................................................................... ........180 第2 章............................................................................................................................... ........180 第3 章............................................................................................................................... ........180 第4 章............................................................................................................................... ........181 第5 章............................................................................................................................... ........181 第6 章............................................................................................................................... ........182 第7 章............................................................................................................................... ........182 第8 章............................................................................................................................... ........182 第9 章............................................................................................................................... ........183 第10 章............................................................................................................................... ...... 183 第11 章............................................................................................................................... ...... 184 第12 章............................................................................................................................... ...... 184 第13 章............................................................................................................................... ...... 185 第14 章............................................................................................................................... ...... 186 第15 章............................................................................................................................... ...... 187 第16 章............................................................................................................................... ...... 187 - viii - 第17 章............................................................................................................................... ...... 188 第18 章............................................................................................................................... ...... 190 第19 章............................................................................................................................... ...... 190 索引（INDEX）.......................................................................................................................... 193 - ix - 焦油坑（The Ta r Pit） 岸上的船儿，如同海上的灯塔，无法移动。 - 荷兰谚语 Een schip op het strand is een baken in zee. [A ship on the beach is a lighthouse to the sea.] - DUTCH PROVERB 史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着 恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛 兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧 烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了 目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个 淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解 决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻 烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题， 就必须试图先去理解它。 因此，首先让我们来认识一下软件开发这个职业，以及充满在这个职业中的乐趣和苦 恼吧。 编程系统产品 报纸上经常会出现这样的新闻，讲述两个程序员如何在经改造的简陋车库中，编出了 超过大型团队工作量的重要程序。接着，每个编程人员准备相信这样的神话，因为他知道自 - 1 - 己能以超过产业化团队的1000代码行/ 年的生产率来开发任何程序。 为什么不是所有的产业化队伍都会被这种专注的二人组合所替代？我们必须看一下产 出的是什么。 程序 编程产品 （通用化， 测试， 文档， 维护） 编程系统 （接口 系统集成） 编程系统产品 x3 x3 图1.1 ：编程系统产品的演进 在图1.1 的左上部分是程序（Progra m）。它本身是完整的，可以由作者在所开发的系 统平台上运行。它通常是车库中产出的产品，以及作为单个程序员生产率的评估标准。 有两种途径可以使程序转变成更有用的，但是成本更高的东西，它们表现为图中的边 界。 水平边界以下，程序变成编程产品（P ro gr am ming Pr od uc t）。这是可以被任何人运行、 测试、修复和扩展的程序。它可以运行在多种操作系统平台上，供多套数据使用。要成为通 用的编程产品，程序必须按照普遍认可的风格来编写，特别是输入的范围和形式必须扩展， 以适用于所有可以合理使用的基本算法。接着，对程序进行彻底测试，确保它的稳定性和可 靠性，使其值得信赖。这就意味着必须准备、运行和记录详尽的测试用例库，用来检查输入 的边界和范围。此外，要将程序提升为程序产品，还需要有完备的文档，每个人都可以加以 使用、修复和扩展。经验数据表明，相同功能的编程产品的成本，至少是已经过测试的程序 的三倍。 - 2 - 回到图中，垂直边界的右边，程序变成编程系统（Pr og ra mm in g Sys te m ）中的一个构 件单元。它是在功能上能相互协作的程序集合，具有规范的格式，可以进行交互，并可以用 来组装和搭建整个系统。要成为系统构件，程序必须按照一定的要求编制，使输入和输出在 语法和语义上与精确定义的接口一致。同时程序还要符合预先定义的资源限制——内存空 间、输入输出设备、计算机时间。最后，程序必须同其它系统构件单元一道，以任何能想象 到的组合进行测试。由于测试用例会随着组合不断增加，所以测试的范围非常广。因为一些 意想不到的交互会产生许多不易察觉的bug ，测试工作将会非常耗时，因此相同功能的编程 系统构件的成本至少是独立程序的三倍。如果系统有大量的组成单元，成本还会更高。 图1.1 的右下部分代表编程系统产品（P ro gr ammin g Sy st ems P ro du ct ）。和以上的所 有的情况都不同的是，它的成本高达九倍。然而，只有它才是真正有用的产品，是大多数系 统开发的目标。 职业的乐趣 编程为什么有趣？作为回报，它的从业者期望得到什么样的快乐？ 首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样，成年人喜欢创 建事物，特别是自己进行设计。我想这种快乐是上帝创造世界的折射，一种呈现在每片独特、 崭新的树叶和雪花上的喜悦 1 。 其次，快乐来自于开发对其他人有用的东西。内心深处，我们期望其他人使用我们的 劳动成果，并能对他们有所帮助。从这个方面，这同小孩用粘土为“爸爸办公室”捏制铅笔 盒没有本质的区别。 第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们 精妙地运行，得到预先所希望的结果。比起弹珠游戏或点唱机所具有的迷人魅力，程序化的 计算机毫不逊色。 第四是学习的乐趣，来自于这项工作的非重复特性。人们所面临的问题，在某个或其 它方面总有些不同。因而解决问题的人可以从中学习新的事物：有时是实践上的，有时是理 论上的，或者兼而有之。 最后，乐趣还来自于工作在如此易于驾驭的介质上。程序员，就像诗人一样，几乎仅 - 3 - 仅工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的“城堡”。很少有这 样的介质——创造的方式如此得灵活，如此得易于精炼和重建，如此得容易实现概念上的设 想。（不过我们将会看到，容易驾驭的特性也有它自己的问题） 然而程序毕竟同诗歌不同，它是实实在在的东西；可以移动和运行，能独立产生可见 的输出；能打印结果，绘制图形，发出声音，移动支架。神话和传说中的魔术在我们的时代 已变成了现实。在键盘上键入正确的咒语，屏幕会活动、变幻，显示出前所未有的或是已经 存在的事物。 编程非常有趣，在于它不仅满足了我们内心深处进行创造的渴望，而且还愉悦了每个 人内在的情感。 职业的苦恼 然而这个过程并不全都是喜悦。我们只有事先了解一些编程固有的烦恼，这样，当它 们真的出现时，才能更加坦然地面对。 首先，必须追求完美。因为计算机也是以这样的方式来变戏法：如果咒语中的一个字 符、一个停顿，没有与正确的形式一致，魔术就不会出现。（现实中，很少的人类活动要求 完美，所以人类对它本来就不习惯。）实际上，我认为学习编程的最困难部分，是将做事的 方式往追求完美的方向调整。 其次，是由他人来设定目标，供给资源，提供信息。编程人员很少能控制工作环境和 工作目标。用管理的术语来说，个人的权威和他所承担的责任是不相配的。不过，似乎在所 有的领域中，对要完成的工作，很少能提供与责任相一致的正式权威。而现实情况中，实际 （相对于正式）的权威来自于每次任务的完成。 对于系统编程人员而言，对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程 序，而往往这些程序设计得并不合理，实现拙劣，发布不完整（没有源代码或测试用例）， 或者文档记录得很糟。所以，系统编程人员不得不花费时间去研究和修改，而它们在理想情 况下本应该是可靠完整的。 下一个烦恼——概念性设计是有趣的，但寻找琐碎的bug 却只是一项重复性的活动。 伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的劳动。程序编制工作也不例外。 - 4 - 另外，人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂 度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。 最后一个苦恼，有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或 者终于完成的时候，却已显得陈旧过时。可能是同事和竞争对手已在追逐新的、更好的构思； 也许替代方案不仅仅是在构思，而且已经在安排了。 现实情况比上面所说的通常要好一些。当产品开发完成时，更优秀的新产品通常还不 能投入使用，而仅仅是为大家谈论而已。另外，它同样需要数月的开发时间。事实上，只有 实际需要时，才会用到最新的设想，因为所实现的系统已经能满足要求，体现了回报。 诚然，产品开发所基于的技术在不断地进步。一旦设计被冻结，在概念上就已经开始 陈旧了。不过，实际产品需要一步一步按阶段实现。实现落后与否的判断应根据其它已有的 系统，而不是未实现的概念。因此，我们所面临的挑战和任务是在现有的时间和有效的资源 范围内，寻找解决实际问题的切实可行方案。 这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。 对于许多人而言，其中的乐趣远大于苦恼。而本书的剩余部分将试图搭建一些桥梁，为通过 这样的焦油坑提供一些指导。 - 5 - 人月神话（The Mythical Man-Month ） 美酒的酿造需要年头，美食的烹调需要时间；片刻等待，更多美味，更多享受。 - 新奥尔良Antoine餐厅的菜单 Good cooking takes tim e. If you are made to wait, it is to serve you better, and to please you. - MENU OF REST A URANT ANT OINE, NEW ORLEANS 在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所 有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？ 首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但 并不真实的假设——一切都将运作良好。 第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互 混淆。 第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工 作。 第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程 序，在软件工程中常常被认为是无谓的举动。 第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用 汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会 导致灾难的循环。 进度监督是另一篇论文的主题，而本文中我们将对问题的其他方面进行更详细的讨论。 - 6 - 乐观主义 所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的 人；也可能是成百上千琐碎的挫折赶走了大多数人，只剩下了那些习惯上只关注结果的人； 还可能仅仅因为计算机还很年轻，程序员更加年轻，而年轻人总是些乐观主义者——无论是 什么样的程序，结果是勿庸置疑的：“这次它肯定会运行。”或者“我刚刚找出了最后一个错 误。” 所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花 费它所“应该”花费的时间。 对这种弥漫在编程人员中的乐观主义，理应受到慎重的分析。Dorothy Sa yers 在她的 “The Mind of the Ma ker ”一书中，将创造性活动分为三个阶段：构思、实现和交流。书 籍、计算机、或者程序的出现，首先是作为一个构思或模型出现在作者的脑海中，它与时间 和空间无关。接着，借助钢笔、墨水和纸，或者电线、硅片和铁氧体，在现实的时间和空间 中实现它们。然后，当某人阅读书本、使用计算机和运行程序的时候，他与作者的思想相互 沟通，从而创作过程得以结束。 以上Sayers 的阐述不仅仅可以描绘人类的创造性活动，而且类似于“基督的教义”， 能指导我们的日常工作。对于创造者，只有在实现的过程中，才能发现我们构思的不完整性 和不一致性。因此，对于理论家而言，书写、试验以及“工作实现”是非常基本和必要的。 在许多创造性活动中，往往很难掌握活动实施的介质，例如木头切割、油漆、电器安 装等。这些介质的物理约束限制了思路的表达，它们同样对实现造成了许多预料之外的困难。 由于物理介质和思路中隐含的不完善性，实际实现起来需要花费大量的时间和汗水。 对遇到的大部分实现上的困难，我们总是倾向于去责怪那些物理介质，因为它们不顺应“我 们”设定的思路。其实，这只不过是我们的骄傲使判断带上了主观主义色彩。 然而，计算机编程基于十分容易掌握的介质，编程人员通过非常纯粹的思维活动—— 概念以及灵活的表现形式来开发程序。正由于介质的易于驾驭，我们期待在实现过程中不会 碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有bu g 。也就 是说，我们的乐观主义并不应该是理所应当的。 在单个的任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇 - 7 - 的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划 安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后 的次序，从而一切正常的概率变得非常小，甚至接近于无。 人月 第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月。成本的确随 开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为 衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互 替换的。 人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之 间不需要相互的交流（图2.1 ）。这在割小麦或收获棉花的工作中是可行的；而在系统编程 中近乎不可能。 月 人 图2.1 ：人员和时间之间的关系——完全可以分解的任务 当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助（图2.2）。无论多 少个母亲，孕育一个生命都需要十个月。由于调试、测试的次序特性，许多软件都具有这种 特征， - 8 - 月 人 图2.2 ：人员和时间之间的关系——无法分解的任务 对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟 通的工作量。因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未 调整前要差一些（图2.3 ）。 月 人 图2.3 ：人员和时间之间的关系——需要沟通的可分解任务 沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、项 目目标以及总体策略上的培训。这种培训不能分解，因此这部分增加的工作量随人员的数量 呈线性变化 1 。 - 9 - 相互之间交流的情况更糟一些。如果任务的每个部分必须分别和其他部分单独协作， 则工作量按照n(n-1)/2递增。一对一交流的情况下，三个人的工作量是两个人的三倍，四 个人则是两个人的六倍。而对于需要在三四个人之间召开会议、进行协商、一同解决的问题， 情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作 用，此时我们会被带到图2.4 的境地。 月 人 图2.4 ：人员和时间之间的关系——关系错综复杂的任务 因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流 的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手， 实际上是延长了，而不是缩短了时间进度。 系统测试 在时间进度中，顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到 的牵涉更彻底。而且，要求的时间依赖于所遇到的错误、缺陷数量以及捕捉它们的程度。理 论上，缺陷的数量应该为零。但是，由于我们的乐观主义，通常实际出现的缺陷数量比预料 的要多得多。因此，系统测试进度的安排常常是编程中最不合理的部分。 对于软件任务的进度安排，以下是我使用了很多年的经验法则： 1/3 计划 1/6 编码 - 10 - 1/4 构件测试和早期系统测试 1/4 系统测试，所有的构件已完成 在许多重要的方面，它与传统的进度安排方法不同： 1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说 明，也不足以容纳对全新技术的研究和摸索。 2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。 3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。 通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大 多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还 能保持进度。或者说，除了系统测试，进度基本能保证 2 。 特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生 在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有 任何预兆，很晚才出现在客户和项目经理面前。 另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前，项目 已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更重要的是，当软件用 来支持其他的商业活动（计算机硬件到货，新设备、服务上线等等）时，这些活动延误出现 即将发布前，那么将付出相当高的商业代价。 实际上，上述的二次成本远远高于其他开销。因此，在早期进度策划时，允许充分的 系统测试时间是非常重要的。 空泛的估算 观察一下编程人员，你可能会发现，同厨师一样，某项任务的计划进度，可能受限于 顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。就像约好在两分钟内完成一个 煎蛋，看上去可能进行得非常好。但当它无法在两分钟内完成时，顾客只能选择等待或者生 吃煎蛋。软件顾客的情况类似。 厨师还有其他的选择：他可以把火开大，不过结果常常是无法“挽救”的煎蛋——一 - 11 - 面已经焦了，而另一面还是生的。 现在，我并不认为软件经理内在的勇气和坚持不如厨师，或者不如其他工程经理。但 为了满足顾客期望的日期而造成的不合理进度安排，在软件领域中却比其他的任何工程领域 要普遍得多。而且，非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的 直觉，这样的方式很难生产出健壮可靠和规避风险的估计。 显然我们需要两种解决方案。开发并推行生产率图表、缺陷率、估算规则等等，而整 个组织最终会从这些数据的共享上获益。 或者，在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计， 确信自己的经验和直觉总比从期望派生出的结果要强得多。 重复产生的进度灾难 当一个软件项目落后于进度时，通常的做法是什么呢？自然是加派人手。如图2.1 至 2.4 所示，这可能有所帮助，也可能无法解决问题。 我们来考虑一个例子 3 。设想一个估计需要12个人月的任务，分派给3 个成员4 个月 时间，在每个月的末尾安排了可测量的里程碑A 、B 、C 、D （图2.5 ）。 现在假定两个月之后，第一个里程碑没有达到（图2.6）。项目经理面对的选择方案有 哪些呢？ 1. 假设任务必须按时完成。假设仅仅是任务的第一个部分估计不得当，即如图 2.6 所示，则剩余了9 个人月的工作量，时间还有两个月，即需要4.5 个开发人员，所以需要在 原来3 个人的基础上增加2 个人。 2. 假设任务必须按时完成。假设整个任务的估计偏低，即如图2.7 所示，那么还有 18个人月的工作量以及2 个月的时间，需要将原来的3 个人增至9 个人。 3. 重新安排进度。我喜欢P. Fa gg ，一个具有丰富经验的硬件工程师的忠告：“避免小 的偏差（Take no sm all slips ）”。也就是说，在新的进度安排中分配充分的时间，以确保 工作能仔细、彻底地完成，从而无需重新确定时间进度表。 4. 削减任务。在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进 - 12 - 行削减。当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。项目经理的相 应措施是仔细、正式地调整项目，重新安排进度；或者是默默地注视着任务项由于轻率的设 计和不完整的测试而被剪除。 月 人 1 2 4 3 5 123 4 567 8 ABC D 计划进度 图2.5 月 人 1 2 4 3 5 123 4 567 8 A BCD 落后 1 个月 （剩余9 人/ 月） 图2.6 - 13 - 月 人 1 2 4 3 5 123 4 567 8 AB C （剩 余18人/ 月） D 图2.7 月 人 1 2 4 3 5 1 2 3 45678 A BC D 5 个编 程人 员 7 ＋人月 培训结束 图2.8 前两种情况中，坚持把不经调整的任务在四个月内完成将是灾难性的。考虑到重复生 成的工作量，以第一种为例（图2. 8）——不论在多短的时间内，聘请到多么能干的两位新 员工，他们都需要接受一位有经验的职员的培训。如果培训需要一个月的时间，那么三个人 月将会投入到原有进度安排以外的工作中。另外，原先划分为三个部分的工作，会重新分解 成五个部分；某些已经完成的工作必定会丢失，系统测试必须被延长。因此，在第三个月的 月末，仍然残留着7 个人月的工作，但此时只有5 个有效的人月。如同图2.8 所示，产品还 是会延期，如同没有增加任何人手（图2.6 ）。 期望四个月内完成项目，仅仅考虑培训的时间，不考虑任务的重新划分和额外的系统 测试，在第二个月末需要增添4 个，而不是2 个人员。如果考虑任务划分和系统测试的工作 - 14 - 量，则还需要继续增加人手。到那时所拥有的就不是3 人的队伍，而是7 人以上的团队；并 且小组的组织和任务的划分在类型上都不尽相同，这已经不是程度上的差异问题。 注意在第三个月的结尾时，情况看上去还是很糟。除去管理的工作不谈，3 月1 日的里 程碑仍未达到。此时，对项目经理而言，仍然存在着很强的诱惑——添加更多人力，结果往 往会是上述循环的重复。这简直就是一种疯狂、愚蠢的做法。 前面的讨论仅仅是第一个里程碑估计不当的情况。如果在3 月1 日，项目经理做出了 比较保守的假设，即整个估计过于乐观了，如图2.7 所示。6 个人手需要添加到原先的任务 中。培训、任务的重新分配、系统测试工作量的计算作为练习留给读者。但是毫无疑问，重 现“灾难”所开发出的产品，比没有增加人手，而是重新安排开发进度所产生的产品更差。 简单、武断地重复一下Brooks法则： 向进度落后的项目中增加人手，只会使进度更加落后。（Addin g man po we r to a l ate software project makes it later ） 这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制，人员的数量依赖于 单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时 间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无 法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最 主要原因，它比其他所有因素加起来的影响还要大。 - 15 - 外科手术队伍（The Surgical Team） 这些研究表明，效率高和效率低的实施者之间具体差别非常大，经常达到了数量级的水平。 - SACKMAN, ERIKSON和GRANT 1 These st ud ies reveal ed l a rge indi vi dual diff er en ce s between h i gh and low p e rforme rs, often by a n or der of magnitude. - SACKMAN, ERIKSON, AND GRANT 1 在计算机领域的会议中，常常听到年轻的软件经理声称他们喜欢由头等人才组成的小 型、精干的队伍，而不是那些几百人的大型团队，这里的“人”当然暗指平庸的程序员。其 实我们也经常有相同的看法。 但这种幼稚的观点回避了一个很困难的问题——如何在有意义的时间进度内创建大型 的系统？那么就让我们现在来仔细讨论一下这个问题的每一个方面。 问题 软件经理很早就认识到优秀程序员和较差的程序员之间生产率的差异，但实际测量出 的差异还是令我们所有的人吃惊。在他们的一个研究中，Sa ck ma n 、E rikso n 和Gr and 曾对 一组具有经验的程序人员进行测量。在该小组中，最好的和最差的表现在生产率上平均为 10:1；在运行速度和空间上具有5:1 的惊人差异！简言之，$20,0 00 / 年的程序员的生产率可 能是$10,000/ 年程序员的10倍。数据显示经验和实际的表现没有相互联系（我怀疑这种现 象是否普遍成立。） 我常常重复这样的一个观点，需要协作沟通的人员的数量影响着开发成本，因为成本 的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。 这一点，也暗示系统应该由尽可能少的人员来开发。实际上，绝大多数大型编程系统的经验 显示出，一拥而上的开发方法是高成本的、速度缓慢的、不充分的，开发出的是无法在概念 - 16 - 上进行集成的产品。OS/3 60 、Ex ec 8 、Sc op e 6 600、Mu lt ics、TSS 、S AFE 等等——这个列 表可以不断地继续下去。 得出的结论很简单：如果一个200 人的项目中，有25 个最能干和最有开发经验的项目 经理，那么开除剩下的175 名程序员，让项目经理来编程开发。 现在我们来验证一下这个解决方案。一方面，原有的开发队伍不是理想的小型强有力 的团队，因为通常的共识是不超过10 个人，而该团队规模如此之大，以至于至少需要两层 的管理，或者说大约5 名管理人员。另外，它需要额外的财务、人员、空间、文秘和机器操 作方面的支