第1章 焦油坑
1.1 编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。
我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。
1.2 编程为什么会有趣？作为回报，它的从业者期望得到什么样的快乐？
首先，这种快乐是一种创建事物的纯粹快乐。
其次，这种快乐来自于开发对他人有用的东西。
第三，快乐来自于整个过程中体现出的一股强大的魅力。
第四，这种快乐是持续学习的快乐，它来自这项工作的非重复特性。
最后，这种快乐还来自于在易于驾驭的介质上工作。
1.3 职业的苦恼
首先，苦恼来自追求完美，这是学习编程的最困难部分
其次，苦恼来自由他人来设定目标、供给资源和提供信息。
下一个苦恼——概念性设计是有趣的，但寻找琐碎的bug却只是一项重复性的活动。
最后一个苦恼，人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢，而产品在即将完成时总面临着陈旧过时的威胁。
这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。
第2章 人月神话
缺乏合理的时间进度是造成项目滞后的最主要原因。
导致这种普遍性灾难的原因是什么呢？
首先，我们对估算技术缺乏有效的研究，我们总是基于一种不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
2.1 所有的编程人员都是乐观主义者：“一切都将运作良好”。所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
计算机编程基于十分容易掌握的介质，编程人员通过非常纯粹的思维活动——概念以及灵活的表现形式来开发程序。正由于介质的易于驾驭，我们期待在实现过程中不会碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有bug。
2.2 我们围绕成本核算的估计技术，混淆了工作量和项目进展。用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解，因此这部分增加的工作量随人员的数量呈线性变化。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用。
从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
2.3 关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
在许多重要的方面，它与传统的进度安排方法不同：
分配给计划的时间比寻常的多。
对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
容易估计的部分，即编码，仅仅分配了六分之一的时间。
通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还能保持进度。或者说，除了系统测试，进度基本能保证。
2.4 作为一个学科，我们缺乏数据估计。因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出健壮可靠和规避风险的估计。
2.5 Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）
向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。
第3章 外科手术队伍
3.1 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。（Sackman、Erikson和Grand）
需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。这一点，也暗示系统应该由尽可能少的人员来开发。小型、精干队伍是最好的——尽可能的少。
3.2 Mills建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。即由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
Mills概念的真正关键是“从个人艺术到公共实践”的编程观念转换。它向所有的团队成员展现了所有计算机的运作和产物，并将所有的程序和数据看作是团队的所有物，而非私人财产。
这样的队伍应该包含：
外科医生。Mills称之为首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。首席程序员需要极高的天分、十年的经验和应用数学、业务数据处理或其他方面的大量系统和应用知识。
副手。他是外科医生的后备，能完成任何一部分工作，但是相对具有较少的经验。他的主要作用是作为设计的思考者、讨论者和评估人员。外科医生试图和他沟通设计，但不受到他建议的限制。
管理员。外科医生是老板，他必须在人员、加薪等方面具有决定权，但他决不能在这些事务上浪费任何时间。因而，他需要一个控制财务、人员、工作地点安排和机器的专业管理人员，该管理员充当与组织中其他管理机构的接口。
编辑。编辑根据外科医生的草稿或者口述的手稿，进行分析和重新组织，提供各种参考信息和书目，对多个版本进行维护以及监督文档生成的机制。
两个秘书。管理员和编辑每个人需要一个秘书。管理员的秘书负责项目的协作一致和非产品文件。
程序职员。他负责维护编程产品库中所有团队的技术记录。该职员接受秘书性质的培训，承担机器码文件和可读文件的相关管理责任。所有的计算机输入汇集到这个职员处。如果需要，他会对它们进行记录或者标识。
工具维护人员。保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具（特别是交互式计算机服务）的构建、维护和升级责任。
测试人员。因此，测试人员既是为外科医生的各个功能设计系统测试用例的对头，同时也是为他的日常调试设计测试数据的助手。他还负责计划测试的步骤和为测试搭建测试平台。
语言专家。语言专家寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。他通常需要对技术进行一些研究（两到三天）。通常一个语言专家可以为两个到三个外科医生服务。
3.3 传统的两人队伍与外科医生——副手队伍架构之间的区别：
首先，传统的团队将工作进行划分，每人负责一部分工作的设计和实现。在外科手术团队中，外科医生和副手都了解所有的设计和全部的代码。
第二，在传统的队伍中大家是平等的，出现观点的差异时，不可避免地需要讨论和进行相互的妥协和让步。而在外科手术团队中，不存在利益的差别，观点的不一致由外科医生单方面来统一。
另外，团队中剩余人员职能的专业化分工是高效的关键，它使成员之间采用非常简单的交流模式成为可能。
3.4 当我们需要面对几百人参与的大型任务时，如何应用外科手术团队的概念呢？
扩建过程的成功依赖于这样一个事实，即每个部分的概念完整性得到了彻底的提高——决定设计的人员是原来的七分之一或更少。
所以，可以让200人去解决问题，而仅仅需要协调20个人，即那些“外科医生”的思路。