| 商家名称 | 信用等级 | 购买信息 | 订购本书 |
 |
 |
人月神话(弗雷德里克.布鲁克斯 著) |  |
 |
|
人月神话(弗雷德里克.布鲁克斯 著) | |
![人月神话 [平装]](http://img.reader8.com/uploadfile/2012/1204/20121204025139236.jpg)
“又见人月神话 重温软工经典”
1.软件领域绝无仅有，32年之后依旧畅销不衰的传奇经典！
2.软件开发人员、软件项目经理、系统分析师必读的一本书！
《人月神话》读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。
书评
各路英豪品评人月实践
软工经典再启江湖争论
汇集国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得！
Frank Chance
介绍
出版于1975年的《人月神话》是软件开发方面的经典作品。1995年版包括了令人感兴趣的新的几章，但原来的随笔依然是这本书的心脏与灵魂。在这本书中，Brooks解决了如何组织和管理大规模编程项目的问题。这些项目要求成百上千的程序员，产生几百万行代码(想想SAP、Oracle数据库引擎、Windows2000)。这部书由一系列简明的随笔组成。在这篇评论中我将讨论开篇随笔――我的最爱之一。
焦油坑
Brooks将大系统编程作比喻作史前的焦油坑来开始他的第一篇随笔：“记忆中，我们看到恐龙、猛犸象、剑齿虎正在挣脱沥青的魔爪。挣扎得越剧烈，陷入的越深，没有哪只野兽足够强壮或熟练，它们最终都沉没了。大系统编程在过去的十年间就像焦油坑，许多大而强有力的野兽在其中已经惨烈地失败了。大部分已实现并在运行的系统，很少有达到目标、时间表和预算的。大和小、厚重和细实，一个接一个的团队卷入了沥青(陷阱)。没有什么事情似乎会导致这个困难――任何特殊的手掌都能被拉出来。但同时并相互作用的因数的相互聚集导致运动越来越慢。每个人似乎都惊讶于问题的难缠，难于面对它的本质。”
记住，这些话写于1975年。今天它们仍然可用吗？考虑一下WindowsNT5.0。第一次计划于1997年发布，随后延迟到1998年早期，1998年末，然后是1999年(为此它被重新命名为Windows2000)。这儿是一些公开的估计：
●5,000程序员。
●35,000,000行代码。
显然，NT5.0是个大系统编程项目。同样显而易见，Brooks的焦油坑在今天同1975年一样普遍！
让我们继续NT5.0的例子。假设最糟糕的情况，全部35，000，000 行代码都是新编的。有理由假设开发工作大致在1994年开始。所以我们有：
●5,000 程序员 X 5 年 = 25，000 程序员年
●35,000,000 行代码/ 25,000 程序员年 = 1,400 行／程序员年。
如果你是个程序员，或者你只接受过编程课程的教育，这个数字(1,400行每年)似乎令人惊异的低。我们当中的大部分人都能在一两天内堆积出接近一千行的代码。什么使得Microsoft的程序员一整年才产出1,400行代码？
两种可能性跃入我们的脑海：
●Microsoft 雇用了5，000名不合格的程序员去开发NT 5.0。
或者
●写一个大规模的程序系统产品远难于堆砌出单一的程序。
Brooks将讨论认为后一个答案是正确的。他由定义术语开始：
(1) 程序
一个独立的程序是我们两天编程狂欢的结果。它是准备自己运行于我们编程的那台机器上的。如果我们加上文档、通用化代码、编写测试用例、使得代码可以由其他无关的编程人员来维护，我们就有了：
(2) 程序产品
另外，如果我们接受我们的程序，并且完整地定义了它的接口使得它达到预定义的规范，并且测试了它和大量的其它组件的交互作用，我们就有：
(3) 程序系统组件
并且如果我们都做了(加上文档、通用化代码、编写测试用例、使得代码可维护、定义了接口、测试了交互作用)，我们就有：
(4) 程序系统产品组件
Brooks用手边的三倍规则说明在上述每个步骤中的工作要求：
(2) ＝3倍(1)的人力
(3) ＝3倍(1)的人力 (4)＝9倍(1)的人力
或者，换句话说，开发一个独立的程序仅仅要求开发一个程序系统组件的1／9的人力。
回到Microsoft的例子，如果我们将这个9倍的因子乘以1，400行每程序员年的生产力测量，我们得到12，600行每程序员年(举例来说，假设我们掌握每一程序员，并且使得他们独立工作，堆砌在单一的程序上)。在一篇独立的随笔中，Brooks引用一个发现这点的经理的话说，平均他的每个程序员仅能将他的一半时间用于开发――其它时间由文书工作、会议和各种其它任务所占据。把这些因素考虑到Microsoft的例子中，我们达到了25，200行每程序员年。那么，Microsoft的程序员开始看来非常可敬。另一个测量自1975年来有了很小的改变，Brooks引用的估计是1，000行每程序员年。如果上面引用的1，400行每程序员年是精确的，那么，它表现了在1975年到1995年20年间，生产力仅仅提升了1.75%每年。这个结果证实了Brooks的另一个假定——程序员的生产力相对是个常量，它不受开发所用的语言的影响。因此，实际的生产力收获来自于迁移到高级语言编程，这些语言每行表达了更多的实际工作。尽管目标是大系统项目，Brooks的解释常常被广泛的应用。例如，这个第一篇随笔用标有“手艺的快乐”和“手艺的悲哀”的小节来结束。在悲哀中，他讨论了荒废的问题：
“…这个人们已经工作了很长时间的产品，显然在完成前将被废弃。同事和竞争者已经在热烈地用新的和更好的主意反击。人们的孩童般想法的取代已经不仅仅在构思，而且付诸时间表。这一切总是似乎比它的实际更糟糕。新的和更好的想法通常在完成之前不被应用；它仅仅被谈论。真老虎永远不能和纸老虎相比。”
小结
Brooks的随笔涉及到了大系统编程所固有的多种挑战，但对任何投身于软件开发的人来说读这本书都是有用的。题名的随笔(《人月神话》)讨论了许多编程任务的不可分割性，和为什么增加人力到软件项目中无法产生效用。我的另一篇最爱是“贵族、民主和系统设计”(概念完整性的讨论)和“计划和投放之路”(在付运前多次交付的明确计划的益处)。一些问题已经因为技术的进步而废弃，例如关于如何在一个大型团队中分发写好的文档。然而，你可能惊讶Brooks面对的许多问题今天如何阻止我们。另外的益处是Brooks简洁、清晰的作品读起来令人愉快。如果你是个程序员，如果你和程序员一起工作，如果你管理程序员，你应该阅读这本书。
作者：(美)弗雷德里克·布鲁克斯 译者：汪颖
Frederick P.Brooks,Jr.曾荣获美国计算机领域最具声望的图灵奖（A.M.Turing Award）桂冠。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献”。
Brooks博士是北卡罗莱纳大学Kenan－Flagler商学院的计算机科学教授。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理，以及360系统项目设计阶段的经理。凭借在此项目中的杰出贡献，他与Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖（National Medal of Technology）。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。
Brooks博士创立了北卡罗莱纳大学的计算机科学系，并在1964～1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。Brooks博士目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计。
第1章 焦油坑
编程系统产品
职业的乐趣
职业的苦恼
第2章 人月神话
乐观主义
人月
系统测试
空泛的估算
重复产生的进度灾难
第3章 外科手术队伍
问题
Mills的建议
如何运作
团队的扩建
第4章 贵族专制、民主政治和系统设计
概念的完整性
获得概念的完整性
贵族专制统治和民主政治
在等待时，实现人员应该做什么
第5章 画蛇添足
结构师的交互准则和机制
自律——开发第二个系统所带来的后果
第6章 贯彻执行
文档化的规格说明——手册
形式化定义
直接整合
会议和大会
多重实现
电话日志
产品测试
第7章 为什么巴比伦塔会失败
巴比伦塔的管理教训
大型编程项目中的交流
项目工作手册
大型编程项目的组织架构
第8章 胸有成竹
第9章 削足适履
第10章 提纲挈领
第11章 未雨绸缪
第12章 干将莫邪
第13章 整体部分
第14章 祸起萧墙
第15章 另外一面
第16章 没有银弹
第17章 再论“没有银弹”
第18章 《人月神话》的观点：是与非？
第19章 20年后的《人月神话》
结束语：令人向往、激动人心和充满乐趣的50年
注解与参考文献
插图及附品图片
第一版序言
在很多方面，管理一个大型的计算机编程项目和管理其他行业的大型工程很相似—— 比大多数程序员所认为的还要相似；在另外一些方面，它又有差别—— 比大多数职业经理人所认为的差别还要大。
这个领域的知识在累积。现在AFIPS（美国信息处理学会联合会）已经有了一些讨论和会议，也出版了一些书籍和论文，但是还没有成形的方法对这一领域来进行系统地阐述。提供这样一本主要反映个人观点的小书看来是合适的。
虽然我原来从事计算机科学的编程方面的工作，但是在1956—1963年间，自动控制程序和高级语言编译器开发出来的时候，我主要参加的是硬件构架方面的工作。1964年，我成为操作系统OS/360的经理，我发现前些年的进展使编程世界改变了很多。
虽然是失败的，但管理OS/360的开发仍是一次很有帮助的经历。负责这次开发项目的团队，包括我的继任经理F. M. Trapnell，有很多值得自豪的东西。该系统在设计和执行方面都很出色，并被成功地应用到很多领域，特别是设备独立的输入输出和外部库管理，在很多技术革新中被广泛复制。现在，这一系统是十分可靠的，相当有效且非常通用。
但是，并不是所有的努力都是成功的。所有OS/360的用户很快就能发现它应该能够做得更好。设计和执行上的缺陷在控制程序中特别普遍，相比之下，语言编译器就好得多。大多数缺陷发生在1964—1965年的设计阶段，所以这肯定是我的责任。此外，这个产品发布推迟了，需要的内存比计划中的要多，成本也是估计的好几倍，而且第一次发布时并不能很好地运行，直到发布了几次以后，问题才得以解决。
按照当初接受OS/360任务时的协议，在1965年离开IBM后，我来到Chapel Hill。我开始分析OS/360的经验，看能不能从中学到什么管理和技术上的教训。特别要说明的是，System/360硬件开发和OS/360软件开发中的管理经验是大相径庭的。对Tom Watson关于为什么编程难以管理的探索性问题，这本书是一份迟来的答案。
在这次探索中，我和1964—1965年的经理助理R.P.Case，还有1965—1968年的经理F.M.Trapnell进行了长谈，从中受益很多。我还对比了其他大型编程项目经理的结论，这些项目经理包括M.I.T.的F.J.Corbato，贝尔电话实验室的V.Vyssotsky和John Harr，International Computers Limited的Charles Portman，苏联科学院西伯利亚分部计算实验室的A.P.Ershov和IBM的A.M.Pietrasanta。
我自己的结论体现在下面的文字中，送给专业程序员、职业经理，特别是程序员的职业经理。
虽然写出来的是各自独立的章节，但本书还是有一个中心的论点，特别包含在第2~7章。简言之，我相信由于人员的分工，大型编程项目碰到的管理问题和小项目碰到的管理问题区别很大；我相信关键需要的是维持产品自身的概念完整性。这几章探讨了其中的困难和解决的方法。而后续的章节则探讨了软件工程管理的其他方面。
这个领域的文献并不多，但散布很广。因此我尝试在书后给出了参考文献，说明某个特定知识点并指导感兴趣的读者去参阅其他有用的文献。很多朋友读过了本书的手稿，其中一些朋友还给出了很有帮助的意见。这些意见很有价值，但为了不打乱文字的通顺，我把它们作为注解包含在本书中。
因为这本书是一部文集而不是一部教材，所有的参考文献和注解都被放到书的末尾，建议读者在读第一遍时略去不看。
深深地感谢Sara Elizabeth Moore小姐，David Wagner先生和Rebecca Burris夫人，他们帮助我准备了手稿。感谢Joseph C.Sloane教授在图解方面的建议。
Frederick P.Brooks, JR.
Chapel Hill, N.C.
1974年10月
二十周年纪念版序言
令我惊奇和高兴的是，《人月神话》在20年后仍然继续流行，印数超过了250 000册。人们经常问，我在1975年提出的观点和建议，哪些是我仍然坚持的，哪些是已经改变了的，又是怎样改变的？尽管我在一些讲座上也分析过这个问题，但我还是一直想把它写成文章。
Peter Gordon现在是Addison-Wesley的出版伙伴，他从1980年开始和我共事。他非常有耐心，对我帮助很大。他建议我们准备一个纪念版本。我们决定不对原版本做任何修订，只是原封不动地重印(除了一些无足轻重的修正)，并用更新的思想来扩充它。
第16章重印了一篇在1986年IFIPS会议上的论文《没有银弹：软件工程的根本和次要问题》(No Silver Bullet：Essence and Accidents of Software Engineering)。这篇文章来自我在国防科学委员会主持军用软件方面研究时的经验。我当时的研究合作者，也是我的执行秘书，Robert L. Patrick，他帮助我回想和感受那些做过的软件大项目。1987年，IEEE的《计算机》(Computer)杂志重印了这篇论文，使它传播得更广了。
《没有银弹》被证明是富有煽动性的，它预言十年内没有任何编程技巧能够给软件的生产率带来数量级上的提高。十年只剩下一年了，我的预言看来是安全了。《没有银弹》激起了越来越多文字上的剧烈争论，比《人月神话》还要多。因此在第17章，我对一些公开的批评作了说明，并更新了在1986年提出的观点。
在准备《人月神话》的回顾和更新时，一直在进行的软件工程研究和经验已经批评、证实或否定了少数书中断言的观点，也影响了我。剥去辅助的争论和数据后，把那些观点粗略地分类，对我来说是很有帮助的。我在第18章列出了这些观点的概要，希望这些单调的陈述能够引来争论和证据，然后得到证实、否定、更新或精炼。
第19章是一篇更新的短文。读者应该注意的是，新观点并不像原来的书一样来自我的亲身经历。我在大学里工作，而不是在工业界，做的是小规模的项目，而不是大项目。自1986年以来，我就只是教授软件工程，不再做这方面的研究。我现在的研究领域是虚拟环境及其应用。
在这次回顾的准备过程中，我找了一些正在软件工程领域工作的朋友，征求他们现在的观点。他们很乐意和我分享他们的想法，并仔细地对草稿提出了意见，这些都使我重新受到启发。感谢Barry Boehm、Ken Brooks、Dick Case、James Coggins、Tom DeMarco、Jim McCarthy、David Parnas、Earl Wheeler和Edward Yourdon。感谢Fay Ward出色地对新的章节进行了技术加工。
感谢我在国防科学委员会军事软件工作组的同事Gordon Bell、Bruce Buchanan、Rick Hayes-Roth，特别是David Parnas，感谢他们的洞察力和生动的想法。感谢Rebekah Bierly对第16章的论文进行了技术加工。我把软件问题分成“根本的”和“次要的”，这是受Nancy Greenwood Brooks的启发，她在一篇Suzuki小提琴教育的论文中应用了这样的分析方法。
在1975年版本的序言中，Addison-Wesley出版社按规定不允许我向它的一些扮演了关键角色的员工致谢。可是，有两个人的贡献必须特别指出：执行编辑Norman Stanton和美术指导Herbert Boes。Boes设计了优雅风格的版式和封面，他在评注时特别提到：“页边的空白要宽，字体和版面要有想像力”。更重要的是，他提出了至关重要的建议：为每一章的开头配一幅图片(当时我只有“焦油坑”和“兰斯大教堂”的图片)。寻找这些图片使我多花了一年的时间，但我永远感激这个忠告。
Soli Deo gloria—愿神独得荣耀。
Frederick P.Brooks, Jr.
Chapel Hill, N.C.
1995年3月
编辑推荐：
更多图书资讯可访问读书人图书频道：http://www.reAder8.cn/book/
