在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。在《人月神话》第一次出版40年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享，更使本书成为国内从业者的必读经典之一。本书读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。
作者简介：
小弗雷德里克布鲁克斯曾获得美国计算机领域最具声望的图灵奖(A.M.TuringAward)。美国计算机协会(ACM)称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献”。布鲁克斯博士1956年开始任职于IBM公司，早期担任Stretch和Harvest计算机的体系建构师。他被认为是“IBM360系统之父”，曾担任360系统的项目经理。凭借在此项目中的杰出贡献，他与BobEvans和ErichBloch在1985年获得了美国国家技术奖(NationalMedalofTechnology)。布鲁克斯博士创立了北卡罗来纳大学的计算机科学系，并于1965-1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。目前其仍活跃于从事虚拟环境和科学可视化等方面的研究工作，2010年获得虚拟现实事业奖(IEEEVirtualRealityCareerAward)。
目录：
第1章焦油坑1
编程系统产品4
职业的乐趣6
职业的苦恼8
第2章人月神话11
乐观主义14
人月16
系统测试19
空泛的估算21
重复产生的进度灾难22
第3章外科手术队伍27
问题30
Mills的建议32
如何运作35
团队的扩建36第1章焦油坑1编程系统产品4职业的乐趣6职业的苦恼8第2章人月神话11乐观主义14人月16系统测试19空泛的估算21重复产生的进度灾难22第3章外科手术队伍27问题30Mills的建议32如何运作35团队的扩建36第4章贵族专制、民主政治和系统设计39概念的完整性42获得概念的完整性43贵族专制统治和民主政治44在等待时，实现人员应该做什么47第5章画蛇添足51结构师的交互准则和机制54自律——开发第二个系统所带来的后果55第6章贯彻执行59文档化的规格说明——手册62形式化定义63直接整合66会议和大会66多重实现68电话日志68产品测试69第7章为什么巴比伦塔会失败71巴比伦塔的管理教训75大型编程项目中的交流76项目工作手册76大型编程项目的组织架构80第8章胸有成竹85Portman的数据89Aron的数据90Harr的数据90OS/360的数据92Corbató的数据93第9章削足适履95作为成本的程序空间98规模控制99空间技能100数据的表现形式是编程的根本102第10章提纲挈领105计算机产品的文档108大学科系的文档110软件项目的文档110为什么要有正式的文档111第11章未雨绸缪113试验性工厂和增大规模116唯一不变的就是变化本身117为变更设计系统117为变更计划组织架构118前进两步，后退一步120前进一步，后退一步122第12章干将莫邪125目标机器129辅助机器和数据服务131高级语言和交互式编程134第13章整体部分139剔除bug的设计142构件单元调试144系统集成调试147第14章祸起萧墙153里程碑还是沉重的负担156“其他的部分反正会落后”158地毯的下面159第15章另外一面165需要什么样的文档169流程图171自文档化的程序175第16章没有银弹181摘要184介绍184根本困难185以往解决次要困难的一些突破190银弹的希望192针对概念上根本问题的颇具前途的方法200第17章再论“没有银弹”209人狼和其他恐怖传说212存在着银弹——就在这里212含糊的表达将会导致误解213Harel的分析216Jones的观点——质量带来生产率221那么，生产率的情形如何222面向对象编程——这颗铜质子弹可以吗223重用的情况怎样225学习大量的词汇——对软件重用的一个可预见但还没有被预言的问题228子弹的本质——形势没有发生改变229第18章《人月神话》的观点：是与非231第1章焦油坑234第2章人月神话235第3章外科手术队伍236第4章贵族专制、民主政治和系统设计237第5章画蛇添足238第6章贯彻执行239第7章为什么巴比伦塔会失败240第8章胸有成竹242第9章削足适履243第10章提纲挈领245第11章未雨绸缪246第12章干将莫邪249第13章整体部分251第14章祸起萧墙253第15章另外一面255第1版结束语256第19章20年后的《人月神话》257为什么要出版20周年纪念版本260核心观点——概念完整性和结构师261开发第二个系统所引起的后果——盲目的功能和频率猜测263图形界面的成功265没有构建舍弃原型——瀑布模型是错误的269增量开发模型更佳——渐进地精化272关于信息隐藏，Parnas是正确的，我是错误的276人月到底有多少神话色彩？Boehm的模型和数据278人就是一切(或者说，几乎是一切)280放弃权力的力量281最令人惊讶的新事物是什么？数百万的计算机283全新的软件产业——塑料薄膜包装的成品软件286买来开发——使用塑料包装的成品软件包作为构件288软件工程的状态和未来290结束语：令人向往、激动人心和充满乐趣的50年293注解与参考文献295附录：人月落地实战体验315一、名家谈人月3171.年金3172.《人月神话》与实践3183.FrankChance评人月3274.软件尚方宝剑(SilverBullet)何在330二、名著评人月339三、读者感言3511.读书有感——人月神话3512.我这几天很烦(产品概念完整性)3533.关于我们的思考——“项目开发”及读《人月神话》有感3554.我的“人月神话”3585.《人月神话》软玉生香360前言神品——代序*
这是本书中唯一的一节废话。*
我是一个书狂，积习甚深，费尽心机在软件工程、系统工程方面积累了一些书。书，在我看来当分为神品、精品和普通三等，其中神品、精品又分别有一、二和三品之分。我所收集的书中，软件工程书大都属于精品，神品只有两本，FrederickP.Brooks的这本书就属于神品之列。
软件作为一个行业，逐步背起了“solvingthe wrong problem”(解决错误的问题)的名声。问题决定解决方案，这也就是说，我们一直在制造错误解决方案！这方面有大量的神品——代序*这是本书中唯一的一节废话。*我是一个书狂，积习甚深，费尽心机在软件工程、系统工程方面积累了一些书。书，在我看来当分为神品、精品和普通三等，其中神品、精品又分别有一、二和三品之分。我所收集的书中，软件工程书大都属于精品，神品只有两本，FrederickP.Brooks的这本书就属于神品之列。软件作为一个行业，逐步背起了“solvingthewrongproblem”(解决错误的问题)的名声。问题决定解决方案，这也就是说，我们一直在制造错误解决方案！这方面有大量的证据，其中最著名的是美国政府统计署(GAO)的数据：全球最大的软件消费商(美国军方)每年要花费数十亿美元购买软件，而在其所购软件中，可直接使用的只占2%，另外3%需要做一些修改，其余95%都成了垃圾。一句话，不管这些软件是否符合需求规格，它们都显然没有满足客户的需求。面向对象技术并没有给我们带来“神奇的效应”，不管开发商如何吹嘘面向对象OO(Object-Oriented)工具多么万能，也不管那些OO狂热者多么毅然地前赴后继，这方面的数据从20世纪80年代以来并没有发生大的改观。这实在令我们的软件工程专家和从业人员们羞愧，因为它揭示了我们可能一开始就从根本上做错了什么！20世纪90年代中期，当软件工程一代宗师MichaelJackson(非歌坛巨星MichaelJackson)宣布他们的研究结果时，立刻在软件工程界激起了阵阵涟漪。Jackson指出，软件从业人员和方法学大师们只是简单地模仿和照搬其他学科的方法，却将最重要的方面(问题域)忽略了。他指出，面向对象方法和结构化方法对问题域的处理没有什么大的区别，却被人们过分地用美好的词汇美化了：“...Youcanseetheresultsclearlyinmanyobject-orientedmodelingdescriptions.Oftentheyareaccompaniedbyfinewordsaboutmodelingtherealworld.Butwhenyoulookcloselyyoucanseethattheyarereallydescriptionsofprogrammingobjects,pureandsimple.Anysimilaritytoreal-worldobjects,livingordead,ispurelycoincidental...”(……从众多面向对象建模的描述中，你可以很清楚地看到这些恶果。而且它们还经常伴随着有关现实世界建模的非常美好的词汇。然而，仔细看看，你就会发现它们其实是彻头彻尾的编程对象！如果说有任何和现实世界对象相似的地方，不管是死是活，纯属巧合……)回首软件工程近40年的发展，Jackson哀叹软件行业普遍缺乏专业性，充满了业余人员，“手中有一个锤子，看到什么都是钉子”，谁都可以开发性命攸关的软件。这就是我们面临的严峻而复杂的现实，也许您会感到震惊！然而在大师FrederickP.Brooks眼里，是那么的平静。因为早在28年前，他就在《人月神话》(TheMythicalMan-Month)这本不朽著作中对这些内容做了深入论述。这本小册子行文优美，思想博大精深，字字真言，精读之有不尽的趣味，藏之又是极珍贵的文献，名眼高人，自能鉴之。前些年，一位朋友从印度归来，说此书在印度极为普及，我也动起笔来，但惭愧终未成正果。汪颖兄素来勤恳，明知此翻译为“successwithoutapplause,diligencewithoutreward”(没有掌声的成功，没有回报的勤勉)，却兢兢业业，反复琢磨，历经单调、繁琐、艰辛的劳动，终于付梓。钦佩之余随即作序共勉。DaveWangSEForumChina2002年3月于深圳20周年纪念版序言令我惊奇和高兴的是，《人月神话》在20年后仍然继续流行，印数超过了250000册。人们经常问，我在1975年提出的观点和建议，哪些是我仍然坚持的，哪些是已经改变了的，又是怎样改变的？尽管我在一些讲座上也分析过这个问题，但我还是一直想把它写成文章。PeterGordon现在是Addison-Wesley的出版伙伴，他从1980年开始和我共事。他非常有耐心，对我帮助很大。他建议我们准备一个纪念版本。我们决定不对原版本做任何修订，只是原封不动地重印(除了一些无足轻重的修正)，并用更新的思想来扩充它。第16章重印了一篇在1986年IFIPS会议上的论文“没有银弹：软件工程的根本和次要问题”(NoSilverBullet：EssenceandAccidentsofSoftwareEngineering)。这篇文章来自我在国防科学委员会主持军用软件方面研究时的经验。我当时的研究合作者，也是我的执行秘书，RobertL.Patrick，他帮助我回想和感受那些做过的软件大项目。1987年，IEEE的《计算机》(Computer)杂志重印了这篇论文，使它传播得更广了。“没有银弹”被证明是富有煽动性的，它预言10年内没有任何编程技巧能够给软件的生产率带来数量级上的提高。10年只剩下一年了，我的预言看来是安全了。“没有银弹”激起了越来越多文字上的剧烈争论，比《人月神话》还要多。因此在第17章，我对一些公开的批评做了说明，并更新了在1986年提出的观点。在准备《人月神话》的回顾和更新时，一直在进行的软件工程研究和经验已经批评、证实或否定了少数书中断言的观点，也影响了我。剥去辅助的争论和数据后，把那些观点粗略地分类，对我来说是很有帮助的。我在第18章列出了这些观点的概要，希望这些单调的陈述能够引来争论和证据，然后得到证实、否定、更新或精炼。第19章是一篇更新的短文。读者应该注意的是，新观点并不像原来的书一样来自我的亲身经历。我在大学里工作，而不是在工业界，做的是小规模的项目，而不是大项目。自1986年以来，我就只是教授软件工程，不再做这方面的研究。我现在的研究领域是虚拟环境及其应用。在这次回顾的准备过程中，我找了一些正在软件工程领域工作的朋友，征求他们现在的观点。他们很乐意与我分享他们的想法，并仔细地对草稿提出了意见，这些都使我重新受到启发。感谢BarryBoehm、KenBrooks、DickCase、JamesCoggins、TomDeMarco、JimMcCarthy、DavidParnas、EarlWheeler和EdwardYourdon。感谢FayWard对新的章节进行了出色的技术加工。感谢我在国防科学委员会军事软件工作组的同事GordonBell、BruceBuchanan、RickHayes-Roth，特别是DavidParnas，感谢他们的洞察力和生动的想法。感谢RebekahBierly对第16章的论文进行了技术加工。我把软件问题分成“根本的”和“次要的”，这是受NancyGreenwoodBrooks的启发，她在一篇“Suzuki小提琴教育”的论文中应用了这样的分析方法。在1975年版本的序言中，Addison-Wesley出版社按规定不允许我在书中向该社的一些扮演了关键角色的员工致谢。可是，有两个人的贡献必须特别指出：执行编辑NormanStanton和美术指导HerbertBoes。Boes设计了优雅风格的版式和封面，他在评注时特别提到：“页边的空白要宽，字体和版面要有想象力。”更重要的是，他提出了至关重要的建议：为每一章的开头配一幅图片(当时我只有“焦油坑”和“兰斯大教堂”的图片)。寻找这些图片使我多花了一年的时间，但我永远感激这个忠告。SoliDeoGloria——愿神独得荣耀。FrederickP.Brooks,Jr.ChapelHill,N.C.1995年3月第1版序言在很多方面，管理一个大型的计算机编程项目与管理其他行业的大型工程很相似——比大多数程序员所认为的还要相似；在另外一些方面，它又有差别——比大多数职业经理人所认为的差别还要大。这个领域的知识在于累积。现在，AFIPS(美国信息处理学会联合会)已经有了一些讨论和会议，也出版了一些书籍和论文，但是还没有成形的方法对这一领域来进行系统地阐述。提供这样一本主要反映个人观点的小书看来是合适的。虽然我原来从事计算机科学的编程方面的工作，但是在1956—1963年，自动控制程序和高级语言编译器开发出来的时候，我主要参加的是硬件构架方面的工作。1964年，我成为操作系统OS/360的经理，我发现前些年的进展使编程世界改变了很多。虽然是失败的，但管理OS/360的开发仍是一次很有帮助的经历。负责这次开发项目的团队，包括我的继任经理F.M.Trapnell，有很多值得自豪的东西。该系统在设计和执行方面都很出色，并被成功地应用到很多领域，特别是设备独立的输入输出和外部库管理，在很多技术革新中被广泛复制。现在，这一系统是十分可靠的，相当有效且非常通用。但是，并不是所有的努力都是成功的。所有OS/360的用户很快就能发现它应该能够做得更好。设计和执行上的缺陷在控制程序中特别普遍，相比之下，语言编译器就好得多。大多数缺陷发生在1964—1965年的设计阶段，所以这肯定是我的责任。此外，这个产品发布推迟了，需要的内存比计划中的要多，成本也是估计的好几倍，而且第一次发布时并不能很好地运行，直到发布了几次以后，问题才得以解决。按照当初接受OS/360任务时的协议，在1965年离开IBM后，我来到ChapelHill。我开始分析OS/360的经验，看能不能从中学到什么管理和技术上的教训。特别要说明的是，System/360硬件开发和OS/360软件开发中的管理经验是大相径庭的。对TomWatson关于为什么编程难以管理的探索性问题，这本书是一份迟来的答案。在这次探索中，我和1964—1965年的经理助理R.P.Case，还有1965—1968年的经理F.M.Trapnell进行了长谈，从中受益很多。我还对比了其他大型编程项目经理的结论，这些项目经理包括我唯一一本读过一遍以上的书，是FredBrooks的《人月神话》，实际上我每过一两年都会重读一遍。部分原因是这本书文笔很好，另外就是书中的忠告很有价值，即使是在25年以后。当然，很多细节上的地方与我们做事情的方法有所不同。我们的工作更自动化，计算机的“马力”更强劲，但书中依然有许多好的忠告，因此，我非常推崇这本书。这是我唯一能想起来的能从中体会到乐趣和思想的计算机科学书籍。
——BrianKernighan，名著《C程序设计语言》的合著者之一(与DennisM.Ritchie合作)
(《人月神话》)仍然是计算机书籍中被引用次数最多的书籍，而且即便本书最初出版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说一句“对极了”是很难受的。
——SteveMcConnell，Construx公司首席软件工程师，名著《代码大全》、《快速软件开发》的作者
这是一本经典著作，与软件开发有关的每一个人都应该不止一遍地读这本书。我唯一一本读过一遍以上的书，是FredBrooks的《人月神话》，实际上我每过一两年都会重读一遍。部分原因是这本书文笔很好，另外就是书中的忠告很有价值，即使是在25年以后。当然，很多细节上的地方与我们做事情的方法有所不同。我们的工作更自动化，计算机的“马力”更强劲，但书中依然有许多好的忠告，因此，我非常推崇这本书。这是我唯一能想起来的能从中体会到乐趣和思想的计算机科学书籍。——BrianKernighan，名著《C程序设计语言》的合著者之一(与DennisM.Ritchie合作)(《人月神话》)仍然是计算机书籍中被引用次数最多的书籍，而且即便本书最初出版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说一句“对极了”是很难受的。——SteveMcConnell，Construx公司首席软件工程师，名著《代码大全》、《快速软件开发》的作者这是一本经典著作，与软件开发有关的每一个人都应该不止一遍地读这本书。——PhilippeKruchten，Rational统一过程首席架构师史前史中，没有别的场景比巨兽们在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越猛烈，焦油纠缠得就越紧，没有哪种猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过只有极少数的项目满足了目标、进度和预算的要求。各种团队，大型的或小型的，庞杂的或精干的，一个接一个地淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对于问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去了解问题。因此，首先让我们来认识一下系统开发这个职业，以及充满在这个职业中的乐趣和苦恼吧！编程系统产品报纸上经常会出现这样的新闻，讲述两个程序员如何在经过改造的简陋车库中，编出超过大型团队工作量的重要程序。接着，每个编程人员准备相信这样的神话，因为他知道自己能以超过产业化团队的1000代码行/年的生产率来开发任何程序。为什么不是所有的产业化队伍都会被这种专注的二人组合所替代？我们必须看一下产出的是什么。图1-1的左上部分是程序(Program)。它本身是完整的，可以由作者在所开发的系统平台上运行。它通常是车库中产出的产品，以及作为单个程序员生产率的评估标准。图1-1编程系统产品的演进有两种途径可以使程序转变成更有用但是成本更高的产物，这两种途径表现为图中的边界。水平边界以下，程序转变成编程产品(ProgrammingProduct)。这是可以被任何人运行、测试、修复和扩展的程序。它可以在多种操作系统平台上运行，供多套数据使用。要成为通用的编程产品，程序必须按照普遍认可的风格来编写，特别是输入的范围和形式必须广泛地适用于所有可以合理使用的基本算法。接着，对程序进行彻底测试，确保它的稳定性和可靠性，使其值得信赖。这就意味着必须准备、运行和记录详尽的测试用例库，用来检查输入的边界和范围。此外，要将程序提升为程序产品，还需要有完备的文档，每个人都可以加以使用、修复和扩展。经验数据表明，相同功能的编程产品的成本，至少是已调试的程序的成本的3倍。回到图中，垂直边界的右边，程序转变成编程系统(ProgrammingSystem)中的一个构件单元。它是在功能上能相互协作、具有规范的格式、可以进行交互的程序集合，并可以用来组装和搭建整个系统。要成为编程系统构件，程序必须按照一定的要求编制，使输入和输出在语法和语义上与精确定义的接口一致。同时程序还要符合预先定义的资源限制——内存空间、输入输出设备、计算机时间。最后，程序必须同其他系统构件单元一道，以任何能想象到的组合进行测试。由于测试用例会随着组合不断增加，所以测试的范围必须广泛。因为一些意想不到的交互会产生许多不易察觉的bug，测试工作将会非常耗时，因此相同功能的编程系统构件的成本至少是独立程序的3倍。如果系统有大量的组成单元，成本还会更高。图1-1的右下部分代表编程系统产品(ProgrammingSystemsProduct)。与以上的所有的简单的程序都不同的是，它的成本高达9倍。然而，只有它才是真正有用的产品，是大多数系统开发的目标。职业的乐趣编程为什么有趣？作为回报，它的从业者期望得到什么样的快乐？首先，这种快乐是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到快乐一样，成年人喜欢创建事物，特别是自己进行设计。我想这种快乐是上帝创造世界的折射，一种呈现在每片独特的、崭新的树叶和雪花上的喜悦。其次，这种快乐来自于开发对他人有用的东西。内心深处，我们期望我们的劳动成果能够被他人使用，并能对他们有所帮助。从这一角度而言，这同小孩用粘土为“爸爸的办公室”捏制铅笔盒没有任何本质的区别。第三，快乐来自于整个过程体现出的一股强大的魅力——将相互啮合的零部件组装在一起，看到它们以精妙的方式运行着，并收到了预期的效果。比起弹球游戏机或自动电唱机所具有的迷人魅力，程序化的计算机毫不逊色。第四，这种快乐是持续学习的快乐，它来自于这项工作的非重复特性。人们所面临的问题总有这样那样的不同，因而解决问题的人可以从中学习新的事物，有时是实践上的，有时是理论上的，或者兼而有之。最后，这种快乐还来自于在易于驾驭的介质上工作。程序员，就像诗人一样，几乎仅仅在单纯的思考中工作。程序员凭空地运用自己的想象，来建造自己的“城堡”。很少有创造介质如此灵活，如此易于精炼和重建，如此容易实现概念上的设想(不过我们将会看到，容易驾驭的特性也有它自己的问题)。然而程序毕竟同诗歌不同，它是实实在在的东西；它可以移动和运行，能独立产生可见的输出；它能打印结果，绘制图形，发出声音，移动支架。神话和传说中的魔术在我们的时代已变成现实。在键盘上键入正确的咒语，屏幕会活动、变幻，显示出前所未有的也不可能存在的事物。编程的快乐在于它不仅满足了我们内心深处进行创造的渴望，而且还唤醒了每个人内心的情感。
|
