如何从CMMI迈向DevOps国标？
原创-
2024-07-25 10:00:00
-
358
DevOps国标是个民间说法，官方名称是《系统与软件工程 开发运维一体化 能力成熟度模型》，由中国电子技术标准化研究院牵头制定，于2023年5月正式发布。
想要获取全文，可以在DevOps国标官方网站（https://openstd.samr.gov.cn/bzgk/gb/ ）中通过关键词“开发运维一体化”搜索到。
DevOps国标成熟度模型由6项能力域、30项能力以及各项能力在五级成熟度下定义的实践集组成。
那就有小伙伴问了，我司已经通过CMMI某个级别的评定，我们需要做什么才能够达到DevOps国标同级别的要求呢？今天我们就来探讨一下这个话题。
首先我们来看看CMMI和DevOps国标在范围覆盖方面的关系：
图中打对钩的部分是DevOps国标中CMMI覆盖到的部分，可见覆盖率相当高！同时，DevOps国标中还有5个DevOps特有的能力。
我们继续更深入探索，我们以“估算与计划”为例，来说明其在CMMI与DevOps国标中内容的差异。
在CMMI中，“估算”和“计划”是两个不同的实践域。具体来讲，CMMI中的“估算”内容如下：
CMMI中的“计划”内容如下：
在DevOps国标中，“估算和计划”是一项能力，定义如下：
ESP 1.1的实践典型活动如下：
——与团队成员共同审查需求和假设并确定估算结果；
——建立和维护项目任务列表，并分配人员，项目任务列表应包含优先级、任务粒度、任务难度、复杂程度等因素；
——与受影响的利益相关方一起评审项目任务列表，并达成共识，例如通过会议、邮件或其他在线协同软件来完成评审；
——记录任务分配情况，将达成共识的任务分配结果通过合适形式显式地记录下来。
ESP 2.1的实践典型活动如下:
——识别项目的目标，描述为什么和如何做任务以及如何执行将完成的工作，将使用的方法或技术；将如何提供资源来支持和完成这项工作；
——确定需求，记录需求将如何被处理；
——记录业务考量，业务考量可包括潜在的成本和收益、知识产权、竞争环境、长期需要和利润率、有待提高的核心胜任力、来自其他方面的所需核心胜任力、未来的趋势；
——识别风险和机遇，参考ROM能力。
ESP 2.2的实践典型活动如下：
——确定估算使用的单位，例如故事点、T恤尺码（相对大小标准）等；
——通过合适的方法来估算解决方案和任务的规模和属性，典型地，规模的估算方法包括卡片队列估算法、计划扑克估算方法、对象点估算方法、类比估算等。随着对解决方案特征与规模之间关系的理解的深入，项目估算方法及其运用可能会发生改变。典型属性包括复杂性、难度等，通常用于从规模到工作量、周期和成本的转换。属性可包括解决方案的定性方面，如新开发和老系统升级对比；也可以包括定量的分析和比较。
ESP2.3的实践典型活动如下:
——确定估算使用的单位，如人员、故事点、服务器等；
——描述解决方案的工作量、周期和成本的估算依据。团队对估算依据达成共识。
ESP2.4的实践典型活动如下：
——识别主要里程碑，里程碑可以基于特定事件或基于时间等。
——识别约束条件，尽早识别限制计划灵活性的因素。检查解决方案和任务特征可以确定这些问题。约束条件可包括需求、资源、活动之间的依赖关系等。
——识别资源需求，项目资源可包括：人员配备需要和成本（根据项目、任务、角色和职责以及每个职位所需的知识和技能来决定人员配备）；环境，如操作系统；设施，如云服务；可获得的知识产权等。
——识别和分析风险、机遇，评审和分析确定的约束条件，并将其记录为可能影响预算或进度的风险和机遇。
——根据估算制定预算和进度，并保持更新，具体包括：估算规模、资源；定义承诺的资源或预期可用的资源；确定活动的周期；确定附属计划；识别解决方案交付的发布或增量；更新风险和机遇。
ESP 2.5
按需要建立和维护附属计划以支持项目目标的达成。
对项目的愿景、目标、任务、里程碑、运维服务等各要素建立共识，指导与协调工作。
GB/T 42560-2023
一份完整项目计划可以包含多个计划。本实践需考量项目计划各个相关方面，并以合乎逻辑的方式将以下（不限于）要素组合在一起：
——任务；
——预算和进度；
——里程碑；
——信息和数据的管理和治理；
——风险和机遇；
——资源和技能；
——利益相关方的角色和参与；
——基础设施；
——运维服务；
——其他计划，例如配置管理或发布计划、个体工作计划、质量计划、度量和数据管理计划。
ESP 2.6的实践典型活动如下：
——平衡与协调资源以调整任务和资源的进度安排；
——确保共识得到足够的人员或其他所需资源的支持。
ESP 2.7的实践典型活动如下：
——确保参与实际工作的人员评审他们所负责的工作和启动工作的输入，评审决策、协议和必要的相关信息以理解完成工作所需的要求和计划；
——获得承诺，承诺是一种志愿承担、可见和预期的契约，由所有参与方遵守；承诺可以是文字记录，也可以是口头的，甚至是默认的；承诺可以是内部的，也可以是外部的；获得承诺从而达成共识，以用于项目跟踪和维护。
ESP 2.8的实践典型活动如下:
——记录项目计划；
——与受影响的利益相关方一起评审项目计划，确保项目计划描述了满足受影响的利益相关方的需要、期望和约束的可行方案，并帮助确保受影响的利益相关方履行其职责；
——按需修订项目计划。
ESP 3.1的实践典型活动如下：
——从组织的标准过程集中选择最符合项目需要的标准过程，这些过程共同构成了项目过程基本框架；
——根据裁剪指南修改组织的标准过程集和其他组织过程资产，以生成项目过程；
——酌情使用组织过程资产库中的其他资产，其他资产可以包括估算模型、经验教训文档、模板、示例文档等；
——记录项目过程，项目过程涵盖了工作活动以及与受影响的利益相关方的接口或连接；
——评审项目过程，记录并使用项目过程的评审结果、输入和问题以识别潜在影响；
——必要时修改项目过程，随着项目的进展，修改项目过程的描述以更好地满足项目需求以及组织的过程需要和目标。
ESP 3.2的实践典型活动如下：
——使用项目过程的任务和工作产品作为估算和计划项目活动的基础；
——依托组织级度量库来辅助估算工作；
——使用经过组织认可的估算方法；
——为组织提供结果和度量项，以改进估算方法并更新组织资产，包括实际结果、背景信息和确定的改进；
——分析组织过程数据，以更好地了解变化性、数据质量、均值、中位数和众数等信息；
——整合其他影响项目的计划，可包括人员配备计划、培训计划、利益相关方参与计划、性能改进和维持计划、度量与分析计划、协议管理计划、质量保证计划；
——纳入度量项定义和度量活动，度量项可包括组织的公共度量项集、项目或产品特定的额外度量项；
——为任务和活动建立客观的入口和出口准则，入口和出口准则清楚表明何时需要人员、何时开始以及何时完成任务;
——确定受影响的利益相关方之间识别、协调解决冲突的方法和工作机制。
ESP 3.3的实践典型活动如下:
——识别和记录关键依赖及其内在关系，并分析它们对计划的潜在影响；
——开发、运维各方以及其他受影响的利益相关方一起评审和协商依赖和内在关系，协调解决各类潜在冲突；
——记录各方承诺以便于处理识别出来的关键依赖。
ESP 3.4的实践典型活动如下：
——分析项目并规划相关的资源、设施和环境。项目环境的关键方面是需求驱动的。以与任何其他项目计划活动相同的严谨程度探索项目环境功能和质量特征。要考量的资源示例包括项目环境的关键因素、文化问题、可见性、会议空间、支持区域、实验室、交流协同工具、工作区的专门特性、安全、存储、项目设备等。
——指派负责任的个体来落实工作所需的资源、设施和环境。措施可包括：准备预算；成本效益论证；咨询主题专家；提交采购订单；与其他相关人员协商等。
——确保个体和团队参与有关资源、设施和环境的决策，可包括：项目设施的安排；项目环境的改变或改进；执行项目所需的资源。
ESP 4.1的实践典型活动如下：
——建立明确的业务目标；
——基于业务目标，识别完整的质量和其他过程性能目标；
——识别关键目标的度量方式，权衡优先级、可度量性、可控制程度等因素；
——识别关键控制变量，统计分析潜在的控制变量和关键目标度量间的相关性；
——建立性能基线，与组织资产交互；
——基于组织资产中的历史数据和当前的项目数据，建立量化模型。
可见，DevOps国标的内容比CMMI相应的内容颗粒度更细，而且更加具有DevOps特色。如果说把CMMI比作宪法，那么DevOps国标相应的内容可以看作是特定领域的法律。
DevOps国标与CMMI并不冲突，但DevOps国标在DevOps方面具有更加具体的指导性和可操作性。因此，CMMI做得更扎实的企业，会有更好的基础来达成DevOps国标相应的等级，到底相差多少，还要看这家企业实际做的和DevOps国标的对比结果。
*图片和部分内容来源：DevOps国标官网《系统与软件工程 开发运维一体化 能力成熟度模型》
15
联系我们
刘斌
高级客户经理
电话(微信)
17685869372
QQ号码
526288068
联系邮箱
liubin@chandao.com
名额有限
完善信息领取项目管理礼包
400+项目管理实践
100+项目管理视频
50+项目管理知识模版
去完善
刘斌/高级客户经理
联系客服领取礼包
