具体描述
在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。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)。
目录信息
编程系统产品 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
· · · · · · (收起)
读后感
如果你是技术出身的管理人员，看完了会有这样的感慨。。。丫什么都没说吧。。。:) 所以也没记住什么。。。唯一有些印象的是原版中反对封装，后来事实证明他错了。:)不过作者能坦率的承认也实在值得我们学习。 另外，而对于人月神话这个著名的命题，太理想化了。 很多时候，de...
评分历史对于现实有很重要的借鉴作用。 虽然我对编程一无所知，但是我还是打算找一本来读，各行各业很多知识都是相通的 以史为鉴，可知过往，可知兴衰。
评分我是在 03年春节回家在火车上看这本书的，其实书早买了，我当时还只是一个普通的程序员，因此，觉得看这本书还不是很必要。后来我做了项目经理，很多工程以及管理方面的理念都是来自于这本书，很长了，我只能凭借我的记忆基于我的理解来谈谈。 软件的现状是什么样的？文中认为...
评分本评论转自我的Blog 转载必须包含本声明、保持本文完整。并以超链形式注明作者编程随想和本文原始地址： http://program-think.blogspot.com/2009/03/book-review-mythical-man-month.html 对于软件工程而言，我个人认为到目前为止，尚未有哪本书的影响力和深刻程度能够超越《...
评分作为软件工程的经典著作，《人月神话》的主要贡献是对软件开发过程的几个重要关键点，提出了独到的见解。 这几个关键内容就是： （1）提倡外科手术式的团队组织： [在软件开发组织上的过份民主，往往带来的是没有效率和责任，参与其中的人想法太多，层面参差不齐...
用户评价
#本来可以用一章就写完，偏要写一本书
评分缺乏合理的时间进度是造成项目滞后的主要原因。人月暗示了人员数量和时间是可以相互替换的，混淆了工作量和项目进展。进度安排是1/3计划、1/6编码、1/4构件测试以及1/4系统测试。为进度落后的项目增加人员只会拖后进度（任务重新分配、培训新人员、额外的沟通）。首席程序员带领一个外科手术队伍、小型精干的团队是最好的，少数结构师保证了产品的概念完整性（系统设计最重要的因素），其他协助人员保证了生产率，概念统一能加快开发和测试，体系结构、设计实现和物理实现的工具可以并行。项目会失败的首要原因是缺乏网状的交流和协作，必须进行人力和职责划分。软件项目要明确目标、用户手册、内部文档、进度、预算、规模组织结构和工作空间分配。没有银弹=没有任何单独的软件工程进展可以使软件生产率有数量级的提高。SY
评分第一遍
评分看前半本的时候有打两三星的冲动，在当下原书也只有最后几章值得一读了，最后几章翻译相对也没那么差。
评分在合适的时间读到合适的书是一种幸运，有限的读书经验使我认为很多事情必有实际经历才能产生更深的理解与共鸣。本书中关于项目复杂度、规划的乐观性、沟通重要性、组织的形式和冲突、任务执行的关键、 文档的作用和构成以及其在不同阶段的角色，都深有感触。仅将此书推荐给软件工程的项目管理者实在是浪费，应该给更广泛的复杂系统开发管理者。#原来此书和Project Apollo并没有一毛钱关系，火车上六小时看完
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 book.quotespace.org All Rights Reserved. 小美书屋 版权所有