书籍链接：https://book.douban.com/subject/26358448/
序言
书名《人月神话・40周年中文纪念版》，2015年清华大学出版社出版，但这本书其实是1995年《人月神话・20周年英文纪念版》的一个译本，这种把20年前的书翻译后称作40周年也太标题党了。那么，由上面的描述就可以推算出第一版《人月神话》，是在1975年出版的，掌握这几个时间点，有利于理解该书的历史背景。
本书第1~15章是第一版的原版内容。第16章是作者在1986年发表的一篇论文“没有银弹：软件工程的根本和次要问题”，第17章是在1995年出版纪念版时对外界关于第16章论文的一些批评进行回答，第18章是对前面第1~15章每个章节进行总结，最后第19章是与本书论点相关的短文。
第1章 焦油坑
- 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的9倍。软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又加强了3倍的工作量，这些高成本的构件在根本上是相互独立的。
- 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，其提供了五种乐趣：
- 创建事物的快乐；
- 开发对其他人有用的东西的乐趣；
- 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力；
- 面对不重复的任务，不断学习的乐趣；
- 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动——其存在、移动和运转方式完全不同于实际物体。
- 同样，这个行业具有一些内在固有的苦恼：
- 将做事方式调整到追求完美是学习编程的最困难部分；
- 由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任；
- 实际情况看起来要比这点好一些：真正的权威来自于每次任务的完成；
- 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外；
- 人们通常期望项目在接近结束时，软件项目能收敛得快一些，然而，情况却是越接近完成，收敛得越慢；
- 产品在完成前总面临着陈旧过时的威胁；只有实际需要时，才会用到最新的设想。
第2章 人月神话
- 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素的总和影响还大。
- 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
- 所有的编程人员都是乐观主义者：“一切都将运作良好”。
- 由于编程人员通过纯粹的思维活动来开发，我们期待在实现过程中不会碰到困难。
- 但是，我们的构思本身是有缺陷的，因此总会有bug。
- 围绕着成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
- 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
- 关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
- 作为一门学科，我们缺乏数据估计。
- 我们对自己的估计技术不确定，因此在管理和客户的压力下，我们常常缺乏坚持的勇气。
- Brooks法则：为进度落后的项目增加人手，只会使进度更加落后。
- 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断。培训新人员。额外的相互沟通。
第3章 外科手术队伍
- 同样有两年工作经验而且在受到同样培训的情况下，优秀的专业程序员的生产率是较差的程序员的10倍。
- 小型、精干队伍是最好的——思绪尽可能少。
- 两个人的团队，其中一个人是领导者，常常是最佳的人员使用方法。
- 对于真正意义上的大型系统，小型精干的队伍太慢了。
- 实际上，绝大多数大型编程系统的经验显示，一拥而上的开发方法是高成本、速度缓慢、低效的，开发出的产品无法进行概念上的集成。
- 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产效率，还彻底地减少了沟通的工作量。
第4章 贵族专制、民主政治和系统设计
- “概念完整性是系统设计中最重要的考虑因素。”
- “功能与理解上的复杂程度的比值才是系统设计的最终测试目标。而不仅仅是丰富的功能。（该比值是对易用性的一种测量，由简单和复杂应用共同验证。）
- 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
- “对于非常大型的项目。将体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。”（其同样适用于小型项目。）
- “如果要得到系统概念上的完整性。就必须有人控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。”
- 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
- 概念上统一的系统能更快的开发和测试。
- 体系结构、设计实现、物理实现的许多工作可以并行。
第5章 画蛇添足
- 尽早交流和持续沟通能使结构师有较好的成本意识，使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
- 结构师如何成功的影响实现：
- 牢记是开发人员承担创造性地实现责任。结构师只能提出建议。
- 时刻准备着为所指定的说明建议一种实现的方法。准备接受任何其他可行的方法。
- 对上述建议保持低调和平静。
- 准备对所建议的改进放弃坚持。
- 听取开发人员在体系结构上改进的建议。
- 第二个系统是人们所设计的最危险的系统。通常的倾向是过分地进行设计。
- OS/360是典型的画蛇添足的例子。(Windows NT似乎是20世纪90年代的例子。)
- 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。
第6章 贯彻执行
- 即使是大型的设计团队。设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
- 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
- 出于精确性的考虑，我们需要形式化地设计定义；同样，我们需要记叙性定义来加深理解。
- 必须采用形式化定义和记叙性定义中的一种作为标准。另一种作为辅助措施；他们都可以作为表达的标准。
- 设计实现，包括模拟仿真，可以充当一种体系结构的定义；这种方法有一些严重的缺点。
- 直接整合是一种强制推行软件的结构性标准的方法。
- “如果起初至少有两种以上的实现，体系结构定义会更加整洁和规范。”
- 允许体系结构师对实现人员的询问做出应答解释是非常重要的，并且必须进行日志记录和整理发布。
- “项目经理最好的朋友就是他每天要面对的对手。独立的产品测试机构/小组。”
第7章 为什么巴比伦塔会失败
巴比伦塔项目的失败是因为缺乏交流以及交流的结果——组织。
交流
- “因为左手不知道右手在做什么。从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于存在对其他人的各种假设，团队成员之间的理解开始出现偏差。
- 团队应该以尽可能多的方式进行相互之间的交流。非正式的进行简要技术陈述的常规项目会议，共享的正式项目工作手册。
项目工作手册
- 项目工作手册“不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构”。
- “项目所有的文档都必须是该工作手册结构的一部分。”
- 需要尽早和仔细地设计工作手册结构。
- 事先制定良好结构的工作手册，可以将后来书写的文字放置在合适的章节中，并且可以提高产品手册的质量。
- 每个团队成员应该能够看到所有材料。
- 实时更新是至关重要的。
- 工作手册的使用者应该将注意力集中在上次阅读后的变更以及关于这些变更重要性的评述上。
- Parnas强烈的认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者被允许看到其他部分的内部结构，只需要了解接口。
组织架构
- 团队组织的目标是为了减少必要的交流和协作量。
- 为了减少交流，组织结构包括了人力划分和限定职责范围。
- 传统的树状组织结构反映了权力的结构原理——不允许双重领导。
- 组织中的交流是网状而不是树状结构，因此所有的特殊组织机制（往往体现为组织结构图中的虚线部分）都是为了进行调整，以克服树状组织结构中交流缺乏的困难。
- 每个子项目具有两个领导角色——产品负责人，技术主管或结构师。这两个角色的职能有很大的区别，需要不同的技能。
- 两种角色的任意组合都可以是非常有效的：
- 产品负责人和技术主管是同一个人；
- 产品负责人作为总指挥，技术主管充当其左右手；
- 技术主管作为总指挥，产品负责人充当其左右手。
结束语
- 软件系统可能是人类创造中最错综复杂的事物。
- 软件工程的焦油坑在将来很长一段时间内仍然会使人们举步维艰，无法自拔。
总结
本书虽然一共有19章节，但是精华部分在第2~7章，后续章节则探讨了软件工程管理的其他方面。作者向我们表达了几个重要的观点：1. 程序员总是乐观的，总是假设船到桥头自然直。 2. 人月神话，人们错误地认为1个人工作10个月的工作量，10个人工作1个月就可以完成。3. 开发团队应该向外科手术团队一样，队伍小型且精干，由一位架构师领导。4. 概念完整性，由架构师统一系统概念，保证整体系统体现的是一套完整的设计理念。
