推荐理由：

作为一部在软件领域40年畅销不衰的传奇经典，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验，该项目堪称软件开发项目管理的典范。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位，被誉为软件开发人员、软件项目经理、系统分析师必藏之软工圣经。

本书要点：

第一章 焦油坑

将大型系统的开发比做史前时代的焦油坑，如被其吞噬的成千上万个力大无穷的巨兽一样，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。向我们阐述了程序、编程产品、编程系统产品这三个按开发目标、规模不同而划分的程序员得出软件程序产品，进而指出由这个带来的无穷乐趣和行业苦恼的根源。

第二章 人月神话

项目滞后的众多原因中最主要的是缺乏合理的时间进度，这比其他因素综合起来还要大。指出几个错误的思考方式：一、所有的编程人员都是乐观主义者：“一切都将运作良好”；二、估计和进度安排中使用人月来作为工作量单位，而这个危险带有欺骗性的度量暗示人员数量和时间是可以互相替换的，这种错误的暗示忽视了人员之间的交流以及任务分解存在次序限制。提出了Brooks法则：向滞后的软件项目追加人手会使得进度更加落后。

第三章 外科手术队伍

优秀的程序员的成产率平均比较差程序员的高达10倍，但纯粹由优秀的程序员组成的小型、精干队伍对于大型系统来说又太慢了。优秀的大型优秀团队需要合理的配置，本章推荐大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。

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

概念的完整性是系统设计总最重要的因素，关乎项目能否顺利进行，为了达到概念的完整性，架构设计由精简的架构设计小组及负责所谓的贵族专制统治，而这不是否定实现人员的创造性，只是具体实现则围绕核心概念展开，是另一种创造，彰显了民主政治，架构设计和具体实现既相分离，又相辅相成。

第五章 画蛇添足

第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计，成为画蛇添足的牺牲品。为了避免这种冒进错误，要运用特别的自我约束准则来避免功能上的过于修饰，根据系统基本理念及目标变更舍弃一些功能，开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。

第六章 贯彻执行

为保持系统概念上的完整性，须确保每个人听到、理解并实现结构师的决策。本章以System 360的开发经验为例介绍了文档化的规格说明—手册的重要性，采用形式化定义、会议、大会、电话日志等技术确保概念被精确地定义传达贯彻执行。同时提出独立的测试小组也是在系统设计实施中重要的保障环节。

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

以巴比伦塔失败为例，指出交流和交流的结果－组织是成功的关键，交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。如果缺乏良好有效的沟通和协作，成员间难以有效的配合，团队项目的目标就无法实现。清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。

第八章  胸有成竹

仅仅对编码部分的估计是无法的得出整个任务的估计，编码部分只占问题的1/6左右，测试和调试时间更多。同时独立小型程序的数据不适用于编程系统产品。

第九章 削足适履

规模是软件系统成本的重要组成部分，开发人员设置规模目标，控制成本，合理减小不必要规模是设计人员重要的职责。使软件系统在资源有限的情况下依然保证了良好的性能，从而实现良好的可伸缩性和健壮性，巧妙的数据表现形式往往能大幅度地俭省资源耗费，提高系统运行的性能，是编程的根本。

第十章  提纲挈领

强调了在软件项目开发过程中文档的重要性。文档能记录决策，消除分析，使决策清晰明确；也可以作为沟通的渠道；作为数据基础和检查列表。介绍了项目中比较重要的几种文档。

第十一章 未雨绸缪

唯一不变的就是变化本身，对于大多数项目第一个开发的系统并不合用，为舍弃而计划。要为变更设计系统，计划组织架构。设计可替代的，易修改的接口，程序更能减少维护的成本。即使最熟练的软件维护工作也只是放缓系统退化的进程，因此要时刻未雨绸缪。

第十二章 干将莫邪

本章强调了软件开发项目所选择的技术和工具对保障项目能否令人满意地如期完成的重要性。我们应当同时合理运用个性化和公共通用编程开发工具、评测技术，为此需要制定一套合理的策略。本章提供了当年软件开发项目选择技术和工具的重要原则和建议。

第十三章 整体部分

本章细致介绍了如何开发一个可运行系统，测试系统，系统集成。我应当具体深入了解系统所有的局部设计的精确定义和技术，采用测试规格说明，自上而下的设计，结构化编程，构件单元测试等技术开发系统。实际工作中测试越早，集成越早代价更小，更早消灭隐患。采用一次添加一个构件。

第十四章 祸起萧墙

项目进度的滞后经常来自不易察觉的点滴延误的累积。设置里程碑可以有效帮助管理进度，但是其本身必须清晰明确可度量，不要自身变成负担。经理在管理进度时需减少角色的冲突，使报告更真实或者采用猛拉地毯形式时刻关注，采用关键路径图等技术观察进度合理调控。

第十五章 另一面

公共程序用户与作者时空上都存在巨大距离，因此对于这类程序文档就很重要，故而提供给用户的使用说明等文档是软件呈现给用户的另外一面，这也能直接影响用户对软件的满意度和可用性评价。文档内容取决于用户需求：使用程序、验证程序、修改程序，形式有流程图、自动文档化的程序（建立在高级编程语言之上）。

第十六章 没有银弹－软件工程中的根本和次要问题

本章提出软件工程中存在根本问题与次要问题之分，而只有解决根本问题才能极大提高生产率，而这种解决方法称之为“银弹”。由于软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。接着介绍了二十世纪80年代前期为业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具备的优势和缺憾。给出了作者的结论：没有任何单独的软件工程进展可以使软件生产率有数量级的提高。

第十七章 再议“没有银弹”

本章在“没有银弹”发表多年之后，结合20世纪80年代后期到90年代前期之间软件复用、面向对象程序开发等等新技术的发展状况，回应了对《没有银弹》一文各种主要异议坚持了原文的观点。

第十八章 《人月神话》的观点：是与非

本章为作者对初版中十五个章节中概要的提炼和结合近年来软件技术的发展状况，对这些观点进行强调、修正和反思。

第十九章 人月神话二十年

“ 在《人月神话》初版发布二十周年后，计算机技术领域已有很大变化，《人月神话》体现出深远的影响力，初版中的许多观点依然经常被人们谈论和引用，其中有些断言至今仍被软件开放人员奉为圭臬。作者结合当前软件工程领域的发展现状重新梳理了初版中的各核心观点，强调了概念完整性，重新评议了第二个系统效应，反省了瀑布模型的局限性，结合初版中的观点，作者评述了图形桌面系统、信息隐藏、面向对象高级语言等技术的发展，以及近年来软件工程领域的重要成果。”

——引用自书评。

书摘：

首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样,成年人喜欢创 建事物,特别是自己进行设计。我想这种快乐是上帝创造世界的折射,一种呈现在每片独特、 崭新的树叶和雪花上的喜悦。

简单、武断地重复一下Brooks法则: 向进度落后的项目中增加人手,只会使进度更加落后。(Adding manpower to a late software project makes it later)

风格的一致和完整性来自8代拥有自我约束和牺牲精神的建筑师们,他们每一个人 牺牲了自己的一些创意,以获得纯粹的设计。同样,这不仅显示了上帝的荣耀,同时也体现 了他拯救那些沉醉在自我骄傲中的人们的力量。

如果要得到系统概念上的完整性,那 么必须控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。

结构师如何避免画蛇添足——开发第二个系统所引起的后果(second-system effect)?是的,他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险,运用特 别的自我约束准则,来避免那些功能上的修饰;根据系统基本理念及目的变更,舍弃一些功 能。

项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。该 小组根据规格说明检查机器和程序,充当麻烦的代言人,查明每一个可能的缺陷和相互 矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门,来保证其公正性。

编程人员仅了 解自己负责的部分,而不是整个系统的开发细节时,工作效率最高。这种方法的先决条件是 精确和完整地定义所有接口。这的确是一个彻底的解决方法。如果能处理得好,的确是能解 决很多“灾难”。一个好的信息系统不但能暴露接口错误,还能有助于改正错误。

交流和交流的结果— —组织,是成功的关键。交流和组织的技能需要管理者仔细考虑,相关经验的积累和能力的 提高同软件技术本身一样重要。

实际上,数据的表现形式是 编程的根本。

然而,目标上的一些变化无可避免,事先为它们做准备总比假设它们不会出现要好得 多。不但目标上的变化不可避免,而且设计策略和技术上的变化也不可避免。抛弃原型概念 本身就是对事实的接受——随着学习的过程更改设计 。

系统软件开发是减少混乱度(减少熵)的过程,所以它本身是处于亚稳态的。软件维 护是提高混乱度(增加熵)的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化 到非稳态的进程。

所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构,次要任务 ——使用编程语言表达这些抽象实体,在空间和时间限制内将它们映射成机器语言。

不仅仅是在目力所及的范围内,没有发现银弹,而且软件的特性本身也导致了不大可 能有任何的发明创新——能够像计算机硬件工业中的微电子器件、晶体管、大规模集成一样 ——提高软件的生产率、可靠性和简洁程度。我们甚至不能期望每两年有一倍的增长。

夏明瑞 MF1632082