论敏捷与CMMI 的异同及敏捷中融合CMMI思想以提高敏捷性能的思路

蔡 泉

（ 沈阳东软智睿放疗技术有限公司，辽宁 沈阳110167）

近二十年来，对于软件开发项目的从业人员来说，CMMI 和敏捷可以说是必须要了解的概念。 CMMI 全称是Capability Maturity Model Integration，即软件能力成熟度模型集成，是由美国国防部与卡内基- 梅隆大学和美国国防工业协会共同开发和研制的，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。 早期国内软件企业刚接触CMMI 时多用来指导瀑布型软件开发项目，而随着互联网行业的崛起，敏捷开发这种侧重于构建团队级能力，以人为核心、迭代、循序渐进的开发方法越来越受到软件项目从业人员的欢迎。

毫无疑问，CMMI 和敏捷开发是存在很多差异的。 CMMI 把软件开发组织的能力成熟度分为了5 个等级， 22 个过程域，通过开发过程覆盖的过程域来描述织的成熟度级别达到了什么等级，CMMI 注重的是过程改进和组织成熟度。 而对于近年来的软件开发项目而言，市场风向转变很快，需要及时快速的、阶段性的交付产品，这正是敏捷开发的特性，也是敏捷越来越流行的原因所在。 另一方面，CMMI 中证明满足过程域的最佳实践，是从制品和访谈两个维度进行考察， 有证据即可，并没有对证据的数量和格式有何具体的要求。 而敏捷则通过价值观、开发原则、具体实践等明确说明了怎样更快、更好的交付高质量的产品。 综上所述，CMMI 模告诉我们的是要做什么，而敏捷告诉我们的是要怎么做。

虽然差异明显，但是敏捷和CMMI 并不是对立的。从本质上来讲，CMMI 和敏捷的最终目标是一致的，都是人们为了解决在软件生产过程中出现的质量低下、进度延迟、预算超支等问题，而产生的标准或过程改进的模型或方法实践。 做什么和怎么做并不矛盾，比如你知道运动减肥的道理，可以选择慢跑也可以选择瑜伽，但是不影响运动减肥的理论正确。

在笔者多年的软件开发经验中，经常遇到有人问“ 如何解决敏捷与CMMI 的冲突”，笔者的回答是，请思考一下，存在冲突是不是有哪里做的不对？CMMI 是否被过度解释了，敏捷是否被过度简化了？CMMI 过程域的满足需要有证据，由于实践中大家对CMMI 的误解，很多组织过度准备了证据。 同时，也不是使用了Scrum、Jira 等敏捷工具， 每天组织一下站会就可以称之为敏捷了。 我们应该以保证项目进度、符合预算，高质量交付项目产品，提高组织的开发能力为最终目标去使用CMMI 和敏捷思想，它们只是渡河达到彼岸的舟船。

随着软件行业的发展，需要快速迭代的产品，越来越受到市场的青睐， 很多前沿的互联网企业将敏捷应用于开发过程，同时很多从业人员也都在思考如何提高敏捷性能。 笔者在多年的软件开发经验中经常接触敏捷和CMMI 的概念， 那么在敏捷中应用CMMI 的思想来提高敏捷性能是否是一种可行的手段呢？笔者认为，这是完全可行的。其实敏捷与CMMI 存在着很多共性的东西，例如对于配置管理的高要求，提倡头脑风暴等。

下面我们着重从几方面论述一下敏捷中融合CMMI 思想并提高敏捷性能的思路：

1 敏捷开发项目初期通过融合CMMI 思想进行项目过程定义

CMMI 强调通过规范的流程，将人、技术、工具集成在一起，从而产生好的结果，而敏捷开发宣言中明确提到，能够工作的软件胜过完备的文档。 因此，人们普遍认为CMMI 重视流程，重视文档，而敏捷开发轻流程，轻文档。 其实很多项目的CMMI 实践中， 往往迷失了目标， 为了规范而规范， 恰恰忘了CMMI 的OPD 组织级过程定义过程域中的一个重要活动就是裁剪过程。而敏捷开发的轻流程、轻文档并不是没有流程、没有文档，软件开发组织完全可以通过大量的敏捷开发项目实践，总结出合理的流程， 针对具体的敏捷开发项目， 融合CMMI 的裁剪过程思想，灵活的配置具体项目的具体流程，编写刚刚好的文档即可。这样通过组织级的经验总结，为以后新的敏捷开发项目进行指导，达到提高敏捷开发性能的目的。

2 敏捷开发项目通过融合CMMI 思想进行风险控制

CMMI 在项目初期即要引入风险控制， 有专门的RSKM 风险管理过程域对风险控制进行描述。 敏捷开发同样会在项目初期使用头脑风暴的方法预估风险。 那么我们在敏捷项目中，融合CMMI 思想， 使用风险矩阵跟踪等方式进行风险控制不正是提高敏捷性能的好方案么。 当然敏捷并不需要完全照搬CMMI，CMMI 强调项目初期即要尽量识别出全部风险并进行跟踪，而敏捷开发的一大特色就是拥抱变化，强调即使项目末期仍可引入变化，所以敏捷不必追求穷尽风险，我们要借鉴的是先进思想，而不是思想僵化的固定流程。

3 敏捷与CMMI 思想对于需求跟踪的共性。

CMMI 有REQM 需求管理、RD 需求开发两个过程域， 强调在整个项目周期中的需求跟踪。 而敏捷开发宣言中，虽然没有明确提到需求跟踪，但其实常见的敏捷开发工具都引入了需求跟踪的思想。 例如对于迭代前通过对Backlog、Story 的定义，通过整个项目周期对Backlog、Story 的跟踪来完成整体项目需求跟踪的目标；例如每个迭代的目标制定、任务拆解，迭代中对任务进度和燃尽图的看板展示，这也可以认为是每次迭代的“ 需求”理解和跟踪的实际体现。

4 敏捷开发项目通过融合CMMI 思想进行成果验收

CMMI 中存在VAL 确认过程域和VER 验证过程域，确认是为了证明所提供的产品符合预期的使用需求，而验证关注的则是工作产品是否恰当地反映了那些被指定了的需求。 简单的说，验证确保“ 你把事做对了”，而确认确保“ 你做了对的事”。 在敏捷中，每次迭代结束的成员成果展示和验收，正是集体进行的验证环节，对开发人员的工作成果进行验收。 如果我们进一步引入CMMI 思想，在迭代前的目标制定、任务拆解时，进行确认过程，则能更加提高工作效率，减少返工率，保证项目进度和提高产品质量。

5 敏捷开发项目通过融合CMMI 思想进行组织级持续改进

敏捷开发中，每次迭代结束的总结会，既要展示和验收每个成员的工作成果，也要总结该次迭代存在的问题，为之后的迭代总结经验，提供改进建议。这与CMMI 中4、5 级成熟度的持续改进要求不谋而合， 同时CMMI 中也有MA 测量与分析过程域用于经验数据的分析与总结。如果我们能够融合CMMI 思想，在敏捷中，记录和总结经验数据，并上升为组织级经验，在更好的服务于该敏捷项目外，还可以用于组织级经验积累并指导组织内其他敏捷项目的开发。

结束语

综上所述， 本文首先明确了CMMI 和敏捷并不是软件开发项目中两种对立的模型，只是概念抽象层次的不同，而在改善软件生产过程的最终目标上，它们是殊途同归的。 之后提出了在敏捷中融合CMMI 思想用以提高敏捷性能的几点思路， 希望能对读者有所启发，今后在软件开发项目中更好的开展工作。