1、 THE MYTHICAL MAN-MONTH 人人月月神神话话FREDERICK P. BROOKS, JR. 翻译： Adams Wang 关于作者 Frederick P. Brooks， Jr.是北卡罗 来纳大学 Kenan-Flagler 商学院的计算机科学 教授，北卡来罗来纳大学位于美国北卡来罗来纳州的查布尔希尔。 Brooks 被认为是“ IBM 360系统之父” ， 他担任了 360 系统的项目经理，以及 360 操作系统 项目设计阶段的经理。凭借在上述项目的杰出贡献，他、 Bob Evans 和 Erich Bloch 在 1985 年荣获了 美国国家技术奖（ Nationa
2、l Medal of Techology） 。 早期， Brooks 曾担任 IBM Stretch 和 Harvest 计算 机的体系结构师。 在查布尔希尔， Brooks 博士创立了计算机科学系， 并在 1964 至 1984 年 期间担任主席。他曾任 职于 美国国 家科 技局和 国防 科学技 术委 员会。 Brooks 目前的教 学和研 究方 向是计算机体系结构、分子模型绘图和虚拟环境。 1975 年版献辞 致两位特别丰富了我 IBM 岁月的人： Thomas J. Watson, Jr.， 他对人们的关怀在他的公司依然无所不在 和 Bob O. Evans， 他大胆的领导使工作成为了探
3、险。 1995 年版献辞 致 Nancy， 上帝赐给我的礼物。 二十周年纪念版序言（Preface to the 20thAnniversary Edition） 令我惊奇和高兴的是， 人月神话 在 20 年后仍 然继续流行， 印数超过 了 250,000。人们经常问， 我在 1975 年 提出的观点和建议， 哪些是我仍然坚持的， 哪些是已经改变观点的，是怎样改变的？尽管我在一些讲座上也分析过这个问题，我还是一直想把它写成文章。 Peter Gordon 现在是 Addison-Wesley 的出版伙伴，他从 1980 年开始和我共事。他 非常耐心，对我帮助很大。他建议我们准备一个纪念版本。我
4、们决定不对原版本做任何修订，只是原封不动地重印（除了一些细小的修正） ，并用更新的思想来扩充它。 第 16 章重印 了一篇在 1986 年 IFIPS 会议上的论文没有银弹：软件工程的根本和次要问题 。 这 篇文章来 自 我在国防 科 学委员会 主 持军用软 件 方面研究 时 的经验。 我 当时的研究合作者，也是我的执行秘书， Robert L. Patrick 帮助我回 想和感受那些做过的软件大项目。 1987 年， IEEE 的 计算机 杂志重印了这篇论文，使它传播得更广了。 没有银弹被证明是富有煽动性的，它预言十年内没有任何编程技巧能够给软件 的生产率带 来 数量级上 的 提高。十 年
5、只剩下一 年 了，我的 预 言看来安 全 了 。 没有 银 弹激起了越来越多文字上的剧烈争论，比 人月神话 还要多。因此在第 17 章，我对一些公开的批评作了说明，并更新了在 1986 年提出的观点。 在准备 人月神话 的回顾和更新时，一直进行的软件工程研究和经验已经批评、 证实和否定了少数书中断言的观点， 也影响了我。 剥去辅助的争论和数据后， 把那些观点粗略地分类，对我来说很有帮助。我在第 18 章列出 这些观点的概要，希望这些单调的陈述能够引来争论和证据，然后得到证实、否定、更新或精炼。 第 19 章是一 篇更新的短文。 读者应该注意的是， 新观点并不象原来的书一样来自我的亲身经 历。
6、我在大 学里 工作， 不是 在工业 界， 做的是 小规 模的项 目， 不是大 项目 。自 1986年以来， 我就只是教授软件工程， 不再做这方面的研究。 我现在的研究领域是虚拟环境及其应用。 在这次回顾的准备过程中，我找了一些正工作在软件工程领域的朋友，征求他们的 当- i - 前观点。 他们很乐意和我共享他们的想法， 并仔细地对草稿提出了意见， 这些都使我重新受到启发。感谢 Barry Boehm、 Ken Brooks、 Dick Case、 James Coggins、 Tom Demarco、 Jim McCarthy、 David Parnas、 Earl Wheeler 和 Edw
7、ard Yourdon。感 谢 Fay Eard 出色地对新的章节进行了技术加工。 感谢我在国防科学委员会军事软件工作组的同事 Gordon Bell、 Bruce Buchanan、 Rick Hayes-Roth， 特别是 David Parnas， 感谢他们的洞察力和生动的想法。 感谢 Rebekah Bierly对 16 章的论 文进行了技术加工。 我把软件问题分成 “ 根本的 ”和“ 次要的 ” ， 这是受 Nancy Greenwood Brooks 的启发 ，她在一篇 Suzuki 小提琴 教育的论文中应用了这样的分析方法 。 在 1975 年版 本的序言中， Addison-W
8、esleys 出版 社按规定不允许我向它的一些扮演了关键角色的员工致谢。有两个人的贡献必须被特别提到：执行编辑 Norman Stanton 和美术指导 Herbert Boes。 Boes 设计了优雅的风格， 他在评注时特别提到： “页 边的空白要宽， 字体和版面 要 有想像力” 。 更重要的 是 ，他提出 了 至关重要 的 建议：为 每 一章的开 头 配一幅图片（当时 我 只有“焦 油 坑”和“ 兰 斯大教堂 ” 的图片） 。 寻 找这些图 片 使我多花 了 一年的时间，但我永远感激这个忠告。 Soli Deo gloria愿神独得荣耀。 查珀尔希尔，北卡罗来纳 F.P.B., Jr.19
9、95 年 3 月 - ii - 第一版序言（Preface to the First Edition） 在很多方面，管理一个大型的计算机编程项目和其它行业的大型工程很相似比 大多数程序员所认为的还要相似； 在很多另外的方面， 它又有差别比大多数职业经理所认为的差别还要大。 这个领域的知识在累积。 现在 AFIPS（美国信息处理学会联合会） 已经有了一些讨论和会议， 也出版了一些书籍和论文， 但是还没有成型的方法来系统地进行阐述。 提供这样一本主要反映个人观点的小书看来是合适的。 虽然我原来从事计算机科学的编程方面的工作，但是在 1956-1963 年 间自动控制程序和高级语言编译器开发出来的时
10、候，我主要参加的是硬件构架方面的工作。在 1964 年，我成为操作系统 OS/360 的经理，发现前些年的进展使编程世界改变了很多。 管理 OS/360 的开发是很有帮助的经历， 虽然是失败的。 那个团队， 包括我的继任经 理F. M. Trapnell，有很多 值得自豪的东西。那个系统包括了很多优秀的设计和实施，成功地应用在很多领域， 特别是设备无关的输入输出和外部库管理， 被很多技术革新广泛复制。 它现在是十分可靠的，相当有效，和非常通用的。 但是， 并不是所有的努力都是成功的。 所有 OS/360 的用户很 快就能发现它应该做得更好。 设计和实现上的缺陷在控制程序中特别普遍， 相比之下，
11、 语言编译器就好得多。 大多数这些缺陷发生在 1964-1965 年的设计 阶段， 所以这肯定是我的责任。 此外， 这个产品发布推迟了， 需要的内存比计划中的要多， 成本也是估计的好几倍， 而且第一次发布时并不能很好地运行，直到发布了几次以后。 就象当初接受 OS/360 的 任务时协商好的， 在 1965 年离开 IBM 后， 我来到查珀尔希尔 。我开始分析 OS/360 的经验 ，看能不能从中学到什么管理和技术上的教训。特别地，我要说明 System/360 硬件开发和 OS/360 软 件开发中的管理经验是非常不同的。对 Tom Watson 关于为什么编程难以管理的探索性问题，这本书是
12、一份迟来的答案。 在这次探索中，我和 1964-65 年的 经理助理 R.P.Case，还 有 1965-68 年的经 理F.M.Trapnell， 进行了长 谈， 从中受益良多。 我对比了其他大型编程项目的经理的结论， 包括 M.I.T.的 F.J.Corbato， Bell 电话实验室的 V.Vyssotsky， International Computers - iii - Limited 的 Charles Portman，苏联科 学院西伯利亚分部计算实验室的 A.P.Ershov，和 IBM的 A.M.Pietrasanta。 我自己的结论体现在下面的文字中，送给职业程序员、职业经理
13、、特别是程序员的 职业经理。 虽然写出来的是分离的章节， 还是有一个中心的论点， 特别包含在第 2-7 章。 简言 之 ，我相信由于人员的分工， 大型编程项目碰到的管理问题和小项目区别很大； 我相信关键需要是维持产品自身的概念完整性。 这些章节探讨了其中的困难和解决的方法。 后续的章节探讨软件工程管理的其他方面。 这个领域的文献并不多，但散布很广。因此我尝试给出参考资料，说明某个特定知 识点和指引感兴趣的读者去看其他有用的工作。 很多朋友读过了本书的手稿， 其中一些朋友给出了很有帮助的意见。 这些意见很有价值， 但为了不打乱文字的通顺， 我把它们作为注解包含在书中。 因为这本书是随笔不是课本，
14、所有的参考文献和注解都被放到书的末尾，建议读者 在读第一遍时略去不看。 深切感谢 Sara Elizabeth Moore 小姐， David Wagner 先生，和 Rebecca Burris 夫人，他们帮助我准备了手稿。感谢 Joseph C.Sloane 教授在图解方面的建议。 查珀尔希尔，北卡罗来纳 F.P.B., Jr1974 年 10 月 - iv - 目录（Contents） 二十周年 纪 念版序言 （ PREFACE TO THE 20THANNIVERSARY EDITION） . I 第一版序 言 （ PREFACE TO THE FIRST EDITION） . III
15、 目录（ CONTENTS） .V 焦油坑（ THE TAR PIT） .1 编程系统产品 .1 职业的乐趣 .3 职业的苦恼 .4 人月神话 （ THE MYTHICAL MAN-MONTH） .6 乐观主义 .7 人月 .8 系统测试 .10 空泛的估算 .11 重复产生的进度灾难 .12 外 科 手 术队伍 （ THE SURGICAL TEAM） .16 问题 .16 MILLS 的建议 .17 如何运作 .20 团队的扩建 .21 贵族专制、 民主政治 和 系统设计 （ ARISTOCRACY, DEMOCRACY, AND SYSTEM DESIGN）.22 概念一致性 .22 获
16、得概念的完整性 .23 贵族专制统治和民主政治 .24 在等待时，实现人员应该做什么？ .26 画蛇添足 （ THE SECOND-SYSTEM EFFECT） .29 结构师的交互准则和机制 .29 自律开发第二个系统所带来的后果 .30 贯彻执行 （ PASSING THE WORD） .33 文档化的规格说明手册 .33 形式化定义 .34 直接整合 .36 会议和大会 .36 多重实现 .38 - v - 电话日志 .38 产品测试 .38 为什么巴 比 伦塔会失 败 ？ （ WHY DID THE TOWER OF BABEL FAIL?） .40 巴比伦塔的管理教训 .41 大型编
17、程项目中的交流 .41 项目工作手册 .42 大型编程项目的组织架构 .44 胸有成竹 （ CALLING THE SHOT） .49 PORTMAN 的数 据 .50 ARON 的数据 .51 HARR 的数据 .51 OS/360 的数 据 .53 CORBATO 的数 据 .53 削足适履 （ TEN POUNDS IN A FIVE-POUND SACK） .55 作为成本的程序空间 .55 规模控制 .56 空间技能 .57 数据的表现形式是编程的根本 .58 提纲挈领 （ THE DOCUMENTARY HYPOTHESIS） .60 计算机产品的文档 .60 大学科系的文档 .6
18、2 软件项目的文档 .62 为什么要有正式的文档？ .63 未雨绸缪 （ PLAN TO THROW ONE AWAY） .64 试验性工厂和增大规模 .64 唯一不变的就是变化本身 .65 为变更计划系统 .66 为变更计划组织架构 .66 前进两步，后退一步 .68 前进一步，后退一步 .69 干将莫邪 （ SHARP TOOLS） .71 目标机器 .72 辅助机器和数据服务 .73 高级语言和交互式编程 .76 整体部分 （ THE WHOLE AND THE PARTS） .78 剔除 BUG 的设 计 .78 构件单元调试 .80 - vi - 系统集成调试 .82 祸起萧墙 （
19、HATCHING A CATASTROPHE） .85 里程碑还是沉重的负担？ .85 “其他的部分反正会落后” .86 地毯的下面 .87 另外一面 （ THE OTHER FACE） .92 需要什么样的文档 .93 流程图 .95 自文档化（ SELF-DOCUMENTING）的程 序 .96 没有银弹软件工程中的根本和次要问题（ NO SILVER BULLET ESSENCE AND ACCIDENT IN SOFTWARE ENGINEERING） .102 摘要1.102 介绍 .103 是否一定那么困难呢？根本困难 .103 以往解决次要困难的一些突破 .106 银弹的希望 .108 针对概念上根本问题的颇具前途的方法 .
