Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
软件工程研究所发布的功能成熟度模型集成(CMMI)最终指南是“CMMI:流程集成和产品改进指南”。这本书描述了 CMMI-DEV(版本 1.3),CMMI 产品系列中的模型之一。 “CMMI 精要:集成过程改进的实用简介”是一本简洁、易读的书籍,非常适合许多读者。
注释
本文基于 CMMI 版本 1.3 和 Azure DevOps 支持的 CMMI 过程的指导。 我们目前不打算将此内容更新到更高版本的 CMMI 版本。
历史笔记
CMMI 始于 1987 年,作为卡内基梅隆大学软件工程研究所(SEI)项目的能力成熟度模型(CMM)。 最初于 1991 年发布的软件能力成熟度模型(CMM)起初作为关键成功因素的检查表而出现。 该模型还借鉴了 IBM 的研究,以及菲利普·克罗斯比和W.爱德华兹·德明等优质先驱。 Crosby 的制造成熟度模型启发了能力成熟度模型及其五级阶段表示法的名称。
最初在国防计划中应用,CMM 增长、多元化,并进行了修订。 不同模型的激增导致政府资助的两年努力,以创建一个集成系统工程、软件工程和产品开发的单一可扩展框架。 200多名行业和学术专家为这项工作做出了贡献:生成的框架为 CMMI。
CMMI-DEV 是一个模型,而不是一个规范性过程。 它定义了通常导致更好的软件工程和系统工程结果的组织行为和目标。 人们经常误解了关于模型的三个问题:为什么使用模型? 其用途是什么? 应如何应用它? 以下指南解决了这些问题。
为什么使用模型?
改进工作需要一个模型,该模型描述组织的工作方式、需要哪些功能以及这些功能如何交互。 模型提供共享语言和结构,用于讨论要改进的内容。
模型提供几个具体优势:
- 改善通信的公共框架和语言。
- 几十年的经验积累汇聚成指导。
- 专注于改进工作的同时,记住大局的方法。
- 培训师和顾问在许多市场中提供支持。
- 一个外部参考,它通过使用商定的标准来帮助解决分歧。
CMMI 模型的用途是什么?
CMMI 可帮助你评估流程成熟度,并指导流程改进,以生成更可预测的结果和更高质量的产品。 它还提供了一种结构化的风险管理方法,并衡量组织管理风险的方式。 管理风险的能力直接有助于组织提供高质量结果的能力。
CMMI 不能保证经济性能。 成熟度较高的组织可能会更好地管理风险,并变得更加可预测,但它们也可能成为风险厌恶或官僚主义,这可能会减缓创新和增加领先时间。 低成熟度组织有时会创新更多,但以更混乱、更可预测的方式运作:成功可能取决于各个英雄,而不是可重复的进程。
应如何使用 CMMI 模型?
使用 CMMI 作为流程改进计划的基础;将评估视为衡量进步而不是主要目标的一种方式。 避免将模型视为必须严格遵循的指导方针。 CMMI 的构建基块是定义目标以及用于满足它们的常见活动的流程区域(例如流程和产品质量保证或配置管理)。 请记住,进程区域与进程不同:一个进程可以跨越多个进程区域,一个进程区域可以涉及多个进程。
CMMI-DEV 提供两种互补表示形式:
- 分阶段表示将 22 个进程区域分组为五个成熟度级别,并为组织生成单个成熟度级别。 经理和高管通常将此级别用作组织能力的简单指标。
- 连续表示可评估每个流程区域的功能,让你专注于改进,从而提供最有价值的业务价值。 持续评估生成能力概况,而不是单个数字,可以根据需要将连续结果映射到分级水平。
级别 4 和 5 表示更高的成熟度。 成熟度较高的组织倾向于应用定量管理和优化做法,显示较低的流程可变性,并使用领先指标作为统计防御管理的一部分。 这些行为可以使此类组织更可预测、更快速地响应新信息,前提是官僚机构不会扼杀响应能力。 相反,低成熟度组织在出现问题时往往依靠英勇的努力。
22 个流程区域中的每个持续表示模型功能,使组织能够定制对提供最大业务效益的流程领域的改进。 许多从业者更喜欢持续改进,当他们想要进行集中且经济驱动的改进时,而不是追求单一成熟度目标。
如果实施者将成熟度级别视为目标,然后设计流程和基础结构来通过评估,那么使用分阶段表示形式作为计划目标可能会适得其反。 可衡量的、持续改进(而不是数字)应仍然是任何改进计划的目标。
一些咨询公司主要关注持续性表达。 这种方法避免人为的成熟度目标,并倾向于确定可衡量的业务价值的改进的优先级,增加积极反馈的机会和持续改进的良性循环。
CMMI 模型的元素
CMMI-DEV 模型在版本 1.3 中定义了 22 个进程区域。 下表列出了这些进程区域:
| 缩略词 | 进程区域 |
|---|---|
| 汽车 | 因果分析与解决 |
| CM | 配置管理 |
| DAR | 决策分析与解决方案 |
| IPM | 集成项目管理 |
| MA | 度量和分析 |
| OID | 组织创新与部署 |
| OPD | 组织过程定义 |
| OPF | 组织过程焦点 |
| OPP | 组织过程性能 |
| OT | 组织培训 |
| PI | 产品集成 |
| PMC | 项目监视和控制 |
| PP | 项目规划 |
| 过程与产品质量保证 (PPQA) | 流程和产品质量保证 |
| QPM | 量化项目管理 |
| RD | 要求定义 |
| REQM | 需求管理 |
| RSKM | 风险管理 |
| SAM | 供应商协议管理 |
| TS | 技术解决方案 |
| VER | 验证 |
| 瓦尔 | 验证 |
在分阶段表示形式中,流程区域映射到成熟度级别;下图突出显示了该映射。
在连续表示形式中,进程区域映射到功能分组;下图突出显示了该映射。
每个进程区域包括必需组件、预期组件和信息性组件。 所需的组件(特定和通用目标)确定评估需要什么。 预期组件(特定和泛型做法)用于指导实施者,但如果能够向评估员提出充分的理由,可以用等效的做法替代。 信息性组件(例如典型工作产品和子方案)提供了更多详细信息,以帮助组织开始改进。
只有具体目标和通用目标是严格必须评估的,预期组件和信息组件的存在是为了指导实现。 CMMI 的示例做法和工作产品历史上来自大型空间和防御项目:它们可能不会反映组织的项目类型或较新的行业趋势,例如敏捷方法。 调整模型以适应你的上下文和目标。