人月神话（40周年中文纪念版）
[美] 小弗雷德里克·布鲁克斯（Frederick，P.Brooks，Jr.） 著，汪颖，UMLChina翻组 译
- 出版社： 清华大学出版社
- ISBN：9787302392644
- 版次：1
- 商品编码：12401749
- 品牌：清华大学出版社（Tsinghua University Press）
- 包装：平装
- 外文名称：The Mythical Man-Month：Essays on Software Engineering Anniversary Edition
- 开本：16开
- 出版时间：2015-04-01
- 用纸：胶版纸
- 页数：369
- 字数：316000
- 正文语种：中文
内容简介
在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了具有洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。
《人月神话（40周年中文纪念版）》内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。
《人月神话（40周年中文纪念版）》英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。
在《人月神话（40周年中文纪念版）》第首次出版40年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享，更使《人月神话（40周年中文纪念版）》成为国内从业者的必读经典之一。
《人月神话（40周年中文纪念版）》读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。
作者简介
小弗雷德里克·布鲁克斯，曾获得美国计算机领域具声望的图灵奖（A.M.Turing Award）。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献”。
布鲁克斯博士1956年开始任职于IBM公司，早期担任Stretch 和Harvest计算机的体系建构师。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理。凭借在此项目中的杰出贡献，他与Bob Evans和Erich Bloch在1985年获得了美国国家技术奖（National Medal of Technology）。
布鲁克斯博士创立了北卡罗来纳大学的计算机科学系，并于1965-1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。目前其仍活跃于从事虚拟环境和科学可视化等方面的研究工作，2010年获得虚拟现实事业奖（IEEE Virtual Reality Career Award）。
精彩书评
★《人月神话》仍然是计算机书籍中被引用次数多的经典著作，而且即便本书最初出版于20世纪，其内容至今仍未过时。在阅读的时候，每隔几页不说一句“对极了！”是很难受的。
——Steve McCormell，Constmx&首席软件工程师 名著《代码大全》、《快速软件开发》作者
★这是一本经典著作，与软件开发有关的每一个人都应该不止一遍地读这本书。
——Philippe Kruchten，Rational统一过程首席架构师
★我一本读过很多遍的书，是Fred Brooks的《人月神话》，实际上我每过一两年都重读一遍。因为这本书文笔很好，而且书中的忠告很有价值，即使是在40年以后。当然，其在很多细节上和我们现在做事情的方法有所不同。我们的工作更自动化，计算机的“马力”更强劲，但书中依然有许多好的忠告，我非常推崇这本书。这是我能想起来的你能从中体会到乐趣和思想的计算机科学书籍。
——Briall Kenlighan，名著《C程序设计语言》的合著者之一
目录
第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．《人月神话》软玉生香
精彩书摘
《人月神话（40周年中文纪念版）》：
作为成本的程序空间
程序有多大？除了运行时间以外，它所占据的空间也是主要开销。这同样适用于专用开发的程序，用户支付给开发者一笔费用，作为必要分担的开发成本。考虑一下IBMAPL交互式软件系统，它的租金为每月400美元，在使用时，它至少占用160K字节的内存。在Model165上，内存租金大约是12美元／每月·千字节。如果程序在全部时间内都可用，他需要支付400美元的软件使用费和1920美元的内存租用费。如果某个人每天使用APL系统4小时，他每月需要支出400美元的软件租金和320美元的内存租用费。
常常听到的一个“可怕的”谈论是在2M内存的机器上，操作系统就需要占用400K内存。这种言论就好像批评波音747飞机，仅仅因为它耗资2700万美元一样无知。我们首先必须问的是“它能干什么？”对于所耗费的资金，获得的易用性和性能（高效的系统利用）是什么？投资在内存上的每月4800美元的租金能否比用在其他硬件、编程人员、应用程序上更加有效？
当系统设计者认为对用户而言，常驻程序内存的形式比加法器、磁盘等更加有用时，他会将硬件实现中的一部分移到内存上。相反，其他的做法是非常不负责任的。所以，应该从整体上进行评价。没有人可以在自始至终提倡更紧密的软硬件设计集成的同时，又仅仅就规模本身对软件系统提出批评。
由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法，就像硬件开发人员会设立元器件数量目标，控制元器件的数量，想出一些减少零件的方法。同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。
规模控制
对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。他必须研究用户和用户需求，以设置待开发系统的规模。接着，把这些系统划分成若干部分，并设定每个部分的规模目标。由于“规模一速度”权衡方案的结果在很大的范围内变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。聪明的项目经理还会给自己预留一些空间，在工作推行时分配。
在OS/360项目中，即使所有的工作都完成得相当仔细，我们依然从中得到了一些痛苦的教训。
首先，仅对核心程序设定规模目标是不够的，必须把所有方面的规模都编入预算。在先前的大多数操作系统中，系统驻留在磁带上，长时间的磁带搜索意味着它无法自如地运用在程序片段上。OS/360和它的前任产品Stretch操作系统和1410-7010磁盘操作系统一样，是驻留在磁盘上的。它的开发者对自由、廉价的磁盘访问感到欣喜。而如果使用磁带，会给性能带来灾难性的后果。
在为每个单元设立核心规模的同时，我们没有同时设置访问的预算。正如大家能想到的一样，当程序员发现自己的单元核心未能达到要求时，他会把它分解成覆盖模块。这个过程本身增加了程序整体的规模，并降低了运行速度。最重要的是，我们的管理控制系统既没有度量，也没有捕获这些问题。每个人都汇报了内核的大小，由于都在目标范围之内，所以没有人发现规模上的问题。
幸运的是，OS/360性能模拟程序投入使用的时间较早。第一次运行的结果反映出很大的麻烦。FortranH在带磁鼓的Model65上，每分钟模拟编译5条语句。嵌入的例程显示控制程序模块进行了很多次磁盘访问。甚至使用频繁的监控模块也犯了很多同样的错误，结果很类似于页
前言/序言
在很多方面，管理一个大型的计算机编程项目与管理其他行业的大型工程很相似——比大多数程序员所认为的还要相似；在另外一些方面，它又有差别——比大多数职业经理人所认为的差别还要大。
这个领域的知识在于累积。现在，AFIPS（美国信息处理学会联合会）已经有了一些讨论和会议，也出版了一些书籍和论文，但是还没有成形的方法对这一领域来进行系统地阐述。提供这样一本主要反映个人观点的小书看来是合适的。
虽然我原来从事计算机科学的编程方面的工作，但是在1956-1963年，自动控制程序和高级语言编译器开发出来的时候，我主要参加的是硬件构架方面的工作。1964年，我成为操作系统OS/360的经理，我发现前些年的进展使编程世界改变了很多。
虽然是失败的，但管理OS/360的开发仍是一次很有帮助的经历。负责这次开发项目的团队，包括我的继任经理F.M.Trapnell，有很多值得自豪的东西。该系统在设计和执行方面都很出色，并被成功地应用到很多领域，特别是设备独立的输入输出和外部库管理，在很多技术革新中被广泛复制。现在，这一系统是十分可靠的，相当有效且非常通用。
但是，并不是所有的努力都是成功的。所有OS/360的用户很快就能发现它应该能够做得更好。设计和执行上的缺陷在控制程序中特别普遍，相比之下，语言编译器就好得多。大多数缺陷发生在1964-1965年的设计阶段，所以这肯定是我的责任。此外，这个产品发布推迟了，需要的内存比计划中的要多，成本也是估计的好几倍，而且第一次发布时并不能很好地运行，直到发布了几次以后，问题才得以解决。