描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787302392644
“图灵奖得主、“IBM 360系统之父”作者Brooks颠覆了项目管理领域，长久不衰传奇经典！
软件开发人员、软件项目经理、系统分析师等IT从业者必藏之软工圣经！
畅销全球40年！新版再发行
全球软工领域畅销的项目管理经典！
影响人力编程思想的著作之一！
在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了*洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。
在《人月神话》出版40年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享，更使本书成为国内从业者的经典之一。
本书读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。
第1章 焦油坑
编程系统产品
职业的乐趣
职业的苦恼
第2章 人月神话
乐观主义
人月
系统测试
空泛的估算
重复产生的进度灾难
第3章 外科手术队伍
问题
Mills的建议
如何运作
团队的扩建
第4章 贵族专制、民主政治和系统设计
概念的完整性
获得概念的完整性
贵族专制统治和民主政治
在等待时，实现人员应该做什么
第5章 画蛇添足
结构师的交互准则和机制
自律―― 开发第二个系统所带来的后果
第6章 贯彻执行
文档化的规格说明―― 手册
形式化定义
直接整合
会议和大会
多重实现
电话日志
产品测试
第7章 为什么巴比伦塔会失败
巴比伦塔的管理教训
大型编程项目中的交流
项目工作手册
大型编程项目的组织架构
第8章 胸有成竹
Portman的数据
Aron的数据
Harr的数据
OS/360的数据
Corbató的数据
第9章 削足适履
作为成本的程序空间
规模控制
空间技能
数据的表现形式是编程的根本
第10章 提纲挈领
计算机产品的文档
大学科系的文档
软件项目的文档
为什么要有正式的文档
第11章 未雨绸缪
试验性工厂和增大规模
不变的就是变化本身
为变更设计系统
为变更计划组织架构
前进两步，后退一步
前进一步，后退一步
第12章 干将莫邪
目标机器
辅助机器和数据服务
高级语言和交互式编程
第13章 整体部分
剔除bug的设计
构件单元调试
系统集成调试
第14章 祸起萧墙
里程碑还是沉重的负担
“其他的部分反正会落后”
地毯的下面
第15章 另外一面
需要什么样的文档
流程图
自文档化的程序
第16章 没有银弹
摘要
介绍
根本困难
以往解决次要困难的一些突破
银弹的希望
针对概念上根本问题的颇具前途的方法
第17章 再论“没有银弹”
人狼和其他恐怖传说
存在着银弹―― 就在这里
含糊的表达将会导致误解
Harel的分析
Jones的观点―― 质量带来生产率
那么，生产率的情形如何
面向对象编程―― 这颗铜质子弹可以吗
重用的情况怎样
学习大量的词汇―― 对软件重用的一个可预见但还没有被预言的问题
子弹的本质―― 形势没有发生改变
第18章 《人月神话》的观点：是与非
第1章 焦油坑
第2章 人月神话
第3章 外科手术队伍
第4章 贵族专制、民主政治和系统设计
第5章 画蛇添足
第6章 贯彻执行
第7章 为什么巴比伦塔会失败
第8章 胸有成竹
第9章 削足适履
第10章 提纲挈领
第11章 未雨绸缪
第12章 干将莫邪
第13章 整体部分
第14章 祸起萧墙
第15章 另外一面
第1版结束语
第19章 20年后的《人月神话》
为什么要出版20周年纪念版本
核心观点―― 概念完整性和结构师
开发第二个系统所引起的后果―― 盲目的功能和频率猜测
图形界面的成功
没有构建舍弃原型―― 瀑布模型是错误的
增量开发模型更佳―― 渐进地精化
关于信息隐藏，Parnas是正确的，我是错误的
人月到底有多少神话色彩？Boehm的模型和数据
人就是一切(或者说，几乎是一切)
放弃权力的力量
令人惊讶的新事物是什么？数百万的计算机
全新的软件产业―― 塑料薄膜包装的成品软件
买来开发―― 使用塑料包装的成品软件包作为构件
软件工程的状态和未来
结束语：令人向往、激动人心和充满乐趣的50年
注解与参考文献
附录：人月落地实战体验
一、名家谈人月
1. 年金
2. 《人月神话》与实践
3. Frank Chance评人月
4. 软件尚方宝剑(Silver Bullet)何在
二、名著评人月
三、读者感言
1. 读书有感――人月神话
2. 我这几天很烦(产品概念完整性)
3. 关于我们的思考――“项目开发”及读《人月神话》有感
4. 我的“人月神话”
5. 《人月神话》软玉生香
神品―― 代序*
这是本书中的一节废话。*
我是一个书狂，积习甚深，费尽心机在软件工程、系统工程方面积累了一些书。书，在我看来当分为神品、精品和普通三等，其中神品、精品又分别有一、二和三品之分。我所收集的书中，软件工程书大都属于精品，神品只有两本，Frederick P. Brooks的这本书就属于神品之列。
软件作为一个行业，逐步背起了“solvingthe wrong problem”(解决错误的问题)的名声。问题决定解决方案，这也就是说，我们一直在制造错误解决方案！这方面有大量的证据，其中著名的是美国政府统计署(GAO)的数据：全球的软件消费商(美国军方)每年要花费数十亿美元购买软件，而在其所购软件中，可直接使用的只占2%，另外3%需要做一些修改，其余95%都成了垃圾。一句话，不管这些软件是否符合需求规格，它们都显然没有满足客户的需求。面向对象技术并没有给我们带来“神奇的效应”，不管开发商如何吹嘘面向对象OO(Object-Oriented)工具多么，也不管那些OO狂热者多么毅然地前赴后继，这方面的数据从20世纪80年代以来并没有发生大的改观。
这实在令我们的软件工程专家和从业人员们羞愧，因为它揭示了我们可能一开始就从根本上做错了什么！20世纪90年代中期，当软件工程一代宗师MichaelJackson(非歌坛巨星Michael Jackson)宣布他们的研究结果时，立刻在软件工程界激起了阵阵涟漪。Jackson指出，软件从业人员和方法学大师们只是简单地模仿和照搬其他学科的方法，却将重要的方面(问题域)忽略了。他指出，面向对象方法和结构化方法对问题域的处理没有什么大的区别，却被人们过分地用美好的词汇美化了：
“…You can seethe results clearly in many object-oriented modeling descriptions. Often theyare accompanied by fine words about modeling the real world. But when you lookclosely you can see that they are really descriptions of programming objects,pure and simple. Any similarity to real-world objects, living or dead, ispurely coincidental…”
(……从众多面向对象建模的描述中，你可以很清楚地看到这些恶果。而且它们还经常伴随着有关现实世界建模的非常美好的词汇。然而，仔细看看，你就会发现它们其实是彻头彻尾的编程对象！如果说有任何和现实世界对象相似的地方，不管是死是活，纯属巧合……)
回首软件工程近40年的发展，Jackson哀叹软件行业普遍缺乏专业性，充满了业余人员，“手中有一个锤子，看到什么都是钉子”，谁都可以开发性命攸关的软件。
这就是我们面临的严峻而复杂的现实，也许您会感到震惊！然而在大师Frederick P. Brooks眼里，是那么的平静。因为早在28年前，他就在《人月神话》(The Mythical Man-Month)这本不朽著作中对这些内容做了深入论述。
这本小册子行文优美，思想博大精深，字字真言，精读之有不尽的趣味，藏之又是极珍贵的文献，名眼高人，自能鉴之。
前些年，一位朋友从印度归来，说此书在印度极为普及，我也动起笔来，但惭愧终未成正果。汪颖兄素来勤恳，明知此翻译为“success without applause, diligence without reward”(没有掌声的成功，没有回报的勤勉)，却兢兢业业，反复琢磨，历经单调、繁琐、艰辛的劳动，终于付梓。钦佩之余随即作序共勉。
Dave Wang
SE ForumChina
2002年3月于深圳
20周年纪念版序言
令我惊奇和高兴的是，《人月神话》在20年后仍然继续流行，印数超过了250 000册。人们经常问，我在1975年提出的观点和建议，哪些是我仍然坚持的，哪些是已经改变了的，又是怎样改变的？尽管我在一些讲座上也分析过这个问题，但我还是一直想把它写成文章。
PeterGordon现在是Addison-Wesley的出版伙伴，他从1980年开始和我共事。他非常有耐心，对我帮助很大。他建议我们准备一个纪念版本。我们决定不对原版本做任何修订，只是原封不动地重印(除了一些无足轻重的修正)，并用更新的思想来扩充它。
第16章重印了一篇在1986年IFIPS会议上的论文“没有银弹：软件工程的根本和次要问题”(No Silver Bullet：Essence and Accidents ofSoftware Engineering)。这篇文章来自我在国防科学委员会主持军用软件方面研究时的经验。我当时的研究合作者，也是我的执行秘书，Robert L. Patrick，他帮助我回想和感受那些做过的软件大项目。1987年，IEEE的《计算机》(Computer)杂志重印了这篇论文，使它传播得更广了。
“没有银弹”被证明是富有煽动性的，它预言10年内没有任何编程技巧能够给软件的生产率带来数量级上的提高。10年只剩下一年了，我的预言看来是安全了。“没有银弹”激起了越来越多文字上的剧烈争论，比《人月神话》还要多。因此在第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 DeoGloria―― 愿神独得荣耀。
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软件开发中的管理经验是大相径庭的。对Tom Watson关于为什么编程难以管理的探索性问题，这本书是一份迟来的答案。
在这次探索中，我和1964―1965年的经理助理R. P. Case，还有1965―1968年的经理F. M.Trapnell进行了长谈，从中受益很多。我还对比了其他大型编程项目经理的结论，这些项目经理包括
我读过一遍以上的书，是Fred Brooks的《人月神话》，实际上我每过一两年都会重读一遍。部分原因是这本书文笔很好，另外就是书中的忠告很有价值，即使是在25年以后。当然，很多细节上的地方与我们做事情的方法有所不同。我们的工作更自动化，计算机的“马力”更强劲，但书中依然有许多好的忠告，因此，我非常推崇这本书。这是我*能想起来的能从中体会到乐趣和思想的计算机科学书籍。
―― Brian Kernighan，名著《C程序设计语言》的合著者之一(与Dennis M.Ritchie合作)
(《人月神话》)仍然是计算机书籍中被引用次数*多的书籍，而且即便本书*初出版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说一句“对极了”是很难受的。
―― Steve McConnell，Construx公司首席软件工程师，名著《代码大全》、《快速软件开发》的作者
这是一本经典著作，与软件开发有关的每一个人都应该不止一遍地读这本书。
―― Philippe Kruchten，Rational统一过程首席架构师
评论
还没有评论。