人月神话（英文版）(图灵奖得主总结软件项目实战得失)(china-pub首发)

　　本书内容源于作者brooks在ibm公司任system/360计算机系列以及其庞大的软件系统os/360项目经理时的实践经验。在本书中，brooks为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管理者给出了自己的真知灼见。
　　 大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。本书探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。本书适合任何软件开发行业的从业人员阅读，对软件开发人员、软件项目经理、系统分析师更是必读之作。

chapter 1 the tar pit 3
chapter 2 the mythical man-month 13
chapter 3 the surgical team 29
chapter 4 aristocracy, democracy, and system design 41
chapter 5 the second-system effect 53
chapter 6 passing the word 61
chapter 7 why did the tower of babel fail? 73
chapter 8 calling the shot 87
chapter 9 ten pounds in a five-pound sack 97
chapter 10 the documentary hypothesis 107
chapter 11 plan to throw one away 115
chapter 12 sharp tools 127
chapter 13 the whole and the parts 141
chapter 14 hatching a catastrophe 153
chapter 15 the other face 163
chapter 16 no silver bullet—essence and accident 177
chapter 17 "no silver bullet" retired 205
chapter 18 propositions of the mythical man-month: true or false? 227
chapter 19 the mythical man-month after 20 years 251
epilogue 291

　　20 周年纪念版前言
　　20 年过去了，《人月神话》依然受到读者喜欢，真让我惊喜不已，这本书已总计印行25 万多册了。常常有人问我，1975 年阐述的那些观点和建议中，哪些我仍坚持如故，哪些已有所改变以及如何改变。尽管我已经时不时地在各种演讲场合提到过这些问题，但我一直期望能专门撰文来进行说明。
　　Peter Gordon 自1980 年以来一直耐心地和我一起工作，对我颇有助益，现在他已是Addison-Wesley 的出版合伙人了。他提议出版《人月神话》的纪念版。我们决定不对初版进行改动，而是只做一些细微的校正，基本上是将原内容重印，同时增补几章更现代的思想。
　　第16 章重刊了1986 年我在IFIPS（国际信息处理学会联合会）上发表的论文《没有银弹：软件工程的必然和偶然》（No SilverBullet: Essence and Accidents of Software Engineering），这篇论文源自我主持一项国防科学委员会军事软件研究时的经验。论文的合作者兼我们的执行秘书Robert L. Patrick 发挥了不可估量的作用，他让我重新亲历了真实的大型软件项目。此文曾于1987 年重新刊发于IEEE《计算机》杂志上，从而广为传播。
　　《没有银弹》引起了轩然大波，它预言在10 年内不会出现任何编程技术能够给软件生产率带来数量级上的提高。再有1 年就满10 年了，我的预言看来是安全了。从大家发表的文章来看，相比《人月神话》，《没有银弹》激发的讨论越来越热烈。因而，第17 章评议了发表过的一些评论意见，并更新了我1986 年提出的这个观点。
　　在着手回顾和更新《人月神话》的过程中，我发现其中断言的观点很少被软件工程研究和实践所评判、证实或驳斥，这令我颇为震动。因此我觉得现在有必要把这些观点归类整理出来，而剔除掉相关的分析数据。我把这些论点列为第18 章，希望这些简单的陈述可以抛砖引玉，引发大家以论据或事实来证实、驳斥、更新或细化这些观点。
　　第19 章是对旧日文章的更新。提请读者注意的是，这些新观点不像初版那样来自一线实践经验。我后来一直在大学中工作，而不是工业界，所接触的也是小规模的项目，而非大项目。自1986年以来，我只是教授软件工程课程，而完全不作这方面的研究。我的研究转向了虚拟环境及其应用。
　　准备这一版期间，我咨询了实际从事软件工程工作的朋友们。我非常感谢他们慷慨地与我分享观点，深思熟虑地对书稿提出意见，令我重获教益。他们是：Barry Boehm、Ken Brooks、Dick Case、James Coggins、Tom DeMarco、Jim McCarthy、David Parnas、EarlWheeler 和Edward Yourdon。此外，Fay Ward 出色地完成了新章节的排版制作。
　　对于本书的第16 章，我要感谢Gordon Bell、Bruce Buchanan、Rick Hayes-Roth，他们是我在国防科学委员会军事软件任务组中的同事，还要特别感谢David Parnas，是他们的真知灼见启发了我写这篇文章；我还要感谢Rebekah Bierly 完成了这篇论文的排版制作。用“必然和偶然”的方法来分析软件问题则是受到了NancyGreenwood Brooks 的启发，她在一篇关于铃木小提琴教学的论文中使用了这样的分析法。
　　在1975 年版的前言中，我按出版社当时的规矩不能鸣谢其职员起到的重要作用。在此特别表扬两个人的贡献：执行主编Norman Stanton 和美术总监Herbert Boes。Boes 制作了典雅的风格，曾经有个评论人特地赞扬道：“宽大的页边距、字体的使用和排版布局颇具创意。”更重要的是，是他建议每一章要有一幅图片作为开篇。（当时我只有焦油坑和兰斯大教堂的图片。）找齐这些图片多花了我一年的时间，不过我对他的建议无限感激。
　　Soli Deo gloria—— 愿神独得荣耀。
　　Frederick P. Brooks, Jr.北卡罗来纳州查布尔希尔市
　　1995 年3 月
　　第1 版前言
　　管理大型计算机编程项目在很多方面与管理大型集体事务类似—— 比大多数程序员能想到的方面还要多，但它又在许多其他方面与后者不同—— 同样比大多数职业经理人能想到的方面还要多。
　　这个领域的知识日益增长，已经有了几个与此相关的会议，AFIPS（美国信息处理学会联合会）会议增设了一些讨论组，还出版或发表了一些书籍和论文。但是真正系统化的教科书还未出现。因而推出这个小册子似乎正当其时，它基本上反映了我的个人观点。尽管我最初是在计算机编程方面成长起来的，但在自动控制程序和高级语言编译器发展壮大的数年中（1956~1963），我主要参与的工作却是硬件体系结构。故而在1964 年，当我出任操作系统OS/360 的经理时，我发现编程世界经过几年后已经发生了巨大的变化。
　　管理OS/360 开发是一个很有意义的经历，也是非常令我受挫的经历。这个团队，包括我的继任者F. M. Trapnell 在内，有许多值得骄傲的地方。系统在设计和运行方面皆有许多出色之处，它成功地实现了广泛使用的目标。某些思想，比如最引人注目的设备无关的输入输出和外部库管理，现在已经成为被广泛采纳的技术创新。如今这一系统已然相当可靠，具有不错的效率，并且十分通用。然而，上述工作不能说是完全的成功。每个OS/360 的用户很快就会发现它有提高的余地。设计和执行错误散布在与语言编译器分离的控制程序里。多数此类错误可追溯到1964 至1965 年的设计阶段，故而我难逃其咎。而且这个产品的发布延迟了，它比原计划使用了更多的内存，总开销也数倍于原来的预算。开始时它还不能运转得很好，直到几个发布版本之后才得到转机。
　　在接手OS/360 时就已说好，于是1965 年我离开IBM 来到查布尔希尔市的北卡罗来纳大学，我开始分析OS/360 的经验，看看应该吸取哪些管理和技术方面的教训。我尤其希望好好分析一下System/360 硬件开发和OS/360 软件开发中所遭遇的完全不同的管理体验。Tom Watson 曾苦苦探究为何编程难以管理，本书算是对此问题的一个迟来的答案。
　　在探索过程中， 我与1964 至1965 年的项目助理经理R. P.Case 和1965 至1968 年的经理F. M. Trapnell 有过数次长谈，使我获益匪浅。我将结论与其他巨型编程项目经理交换了意见，包括麻省理工学院的F. J. Corbato、贝尔电话实验室的John Harr 和V.Vyssotsky、国际计算机有限公司的Charles Portman、苏联科学院西伯利亚分部计算实验室的A.P. Ershov 以及IBM 的A.M. Pietrasanta。我本人的结论收录于本书的文章中，以飨各位职业程序员和职业经理，尤其是管理程序员的职业经理们。
　　各章尽管独立成文，但都体现了一个中心观点，尤其是第2 章至第7 章。简言之，我相信大型编程项目面临的管理问题与小型项目不同，主要是由于人力划分产生的问题。我相信保持产品本身的概念完整性是一个至关重要的要求。这几章既分析了达成一致性的困难，又探讨了解决的方法。后续的各章则探讨了软件工程管理的其他方面。这一领域的文献并不多，却很分散。因而我努力给出参考文献，帮助阐释特定的观点，也为感兴趣的读者指出其他有用的著作。许多朋友已经读过了手稿，有些人提出了大量颇有帮助的意见，有些内容不便于放到正文中，我将在注解（Notes）中提到。

　　有些书，每读一遍都会有新的收获。《人月神话》就是这样一本书。常常有年轻的软件工程师、贫穷的研究生和懒惰的程序设计老手问我：“如果被困在一个小岛上，只能带一本计算机书在身上，应该带哪一本?”这问题很荒谬，但如果一定要给个答案，应该选《人月神话》陪伴自己。
　　——Ed Yourdon，软件界知名顾问和作家
　　我读过好多遍的计算机书，唯有《人月神话》。事实上我每隔一两年就会重读其中某些章节。部分原因是作者文笔很好，此外，书中的忠告很有价值，即使是时光已经过去了二三十年。我非常推崇这本书，这是唯一一本我认为能从中体会到乐趣和思想的计算机图书。
　　——Brian Kernighan，《C程序设计语言》作者
　　伟大的思想具有前瞻性，一如可预言新现象的物理定律，可成为真理。Brooks二十多年前提出的诸多基本观点主导着今天软件工程领域的基本论题，他对软件开发管理本身的深刻洞察让人拍案叫绝。
　　——豆瓣读者评论