虽然把CMMI和敏捷类的开发方法放在一起比较，尤其是做出“取舍”，已被业界证明为是完全没有必要，也是不正确的，但就两者如何互相配合，共同发挥作用，目前还是相关企业比较关注的问题。站在不同的出发点看，当前主要有两类场景，一是原来较多使用敏捷开发的企业，如何使用CMMI去更好的实现敏捷的价值和规模化，二是原来比较少使用敏捷开发的企业，根据业务的需要导入敏捷方法，该如何利用CMMI实现敏捷开发理念和方法的导入。但无论哪一种情况，了解CMMI在敏捷开发中是如何发挥作用的都非常必要。

CMMI强调过程，专注于不断改善过程性能，提高过程能力，适应业务需要。CMMI模型在内容组织上，将一个组织的能力（Capability）分为执行（DOING）、管理（Managing）、赋能（Enabling） 和改进（Improving）四个大的能力板块，包含12个能力域（Capability Area），能力域下再划分实践域（Practice Area）以及更加细分的实践组（Practice Group）和实践（Practice）。在这个强大的结构中，组织的各方面的过程要求都得到全面的体现。例如，在CMMI看来，每个组织都需要有“保证质量（Ensuring Quality)”的能力，其中，需求开发与管理是一个重要的实践领域，组织除了需要定义如何开发和管理产品/服务需求之外，还要考虑围绕这个需求过程的一系列用于保障、支持和持续改进的其他过程，这样的过程要求才是全面的。

另外，CMMI表述的是要求（WHAT），而不是具体的方法（HOW），敏捷方法是一种“HOW”，也可能有其他的方法。不要误会，CMMI模型中其实有大量的关于“HOW”的内容，例如所谓的“说明性内容”（Explanatory)以及“背景”（Context），Agile with SCRUM就是第一种加进去CMMI模型里的方法类Context，即在基于SCRUM的敏捷的环境中，如何理解并应用某一个CMMI实践域的内容。这些“HOW”的内容，要么通过大量的例子解释说明实践的要求，要么比较系统的介绍在某一种环境下的CMMI实践要求。相对于实践（Practice），目标（Intent）和价值（Value）这几个CMMI模型要素来说，都不是核心要求，但在理解和使用模型时很有用。

敏捷开发方法，实际上是一系列的方法和技术的集合（例如SCRUM），它强调人的因素（例如自我激励的开发团队，团队内部，团队与客户之间的高效沟通），利用小规模的频繁的交付，提高开发的效率和客户满意度。与CMMI比较，敏捷方法比较专注于HOW。

CMMI如何增强敏捷开发呢？

首先，CMMI明确了组织级应该未敏捷开发提供的支持和保障能力要求。先看下图，是业界做的一个关于敏捷方法现状的调查中关于目前企业应用敏捷方法面临的主要挑战的结果：

根据这个调查的反馈，排在前面的几个主要挑战是：

●流程和实践的不一致

●敏捷价值观与企业文化冲突

●组织层面对变更（Change）的抵触

●缺乏敏捷方法的技能和经验

●缺乏管理层的参与

●来自管理层的支持和资助不足

这些挑战，以及其他没有列出的其他挑战，其实都是CMMI模型中的改进（Improving）类能力域关注的问题。例如：

●治理（GOV）强调管理者在过程体系的制定和改进过程中的主导发起、参与和支持的职责。

●实施基础（II）强调流程得以持久实施的所需的基础条件，例如充足的资源、准确完整的流程描述、实施经验的收集和分享、足够的培训等等。

●管理性能和度量（MPM）强调组织的度量能力，以及基于度量对过程性能进行管理的能力

●过程资产开发（PAD）专注于提炼最佳实践并建立组织的标准、过程、方法和指南等，确保正确的方法以及成功的经验在组织层面得到推广和使用。

●过程管理（PCM）专注于过程改进，包括如何管理新的技术和方法（例如敏捷方法）的导入和管理。

●组织级培训（OT）确保担任不同标准流程（包括敏捷开发）角色的员工，其培训需求得以识别从而胜任其角色和岗位等等。

按照这些CMMI的实践域要求，组织可以为敏捷开发提供的组织层面的保障和支持环境。

其次，在CMMI的每一个实践域层面，特别是工程和管理方面的实践，可以直接给敏捷方法提供支持。不可否认的是，目前敏捷方法在支持大型的、复杂的项目方面还是面临较大的挑战的，而这恰恰是CMMI的强项，在敏捷开发的环境中，借鉴CMMI的工程和管理实践（例如集成项目管理、风险管理，结构化的决策分析与解决等），对当前的敏捷过程进行梳理，就可以完善敏捷开发的过程，进一步强化敏捷的效果，降低其在大型项目中应用时的风险。

例如，敏捷实践中出于快速交付高优先级需求的考虑，往往形成技术债（Technical Debt），这些技术债需要管理，才能确保稳定的持续的，并且高质量的交付。技术债的管理可以用到CMMI模型中的多个相关实践：是否应该引入技术债，可以应用技术解决方案（TS）/决策分析与解决（DAR）中的结构化决策相关实践；估算（EST）和计划（PLANNING）实践域的时间，支持敏捷小组规划技术债的解决，例如估算技术债带来的成本、优先级、获得相关干系人的共识和承诺，以及具体的解决计划（Backlog）；最后，使用风险与机会管理（RSK）实践，对技术债的风险进行分析，支持对技术债的决策和管理等等。

综上所述，企业可以参考CMMI的框架，建立组织级对敏捷开发的支持和保障，同时根据每个实践域的要求，对敏捷开发的各方面进行增强，完善过程，控制风险。CMMI模型中的关于SCRUM敏捷有专门的内容（Context），解读CMMI每个实践域对基于SCRUM的敏捷开发的支持，有兴趣的读者可以参考一下。

以上文章转载自公众号《CMMI研究院》

了解更多CMMI认证