《人月神话》读书笔记

一、书名和Brooks

• 《人月神话》是由Fred Brooks所著，他是一位让人非常尊敬的计算机科学家，也是软件工程领域的先驱。他在60年代（在他29岁时）主持并完成了IBM 360系统的开发。IBM 360后来被誉为是人类从原子能时代进入信息时代的标志。该项目不光具有历史意义，而且在软件工程方面非常有代表性（因为其规模和复杂度）。虽然最终IBM 360项目并没有完成全部的预定目标，但是对于这个史无前例的项目，居然没有中途夭折，本身已经算是奇迹了。后来，Brooks在1975年（距今已30多年）把他所写的一些软件工程方面的随笔（很多都与360项目有关）整理出版，也就是我们今天点评的《人月神话》。1

二、书籍概览

• 主要论点和结构

我认为《人月神话》的主要论点是：在软件开发项目中，简单地增加人力资源无法直接缩短项目时间，因为引入新人员需要时间来学习、适应和协调，从而导致更多的沟通和协调成本。Brooks也就是Brooks认为软件开发是一项复杂协作的活动，需要综合考虑多个因素来提高项目成功的机会。前言中Brooks说当年是把他写过的一些随笔整理出书的，所以书中的各个章节相对来说比较独立。因此我觉得不一定按照排版的顺序来阅读。但是如果要按照结构划分的话，我觉得这本书的结构主要可以分为三个部分：**（1）第一部分介绍了软件开发中的困境和挑战。Brooks讨论了软件复杂性、项目进度和质量的权衡、人员需求的估计和软件工程的学科性质等问题；（2）第二部分提出了一些解决方案和管理原则。Brooks讨论了需求分析、进度估计、接口定义、协调会议、原型开发等方法和技巧，以帮助提高软件开发项目的效率和成功率；（3）**第三部分探讨了软件复用、管理者的角色和责任、项目中的风险管理等主题。Brooks讨论了软件复用的挑战、管理者在项目中的重要性以及如何应对项目中的风险。

• 目标读者和应用场景

1. 目标读者

《人月神话》的目标读者主要是软件开发领域的从业者，比如与软件开发项目相关的技术人员、产品经理和项目经理。这本书比较适合那些对软件开发项目管理和团队协作感兴趣的人，以及想要提高软件开发项目效率的员工和同学。此外，该书也对计算机科学、软件工程以及项目管理领域的学生和研究人员（比如我们软件工程还有计算机类相关的研究生）有一定的参考价值。

2. 应用场景

这本书可以应用的场景有很多，几乎都是和项目整个流程息息相关。（1）软件开发项目管理：《人月神话》的原则和观点适用于各种规模的软件开发项目，包括大型企业级项目和小型团队项目。它提供了关于需求分析、进度估计、资源分配、协调沟通和风险管理等方面的指导。 （2）软件团队协作：书中讨论的团队协作原则和实践对于软件开发团队非常重要。它强调合作、沟通、协调和知识共享的重要性，帮助团队成员更好地协作合作，提高工作效率和质量。 （3）项目进度和资源管理：《人月神话》中提到的关于项目进度和资源管理的观点对于项目经理和团队领导者非常有价值。它帮助他们更好地规划和管理项目时间表、资源分配和工作量，以提高项目的成功率。 （4）软件工程教育：《人月神话》作为软件工程的经典著作，可以作为软件工程教育的参考书。它帮助学生了解软件开发项目管理的挑战和解决方案，培养他们的软件工程思维和实践能力。 （5）软件行业顾问和管理咨询师：对于软件行业的顾问和咨询师，他们经常需要提供关于软件开发项目管理的建议和指导。《人月神话》中的观点和经验可以为他们提供宝贵的参考，帮助他们更好地理解客户需求并提供解决方案。

三、核心观点与主题

1. 人月神话

《人月神话》中的核心观点之一是人月神话，即认为在软件项目中增加人力资源并不能缩短项目的时间。

• 子观点1：通信成本的增加

**理解：**在软件开发项目中，团队成员之间的沟通是至关重要的。当增加人力资源时，沟通复杂性也会增加，因为每个新成员都需要与其他成员进行交流、协调和理解。**实例：**在一个软件开发团队中，原本只有几个人的团队决定突然增加了十几个新成员。新成员加入后，团队内部的沟通变得困难，导致项目进度延迟，因为每个人都需要花更多的时间来协调和理解其他成员的工作。

• 子观点2：学习曲线和培训成本

**理解：**新成员加入项目后，需要一定的时间来学习项目的背景、技术栈和工作流程。这涉及到培训和知识传递的成本。**实例：**一个软件开发团队在项目中迅速增加了几名新成员，但这些新成员对项目的技术栈和领域知识并不熟悉。因此，团队其他成员需要花费大量时间来培训和帮助他们适应项目，这导致了项目进度的延迟。

• 子观点3：任务分配和协调复杂性

**理解：**随着团队规模的增加，任务的分配和协调变得更加复杂。不同成员之间的工作可能会产生依赖关系，需要进行统筹和协调，以确保各项任务按时完成。**实例：**一个软件开发项目中，原本只有一个开发人员负责一个特定的模块。随着团队规模的扩大，该模块被分配给了多个开发人员负责，但由于缺乏有效的协调和沟通，导致模块集成的困难和进度延迟。

2. 软件开发复杂性

• 子观点1：任务间的依赖关系

**理解：**在软件开发项目中，不同任务之间通常存在复杂的依赖关系。完成一个任务可能需要先完成其他任务或依赖其他任务的结果。**实例：**在一个电子商务网站的开发项目中，设计和开发数据库必须在前端界面的编写之前完成。如果团队过于关注前端界面的开发而忽视了数据库的设计和开发，将导致项目延迟，因为前端界面无法正常工作。

• 子观点2：技术复杂性

**理解：**现代软件开发通常涉及复杂的技术和工具。掌握这些技术需要时间和经验，并且在开发过程中可能会遇到技术上的挑战。**实例：**在一个移动应用开发项目中，团队决定使用新兴的跨平台开发框架进行开发。然而，该框架存在一些技术上的限制和问题，导致开发过程中遇到了许多困难，最终导致项目延期。

• 子观点3：需求变更和不确定性

**理解：**在软件开发过程中，需求经常发生变化，并且存在不确定性。这可能是由于客户需求的变化、市场环境的变化或对系统的更深入理解等因素引起的。**实例：**在一个大型软件开发项目中，客户在项目进行的中途提出了一些重大的需求变更。这导致团队需要重新评估项目计划、重新设计和开发一些模块，从而导致项目进度延迟。

3. 项目管理和团队协作

• 子观点1：项目计划和进度管理

**理解：**良好的项目计划和进度管理是确保项目按时交付的关键。这包括明确的里程碑、合理的任务分配和进度跟踪。**实例：**在一个软件开发项目中，项目经理制定了详细的项目计划，明确了每个阶段的目标和交付物，并进行了任务分配。通过定期的进度跟踪和调整，团队能够按时完成各项任务并达到里程碑。

• 子观点2：沟通和协作

**理解：**良好的沟通和协作是项目管理和团队协作的基础。团队成员之间应该保持频繁的沟通，及时共享信息和解决问题。**实例：**在一个软件开发团队中，成员之间经常进行日常的沟通和协作。他们使用项目管理工具进行任务分配和进度更新，并定期召开会议进行讨论和解决问题，确保团队成员之间的理解和协作。

• 子观点3：风险管理

**理解：**项目管理应该包括风险管理的考虑。在项目开始之前，应该评估和识别潜在的风险，并制定相应的应对策略。**实例：**在一个软件开发项目中，团队在项目启动阶段进行了风险评估，并识别了潜在的技术风险。为了应对这些风险，团队制定了备选方案和应急计划，并在项目执行过程中定期进行风险监控和调整。

4. 项目进度和质量的权衡

• 子观点1：时间压力和质量折衷

**理解：**在项目中存在时间限制和交付期限，因此在保证质量的同时需要在项目进度上做出一定的妥协，以确保项目按时完成。**实例：**在一个软件开发项目中，团队面临着紧迫的上线日期。为了确保项目按时交付，团队可能需要在测试阶段减少测试用例的覆盖范围或快速修复一些次要的缺陷，以达到时间上的要求。

• 子观点2：变更管理和质量保证

**理解：**在项目进行过程中，可能会出现需求变更或其他变更请求。管理这些变更并保证项目质量需要合理的变更管理策略和控制措施。**实例：**客户提出了一些重要的需求变更。为了确保项目质量，团队需要对变更进行评估，分析其对项目进度和质量的影响，并采取适当的措施来管理和控制变更。

• 子观点3：技术债务和质量妥协

**理解：**在项目开发过程中，可能会出现技术债务，即为了满足项目进度或其他因素而采取的临时解决方案或不完美的设计。这可能会导致质量上的妥协。**实例：**为了快速推出产品，团队可能会采取一些技术债务，例如使用临时的代码补丁或绕过一些最佳实践。虽然这可以加快项目进度，但可能会对代码质量和可维护性产生负面影响。

5. 项目中的风险管理

• 子观点1：风险识别和评估

**理解：**风险管理的第一步是识别和评估潜在的风险。这包括对项目中可能出现的问题、挑战和不确定性进行全面的分析和评估。**实例：**在一个软件开发项目中，团队进行了风险工作坊，识别了一些潜在的风险，例如技术难题、人员变动和需求变更等。然后，团队对这些风险进行了评估，确定了它们的概率和影响程度。

• 子观点2：风险规划和应对策略

**理解：**针对已经识别的风险，团队需要制定相应的风险规划和应对策略。这包括确定风险的优先级、制定预防措施和应急计划等。**实例：**团队确定了一个技术上的风险，即使用新兴的开发框架可能会导致开发延迟。为了应对这个风险，团队制定了备选方案，如培训团队成员、提前进行技术验证和准备替代方案等。

• 子观点3：风险监控和控制

**解释：**风险管理是一个持续的过程，需要对已识别的风险进行监控和控制。这包括定期跟踪风险的状态、采取相应的控制措施和更新风险计划等。**实例：**团队设立了定期的风险监控会议，更新了风险登记册，并跟踪风险的进展。如果某个风险发展为实际问题，团队会立即采取相应的控制措施，如调整资源分配、寻找解决方案或重新评估项目计划。

四、亮点与启发

• 最有影响的观点或实例

（1） Brooks法则Brooks法则是《人月神话》中最著名的观点之一。这个法则指出，将更多的人员投入到已经延迟的项目中并不能加速项目进度。相反，新加入的人员需要时间来适应和融入团队，从而导致沟通和协调成本的增加，反而会延长项目的完成时间。这一观点强调了团队规模和沟通效率之间的关系，提倡合理规划和管理团队规模，以实现更好的项目效率。 （2）关于“银弹论”Brooks在书中提出了银弹论，也就是没有一种单一的技术或方法可以彻底解决软件开发中的所有问题。软件开发是一项复杂的任务，涉及多个因素和挑战，没有简单的解决方案。Brooks在第16章分析了软件开发的根本性困难（复杂性、非一致性、易变性和不可见性）和次要性困难。分析完根本性困难和次要性困难之后，Brooks断言：未来十年内，不可能有某种技术突破（银弹）能够彻底解决根本性困难，从而导致软件开发效率有数量级的提高。现在，时间已经过去了远远不止十年。在“没有银弹”发表之后，软件界冒出了数不清的新玩意儿（比如面向对象、组件技术、设计模式、CMM、UML、敏捷开发、RAD、等等），很多新玩意儿的创造者都号称他们发明了银弹。但实际上没有哪个新技术能够经受住时间的考验并真正获得银弹的称号。 （3）系统复杂度的增长Brooks在书中阐述了软件系统复杂度随着时间推移而增长的观点。他指出，随着需求变更和系统扩展，软件系统的复杂性会逐渐增加，并可能导致开发和维护困难。这一观点提醒人们在项目早期就要考虑系统的可扩展性和灵活性，以便应对复杂度的增长。 （4） 环形开发模型Brooks在书中介绍了环形开发模型，该模型强调小团队的高效协作和迭代开发。环形开发模型通过将团队划分为小而高效的子团队，每个子团队负责不同的任务，并通过迭代循环来持续改进和迭代开发。这一模型强调团队的协同工作和快速反馈，以提高软件开发的质量和效率。 为了解决前几章中提到的大型团队的种种困难，Brooks提出了一种新的解决方案：把大型团队拆分为若干个类似于外科手术式的小团队。每个小团队有一名主程序员，所有的问题分解和功能定义都通过主程序员来完成，以此来降低沟通成本。并且，每个主程序员配备若干个平庸的人帮他/她打下手，也很符合现实情况（“二八原理”）。

• 对个人或专业发展的启示

（1）良好的文档和会议讨论是促进人与人之间联系的重要纽带。在协作过程中，虽然我们可能不喜欢一些规范和约束，但这些规范和约束确保了软件工程中每个人都能履行自己的职责，减少冲突并增进了解。实际上，最耗费时间的不是这些纽带，而是在项目出现问题后需要进行弥补的工作。因此，日常的文档工作就成为了问题预防的关键。（2）架构在人员和代码方面都至关重要。我们不应该急于开始编写代码，而是要合理规划时间和空间，其中空间指的是架构，即每个人应该承担的任务。常常采用垂直划分的方法，由上层人员负责决定顶层设计，下层人员负责具体实现，顶层代码负责对外接口，底层代码负责内部逻辑。（3）试验、测试和维护在软件工程中同样重要。首先，我们需要一个被预期舍弃的系统作为前驱实验，尤其是在没有类似软件经验的情况下。这样的系统可以帮助我们积累经验，更好地设计真正的工程。代码永远不会完美无缺，我们需要不断进行测试以确保用户体验，而测试后则需要修复漏洞，然而修复漏洞也可能引入新的错误。（4）软件工程的核心矛盾无法通过单一解决方案来解决。软件工程是一门复杂的学科，我们无法构建一个抽象实体来全面描述它，我们的描述都是基于某个侧面的描述，无论是代码还是人员。在大型项目中掌握全貌是困难的。因此，我们需要更好的工具来简化实体的构建，并需要更好的组织方式来观察和描述这些实体。

五、批评与局限性

• 任何有争议、模糊或过时的信息

1. 人员资源的可替代性：《人月神话》中提出了"人月"作为衡量工作量的单位，认为增加人手将加速项目进度。然而，在现实情况下，人员之间的技能、经验和专业知识差异会导致他们的可替代性受限。新加入的团队成员需要时间来熟悉项目和团队，可能会导致短期内的生产率下降，而非立即加快进展。
2. 时间估计和计划：书中提到的时间估计和计划方法可能过于理想化。实际项目往往面临复杂性、不确定性和变化，这使得准确的时间估计变得困难。过于乐观的时间估计和刚性的计划可能导致项目延期和资源浪费。
3. 技术的稳定性：《人月神话》出版时，软件开发领域的技术远不如现在成熟和稳定。书中的某些技术观点和建议可能已经过时，无法适用于当今的软件开发环境。随着技术的发展和变化，开发者需要持续学习和适应新的工具、框架和方法。

• 可能的不足或缺陷

1. 时代局限性：《人月神话》首次出版于1975年，当时软件工程的实践和技术环境与今天已经有很大的不同。因此，书中的某些观点和方法可能不再适用于现代软件开发。例如，书中提倡的大型、集中式的软件开发模式可能无法适应当今分布式、敏捷的开发环境。
2. 缺乏对新技术的涵盖：由于著作出版时间较早，《人月神话》未能涵盖后来出现的许多重要技术和工具。例如，云计算、容器化、持续集成等现代软件开发中常用的技术和方法在书中并未详细讨论。因此，我觉得在这些方面，《人月神话》可能需要与现代的技术趋势相结合。

六、实际应用和拓展

• 在实际工作/学习中如何应用这些概念

（1）在实际工作或学习中，应重视良好的文档和会议讨论，作为促进人与人之间联系的重要纽带。通过详细的文档记录和有效的会议讨论，可以确保团队成员之间的沟通和协作顺畅。遵守规范和约束能够减少冲突，增进理解，确保每个人能够履行自己的职责。同时，日常的文档工作也是问题预防的关键，它能够帮助团队更好地了解项目，并在问题出现之前做好准备。（2）在项目中，架构在人员和代码方面都至关重要。在开始编写代码之前，应该合理规划时间和空间，即制定良好的架构。通过垂直划分的方式，将任务合理分配给不同的人员，由上层人员负责顶层设计，下层人员负责具体实现。良好的架构能够确保代码的可扩展性和可维护性，提高开发效率，同时也方便团队成员之间的协作和沟通。（3）试验、测试和维护在软件工程中同样重要。在开发过程中，应该预留时间进行试验和测试，以确保系统的稳定性和用户体验。通过构建一个被预期舍弃的系统作为前驱实验，可以积累经验并更好地设计真正的工程。测试后，修复漏洞是必要的，但也要注意修复漏洞可能引入新错误的风险，因此需要谨慎进行测试和维护工作。（4）在软件工程中，核心矛盾无法通过单一解决方案来解决。软件工程是一门复杂的学科，无法通过单一的抽象实体来全面描述。在实际工作或学习中，我们应该采用多种工具和方法来简化实体的构建和观察。通过使用合适的工具来支持开发过程，如版本控制系统、集成开发环境等，可以提高开发效率和质量。同时，建立良好的组织方式和沟通渠道，可以更好地协调团队成员之间的工作，观察和描述项目的不同侧面。

• 对未来研究或实践的建议

（1）我发现交流与组织的技能与专业技术同样重要。意味着在工作中，不仅需要具备专业的技术能力，还需要良好的交流能力和组织能力，以便与他人有效地沟通和协作。 （2） 变化才是永远不变的。 （3）程序注释和自文档的重要性不可忽视。我以前写代码不喜欢写注释，后面自己都忘记自己写的是什么了。在编写代码时，注释和自文档（代码本身的清晰性）是非常重要的，可以帮助他人理解代码并提高代码的可维护性。 （4） 在所有的任务中，都应该追求自我提升。无论是进行任何开发活动还是面对任何任务，都应该不断追求自我提升，不断学习和改进。 （5）学习的事情太多了，也会让我觉得很困惑，不知道究竟该选什么方向，导致自己摇摆不定。 （6）经济下行，总是在b站上刷到很多悲观的视频和言论，但是这个神奇的时代远未结束，它仍在快速发展，未来将带来更多的乐趣！要对未来充满信心！

七、总结与评价

• 对书籍的整体评价

《人月神话》对于我这样一个还在大学校园里的人来说，可能还是有一点抽象，有点技术的哲学的感觉。可能只有在真正切身经历过一个企业级别的软件开发项目之后，对于Brooks观点的体会和认识才能来的更加深刻吧。正如别的书评里面所说的“它不是良药，不能为你解决实际工作中的问题，但它可以给你提供很多思考的空间，让你变得更加成熟。”《人月神话》确实得以让我站在一个更高的视角来看待软件行业；而我现在需要做的则是脚踏实地走好每一步路。这本书感觉更像是给产品经理读的，不过项目中，我觉得没有任何一个人是应该被局限在一个角色中的，技术人员也要懂产品，产品人员也要懂技术，我觉得这本书读完以后让我更加“现实”，更多地把我拉近现实开发中看待问题，感觉很有收获。我觉得这本书肯定常读常新，希望在以后我工作以后再读会有新的观点和想法。

• 书籍的长处和短处

优点：（1） 提供了很多法则和经验：它提供了许多经典的原则和技术，感觉在后续实习开发中可以用到。 （2）不是纸上谈兵，是经过实践进行检验的：Brooks通过自身的实践经验和案例研究，向我们介绍了许多真实世界中的软件项目。这些案例能够帮助我们更好地理解软件开发中的问题和解决方法。 缺点：（1）缺乏针对新兴技术和方法的更新：《人月神话》首次出版于1975年，尽管后续20周年版本进行了更新和扩展（比如17章），但由于其出版时间较早，一些内容可能已经过时。特别是在现代软件开发中涌现出的新兴技术和方法方面，这本书可能没有涵盖到。 （2）理论性太强了：这本书在讨论软件工程的各个方面时，有时候偏向于理论性的说明和推理，可能对一些我来说较为抽象和难以理解。（3）适用性有限：《人月神话》主要关注大型软件项目的管理和开发，对于小型项目或个人开发者来说，其中的一些观点和方法可能不太适用。

八、参考文献（选填）

• 任何引用或参考的额外读物

1. Ozkaya, “Are DevOps and Automation Our Next Silver Bullet?,” in IEEE Software, vol. 36, no. 4, pp. 3-95, July-Aug. 2019, doi: 10.1109/MS.2019.2910943.2.Wang A.《人月神话》与实践[J].程序员,2007(10):124-126.3.知乎帖子：https://www.zhihu.com/people/dreamer-24-164.《人人都是产品经理》（Everyone’s a Product Manager） - Brooks：Ian McAllister5.《人件》（The Mythical Man-Month） - Brooks：Frederick P. Brooks Jr.

九、附录（选填）

• 额外的笔记或观察

我：其一、文档会议讨论是连接人与人的重要纽带。在合作的过程中，我们厌恶这些条条框框，但是正是这样一些规范和约束才能保证软件工程中每个人都能履行好自己的职责，减少冲突和增进了解。最花时间并不是这些纽带，而是出现项目问题之后的弥补，这些日常的文档工作正是避免出现问题的预防针。 其二、架构很重要，无论是人员还是代码。我们并不是一定要一上手就开始写代码，而是规划好时间和空间，其中空间指的就是架构，每个人做什么事情。我们常常会使用垂直划分，上层人员决定顶层设计，下层人员负责具体实现，顶层代码负责对外接口，底层代码负责内部逻辑。 其三、试验测试维护也是软件工程不可或缺的。首先我们需要一个必定被舍弃的系统作为前驱实验，特别是在没有类似软件经验的条件下，这样的系统里能够学习到很多经验，能够更好的上手设计真正的工程。代码永远不是完美的，我们需要不断地测试来保障用户的体验，测试之后就需要修Bug，而修Bug也是不完美的，可能会引入更多的错误。 其四、针对于软件工程的主要矛盾没有银弹。软件工程是复杂的，我们无法构建一个抽象实体来描述它，我们的描述都是基于某个侧面的描述，无论是代码还是人员，我们都很难在一个大项目中掌握全体。所以我们需要更好的工具来简化实体的构建，更好的组织来观察和描述实体。 这段话帮我润色一下。