20年后的人月神话（The Mythical Man-Month after 20 Years）

★为什么会出现二十周年纪念版本？
反常的并不是软件发展得太慢，而是计算机硬件技术以一种与人类历史不相配的方式爆发出来。
与生产制造相比，硬件和软件开发保持着固有的劳动密集型特征。
软件项目管理并不像大多数程序员起初所认为的那样，而更加类似于其他类型的管理。
人月神话是关于人与团队的书，所以它的淘汰过程会是缓慢的。

★核心观点：概念完整性和结构师
□概念完整性
　一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。
　任何规模很大或者非常紧急，并需要很多人力的项目，都会碰到一个特别的困难：必须由很多人来设计，但与此同时，还需要在概念上保持与单个使用人员的一致。如何组织设计队伍来获得上述的概念一致性？这是《人月神话》关注的主要问题。

□结构师
　结构师开发用于向用户解释使用的产品概念模型，概念模型包括所有功能的详细说明以及调用和控制的方法。结构师是这些模型的所有者，同时也是用户的代理。在不可避免地对功能、性能、规模、成本和进度进行平衡时，卓有成效地体现用户的利益。
　这个角色是全职工作，只有在最小的团队中，才能和团队经理的角色合并。结构师就像电影的导演，而经理类似于制片人。

□将体系结构和设计实现、物理实现相分离。
  体系结构和实现的划分在各个设计任务重形成了清晰的边界，边界两边都有大量的工作。
□体系结构的递归。
　由一位主结构师把系统分解成子系统，系统边界应该划分在使子系统间接口最小化和最容易严格定义的地方。
　每个部分拥有自己的结构师，他必须就体系结构向主结构师汇报。这个过程可以根据需要重复递归地进行。
□今天，我比以往更加确信。
　概念完整性是产品质量的核心。拥有一位结构师是迈向概念完整性的最重要一步。　
　每4个学生左右的小组就选择不同的经理和结构师。在如此小的队伍中定义截然不同的角色可能是有点极端，但我仍然发现这种方法即使对小型团队也运作良好，并且促使了设计的成功。

★开发第二个系统所引起的后果：盲目的功能和频率猜测
□为大型用户群设计
　在商业数据处理领域中，客户应用程序越来越多地被商用软件包所代替。
　
□盲目的功能（Featuritis）
　功能建议的吸引力在初期阶段是很明显的，性能代价在系统测试时才会出现。而随着功能一点一点地添加，手册慢慢地增厚，易用性损失以不易察觉的方式蔓延。

□定义用户群。
  用户群越大和越不确定，就越有必要明确地定义用户群，以获得概念完整性。
　结构师的用户图像会有意或者无意地影响每个结构决策，因此有必要使设计队伍共享一幅相同的用户图像。这需要把用户群的属性记录下来。
１）他们是谁
２）他们需要（need）什么
３）他们认为自己需要（need）什么
４）他们想要（want）的是什么

□频率
  对于软件产品，任何用户群属性实际上都是一种概率分布，每个属性具有若干可能的值，每个值有自己的发生频率。
　为了得到完整、明确和共有的用户群描述，结构师应该猜测（guess），或者假设（postulate）完整的一系列属性和频率值。
１）这种不是很可靠的过程有很多好处。首先，仔细猜测频率的过程会使结构师非常细致地考虑对象用户群。
２）把它们写下来一般会引发讨论，这能起到解释的作用，以及澄清不同设计人员对用户图像认识上的差异。
３）明确地列举频率能帮助大家认识到哪些决策依赖于哪些用户群属性。
　这种非正式的敏感性分析也是颇有价值的。当某些非常重要的决策需要取决于一些特殊的猜测时，很值得为那些数值花费精力来取得更好的估计。

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

□“开发第二系统所引起的后果（second-system effect）”情况怎样？

★图形（WIMP）界面的成功
□通过类比获得的概念完整性。
　WIMP是一个充分体现了概念完整性的用户界面例子。
　哪些地方使WIMP界面远远超越了桌面的比喻？主要是在两个方面：菜单和单手操作。
□用户功能和易用性。
　软件结构师所面临的最困难问题是如何确切地平衡用户功能和易用性。是为初学者或偶尔使用的用户设计简单操作，还是为专业用户设计强大的功能？理想的答案是通过概念一致的方式把两者都提供给用户。　
□WIMP的命运：过时被淘汰。

★没有构建舍弃原型——瀑布模型是错误的！
  瀑布模型的基本谬误是它假设项目只经历一次过程，而且体系结构出色并易于使用，设计是合理可靠的，随着测试的进行，编码实现是可以修改和调整的。换句话说，瀑布模型假设所有错误发生在编码实现阶段，因此它们的修复可以很顺畅地穿插在单元和系统测试中。
  应该一块块地丢弃和重新设计系统，而不是一次性地完成替换。
  瀑布模型的第二个谬误是它假设整个系统一次性地被构建，在所有的设计，大部分编码，部分单元测试完成之后，才为闭环的系统测试合并各个部分。
□必须存在逆向移动
　在开发过程“下游”的经验和想法必须跃行而上，有时会超过一个阶段，来影响“上游”的活动。
  在把任何东西实现成代码之前，可能要往复迭代两个或更多的体系结构－设计－实现循环。

★增量开发模型更佳——渐进地精化
 早期曾提倡我们首先应该构建实时系统的基本轮训回路，为每个功能都提供子函数调用。但仅仅是空的子函数。对它进行编译，测试，使它可以不断运行。它不直接完成任何事情，但至少是正常运行的。一个可运行的系统出现了，尽管只是一个框架。在每个功能基本可以运行之后，我们一个接一个地精化或者重写每个模块--增量地开发整个系统。

　□构建闭环的框架系统
　　我们可以很早开始用户测试，以及我们可以采用按预算开发的策略，来彻底保证不会出现进度或者预算的超支（以允许的功能牺牲作为代价）。
　　第一个可运行的系统对团队士气产生的鼓舞效果而感到震惊。
　
　□Parnas产品族
　 Parnas力劝设计人员对产品的后期扩展和后续版本进行预测，定义它们在功能或者平台上的差异，从而搭建一棵相关产品的家族树。设计类似一棵树的技巧是将那些变化可能性较小的设计决策放置在树的根部。这样的设计使得模块的重用最大化。

　□Microsoft的“每晚重建”方法
　　在每次重建之后，我们会获得一个可运行的系统。如果重建失败，我们将停下整个过程，直到找到问题所在并进行修复。在任何时间，团队中的每个人都了解项目的状态。
　　这是非常困难的。你必须投入大量的资源，而且它是一个规范化、可跟踪、开诚布公的流程。它向团队提供了自身的可信度，而可信度决定了你的士气和情绪状态。
　
　□增量式开发和快速原型
  增量式开发：能使真正的用户较早地参与测试。
　快速原型：仅仅反映了概念模型准备过程中所做的设计决策[的一个程序版本]，它并未反映受实现考虑所驱使的设计决策。
　这种原型化对获取早期的用户反馈非常有用。
　“从第一个里程碑开始构建”的微软流程和快速原型之间的差别是什么？
  功能。第一个里程碑产品可能不包含足够的功能使任何人对它产生兴趣，而可发布产品和定义中的一样，在完整性上——配备了一系列实用的功能集，在质量上——它可以健壮地运行。

★关于信息隐藏，Parnas是正确的，我是错误的
　Harlan Mills颇有说服力地指出“编程是个开放性的公共过程”。把所有工作都暴露在每个人的凝视之下，能够帮助质量控制，这既源于其他人优秀工作的压力，也由于同伴能直接发现缺陷和bug。
　David Parnas认为代码模块应该采用定义良好的接口来封装，这些模块的内部结构应该是程序员的私有财产，外部是不可见的。编程人员被屏蔽而不是暴露在他人模块内部结构面前。这种情况下，工作效率最高。
  关于每个团队成员应该在多大程度上被允许和鼓励相互设计和代码的问题，上面两种方法Parnas是正确的。
　１．过去在软件生产率上取得的进展大多数来自消除非内在的困难，如笨拙的编程语言、漫长的批处理周转时间等。
　２．像这些比较容易解决的困难已经不多了。
　３．彻底的进展将来自对根本困难的处理——打造和组装复杂概念性结构要素。

★人月到底有多少神话色彩？Boehm的模型和数据
　人力（人）和时间（月）之间的平衡远不是线性关系，使用人月作为生产率的衡量标准实际是一个神话。特别的，他发现
　第一次发布的成本最优进度时间，T = 2.5（MM）1/3。即，月单位的最优时间是估计工作量（人月）的立方根，估计工作量则由规模估计和模型中的其他因子导出。最优人员配备曲线是由推导得出的。
　当计划进度比最优进度长时，成本曲线会缓慢攀升。时间越充裕，花的时间也越长。
　当计划进度比最优进度短时，成本曲线急剧升高。
　无论安排多少人手，几乎没有任何项目能够在少于3/4的最优时间内获得成功！当高级经理向项目经理要求不可能的进度担保时，这段结论可以充分地作为项目经理的理论依据。
  向进度落后的软件项目中添加人手只会使进度更加落后。向进度落后的项目中添加人手总会增加项目成本，但并不一定会使项目更加落后。特别的，由于新成员总会立刻带来需要数周来弥补的负面效应，所以在项目早期添加额外的人力比在后期加入更加安全一些。

★人就是一切（或者说，几乎是一切）
即对于项目的成功而言，项目人员的素质、人员的组织管理是比使用的工具或采用的技术方法更重要的因素。

□人件
管理人员的职责不是要人们去工作，而是是创造工作的可能
□项目转移。
团队融合是一个无形的，但是非常关键的特性。很多地点分散的公司，项目从一个实验室转移到另一个。从中，我认为团队融合正是管理上被忽视的因素。
任务可以成功地转移，但是对于项目的转移，即使拥有良好的文档、先进的设计以及保留部分原有人员，新队伍实际上依然是重新开始。我认为正是由于破坏了原有团队的整体性，导致了产品雏形的夭折，项目重新开始。

★放弃权力的力量
授权是朝着正确方向迈出的一大步，：通过权力委派，中心的权威实际上是得到了加强；从整体而言，组织机构实际上更加融洽和繁荣。
每个队伍（30至40人）拥有自己的任务、进度，甚至如何定义、构建、发布的过程。团队由4或5个专家组成，包括开发、测试和书写文档等。由团队而不是老板对争论进行仲裁。我无法形容授权和由团队自行负责项目的成功与否的重要性。
关键的措施是将权力向下委派。这就像是魔术！改进的质量、提高的生产率、高涨的士气。我们的小型团队，没有中心控制。团队是流程的所有者，并且必须拥有一个流程。他们有不同的流程。他们是进度计划的所有者，因此感受到市场的压力。这种压力导致他们使用和利用自己的工具。

□元编程。
为部分软件包用户进行功能定制的过程。元编程并不是新概念，仅仅是重新被提出和重新命名。

★软件工程的状态和未来
 软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。这个复杂的行业需要：进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的管理方法的最佳应用；良好判断的自由发挥；以及能够使我们认识到自己不足和容易犯错的---上帝所赐予的谦卑。