摘要

敏捷开发方法和CMMI(能力成熟度模型集成)最佳实践是通常认为互为抵触的。这份报告澄清了这个不和谐之音是没有必要存在的，提出了CMMI和敏捷冠军两者为真正的收益，可以同时使用协同工作，拥有戏剧性的潜力来提升商业绩效。

1.    Problem Definition问题定义

敏捷开发方法和CMMI最 佳实践是通常认为互为抵触的。如果这些认识或它们的原因没有搞清楚，当这两都被越来越多应用时，我们就可能会看到更多的迷惑和冲突。另外的，每种方法都包 括了优秀软件开发的原则，这些经常被俯视或者轻视，实际需要互相了解另一种方法对项目成功的意义。从长期看，这种不一致的情况对软件工程专业是不健康的。

为什么在敏捷和CMMI两个阵营之间有这种不和谐？本报告的目的是澄清为什么这仲不和谐是没有必要存在的，并且希望得到你的帮助，使得软件开发社区或交流圈了解：当两者正确的同时应用时，敏捷和CMMI可以戏剧性的提高绩效。

我们相信有两个主要的原因对这敏捷和CMMI两个阵营的不和谐：

1，两者早期的应用者都代表了各自软件开发模式的极端例子。早期CMMI应用者是大规模、风险厌恶、关键任务系统的开发者，经常伴随着管理高层的总体视野和分级管理；而早期敏捷方法的应用者通常集中在小型，单一团队开发工程，伴随着单一软件环境中变化的需求。这两种极端给后来者定了调。

2，这关于CMMI和Agile不正确的信息以及两者的误用都导致了在两个阵营中对另外一方的误解。这些把CMMI和Agile放在了对立面的误解通常来自于如下的因素：

A误用--- 20年的经历，先是CMM，后是CMMI，在其中有些实践有时被误用，或者应用到（或强用）一些对于开发活动中，这些活动被一些软件开发团队识别为对开发效率没有帮助

B缺少正确的信息---- 两个社区都缺少对方的正确的信息。

C 技术方面的困难 --- 术语的使用在CMMI(例如原则，质量保证，可预测性)和Agile（例如持续集成，测试驱动开发，集体代码拥有）都有上下文专制含义，因此容易被误解和滥用。

D 从上而下 与 自下而上的改进方法---- 一种方法的介绍有时会偏爱一种声音而压制另一种（管理层 vs 实践者)，这样就忽视了另一个重要的关于对商业运行是多么有效的声音。

在这份报告中，我们识别并讨论这个错误的认识，这个错误的认识强烈地破坏了对两种形式的正确认识，并给出通过这两种强大又有效的软件开发方法来提升我们的杰出表现。同样的，我们也认识到CMMI开发和介绍的方法可能帮助导致了某些用户误解了CMMI的正确信息和本质。这些误解可能已经导致了不一致的、无效的应用CMMI。

进一步，我们识别一般在敏捷社区对CMMI的错误认识，以及一般在CMMI社区对敏捷的错误认识。在许多方式中，这些错误认识与CMMI和Agile的错误应用有关，但是有些错误认识也可能归因于正确信息的缺少。

有些来自Agile社区的关于CMMI的错误认识起步于CMM，CMM在CMMI中没有被发现。CMMI包括了许多改进，使得CMMI与CMM不一样，而CMM从1993年以来，没有再更新。在敏捷社区有些用CMM概念来不公正的判断CMMI。例如，一直到现在，不正确的引用成熟度等级2的目标是创建可重复的过程。在最近CMMI相关的在线论坛中的贴子中，一些参与者承认不了解CMMI，与了解CMM差不多，几个参与者继续他们的争论，说“…但是如果CMMI与CMM有点象的话，那么…”

使问题更复杂的是，有些从来没有升级到CMMI的CMM用户，坚持使用一个视软件和系统开发较之于CMMI模型少灵活的模型。

一个重要的辅助是当参与者给他们的活动命名时，CMMI和Agile标签经常被随意的应用，而这些参与者都未必正确的遵循了任一种方法。这种情况增加了两种方法的误解。

现在我们知道CMMI和Agile可以成功地一起应用，本报告尾部的一些参考文件包括了成功使用这些方法的经验。

SEI一直并继续在敏捷方法的开发和CMMI及Agile的社区经验上很有兴趣，很关注。

2.    两个极端的起源

敏捷方法和CMMI最佳实践的不兼容认识极有可能是来自于它们的不同起源。在这个章节中，我们描述了两个极端：敏捷来自于快速变化的市场，由小组织组成，CMMI来自于结构化驱动的市场，由大组织组成。虽然存在归纳，但是当你观察每一个是如何创建的细节，你会开始看到为什么他们会从不同的认识得到软件开发方法

2.1. 敏捷的起源

敏捷方法的奠基石起源于远早于www和协作技术（比如 wiki和即时消息），这个奠基石是迭代和增量设计和开发（IIDD），一种早在75年前被工程师采用的方法。

早期IIDD的应用者包括了国防部Propulsion相关研究开发的工程师，这个研发开发包括的工程活动与硬件紧密相关，而不是软件。一个IIDD早期的推动者是W. Edward Deming博士，他开发提升 Plan-Do-Study-Act(PDSA)作为工程活动充满活力的组件，早期Deming技术的使用者在航空航天工业包括NASA和美国空军，每个都开发了整体系统，使用时间箱，迭代和增量产品开发循环。

早在1950年代中期，IIDD在软件开发中应用，获得了商业利益，比如 避免管理层泄气和增加客户满意度。事实上，大量早期软件开发项目，在经验和探索方面，为今天的敏捷方法分享了许多特性。

在主机系统充满天下时，COBOL和处理巨大复杂数据集的需求，程式化的自顶而下设计开发方法占统治地位，这些被通常认为是标准。这种状态被DoD标准的程式化和固定价格合同所影响

1976年, Tom Gilb在他的书《Software Metrics》中提出讨论：进化的开发导致超重的软件交付，[张克强1]  提出了一个潮流：向敏捷，轻载和可调节的开发迭代，这可以提供快速结果和更经常可视的商业利益

随着软件工程成熟，更多正式的IIDD的应用形成了，例如 1985年，Barry Boehm发表了《软件开发和提高的螺旋模型》，在1990年代，IIDD在软件业界以不同形式获得了广泛的认可，包括快速原型法，快速应用开发和瑞理统一过程（RUP），大多数现代敏捷方法的种子在这个年代播种了。

当大多数并没有期待的时候，革新和敏捷方法在几个大型公司的一些大型信息技术商店中开始了，这包括一个汽车制造厂和一家海外银行。1996年，XP（极限编程）在Chrysler公司的一个项目中开始应用，成员有Ron Jeffries和Kent Beck，而功能驱动开发（FDD）在新加坡联合海外银行（亚洲最大银行之一）开始。带着最出名的双人编程和重构，XP成为敏捷家族中最广为人知的方法。在90年代结束之前，对许多商业和软件工程师而言，这一点是清楚的，就是在许多情况下，面对面的交流，例行的客户交互，小型快速动作团队和经常的软件发布可以生产大型软件。这个运动不约而同的出现，所谓的轻载方法出现以各种不同的名字，比如Scrum, Crystal, FDD等等其它。

随着这些IIDD方法出现，对关心这些方法成长和维护的人来说，就需要来协调和比较这些方法。这个需要的结果就是在领先者或领导者之间的“思维的聚会“，这些领导者是每个方法理论和应用的当然责任者。

一群领导者聚会了，包括Kent Beck, Ron Jeffries, Alistair Cockburn, Jim Highsmith,

Bob Martin, Mike Beedle, Ken Schwaber, Jeff Sutherland, 与及其他（她）最成功新轻载方法的代表。在一个更早的举行于Oragon的XP热衷者会议之后，这些领导在Wasatch Mountains 犹他聚会，得到了敏捷软件开发宣言。

宣言的部分作者，会聚了其他人，如Mary Poppendieck, 继续推进成立了敏捷联盟，一个非盈利组织，组织目的是鼓励敏捷方法的应用。敏捷联盟首先集中力量在美国每年组织敏捷大会。

即使是犹他事件的参与者也惊喜于后续的成果输出，这些事情是个成功，宣言记录了敏捷开发的指导原则和定义了已经存在的方法论的大纲。当第一份软件开发宣言重心在编程，三年后起始宣言的作者Jim Highsmith和Alistair cockburn组织了一个早期敏捷采用者的小型组织，包括David Anderson, Mike Cohn, Todd Little和其他人，一起建立了六个管理原则的集合 作为互赖项目管理声明(DoI)[Anderson 2005b]，DoI的15位作者后来建立了敏捷项目领导者网络，一个旨在鼓励IT领域和软件工程专业更好领导和管理的利非盈利组织。