内容来自于《人月神话》32 周年纪念版、第十九章：20 年后的《人月神话》。

一、《人月神话》为什么有持久而广泛的的影响力？

1，软件开发学科没有正确地发展。

作者不同意：对比硬件的发展（20 年内翻 1000 倍），软件的发展缓慢，但是硬件技术的发展是反常的、违背历史发展规律的。

2，《人月神话》主要内容是针对团队中的成员如何创建事物的，只是顺便提及了下软件。

作者同意：某种程度上，《人月神话》是关于人和团队的书，所以它的淘汰过程会是缓慢的。

二、对于《人月神话》中观点的强调、反思、检讨、纠正

2.1 核心观点--概念完整性的结构师

1，概念完整性：一个整洁、优雅的编程产品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及指明操作和各种参数的用户界面使用策略。用户所感受到的产品概念完整性是易用性中最重要的元素。

• 任何规模很大或者非常紧急，并且需要很多人力的项目，都会碰到一个特别的困难：必须由很多人来设计，但与此同时，还需要在概念上与单个使用人员保持一致。如何组织设计队伍来获得上述的概念完整性？这是《人月神话》关注的主要问题。其中一点：由于参与人数的不同，大型编程项目与小型项目的管理在性质上都不同。为获得一致性，经过深思熟虑的，有时甚至是英勇的管理活动是完全必要的。

ps：概念完整性应该是指有一个统一的模型，从宏观方面看逻辑是自洽的，没有漏洞。

2，结构师：委派一名产品结构师是最重要的行动。

ps：作者描述的结构师类似于当前的产品经理+技术上的架构师。

3，将体系结构和设计实现、物理实现分离。

• 体系结构与实现的划分在各个设计任务中形成了清晰的边界，边界两边都有大量的工作。

ps：结构师不一定是代码的实现者，只做设计工作，保证概念完整性即可。

4，结构师方案的重用。

• 对于大型系统，即使所有实现方面的内容都被分离出去，一个人也无法完成所有体系结构的工作。所以，有必要由一位主结构师把系统分解成子系统，系统边界应该划分在使子系统间接口最小化和最容易严格定义的地方。每个部分拥有自己的结构师，他必须就体系结构向主结构师汇报。显然，这个过程可以根据需要重复递归的进行。

ps：对大型系统，设计工作太过庞大，工作量超出了一个人的负荷，需要有层级，将真个设计工作分解和组织成树形结构，每个节点负责一部分，根节点看到全局的部分即可。

5，概念完整性是产品质量的核心。拥有一位结构师是迈向概念完整性最重要的一步。这个原理绝不仅限于软件系统，它适用于任何复杂事物的设计，如计算机、飞机、战略防御系统和全球定位系统。

• 经作者试验，该方法在小型团队也运作良好

2.2 开发第二个系统所引起的后果--盲目的功能和频率猜测

1，为大型用户群设计。

设计通用工具比设计专用工具更加困难，这是因为必须为不同的用户的各种需求分配权重。

2，盲目的功能。

过多的向产品添加边界实用功能，是以性能甚至是易用性为代价的。

3，定义用户群。

用户群越大和越不确定，就越有必要明确定义用户群，以获得概念完整性。

ps：通过把用户属性记录下来的方式：他们是谁；他们需要什么；他们认为自己需要什么；他们想要的是什么。

4，频率。

为了得到完整、明确和共享的用户群描述，结构师应该猜测，或者假设一系列完整的属性和频率。

5，为用户群的属性明确地记载各种猜测。清晰和错误都比模糊不清好得多。

ps：因为你能有目标了，能够制定改进计划，可以施行 PDCA 循环去验证和沉淀。

2.3 图形界面的成功

1，通过类比获得概念完整性。

ps：跟一个本身就具有概念完整性的系统做类比，帮助在软件系统获取概念完整性。

2.4 没有构建舍弃原型--瀑布模型是错误的！

1，瀑布模型的基本谬误是它假设项目只经历一次过程，而且体系结构出色并易于使用，设计是合理可靠的，随着测试的进行，编码实现是可以修改和调整的。换句话说，瀑布模型假设所有错误发生在编码实现阶段，因此它们的修复可以很顺畅的穿插在单元和系统测试中。

2，瀑布模型的第二个谬误是它假设整个系统一次性地被构建，在所有的设计、大部分编码、部分单元测试完成之后，才为闭环的系统测试合并各个部分。

3，必须存在逆向移动。

• 在把所有东西变成代码之前，可能要往复迭代两个或者更多的体系结构--设计--实现循环。

ps：把一次性构建改为迭代开发。

2.5 增量开发模型更佳--渐进地精化

1，构建闭环的框架系统

• 在每个功能基本可以运行之后，我们一个接一个地精化或者重写每个模块--增量地开发整个系统。不过，我们有时的确需要修改原有的驱动回路，或者甚至是回路的模块接口。

ps：敏捷开发的过程。

2，增量式开发与快速原型

2.6 关于信息隐藏，Parnas 是正确的，我是错误的

1，David Parnas 认为，代码模块应该采用定义良好的接口来封装，这些模块的内部结构应该是程序员的私有财产，外部是不可见的。编程人员被屏蔽而不是暴露在他人模块的内部结构面前。在这种情况下，工作效率最高。

2，现在，我确信信息隐藏（现在常常内建于面向对象编程中）是唯一提高软件设计水平的途径。

3，第十六章指出了下列情况：

• 过去在软件生产率上取得的进展大多数来自消除非内在的困难，如笨拙的编程语言、漫长的批处理周转时间等；

• 像这些比较容易解决的困难已经不多了；

• 彻底的进展将来自对根本困难的处理--打造和组装复杂概念性结构要素。

最明显的实现这些的方法是，认为程序由比独立的高级语言语句（函数、模块、类）更大的概念结构要素组成。如果能对设计和开发进行限制，我们仅仅需要从已建成的集合中参数化这些结构要素，并把他们组装在一起，这样我们就能大幅度提高概念级别，消除很多无谓的工作和大量语句级别错误的可能性。

ps：作者认为封装、继承、抽象是达到目标的重要途径。

2.7 人月到底有多少神话色彩？Boehm 的模型和数据

1，Barry Boehm 的研究成果和《软件工程经济学》

• 他的结果与《人月神话》的结论充分地吻合，即人力（人）和时间（月）之间的平衡远不是线性关系，使用人月作为生产率的衡量标准实际是一个神话。

2，Brooks 准则有多准确？

• 他们得出结论：“想进度落后的项目中添加人手总会增加项目的成本，但不一定会使项目更加落后。”特别的，由于新成员总会立刻带来需要数周来弥补的负面效应，所以在项目早期添加额外的人力比在后期添加更加安全一些。

• 值得注意的是：他建议开发项目后期添加的开发人员，必须作为团队成员，愿意在过程中努力投入和工作，而不是企图改变或者改进过程本身！ ps：我理解是因为要做到权责匹配，新加入的成员如果后续不再维护该项目，可能会导致他使劲儿在该项目中写屎代码！

2.8 人就是一切（或者说，几乎是一切）

1，《人月神话》的大部分文章在讲述软件工程管理方面的事情，较少涉及技术问题。这部分倾向部分原因因为我在 IBM OS/360 操作系统（现在是 MVS/370）项目中的角色的性质。更基本的来自于一个信念，即对于项目的成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。

• Boehm 的 COCOMO 模型发现，目前，团队质量是项目成功最大的决定因素，实际上是下一个次要因素的 4 倍。

2，人件

• 《人件：高生产率的项目和团队》表达的观点：我们行业的问题实质上更侧重于社会学而不是科学技术。

3，项目转移

• 团队融合正是管理上被忽视的因素

• 任务可以成功的转移，但是对于项目的转移，即使拥有良好的文档、先进的设计以及保留部分原有人员，新队伍实际上依然是重新开始。我认为正是由于破坏了原有团队的整体性，导致了产品雏形的夭折，项目重新开始。

2.9 软件工程的状态和未来

1，软件工程和化学工程一样，与如何扩展到工业级别处理过程的非线性问题有关。而且，与工业工程类似，它总是被人类行为的复杂性所困扰。

2，软件工程的一些特殊问题正如第一章所提出的：

• 如何把一系列程序设计和构建成系统

• 如何把程序和系统设计构建成健壮的、经过测试的、文档化的、可支持的产品

• 如何维持对大量的复杂性的控制

3，软件工程的焦油坑在将来很长一段时间内会继续使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。这个复杂的行业需要：

• 进行持续的发展

• 学习使用更大的要素来开发

• 新工具的最佳使用

• 经论证的工程管理方法的最佳应用

• 良好判断的自由发挥以及能够使我们认识到自己不足和容易犯错的--上帝所赐予的谦卑