基于CMMI模型实现自己的总体研发框架（1）——CMMI模型-前言+概念+通用目标通用实践

一、前言

接触CMMI有12年了，09年开始接触CMMI，跟着咨询老师给自己公司做CMMI认证，自己负责公司的测试相关流程体系的建设。到19年自己负责公司的体系建设，初次也是CMMI过级，不过这次只是为了过级，公司只拿了个证书，没什么实质的收获，自己倒是对CMMI重新学习了一遍。虽然个人又学了一些东西，但对公司很失望。

跨过年后，公司决定要做流程优化，这次是基于敏捷来做，并分析出不同的改进专题，完成一个推广一个，半年时间也有不少成效，例如建立了基于Scrum的内部软件研发流程、建立基于瀑布的交付项目的研发流程、建立了度量的方法和收集了度量数据、梳理了配置管理，并且几乎所有项目都按照迭代计划、每日站会、回顾会议的方式来开展工作。可惜后来自己工作调整，这块工作交给其他同事，该同事也没联系原来的咨询老师，做的东西后来基本作废，各部门又各搞各的，质量也一台糊涂，上线的产品在客户现场测试，被客户发现两百多个bug，真是极度失望。

闲言少叙，再回过头来说CMMI。CMMI针对软件研发提供了一套结构化的方法论，并提供最优的时间供使用者参考，这样既有方法又有示例，按照这套体系可以搭建出一套适合自己公司的可以落地的流程体系。不像PMP，几乎全是理论化的空中楼阁，学完PMP后非常失望，本来想学项目管理的，学完后发现按他们的讨论管项目，完全无法落地，花了半年的时间和几千块钱，最终也只是拿了一个证，对个人能力的提升远不如CMMI这一套来得多。

有人可能说现在都搞敏捷，不用CMMI那套沉重的流程体系了。说这话的人基本是不了解CMMI的本质。CMMI主要提供的是方法论，你按他的方法去做并有相关证据就行了。CMMI说要有需求管理，难道敏捷不做需求管理吗？只是实现的方式不同而已。CMMI说做任何事都要有计划，难道敏捷不用做计划？ CMMI有验证和确认两个过域，翻译过来可以认为就是测试和验收，难道敏捷不用测试和验收？

本文主要讲解一下CMMI的理念，以及对22个过程域，每个过程域的特定实践，已经所有过程域需要满足的通用实践做出说明。

CMMI不同级别的区别则不在此文说明，那涉及CMMI过级的部分，我们要学到是CMMI的方法论和知识，而不是为了了解过级。

二、CMMI解释和理念基础

2.1CMMI概念

CMMI®（Capability Maturity Model® Integration，能力成熟度模型集成）模型系列是帮助组织改进其过程的最佳实践的集合。这些模型由来自产业界、政府以及软件工程研究所（Software Engineering Institute，SEI）的成员所组成的产品团队开发完成。

2.2CMMI起源

CMMI思想根植与一下思想、技术、方法

• 软件工程理论和方法
• 项目管理技术和方法
• 全面质量管理思想
• 持续过程改进思想
• 其它一般管理思想和方法

所以CMMI的过程域也会分为项目管理、过程管理、工程、支持

三、相关名词解释

• PA：过程域，是一个领域内相关的一系列活动的集合，当这些活动一起被执行时，可满足被认为是在该领域做出显著改进的目标。CMMI1.3包含22个过程域
• GG（Generic Goals）通用目标，多个过程域都适用的目标，实际上上每个过程域都需要达到的目标。
• SG（Specific Goals）特定目标，为满足过程域必须满足的独特的目标
• GP（Generic Practices）通用实践，与通用目标关联的活动，对实现通用目标的达成有重要意义，有助于过程域所关联的过程的制度化
• SP（Specific Practices）对达成特定目标具有重要意义的活动的描述，这些活动的实现有助于特定目标的达成
• 组织，一个由成员共同管理一个或多个项目的行政管理结构，这些项目有共同的高层管理人员，并在相同的方针/政策/大原则下运作。CMMI的组织可能是指整个公司，也可能是分公司，也可能是研发中心。

四、通用目标和通用实践

通用目标和通用实践是指所有过程域都需要满足的相同目标，都需要应用的相同实践。其实我觉得不仅仅是CMMI的过程域中使用，在生活中方方面面这些通用目标和通用实践都可以用到，而且应该要借用。

GG1 达成特定目标

过程域的特定目标得到过程的支持，过程的支持通过输入转化为输出的工作产品来实现

GP1.1 执行特定实践

执行过程域的特定实践，主要关注产生的工作产品和交付的服务，只要有结果就行，不用遵循规定的过程，实践做得好坏取决于实施该项工作的个人。

GG2 制度化为已管理的过程

过程得到制度化为已管理的过程

GP2.1建立组织级方针

从组织级层面建立方针，以计划并执行过程。此处组织级可以是公司级的，也可以使公司某个研发中心层面的。

应用到个人层面，可以理解为建立一个框架性的方针或政策。

GP2.2计划过程

建立计划，以执行过程。

应用到个人层面，则是万事都需要有计划。

GP2.3提供资源

提供充分的资源，以执行过程、开发工作产品并体统过程的服务。

确保计划所定义、执行过程所需的资源在必要时可用。

应用在个人层面也是一样，当组好计划后，就要为计划的实现准备充分的资源。

GP2.4分派职责

分派职责与职权。一方面是定义各活动负责角色的责任，另一方面也要分派对应的职权。

此通用实践的意义在于给定义好各种角色，所有角色有相应的职责，这样某人是哪个角色，相应的活动通过角色定义就可以定位到具体负责的人。

GP2.5培训人员

必要时，对执行的人员进行培训，确保基本执行所需的能力。方式可以使自学、自己找培训、提供在岗培训、辅导等。

GP2.6控制工作产品

对所选择的工作产品进行适当级别的控制，保证其寿命内的完整性。例如需求确定后要进行控制，不能随意更改，不同的产品控制级别不一样。有的更改时只需要有记录就行，而有的产品更改必须通过审批。

GP2.7识别相关干系人，并使之参与

识别过程的相关干系人，并使之按计划参与。所谓的干系人，指得是跟活动利益相关的任何实体，可以包括个人、团队、管理层、客户、供方、最终用户、运行与支持人员、其他项目、以及政府监管机构等。

GP2.8监督并控制过程

按照执行过程的计划，监督并控制过程，当出现偏差时，并采取适当的纠正措施

GP2.9客观评价遵守程度

提供可信的保证，确保过程与所选的工作产品按照计划得到实施，并遵循过程描述、标准和流程。即有没有按照规定的方式做事。

GP2.10与上级管理层一起进行状态评审

与上级管理层一起对过程的活动、状态、结果进行评审，为管理层提供对过程的适当可视性，当发现问题时可以及时解决。

GG3 制度化为已定义的过程

过程得到制度化为已定义的过程

GP3.1 建立已定义的过程

建立并维护已定义的过程描述，组织应该定义标准的过程描述，而本实践是根据实际情况对组织的过程描述进行裁剪，使其妈祖项目的需要。

GP3.2收集过程相关经验

收集过程执行中的各种经验，包括工作产品、度量数据、经验教训与过程改进建议，形成组织过程资产，供计划执行相思过程的人员参考使用。

五、后续

CMMI的内容有点多，本来想两篇写完，目前看准备写6篇，此是第一篇，后续项目管理、过程管理、工程、支持的过程域各一篇，CMMI模型表述方式一篇，自己应用落地的研发框架一篇

六、CMMI和OKR的对应关系

最近看了OKR，对照CMMI发现有共同之处

OKR分三层，目标、关键结果和关键行动，目标确定后关键结果支撑目标的实现，而关键行动确保关键结果的达成。

而CMMI的过程域也分为目标、实践和子实践，目标当然跟OKR的目标对应，而实践做到后就能确保目标可以达成，所以实践对用关键结果，而子实践则是确保实践的实现，这个就相当于行动确保OKR中的关键结果得以实现。

这个也是CMMI的精髓所在，目标确定后行动则根据子实践和实践行动就行了，实践落实好了目标就可以达成。