软件工程方法，敏捷方法，CMMI之间的关系

软件工程方法的基本框架

无论采用何种体系，软件工程方法都存在一个不变的基本框架，此框架包括四个部分：

下图中，中间以黑色箭头相连接的产品研发方法论（创新与用户分析，需求分析，产品质量控制，发布、上市与反馈），上面以蓝色箭头相连接的管理方法论（宏观计划，微观计划，跟踪与监控，评价），下面以绿色箭头相连接的工程方法论（服务框架，编码，测试，集成），右侧与之配合的团队结构。

敏捷分支与基本框架之间的关系

敏捷开发的各个分支，实际上是上述框架的不同部分的独立体现。

CMMI与基本框架之间的关系

而上述的所有框架，却都可以被CMMI的过程域所覆盖。并且实际上，CMMI还考虑了方法论框架之外的组织级活动（图中难以体现）。

使用敏捷方法实现CMMI

既然如此，就有可能在CMMI的框架之下，实施敏捷开发。从Practice 的角度看，对照情况如下（从左到右大致是此方法盛行的时间，而非初次出现的时间）：

但需要注意：

1.       敏捷开发各种分支的发明人均来自于一线，因此在管理域、工程域的能力很强，而在组织域（PAD,PCM,OT,PLAN,CAR）和支持域（PQA,MPM）等普遍没有成熟的方法。

2.       各种敏捷分支之间常常存在矛盾（包括见解与商业推广上的），因此看似互补的多个体系常常并没有实质性的联系，对同一事物的定义也常常是矛盾的（如何为需求条目）

3.       CMMI的基本假设（CMMI是SEI为DOD美国国防部设立的招投标标准）是项目开发（甲方提需求，乙方研发，甲方运维）；而DevOps的基本假设是产品研发（企业自己提需求，自己研发和运维）。具体项目实施时，应该根据自己情况向其中一方偏斜。

引入QAD量化敏捷开发实现CMMI

此时应该引入QAD量化敏捷开发来解决这个问题。

QAD包括两个层面的内容：

团队级框架，目标是通过重新定义各敏捷分支中的概念（如用户故事，规模，生产率等），使得从需求到上线的全程可以使用一致的、衔接的、具体的术语、定义、方法、过程。

组织级框架，以“一致性”为前提，引入并简化功能点作为度量的核心，从而使得以数据为基础的EST, PLAN、MPM、CAR等实践域得以运作。度量还使得评价敏捷开发的实际成效成为可能，从而可以谨慎而坚定地推进敏捷转型。

从CMMI看敏捷开发的过去，现在，未来

比如极限编程XP一致若存若亡，但随着DevOps的兴起，反而时隔15年发展出微服务（配合Docker发布技术）等全新技术，其中的自动化测试也随着频繁发布成为研究热点之一。

对比CMMI的等级不难看出，这一顺序实际上反映了敏捷开发自身的成熟度：

1.       以Scrum，看板为代表的初代敏捷，完成了CMMI2级的主要过程域

2.       广义XP、DevOps为代表的二代敏捷，将应用推进到工程域，从而满足了CMMI3的要求

3.       以QAD量化敏捷开发为代表的三代敏捷，将完成CMMI4、5的要求

抛开CMMI的级别，这本身也反映了敏捷开发自身的成熟：从项目级别做简单的计划，到跨部门的工程领域形成严谨的生产流水线，再到过程稳定到可以量化管理和预测。配合大数据、人工智能等分析工具，最佳实践的确认也会变得容易、频繁，从真正推动持续改进。