能力成熟度模型集成 (CMMI) 的背景
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
软件工程研究所发布的面向开发的能力成熟度模型集成 (CMMI) 的权威指南为《CMMI：过程集成和产品改进指南》。本书专门介绍了面向开发的 CMMI (CMMI-DEV) 版本 1.3，它是 CMMI 产品套件中的模型之一。 此外，《CMMI 精选：集成过程改进实践入门》也是有关 CMMI 的通俗易懂的实用手册。
注意
此处提供的指南基于 CMMI 版本 1.3，并支持 Azure DevOps 提供的 CMMI 流程。 目前不存在更新此内容以支持更高版本的计划。
历史记录
1987 年，CMMI 作为软件工程研究所 (SEI) 的能力成熟度模型 (CMM) 项目诞生。 SEI 即卡内基梅隆大学研究中心，由美国国防部建立和资助。 面向软件的 CMM 于 1991 年首次发布，最初是作为关键成功因素清单。 此外，此模型还建立在国际商用机器公司 (IBM) 所开展的研究之上，并且二十世纪质量保证先驱（如 Philip Crosby 和 W. Edwards Deming）也为该模型贡献了大量信息。 关于能力成熟度模型和阶段表示法五个级别的叫法， 灵感源自于 Crosby 的生产成熟度模型。 CMM 主要应用于防御程序，已被普遍采用且经过了多次修订。 CMM 的成功将其开发工作拓展到了软件以外的各个领域。 新模型的大量应用使人眼花缭乱。 为此，政府资助了一个为期两年的项目，其目标是建立一个将系统工程、软件工程和产品开发相集成的可扩展框架。 有 200 多名行业和学术专家参与此项目。 CMMI 由此而诞生。
CMMI-DEV 是一个模型， 而不是一个要遵循的过程或规定。 相反，CMMI-DEV 提供了一套已被公认在软件开发和系统工程领域中十分有用的组织行为。 为何采用此类模型？ 其用途是什么？ 应如何以最佳方式使用它？ 这些关键问题可能也是 CMMI 中最容易产生误解的问题。
为何采用模型？
改进工作需要一个模型来说明组织的工作方式、他们需要哪些功能以及这些功能如何交互。 使用模型，可以了解组织要素，并有助于讨论如何改进以及应该改进哪些方面。
模型有下列优点：
- 提供一种有助于交流的通用框架和语言
- 利用多年经验
- 有助于用户在专注于改进的同时考虑大局
- 通常配备有培训师和顾问支持
- 可以通过提供商定的标准来解决分歧
CMMI 模型的用途是什么？
CMMI 模型的用途在于：对组织过程的成熟度进行评估，并提供过程改进指南，目标是改进产品。 此外，CMMI 作为风险管理模型，提供了一种衡量组织风险管理能力的方法。 管理风险因素的能力是确保组织交付高质量产品所需的能力之一。 风险管理能力的另一个视角是看组织在压力下的表现如何。 较为成熟且能力较高的组织可以轻松应对意外的压力事件。 一个欠成熟的、能力较低的组织在面对压力时往往会惊慌失措、盲目地采取回避措施，或者抛弃所有过程，回到混乱不堪的局面。
不过，CMMI 尚未被证明是组织的经济绩效指标。 尽管高度成熟的组织或许能够更好地管理风险，并进行更准确的预测，但事实证明，越成熟的公司越会规避风险。 风险规避行为会使公司缺乏创新或带有明显的官僚主义的痕迹，从而导致较长的提前期，并使产品缺乏竞争力。 欠成熟的公司往往更富有创新意识和创造力，但却混乱无序且不可预测。 其成果的实现往往是个人或管理人员才干不凡的结果。
应如何以最佳方式使用 CMMI 模型？
该模型的设计初衷是用作过程改进计划的基础，而它在评估方面的使用仅仅是作为评估改进的支持系统。 此用途目前成败各半。 人们很容易将该模型误认作一个过程定义，并会尝试照搬它，而不会将其看作一幅标识现有过程中需要弥补的不足的地图。 过程区域是 CMMI 的基本构造块，用于定义目标以及实现这些目标通常所采用的多个活动。 例如，过程与产品质量保证就是一个过程区域。 再如，配置管理。 请务必明确过程区域并非是过程。 一个过程可能跨多个过程区域，而一个过程区域可能会涉及多个过程。
CMMI-DEV 实际上是两个共享相同基础元素的模型。 第一个模型（即最熟悉的一个模型）为阶段表示模型，它显示了映射到 5 个组织成熟度之一的 22 个过程区域。 组织鉴定将对组织运营所在的级别进行评估，该级别将指示组织管理风险和履行承诺的能力。
级别 4 和 5 通常称为高成熟度。 较成熟和欠成熟的组织之间通常会有明显差异：前者展示量化管理和优化行为，后者仅仅是勉强运营或照搬定义的过程。 较成熟的组织很少改动过程，并且常常使用主要指标作为统计上的防御管理方法的一部分。 因此，较成熟的组织往往能够更准确地预测新信息并更快做出响应（假定没有其他官僚主义行为作祟）。 欠成熟的组织往往会展现不凡才干，较成熟的组织可能会在面临压力时盲目照搬过程，并且无法意识到更改过程可能是一种更合适的响应举措。
持续表示法模型单独处理 22 个过程区域中每个过程区域内的功能，这使得组织能够根据过程调整其改进工作，以便创造最大业务价值。 此种表示法更符合 Crosby 的原始模型。 根据此模型进行鉴定将生成功能概况，而不是一个数字。 由于大多数行政管理人员都对组织成熟度有所了解，因此可以将持续模型评估的结果映射到 5 个阶段。
当实现人员忘记 CMMI 不是一个过程或工作流模型时，使用阶段模型作为过程改进程序的基础可能会十分危险。 相反，CMMI 旨在提供过程和工作流要实现的目标。 实现这些目标使组织更加成熟，并提高事件按计划展开的可能性。 最大的失败模式可能是：将达到某个级别作为目标，而创建过程和基础结构的目的仅仅是为了通过鉴定。 任何过程改进活动的目标都应当是可衡量的改进，而不是一个数字。
作为过程改进的指南，持续模型取得了成功。 一些咨询公司选择只提供有关持续模型的指导。 最明显的区别在于，围绕持续模型设计的过程改进程序并没有由成熟度确定的虚假目标。 此外，在持续模型最可能利用组织的经济优势的领域，该模型适用于在这些领域进行过程改进。 因此，采用连续模型的组织更有希望收到基于 CMMI 模型的计划的积极反馈。 而且，积极反馈更可能促进一整套有效改进。
CMMI 模型的元素
下表列出了构成 CMMI 模型的 22 个过程区域（版本 1.3）：
| 首字母缩写词 | 过程区域 |
|---|---|
| CAR | 原因分析与解决方案 |
| CM | 配置管理 |
| DAR | 决策分析与解决方案 |
| IPM | 集成项目管理 |
| MA | 度量与分析 |
| OID | 组织创新与部署 |
| OPD | 组织过程定义 |
| OPF | 组织过程焦点 |
| OPP | 组织过程性能 |
| OT | 组织培训 |
| PI | 产品集成 |
| PMC | 项目监视与控制 |
| PP | 项目规划 |
| PPQA | 流程与产品质量保证 |
| QPM | 量化项目管理 |
| RD | 要求定义 |
| REQM | 要求管理 |
| RSKM | 风险管理 |
| SAM | 供应商协议管理 |
| TS | 技术解决方案 |
| VER | 验证 |
| VAL | 验证 |
在阶段表示中，过程区域根据每个阶段进行映射，如下图所示。
在连续表示中，过程区域映射到功能分组中，如下图所示。
每个过程区域都由所需组件、预期组件和信息性组件组成。 实际上，只需要所需组件即可满足根据该模型进行鉴定的需求。 所需组件即为每个过程区域的特定目标和一般目标。 预期组件是针对每个特定目标和一般目标的特定实践和一般实践。 请注意，由于预期组件仅仅是一种预期，而不是必需的，这表示特定实践或通用实践可以用等效实践取而代之。 提供预期实践的目的是为了指导实现人员和评估人员。 如果选择了备选实践，实现人员负责向评估人员提供相应建议，并论证备选实践的合理性。 信息性组件提供的详细信息有助于实现人员开始使用由 CMMI 模型指导的过程改进计划。 信息性组件包括部分通用实践和特定实践，还包括典型工作产品。
只有一般和特定目标才是必需的。 所有其他内容都仅作为指南提供。 以预期组件和信息性组件为例，CMMI 文献从大型空间和防御系统项目中请求了数据。 这些项目可能无法反映你的组织所开展的项目类型，也无法反映行业最新趋势，例如，敏捷软件开发方法的问世。