要点

1. 团队组织：提倡外科手术队伍，在软件开发组织上过分民主，往往带来的是没有效率和责任。
2. 概念完整性：软件项目的核心概念只能由很少的人来完成，以保证概念的完整性。
3. 沟通手段：软件开发中最大的风险往往不是技术的缺陷，而是缺少沟通。
4. 进度控制：人月是带有欺骗性质的神话，向落后的项目中加人手只会使进度更落后。
5. 过程管理：文档包含了管理方面的工作，避免了无休止的混乱状态。
6. 没有银弹：在软件开发过程中，只有适度的改进，没有万能的银弹。

书摘

第一章：焦油坑

1. 编程系统产品的成本高达程序的九倍，但是编程系统产品才是真正有用的产品，是大多数系统开发的目标。

第二章：人月神话

1. 缺乏合理的时间进度是造成项目滞后的最主要原因。导致这种普遍性灾难的原因包括： o* 对估算技术缺乏有效的研究 o* 采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆 o* 对估算缺乏信心，没有进行持续的估算 o* 对进度缺少跟踪和监督 o* 当意识到进度的偏移时，下意识的反应是增加人力
2. 介质的易于驾驭造成了乐观主义的弥漫，但构思是有缺陷的，总会有 bug 。在大型的编程工作中，一切顺利的概率非常小。
3. 用人月作为衡量一项工作的规模是一个危险和带有欺骗性质的神话。它暗示着人员数量和时间是可以相互替换的。
4. 作者对于软件任务进度安排的经验法则：1/3 计划；1/6 编码；1/4 构件测试和早期系统测试；1/4 系统测试，所有的构件已完成。
5. Brooks 法则：向进度落后的项目中增加人手，只会使进度更加落后。

第三章：外科手术队伍

1. 需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当引起的不良结果。这一点也暗示系统应该由尽可能少的人员来开发。
2. 外科手术队伍：十个人，其中七个专业人士在解决问题，而系统是一个人或者最多两个人思考的产物，因此客观上达到了概念的一致性。
3. 团队扩建过程的成功依赖于这样一个事实：每个部分的概念完整性得到了彻底的提高——决定设计的人员是原来的七分之一或更少。

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

1. 概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
2. 体系结构同实现必须仔细地区分开来。
3. 整个创造性活动包括了三个独立的阶段：体系结构、设计实现、物理实现。在实际情况中，它们往往可以同时开始和并发地进行。

第五章：画蛇添足

1. 结构师的交互准则： o* 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配 o* 时刻准备为指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法 o* 对上述的建议保持低调和平静 o* 准备放弃坚持所做的改进建议
2. 第二个系统是设计师们所设计的最危险的系统。一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法。

第六章：贯彻执行

1. 同时使用形式化定义和记叙性文字，一种作为标准，另一种作为辅助。
2. 如果起初至少有两种以上的实现，那么定义会更加整洁和规范。

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

1. 团队交流沟通的途径：非正式途径；会议；工作手册。
2. 团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。
3. 减少交流的方法是人力划分和限定职责范围。

第八章：胸有成竹

1. 构建独立小型程序的数据不适用于编程系统产品。
2. 生产率会根据任务本身复杂度和困难程度表现出显著差异。
3. 对常用编程语句而言，生产率似乎是固定的；使用适当的高级语言，编程的生产率可以提高5倍。

第九章：削足适履

1. 规模控制 o* 和制订驻留空间预算一样，应该制订总体规模的预算；和制订规模预算一样，应该制订后台存储访问的预算 o* 在指明模块有多大的同时，确切定义模块的功能 o* 培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能
2. 空间技能 o* 用功能交换尺寸 o* 考虑空间—时间的折中
3. 数据的表现形式是编程的根本。

第十章：提纲挈领

1. 只有一小部分管理人员的时间用来从自己头脑外部获取信息。其他的工作是沟通：倾听、报告、讲授、规劝、讨论、鼓励。不过，对于基于数据的部分，少数关键的文档是至关重要的。

第十一章：未雨绸缪

1. 将原型发布给用户，可以获得时间，但是它的代价高昂。为舍弃而计划。
2. 唯一不变的就是变化本身。
3. 为变更计划系统：高级语言、自文档技术、调用队列、表驱动等等。
4. 对于一个广泛使用的程序，其维护成本通常是开发成本的 40% 或更多。该成本受用户数目的严重影响。用户越多，所发现的错误越多。
5. 程序维护中的一个基本问题：缺陷修复总会以（20-50）% 的机率引入新的 bug 。

第十二章：干将莫邪

1. 开发和维护公共的通用编程工具的效率更高。每个团队应配备一名工具管理人员。

第十三章：整体部分

1. 好的自顶向下设计从多个方面避免了 bug 。
2. 系统调试仅仅应该在所有部件能够正常运作之后开始。
3. 系统测试期间，一次只添加一个构件。

第十四章：祸起萧墙

1. 里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。
2. PERT 技术是关键路径计划的细化。 PERT 图展示某人为了使自己的工作远离关键路径需要超前多少，也建议了补偿其他部分失去的时间的方法。
3. 减少角色冲突和鼓励状态共享。
4. 拥有能够了解状态真相的评审机制是必要的， PERT 图以及频繁的里程碑是这种评审的基础。

第十五章：另外一面

1. 自文档化，即把文档整合到源代码，这对正确维护是直接有力的推动，保证编程用户能方便、即时地得到文档资料。

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

1. 所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。
2. 软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。
3. 现代软件系统中无法规避的内在特性：复杂度、一致性、可变性和不可见性。
4. 以往解决次要困难的一些突破：高级语言、分时、统一编程环境。
5. 银弹的希望：高级语言、面向对象编程、人工智能等。
6. 构建软件最可能的彻底解决方案是不开发任何软件。

再论《没有银弹》

1. “关注质量，生产率自然会随着提高。”“系统化软件开发方法的发展是为了解决质量问题（特别是避免大型的灾难），而不是处于生产率方面的考虑。”

20 年后的人月神话

1. 概念完整性是产品质量的核心，拥有一位结构师是迈向概念完整性的最重要一步。
2. 没有构建舍弃原型——瀑布模型是错误的。
3. 代码模块应该是采用定义良好的接口来封装，这些模块的内部结构应该是程序员的私有财产，外部是不可见的。
4. 彻底提高软件健壮性和生产率的唯一途径，是提升一个级别，使用模块或者对象组合来进行程序的开发。

作者简介

弗雷德里克·布鲁克斯（Frederick P. Brooks, Jr.）是北卡罗莱纳大学Kenan-Flagler商学院的计算机科学教授。他曾荣获图灵奖，美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献。”