在软件领域，很少能有像《人月神话》一样具有深远影响力并且畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解。既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司System/360家族和OS/360中的项目管理经验。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄中等多种语言，全球销量数百万册。确立了其在行业内的经典地位。

在本书第一次出版32年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册与大家共享，更使本书成为国内从业者的必读经典之一。

本书读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。

    在很多方面，管理一个大型的计算机编程项目和管理其他行业的大型工程很相似—— 比大多数程序员所认为的还要相似；在另外一些方面，它又有差别—— 比大多数职业经理人所认为的差别还要大。

　　这个领域的知识在累积。现在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月

　　

第1章  焦油坑 1

编程系统产品 4

职业的乐趣 6

职业的苦恼 8

第2章  人月神话 11

乐观主义 14

人月 16

系统测试 19

空泛的估算 21

重复产生的进度灾难 22

第3章  外科手术队伍 27

问题 30

Mills的建议 32

如何运作 35

团队的扩建 36

第4章  贵族专制、民主政治和系统设计 39

概念的完整性 42

获得概念的完整性 43

贵族专制统治和民主政治 44

在等待时，实现人员应该做什么 47

第5章  画蛇添足 51

结构师的交互准则和机制 54

自律—— 开发第二个系统所带来的后果 55

第6章  贯彻执行 59

文档化的规格说明—— 手册 62

形式化定义 63

直接整合 66

会议和大会 66

多重实现 68

电话日志 69

产品测试 70

第7章  为什么巴比伦塔会失败 71

巴比伦塔的管理教训 75

大型编程项目中的交流 75

项目工作手册 76

大型编程项目的组织架构 80

　　

第8章  胸有成竹 85

Portman的数据 89

Aron的数据 90

Harr的数据 91

OS/360的数据 93

Corbató的数据 93

第9章  削足适履 95

作为成本的程序空间 98

规模控制 99

空间技能 101

数据的表现形式是编程的根本 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

摘要[1] 184

介绍 184

是否一定那么困难呢？—— 根本困难 185

以往解决次要困难的一些突破 190

　　

银弹的希望 192

针对概念上根本问题的颇具前途的方法 200

第17章  再论“没有银弹” 209

 人狼和其他恐怖传说 212

 存在着银弹—— 就在这里！ 212

 含糊的表达将会导致误解 213

 Harel的分析 216

 Jones的观点—— 质量带来生产率 221

 那么，生产率的情形如何 222

 面向对象编程—— 这颗铜质子弹可以吗 224

 重用的情况怎样 226

 学习大量的词汇—— 对软件重用的一个可预见，

     但还没有被预言的问题 229

 子弹的本质—— 形势没有发生改变 230

第18章  《人月神话》的观点：是与非？ 231

 第1章  焦油坑 234

 第2章  人月神话 235

 第3章  外科手术队伍 236

 第4章  贵族专制、民主政治和系统设计 237

 第5章  画蛇添足 238

 第6章  贯彻执行 239

 第7章  为什么巴比伦塔会失败？ 239

　　

 第8章  胸有成竹 242

 第9章  削足适履 243

 第10章  提纲挈领 244

 第11章  未雨绸缪 245

 第12章  干将莫邪 249

 第13章  整体部分 251

 第14章  祸起萧墙 252

 第15章  另外一面 254

 第1版结束语 256

第19章  20年后的《人月神话》 257

 为什么要出版20周年纪念版本 260

 核心观点—— 概念完整性和结构师 261

 开发第二个系统所引起的后果—— 盲目的功能

     和频率猜测 263

 图形界面的成功 266

 没有构建舍弃原型—— 瀑布模型是错误的！ 270

 增量开发模型更佳—— 渐进地精化 273

 关于信息隐藏，Parnas是正确的，我是错误的 277

 人月到底有多少神话色彩？Boehm的模型和数据 279

 人就是一切(或者说，几乎是一切) 281

 放弃权力的力量 283

 最令人惊讶的新事物是什么？数百万的计算机 285

 全新的软件产业—— 塑料薄膜包装的成品软件 287

 

 买来开发—— 使用塑料包装的成品软件包作为构件 290

 软件工程的状态和未来 292

结束语：令人向往、激动人心和充满乐趣的50年 295

注解与参考文献 297