第二部分 · 两个方法论的起源

我们可以认识到的，关于敏捷方法和CMMI的最佳实践的不相容性，在很大程度上，是由于其各自的不同的起源造成的。在本部分中，我们描述了从两个方法论的来源：敏捷来源于由小型组织组成的快速变化的市场，CMMI来源于由大组织组成的由合同驱动的市场。虽然这些话看起来都是很概括的，但当你观察每一个创建的细节，你就可以开始明白为什么他们从不同的角度来处理软件开发。

2.1 敏捷方法的起源

敏捷方法的基础的起源早于万维网和协作技术（例如，维基和即时消息）。这个基础是迭代和增量的设计和研发（IIDD，iterative and incremental de- sign and development ），一种在75年前就被工程师使用的方法。

IIDD的早期使用者，包括国防部致力于推进力相关的研究和开发的工程师，其中包括与硬件相关的工程活动而不是软件相关。IIDD的早期先驱者Dr. W. Edwards Deming，开始推动PDSA（Plan- Do-Study-Act）作为实证工程的重要组成部分。在Dr. W. Edwards Deming的教导下，早期使用者应用在航空航天工业，包括美国国家航空航天管理局（NASA）和美国空军，并在整个系统使用时间控制、迭代和增量产品研发生命周期模型。

早在上世纪50年代中期，IIDD就被用于软件开发，从而作用于企业效益如“避免管理沮丧”和“提高客户满意度”。事实上，早期大量的软件开发项目往往是实验和探索，分享了许多今天的敏捷方法的属性。

然而，在一个系统的世界占主导地位的大型机，使用面向商业的通用语言（COBOL，Common Business-Oriented Language）），并要求处理大型和复杂的数据集，程序自顶向下的设计和开发方法为主，被许多人认为是标准。这种情况是由两方面影响造成的：一是由美国国防部的标准程序；二是固定价格合同扩散给政府系统的供应商（政府是当时的计算机软件的主要消费者）。

1976年，Tom Gilb 主张进化的研发才可以获得优秀的软件交付，将主张发表在他的关于软件度量的书籍里，并发动了一场运动：关于敏捷、轻量级和迭代开发，可以快速提供结果和更频繁可见的商业利益。

作为软件工程的成熟状态，IIDD的更多应用正式作为可用的案例，1985年，Barry Boehm发表了《软件开发和增强的螺旋模型》。

在上世纪90年代，IIDD在各种形式的软件社区中得到了广泛的认可，包括快速原型、快速应用开发（RAD）和统一软件开发过程（RUP）。在这十年里，最先进的敏捷方法得到蓬勃发展。

而最不可期待的，创新和敏捷方法在大型信息技术（IT）的几个大型公司开始流行，包括一家汽车制造商和一家海外银行。1996年，极限编程（XP，eXtreme Programming）开始在克莱斯勒汽车公司的一个项目使用，由IIDD的倡导Ron Jeffries和Kent Beck推动实施。另一边，在亚洲最大的银行之一的新加坡大华银行，特征驱动开发（FDD）也开始实施。结对编程和重构是XP最著名的特点，XP开始成为敏捷家族中最知名的方法。在这个十年结束之前，很明显，对于许多企业和软件工程人员来说，XP获得了的一致好评：面对面的沟通，严格的客户互动，小的快速行动的团队，以及频繁的交付软件，最终产生卓越的软件。这些同时发生在其他地方，我们所谓的轻量级方法，派生了很多的名字，如Scrum，Crystal，FDD，和其他。

随着IIDD衍生方法的不断产生，我们需要对它们进行维护，通过整合和比较这些方法来进行。这种需要的结果就是，将主要负责这些方法论的理论研究和实际应用的领导者集中起来，召开会议进行整合。

一批领导人进行了会面，包括Kent Beck, Ron Jeffries, Alistair Cockburn, Jim Highsmith, Bob Martin, Mike Beedle, Ken Schwaber, Jeff Sutherland，以及那些代表了新的轻量级方法最成功的人。在俄勒冈，由XP爱好者发动的会议之后，又组织了一次建模会议，这些领导人聚集在犹他州Wasatch山脉滑雪放松，最终出版了敏捷软件开发宣言。

敏捷宣言的创造者作为一个子集，连同其他人员，形成了敏捷联盟，一个非营利性组织，致力于鼓励采用敏捷方法。敏捷联盟主要关注于每年在美国组织敏捷会议。

即使犹他州事件的组织者表示对其结果还存在一些疑虑，也不妨碍此次会议是一个巨大的成功。宣言记录了敏捷开发的指导原则，并围绕一套现有的方法论定义了一套思想。对于软件开发的第一个宣言，致力于编程部分，三年后原宣言作者Jim Highsmith和Alistair Cockburn聚集了一组类似早期的敏捷使用者，包括David Anderson, Mike Cohn, Todd Little，和其他人，建立了六项管理原则，被称为DOI（Project Management Declaration of Interdependence）[Anderson 2005b]。DOI的15位作者，随后也形成了敏捷项目领导力网络（APLN，Agile Project Leadership Network），一个不以营利为目的的组织，致力于促进更好的领导和管理IT领域和软件工程专业。

宣言和相关资料的出版物、其原始作者写的书、非营利组织推动敏捷方法的形成，以及互联网的广泛使用，导致了敏捷方法在快速发展和在软件工程专业的的广泛使用。

2.2 CMMI的起源

在见到CMM这个名字之前，第一个能力成熟度类似模型框架出现在1989出版的由Watts Humphrey编写《软件过程管理》一书中。几年前，美国国防部公布了一个征求建议书（RFP），用于解决一个问题：过度大量金钱花在软件上，但却没有交付或交付推迟，并且只实现了很少的预期功能。

合同授予了RFP一个基础，在卡耐基梅隆大学，建立了我们今天所知道的软件工程研究所（SEI，Software Engineering Institute）。SEI汇聚了很多代表人物，他们来自学术界、研究人员和行业，旨在揭露和促进实践证明是成功的，从而避免失败，以帮助国防部软件采购工作。卡耐基梅隆大学解决国防部的问题的框架结构，形成了CMM框架。

如果我们看看CMM的起源，它早于互联网和几乎所有与互联网相关的技术。对于这件事，CMM早于许多软件开发、部署和管理，基础设施，技术，语言，和方法。在过去的20年里，我们都学到了很多。当国防部着手解决“软件的困境”的时候，软件的世界和今天比较是完全不同的。

为了更进一步，大家都努力发展最初的CMM，每个人都努力寻找“软件问题”解决方案。从软件的角度来看，软件是一个组成大的系统的组件，如果它失败了，可能将失去生命（如飞机，船舶，武器装备，医疗器械）。系统使用仔细和谨慎的发展路径进行演化，并根据低风险、标准化合同驱动来维护开发者和客户之间的关系。。

在当今频繁的讨论日益全球化和发挥信托的重要作用（即信任的社会资本水平）[Fukuyama 1995 ]，这两个问题在利益相关者中形成有效的合作非常重要。用户通常不会直接参与项目，只会在最终产品形成时进行现场测试。他们反而不得不依赖于合同关系、需求说明和相关的标准，以获得他们所需要的产品。

这些情况可能是一些极端情况，但他们的目的是概括了当时的美国国防部的软件采购环境。此外，这些情况说明了为什么在CMMI的实践中，有时会表现出一些相同的低信任度特征的高风险，因为政府合同环境的软件失败等于失去生命。

此外，在当时的高风险的政府承包商的环境，交付频率很低，而且流行最终的整体的交付，这样导致了高成本的部署，升级和更换（例如，在20世纪80年代的战斗机的软件升级，无法在空中或在互联网上完成）。因此，一次作对是非常重要的。此外，大多数参与这一合同环境的组织，都是拥有大型复杂项目的大型组织。

最终，对公共资金的使用，在政府合同（或类似的高知名度和高风险的情况下），要求责任制级别，所有这些参与者，去推动各方规避风险，寻找最有效的双赢解决方案，而不是仅仅为了保护自己的利益。商务活动帮助解决一些问题，但要使用开放的、透明的方式经营。

在短短几年内，CMM已经扩展到其他几个模型，这些都是针对非软件开发项目开发的解决方案。此外，CMM和这些变化的模型越来越多国际化并且被商业化使用。组织试图采用多个模型应用在一个项目中，但是很快发现这样做会面临很大的挑战，所以就请求SEI将各种CMM集成到一个模型中，最后SEI联合政府和行业在1998年创建了 CMMI。

当然，多年来，CMM和CMMI一直被很好的维护，来自世界各地的使用者源源不断的提供优秀的管理和开发实践帮助模型的发展。因此，新的理念、标准和实践，不断地融入现在的CMMI框架。

【相关文章】

《CMMI还是Agile：为何不拥抱彼此！》第一部分 · 问题思考

《CMMI还是Agile：为何不拥抱彼此！》第二部分 · 两个方法论的起源

《CMMI还是Agile：为何不拥抱彼此！》第三部分 · 影响对CMMI和敏捷观念的因素

《CMMI还是Agile：为何不拥抱彼此！》第四部分 · CMMI的真相

《CMMI还是Agile：为何不拥抱彼此！》第五部分 · Agile的真相