人月神话(40周年中文纪念版)

书名：人月神话(40周年中文纪念版)软件工程师经典读本不可错过的名著
作者：(美)布鲁克斯(Brooks,F.P.)著
译者：UMLChina翻译组，汪颖译
ISBN：9787302392644
出版社：清华大学出版社
出版时间：2015-4-1
格式：epub/mobi/azw3/pdf
页数：392
豆瓣评分： 8.3

书籍简介：

在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。 在本书第一次出版40年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享，更使本书成为国内从业者的必读经典之一。 本书读者包括：软件开发人员、软件项目经理、系统分析师等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)。

书友短评：

@ 胖冬瓜 最早以为这本书是讲阿波罗计划的，万万没想到是关于软件工程项目的。除去“没有银弹”和“再论‘没有银弹’”外，全书提到的点，没有比书本身的第18章总结的更到位的，也就不再赘述了。这是本常看常新的书，会发现目前的项目和快六十年前的项目二者遇到的问题似曾相识。书并没有提出什么根本的解决方法，毕竟软件工程项目作为一种创造性的艺术产物，它的复杂性一致性可变性和不可见性导致了困难重重。到现在也没有什么革命性的突… 最早以为这本书是讲阿波罗计划的，万万没想到是关于软件工程项目的。除去“没有银弹”和“再论‘没有银弹’”外，全书提到的点，没有比书本身的第18章总结的更到位的，也就不再赘述了。这是本常看常新的书，会发现目前的项目和快六十年前的项目二者遇到的问题似曾相识。书并没有提出什么根本的解决方法，毕竟软件工程项目作为一种创造性的艺术产物，它的复杂性一致性可变性和不可见性导致了困难重重。到现在也没有什么革命性的突破。书带给你的是思考，让你审视目前的工作，是否可以做的更好。这种思考是进步的动力。 @ 神威 1975年出的软件项目管理方面的随笔性质书籍，这不是一本完整软件项目过程管理的书，而是作者在完成某个项目后的工作感想。虽然40年过去了有些东西已经过时，但是很多理论现在还有借鉴价值，看的时候真的在感叹就算到了现在很多软件从业者连基本的原因都不懂，还没别人40年前认识高。 @ 灵茶山艾府 配合《大教堂与集市》阅读。 @ 国王KING 作者就是那个提出银弹理论的人啊…… @ 孙雄飞 2020 No.041 软件开发是一个变化非常快的领域，越是变化快的领域，老经验的重要性越是微不足道，《人月神话》已经45岁高龄，很多教诲也如同老奶奶的忠告，显得有点过时，毕竟在软件工程领域，40年前和今天云原生时代有着天壤之别。但是我还是毫不犹豫地给予这本书5星，不仅仅是因为其40多年来对软件工程领域的贡献，更因为这本书里还是有很多价值观和方法论对今天的软件工程有新意，就比如书中提到“软件开发者… 2020 No.041 软件开发是一个变化非常快的领域，越是变化快的领域，老经验的重要性越是微不足道，《人月神话》已经45岁高龄，很多教诲也如同老奶奶的忠告，显得有点过时，毕竟在软件工程领域，40年前和今天云原生时代有着天壤之别。但是我还是毫不犹豫地给予这本书5星，不仅仅是因为其40多年来对软件工程领域的贡献，更因为这本书里还是有很多价值观和方法论对今天的软件工程有新意，就比如书中提到“软件开发者最终交付物不应该是产品，而应该是用户满意度”直到今天还应该会对很多开发人员带来价值观的冲击。 @ 布谷咕噜咕噜 几十年过去，大家还在焦油坑挣扎… @ 国王KING 作者就是那个提出银弹理论的人啊…… @ 超级峰 举例有点过时，作者主要做的也是互联网底层相关，所以，迁移到现在的互联网，方法一部分不一定适用，例如外科手术团队规划里配备2名秘书，在快速迭代互联网团队难以落地。不过，对于迷信人月的项目规划导致的风险也让人信服，“往进度延期的项目中加人往往达不到效果”，因为增加的老人消耗的时间成本，新人带来的沟通成本，都是造成的原因。最后，也通过策划、研发、单元测试、集成测试大概比例如3366，表明，测试修复bug… 举例有点过时，作者主要做的也是互联网底层相关，所以，迁移到现在的互联网，方法一部分不一定适用，例如外科手术团队规划里配备2名秘书，在快速迭代互联网团队难以落地。不过，对于迷信人月的项目规划导致的风险也让人信服，“往进度延期的项目中加人往往达不到效果”，因为增加的老人消耗的时间成本，新人带来的沟通成本，都是造成的原因。最后，也通过策划、研发、单元测试、集成测试大概比例如3366，表明，测试修复bug环节应该占据绝大多数项目时间（与目前主导的一个项目的过程不谋而合） @ 小白 读完之后再次感叹，中美之间在归纳总结、理论研究方面的巨大鸿沟。美国在70年代就已经有人思考工作量以人/月方式计算的问题，以及项目研发过程中遇到的问题已经归纳总结，并形成文字出版，把遇到的问题理论化后供大家思考改进。反观国内，互联网大厂也许有这样的人，但银行内的科技，还处在美国70年代的水平，甚至还不如，不得不让人感慨啊。国内的体制，专业的人出路很窄，除非出类拔萃，也就导致了领导者们主要都是做管… 读完之后再次感叹，中美之间在归纳总结、理论研究方面的巨大鸿沟。美国在70年代就已经有人思考工作量以人/月方式计算的问题，以及项目研发过程中遇到的问题已经归纳总结，并形成文字出版，把遇到的问题理论化后供大家思考改进。反观国内，互联网大厂也许有这样的人，但银行内的科技，还处在美国70年代的水平，甚至还不如，不得不让人感慨啊。国内的体制，专业的人出路很窄，除非出类拔萃，也就导致了领导者们主要都是做管理的，搞理论、专业研究的凤毛麟角。希望我们的国家，各行各业，也能崇尚技术，尊重技术，从而走上良性循环，少一点官僚行政作风。 @ ManiaJack 第一次读，自己其实还没到项目管理的那个地步，而且只是在地铁上的阅读，没有记录任何笔记，有些内容是能够理解的，而另一部分内容不是特别理解。是一本好书，值得买回来再看一遍，希望我下次再看的时候能收获更多。

第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
电话日志 68
产品测试 69
第7章 为什么巴比伦塔会失败 71
巴比伦塔的管理教训 75
大型编程项目中的交流 76
项目工作手册 76
大型编程项目的组织架构 80
第8章 胸有成竹 85
Portman的数据 89
Aron的数据 90
Harr的数据 90
OS/360的数据 92
Corbató的数据 93
第9章 削足适履 95
作为成本的程序空间 98
规模控制 99
空间技能 100
数据的表现形式是编程的根本 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
摘要 184
介绍 184
根本困难 185
以往解决次要困难的一些突破 190
银弹的希望 192
针对概念上根本问题的颇具前途的方法 200
第17章 再论“没有银弹” 209
人狼和其他恐怖传说 212
存在着银弹—— 就在这里 212
含糊的表达将会导致误解 213
Harel的分析 216
Jones的观点—— 质量带来生产率 221
那么，生产率的情形如何 222
面向对象编程—— 这颗铜质子弹可以吗 223
重用的情况怎样 225
学习大量的词汇—— 对软件重用的一个可预见但还没有被预言的问题 228
子弹的本质—— 形势没有发生改变 229
第18章 《人月神话》的观点：是与非 231
第1章 焦油坑 234
第2章 人月神话 235
第3章 外科手术队伍 236
第4章 贵族专制、民主政治和系统设计 237
第5章 画蛇添足 238
第6章 贯彻执行 239
第7章 为什么巴比伦塔会失败 240
第8章 胸有成竹 242
第9章 削足适履 243
第10章 提纲挈领 245
第11章 未雨绸缪 246
第12章 干将莫邪 249
第13章 整体部分 251
第14章 祸起萧墙 253
第15章 另外一面 255
第1版结束语 256
第19章 20年后的《人月神话》 257
为什么要出版20周年纪念版本 260
核心观点—— 概念完整性和结构师 261
开发第二个系统所引起的后果—— 盲目的功能和频率猜测 263
图形界面的成功 265
没有构建舍弃原型—— 瀑布模型是错误的 269
增量开发模型更佳—— 渐进地精化 272
关于信息隐藏，Parnas是正确的，我是错误的 276
人月到底有多少神话色彩？Boehm的模型和数据 278
人就是一切(或者说，几乎是一切) 280
放弃权力的力量 281
最令人惊讶的新事物是什么？数百万的计算机 283
全新的软件产业—— 塑料薄膜包装的成品软件 286
买来开发—— 使用塑料包装的成品软件包作为构件 288
软件工程的状态和未来 290
结束语：令人向往、激动人心和充满乐趣的50年 293
注解与参考文献 295
附录：人月落地实战体验 315
一、名家谈人月 317
1. 年金 317
2. 《人月神话》与实践 318
3. Frank Chance评人月 327
4. 软件尚方宝剑(Silver Bullet)何在 330
二、名著评人月 339
三、读者感言 351
1. 读书有感——人月神话 351
2. 我这几天很烦(产品概念完整性) 353
3. 关于我们的思考——“项目开发”及读《人月神话》有感 355
4. 我的“人月神话” 358
5. 《人月神话》软玉生香 360
· · · · · ·

添加微信公众号:好书天下获取