CMMI2.0专题——白话CMMI DEV V2.0

第二部分CMMI DEV V2.0 PA精解

 

一、需求开发与管理（RDM）

RDM，是需求开发与管理的简写，该PA合并了CMMI V1.3版本的RD与REQM两个PA。它包含了需求获取、需求分析、需求描述、需求验证与确认、需求管理等五个需求工程的活动。

实践列表

通俗解释

 

RDM1.1记录需求

需求文档化。

 

RDM2.1引导干系人的需要、期望、约束、接口或连接。

引导，意味着需求工程师要启发客户、用户提出自己真实需求，要有引导的手段，比如访谈、原型、问卷调查等。

干系人包括了客户、最终用户、间接用户，包括了高层，中层，操作层的人的需求，包括了内部客户与外部客户，包括了产品生命周期各个阶段的干系人。在捕获需求时，要将干系人识别完备，否则就会遗漏需求。

需求在CMMI模型中分成了四部分：

需要：必需的、不可裁剪的需求；

期望：最好能实现、越多越好、可以裁剪的需求；

约束：实现需要与期望的限制条件，可能是技术的、管理的、商务的、环境的限制；

接口或连接：与其他产品或系统之间的衔接关系，任何一个系统都不是孤立存在的！

 

RDM2.2转换干系人的需要、期望、约束、接口或连接为排列了优先级的客户需求

客户需求要文档化。客户需求中要包含了需要、期望、约束、接口或连接，并且需求要划分了优先级。

需求一定客户划分优先级，没有划分优先级的需求类似一堆垃圾，因为后续无法根据优先级排列开发顺序，无法尽早给客户交付有价值的需求，无法进行多快好省的平衡。

需求划分优先级的方法有多种：

卡诺模型：把需求划分为基本的需求、期望的需求、兴奋型需求；

百分制法：参与划分需求优先级的每个人都有100点，可以根据自己的理解分解100点到每个需求上，然后累计每个需求得到的点数，从高到低排序即可得到需求的优先级。

ROI方法：让客户或客户代表对每个需求的业务价值给出相对的分值，让开发团队针对每个需求给出开发成本的相对分值，二者相除得到相对的投入产出比，然后排序得到优先级。

……

 

RDM2.3和需求提供者关于需求的含义达成一致的理解

这是讲需求理解的外部一致性，即开发方要和需求提供方对需求的理解达成一致。双方要采用面对面的沟通、原型展示、需求评审等多种手段对需求达成一致。

 

RDM2.4从工作投入的参与者处获得他们对需求可实现的承诺

这是讲需求理解的内部一致性，即实现需求的人要对需求理解一致，认为技术上需求是可以实现的，从工期上也是可以保证的。这是需求实现者对需求提供方的承诺，不是需求方承诺需求不变。

需求的内外部沟通交流是很重要的一个作业环节。可以采用需求交底，需求反讲，需求梳理会议，原型展示等多种手段进行需求的内外部沟通。

 

RDM2.5建立、记录、维护需求与活动、工作产品之间的双向可跟踪性

要确保：

所有的需求都分配到人了；

所有的需求都被设计了；

所有的需求都被实现了；

所有的需求都被测试了；

从需求能跟踪到对应的设计，也能从设计跟踪到对应的需求，这就是双向跟踪性。

接口需求、非功能性需求是在实践中最容易忽略的进行跟踪的需求。

 

RDM2.6确保计划、活动和工作产品与需求保持一致

通过各种评审、测试、验证与确认活动确保设计、代码、测试用例、计划等与需求保持一致。

当发生了需求变更时，也要维持相关配套文档与活动与需求的一致性。

 

RDM3.1根据组织级的过程，开发和保持更新解决方案和其构件需求

解决方案和构件需求就是产品和产品构件需求，就是需求规格，就是对需求的详细定义。

需求变更时要执行需求变更影响的分析、评审、认可。

 

RDM3.2定义操作概念和场景

场景，就是各种正常或异常的业务操作路径，要包含产品全生命周期的场景。

操作概念，就是用户在各种场景下如何使用产品的描述。

在描述软件的功能需求时，如果采用use case的方式，把各种正常流，异常流都描述清楚了即是操作概念的描述。

 

RDM3.3分配待实现的需求

所谓的分配需求就是把整体的系统需求分配到每个产品构件上。比如，关于一个杯子的需求，杯子分为杯盖与杯桶，容量的需求主要是分配给杯桶，温度的需求要分配给杯盖与杯桶，比如杯盖要承受110度的温度，杯桶可以承受105度的问题，这就是把整体的系统需求分配到每个产品构件上。

 

RDM3.4识别、定义、保持更新接口与连接需求

接口需求分为外部接口需求与内部接口需求。外部接口需求在需求获取时是必须获取的，内部接口需求是在分配了待实现的需求后，就产生了内部接口需求，就如同上边那个例子，把杯子划分为杯盖和杯桶之后，就产生二者之间的接口需求，这是产品内部不同构件之间的接口，是内部接口。

 

RDM3.5确保需求是必要的和充分的

需求是必要的，就是需求不是多余的，不是也有可无的，不做无用功。需求是充分的，就是需求是不可缺少的。所以这条实践就是要求需求是不多不少的，是刚刚好的。

在需求评审时，需求确认时可以检查需求是否是充分的、必要的。

 

RDM3.6平衡干系人的需要和约束

平衡需要和约束，就是做多快好省的平衡，把需求和工期、质量、投入进行平衡。平衡的前提是要对需求划分了优先级。参见RDM2.2。

 

RDM3.7确认需求以确保最终的解决方案可以在目标环境中运行

要确保需求满足了用户的真正需求，此条实践确认的是需求而不是最终交付的产品，所以对需求的确认是通过评审、模拟或仿真来实现的。

 

二、技术解决方案（TS）

 

TS：技术解决方案，映射到实际工程活动中包含了技术路线选择、概要设计、详细设计、实现、技术文档编写等活动。

 实践列表

 

TS1.1创建满足需求的解决方案

解决方案就是指我们的交付物，产品、系统或服务等。

这条实践的含义就是实现满足客户需求的产品或服务，无论采用什么方法。

 

TS2.1设计和创建满足需求的解决方案

在实现产品或服务之前，必须做设计。设计包含了概要设计、详细设计等。概要设计侧重于各产品部件之间的关系，详细设计侧重于每个部件内部的实现方法。

这条实践是TS1.1的升级，包含了1.1中的活动。

在创建解决方案时，要确保产品的内建质量，在敏捷方法中提倡如下的实践：

结对编程；

测试驱动的开发；

持续集成；

静态检查；

等等。

 

TS2.2评价设计并处理识别的问题

对设计进行评审，并修改发现的问题。

评审时应该对照需求，确保所有的需求都被实现了。

评审有多种方式，如何进行设计评审，可以参见同行评审PA。

 

TS2.3提供解决方案的使用指南

交付给用户后，用户如何使用交付的产品？需要有安装手册、使用手册、在线帮助、培训资料等，本实践要求编写、交付这些使用指南。

 

TS3.1制定设计决策的准则

设计决策的准则即评价设计方案优劣的评价指标、评价方法。

当存在多种技术路线、技术方案时，对这些技术方案要从哪些方面进行评价？怎么评价？

 

TS3.2对选中的构件制定候选解决方案

对产品构件、某些特定需求的解决方案进行多选一，即识别多种技术方案。

 

TS3.3执行创建、购买或复用分析

本实践对产品构件的实现方法进行宏观选择。某些产品构件，是自己从头开发，还是直接从市场上购买成熟的产品，或者复用历史项目已经实现的成品，或者是使用开源的构件。

 

TS3.4基于设计准则选择解决方案

采用TS3.1确定的设计准则对TS3.2识别的各种候选解决方法进行评价选中某种解决方案。

有些非功能性需求在实现时，需要特别慎重，此时往往需要从多种候选方案中选择一种最佳的解决方案。

 

TS3.5制定、保持更新并使用所需信息实现设计

当把系统拆分成子系统，子系统拆分为模块后，实现每个模块所需要的设计信息应该按模块进行分类存放，便于实现者快速检索到所需要的所有信息，并且不会存在信息污染，即他能看到他想看到的，而与他无关的内容不会出现在眼前。当实现的系统比较庞大，设计文档比较多时，这个实践的价值尤其突出。

 

TS3.6使用已建立的准则设计解决方案的接口或连接

此实践包含两层含义：一是定义评价接口优劣的准则，二是对接口进行设计，并确保接口的设计满足了评价准则。

 

 

三、产品集成（PI）

 

产品集成（PI）即把不同部件集成在一起，形成一个更大的部件或一个完整的可交付的产品。该PA包含了集成策略的制定、集成准备、集成、集成后的验证与确认、以及交付的活动。

 

实践列表

 

PI	1.1	Assemble solutions and deliver to the customer.	组装解决方案并交付给客户
PI	2.1	Develop, keep updated, and follow an integration strategy.	制定、保持更新并遵从集成策略
PI	2.2	Develop, keep updated, and use the integration environment.	制定、保持更新并使用集成环境
PI	2.3	Develop, keep updated, and follow procedures and criteria for integrating solutions and components.	为了集成解决方案和部件，制定、保持更新并遵从规程和准则
PI	2.4	Confirm, prior to assembly, that each component has been properly identified and operates according to its requirements and design.	在组装之前，确认每个部件都依据其需求和设计被正确地标示了并能正常运行
PI	2.5	Evaluate assembled components to ensure conformance to the solution’s requirements and design.	评价组装好的部件以确保与解决方案的需求和设计保持一致
PI	2.6	Assemble solutions and components according to the integration strategy.	依据集成策略组装解决方案和部件
PI	3.1	Review and keep updated interface or connection descriptions for coverage, completeness, and consistency throughout the solution’s life.	在解决方案的全生命周期内，评审和保持更新接口或连接的描述，以确保覆盖率、完备性和一致性
PI	3.2	Confirm, prior to assembly, that component interfaces or connections comply with interface or connection descriptions.	在组装之前，确认部件接口或连接与其描述一致
PI	3.3	Evaluate assembled components for interface or connection compatibility.	评价组装的部件，以确保接口或连接的兼容性

 

通俗解释 

 

PI1.1组装解决方案并交付给客户

把不同的构件组装起来形成可交付的产品，并交付客户。

 

PI2.1制定、保持更新并遵从集成策略

集成策略的核心内容包含了：

集成的频率：持续集成、每日构建、每周集成、阶段性集成、一次性集成等；

集成的方法：手工集成还是工具自动化集成；

集成的顺序：由低向上，自顶向下，混合交叉等；

 

PI2.2制定、保持更新并使用集成环境

集成环境包括了集成使用的工具软件、硬件设备、仿真器、测试设备等。

有些环境是自己开发的，有些可能需要外部采购，也可以复用历史已有的环境。

在集成之前要检查环境的正确性。

 

PI2.3为了集成解决方案和部件，制定、保持更新并遵从规程和准则

产品集成的规程即产品集成与测试的具体方法与步骤，包括手工集成的步骤，自动集成的脚本，集成测试的步骤与用例。

产品集成的准则即产品集成的进入退出准则，包括集成准备就绪的准则、集成测试的用例与通过准则等。

 

PI2.4在组装之前，确认每个部件都依据其需求和设计被正确地标示了并能正常运行

检查集成的准备情况：

是否在配置库中？版本与存放位置否正确？

待集成的部件是否完备，是否有遗漏？

待集成的部件是否经过了评审或单元测试？

 

PI2.5评价组装好的部件以确保与解决方案的需求和设计保持一致

执行集成测试以确保集成后的产品部件或产品符合需求与设计。该活动是持续、反复执行的，每次集成后都要进行测试。

 

PI2.6依据集成策略组装解决方案和部件

实际执行集成的活动。

持续集成是目前行业的典型实践，强烈建议各公司搭建自己的持续集成平台，自动化集成。

 

PI3.1在解决方案的全生命周期内，评审和保持更新接口或连接的描述，以确保覆盖率、完备性和一致性

接口分三类：

外部接口：运行时与其他系统的接口；

环境接口：开发、测试、运维时与周围环境的接口；

内部接口：产品的部件之间的接口。

在产品的全生命周期内，要进行接口的管理，有接口需求、接口设计，要评审接口需求、接口设计，发生变更时，要保持各描述的一致。

 

PI3.2在组装之前，确认部件接口或连接与其描述一致

在集成之前，要评审接口的实现与接口需求、接口设计的一致性。

 

PI3.3评价组装的部件，以确保接口或连接的兼容性

在集成之后，对接口进行测试，确保接口的兼容性，包括软硬件的兼容性、浏览器的兼容性、数据兼容性。这是在PI2.5的基础之上，要求更高、更具体了。

 

在CMMI模型中，对接口的管理设计到如下的实践，如果再新增一个PA命名为接口管理的话，可以把如下的实践集中在一起：

 

四、同行评审（PR）

 

同行评审，不是通过测试去发现缺陷，而是通过专家阅读文档、代码发现缺陷，是在实现之前发现缺陷的有效手段。

同行评审这个PA是从VER中剥离出来的，原来1.3版本的VER与VAL合并成了VV PA，让熟悉最早的SW-CMM.1.1的从业者感受到了复古之风。

这个PA的实践描述通俗易懂，最好理解。但是，很多公司做了同行评审，效果不好。

我之前写过多篇博客讲解同行评审如何做的问题，分别列举到对应的实践之下了。 

实践列表

通俗解释 

 

PR1.1评审工作产品并记录问题

做了评审，并记录了问题。

 

PR2.1制定并保持更新用以准备和执行同行评审的规程和支持材料

同行评审怎么做？需要定义具体的方法及规程，包括检查单、评审记录等。如果采用工具辅助同行评审，也需要购买、搭建同行评审的环境。

这个网页下，有常用的代码评审的支持工具：

http://baijiahao.baidu.com/s?id=1585905486202936778&wfr=spider&for=pc。

评审要划分不同的方法，不同公司可能方法不同，比如：邮件评审、会议评审、会议走查，个人走查等等。

评审的分类：https://blog.csdn.net/dylanren/article/details/5906601

 

PR2.2选择待同行评审的工作产品

并非所有的工作产品都需要做评审。

要评审的工作产品并非都采用同一种评审方式。

要制定评审的计划，识别出要评审的工作产品、评审方法、评审参与的角色、评审的时间。

 

PR2.3采用已建立的规程，对选中的工作产品准备和实施同行评审

准备的活动包括了评审通知、评审的资料分发、准备会议室等等。

具体做法参加如下的文章：

做好同行评审的24个细节：https://blog.csdn.net/dylanren/article/details/43668455                               项目计划评审时的36个检查点：https://blog.csdn.net/dylanren/article/details/4964942

项目里程碑评审的关注点：https://blog.csdn.net/dylanren/article/details/4965030

软件需求评审之道：https://blog.csdn.net/dylanren/article/details/4965111

需求评审的案例分析：https://blog.csdn.net/dylanren/article/details/4965231

需求评审会议亲历记：https://blog.csdn.net/dylanren/article/details/4965156

案例：代码走查：https://blog.csdn.net/dylanren/article/details/7739002

 

PR2.4解决同行评审中发现的问题

 

PR3.1分析同行评审的结果

可以分析缺陷密度、评审速度、缺陷类型的分布等等，具体做法参见如下的文章：

例解：如何分析同行评审的度量数据：https://blog.csdn.net/dylanren/article/details/4964773

实例：评审速度与缺陷密度之间的相关性：https://so.csdn.net/so/search/s.do?q=评审&t=blog&u=dylanren

代码评审的速度与缺陷密度啥关系：https://blog.csdn.net/dylanren/article/details/78337871

 

五、 验证与确认（VV）

 

验证verification与确认validation是两个不同的概念，在CMMI V1.3版本中是两个不同的PA，在2.0版本中合并成了一个PA，命名为VV。

验证与确认的区别，可以通过下表来描述：

 

在产品开发过程中持续地进行验证与确认是基本的原则。验证与确认是互补的，缺一不可。只做验证不做确认，一旦跑偏了，就无法满足最初的需求，只做确认不做验证，一是无法及时发现开发过程中的错误，返工的成本极其昂贵，而且确认本身的成本也比较高。所以在业内都是称为V&V，而不是V or V。

 

实践列表

 

通俗解释

 

VV1.1执行验证以确保需求已被实现并记录和沟通验证结果。

 

VV1.2执行确认以确保解决方案在目标环境中能发挥预期的作用，并记录和沟通结果

这2条实践就是要求执行了验证与确认的活动。

 

VV2.1选择验证和确认的部件和方法

对哪些工作产品、产品部件执行验证与确认？采用哪些手段？

 

VV2.2建立、保持更新和使用支持验证和确认的环境

环境包括软件工具、硬件工具、测试设备等。

有些工具可以是自己开发的，有些工具是采购来的。

验证与确认的环境与产品实际执行的环境可能存在差异，这是一个常见的风险。

 

VV2.3制定、保持更新和遵从验证和确认的规程

规程即具体的操作步骤，即如何具体做验证和确认，从前期的准备到执行过程，以及事后的分析。

 

VV3.1制定、保持更新和使用验证和确认的准则

准则包括了验证与确认的检查单、测试用例、验证与确认启动的条件、结束的条件。

 

VV3.2分析和交流验证和确认的结果

对验证与确认结果的分析包括：

验证与确认投入的充分程度分析、覆盖率分析；

缺陷的趋势分析；

各种缺陷类型的分布分析、严重程度分析、原因分析等等。

根据分析结果应识别应采取的纠正措施、改进建议等。

 

 

六、详细剖析（PQA）过程质量保证

 

PA概述

 

1）本PA的名字虽然称为过程质量保证，但是实际上仍然是包含过程的质量保证与产品的质量保证。

2）过程是历史经验教训的总结，是对这些历史财富的规范化，标准化，是为了避免错误的重现。而质量保证则是监督这些历史经验的落地执行，能够让成功得以重复。

3）质量保证的关键是要客观，如何确保客观性呢？

    i）独立的团队。不能自己检查自己是否做事规范，应该由其他角色，其他岗位实施检查。这些QA人员由独立的渠道向项目组的上级报告项目组的规范情况。对于中大型的开发组织，通常有独立于开发团队的质量保证团队负责对项目进行检查，对于小型的开发组织，可以在开发团队中安排人员进行交叉检查。

    ii）依法办事。QA在进行检查时，要对照标准规范进行检查，而不是凭经验进行检查；

    iii）QA人员应该经过了专门的培训与训练。他们熟悉标准规范，知其然也知其所以然，掌握了检查的方法、沟通的方法等；

4）组织级要建立质量保证的文化。建立质量保证的文化一个重要的方法，就是各级管理者要尊重公司的标准规范，而不是总是法外施恩，管理者违反标准规范。

  

实践列表

 

  

实践解析

 

PQA 2.1 基于历史的质量数据，制定、保持更新和遵从质量保证方法和计划。

理解与实施要点：

1） 历史的质量数据包括但不限于如下的内容：

历史项目发现的问题；

历史项目典型文档、典型案例；

历史项目的经验教训；

历史项目提出的改进建议；

历史项目的度量数据及其分析结论；

2）要从历史的这些数据中吸收营养，更好的做好新的项目，充分挖掘历史数据的价值，所以在开始一个新项目之前，要总结历史。

3）在制定质量保证计划时，要选择本项目要参考的标准规范，这些标准规范可能有：

国际的标准；

国家的标准；

行业的标准；

公司的标准；

客户指定的标准；

项目组自己定义的标准；

4）质量保证计划中通常包括的内容有：

参考的标准规范；

质量保证人员；

需要检查的过程或活动；

需要检查的工作产品；

抽样检查的比例；

检查时间；

检查的方法；

问题报告渠道……

5）质量保证计划可以简单也可以完备，简单的QA计划可以就是一页纸，一张表，参见后面的案例。

 

业界案例

 

案例1:质量保证计划，源自深圳某客户的案例：

 

 

周次这一列为项目的时间线，在项目组中会输出一些关键文档，要有一些关键过程，都放在列中，如果在某个周次需要对某文档或过程做检查，则标上Y，如果没有按期完成，则红色显示，如果延期实施则黄色表示，如果按期实施了检查，则绿色表示。如果以列来看，就可以发现某个文档或某个过程是否在整个项目进展过程中是否计划了检查活动，如果以行来看，就可以发现某个周次是否有质量保证的活动。

 

PQA 2.2 在整个工作期间，对照文档化的过程，客观评价选中的、已执行的过程和工作产品

理解与实施要点：

1） 质量保证活动要贯穿项目始终，从项目开始一直到结束。

2） 早发现问题，早修复问题成本低。

3） 对过程与工作产品都要进行检查。

4） 检查时要依据文档化的标准规范。

5） 文档化的标准规范意味着成功的做法是可以重复的。

6） 并非所有的文档和过程都需要进行检查，可以抽样检查。

7） 基于参照的标准规范以及历史发现的不符合问题制定每次检查的检查单。

8） QA检查的方法通常有三种：

查文档的有无、是否符合模版；

旁观活动的执行；

事后访谈过程的执行者；

9）检查单的制定要点：

反应了流程与文档重点；

根据检查项的命中率对检查项进行排序；

一个检查项一个问题；

每个检查项都是是否类型的封闭式问题；

10）进行检查的时机：

交付给客户之前；

入基线之前；

同行评审之前；

里程碑评审之前；

正式发布报告或结论之前；

……

 

PQA 2.3 交流质量问题和不符合问题并确保他们得到解决

理解与实施要点：

1）首先和不符合问题的当事人沟通问题；

2）如果当事人拒绝问题或不按时解决问题，则可以逐级上报问题；

3）如果管理者对不符合问题进行了豁免，需要记录；如果豁免的次数比较多，需要进行反思，是标准规范本身不合理，还是公司缺少质量保证的文化；

4）对于不符合问题要进行横展开的分析，看看其他项目是否有此问题？是否有其他类似的问题？

5）QA人员的沟通技巧很关键，在沟通时要注意如下的原则：

客观陈述事实；

以标准规范为依据；

对事不对人；

不激化与当事人的矛盾；

耐心陈述问题；

以面对面沟通为主；

要当事人知其然也知其所以然；

6）可以通过jira之类的问题跟踪系统记录、跟踪问题的关闭。

7）对不符合性问题的记录包括但不限如下的内容：

问题描述、发现人、发现日期、计划修复日期、责任人、实际修复日期、问题关闭日期。

 

业界案例

 

案例1:QA沟通不当

某软件公司的董事长平时不过问公司的具体事务，某日外出沟通交流学习，看到其他公司很重视质量，于是回到公司后就叫来质量经理汇报工作。

    质量经理觉得很突然，没有做事先准备，当董事长问起当前存在的质量问题时，就汇报了某项目存在的NC问题，项目经理未能按时修改，董事长大怒，叫来该项目经理猛批一通，项目经理很委屈，认为那仅仅是一个无足轻重的问题，却被质量经理打了小报告，于是回头就和质量经理吵了起来。

  

PQA 2.4 记录并使用质量保证活动的结果

理解与实施要点：

1）质量保证活动的记录包括但不限于：

质量保证计划；

质量保证计划跟踪记录；

不符合项纪录；

不符合项的关闭记录；

对不符合项的统计分析报告；

质量保证活动的总结报告；

质量保证活动的度量数据、经验教训总结等；

2）这些记录要保留下来充实到组织过程财富库中，便于将来项目的借鉴使用。

 

PQA 3.1 在质量保证活动期间，识别和记录改进机会

理解与实施要点：

1）对于发生频率比较高的不符合问题要进行反思，分析是否是标准规范定义的不合理，从而识别出标准规范的改进点，也有可能不修改标准规范，而是加强标准规范在组织内的培训、推广力度；

2）质量保证人员与项目组打交道比较多，可以听到、看到很多好的或坏的现象，从中可以识别出改进的机会；

3）识别的改进机会要提交到EPG，进行评价、筛选以确定是否纳入组织级改进。

 

七、供应商合同管理（SAM）

    SAM，supplier agreement management，是在所有的PA中，唯一一个在评估时可以排除在外的PA。

    如果有外包或采购产品或服务的行为，则可以参考SAM这个PA的实践进行分包或采购管理。

 

实践列表

 

 

通俗解释

 

SAM1.1制定并文档化供应商协议

和供应商要签订协议。协议可以包含多种形式，比如正式的合同、授权书、服务等级定义、备忘录、任务描述等等。

 

SAM1.2接受或拒绝供应商交付物

符合要求则接受，否则拒绝交付物。

 

 

SAM1.3处理供应商发票

核对发票信息、供应商提供发票、付款、记录应付账款、与供应商对账。

 

SAM2.1按照供应商协议监督供应商并保持协议更新

与供应商对协议达成一致的理解，签署协议，当需求或外部场景发生变更时更新协议。

对照供应商协议监督供应商的行为。

 

SAM2.2执行供应商协议中的活动

供方、需要都要履行在协议中定义的义务。

双方开展一些评审活动，确保大家都按协议执行了。

有问题解决问题，也有可能修改协议。

 

SAM2.3在接收供应商的交付物之前，验证供应商协议被满足了

验收之前进行检查：数量、质量、工期是否符合供应商协议中定义的验收标准。如果是软件则要进行软件测试。

 

SAM2.4基于供应商协议管理供应商提供的发票

在开发票之前要核对发票信息与金额。

到达付款时间应及时付款。

发票信息不对的，需要重新开。

供方收到款之后，采购方核销应付账款。有可能一张发票对应了多次付款。

 

SAM3.1选择技术性的供应商的交付物进行分析并执行技术评审

双方应该在协议中确定了对哪些交付物需要进行技术评审。

供应商的某些中间技术文档需要进行评审。比如供应商做了需求开发，对于需求的规格就需要双方一起认可。

供应商的最终技术交付物也需要进行评审。比如供应商开发了某些软件构件，需要和采购方自己开发的系统进行联调，对于接口部分就需要进行评审。

 

SAM3.2基于供应商协议中的准则选择并监督供应商的过程和交付物

除了监督交付物以外，也需要对供应商的供应过程进行监督，监督哪些过程，需要在协议中双方达成一致。

 

SAM4.1选择度量元并应用分析技术来定量管理供应商的性能以达成质量与过程性能目标。

为供应商定义定量的目标，并采用统计的技术对其进行定量管理，比如：

对供应过程进行SPC；

对供应商的历史性能建立过程性能基线或性能模型；

对供应过程进行模拟等。

 

八、估算（EST）

EST（estimation）是CMMI V2.0中新增的一个PA，从1.3版本中的PP与IPM PA中剥离了一些实践过来。

 

基本思想

估计什么？规模、工作量、工期、成本等。

估算是承诺的基础，充分沟通是估算的基础。

估算可能是逐步细化的,并非在项目初期就估计一次。初期的估算与实际结果偏差比较大，因此，承诺也是多版本的，会逐渐调整承诺。

估算要有方法论，要根据估计的结果与实际的偏差率不断调整，优化估算方法。

估算时做出的假设要进行沟通和记录。 

 

实践列表 

 

EST	1.1	Develop high-level estimates to perform the work.	建立一个初步的估算以执行任务
EST	2.1	Develop and keep updated the scope of what is being estimated.	建立并保持更新估算对象的范围
EST	2.2	Develop and keep updated estimates for the size of the solution.	建立并保持更新解决方案的规模估算
EST	2.3	Based on size estimates, derive effort, duration, and cost estimates for the solution.	基于规模估算，开发并记录解决方案的工作量、工期和成本估算以及估算的理由
EST	3.1	Develop and keep updated a recorded estimation method.	制定并保持更新文档化的估算方法
EST	3.2	Use the organizational measurement repository and process assets for estimating work.	在估算任务时，使用组织级的度量库和过程资产

 

通俗解释

 

EST 1.1建立一个初步的估算以执行任务

 

EST 2.1建立并保持更新估算对象的范围

列举出所有的估算对象：需求，交付物，任务或活动。

 

EST 2.2建立并保持更新解决方案的规模估算

解决方案即交付的服务或产品。

在估算工作量、工期及成本之前，应该先估计规模。

工作量取决于规模、复杂度、人员的经验、复用率等。

软件的规模可以是功能点，代码行，或者是故事点等。

可以采用业内的标准的度量方法，或者是本组织自定义的方法。可以是经验的方法，也可以是客观的方法。

 

 

EST 2.3基于规模估算，开发并记录解决方案的工作量、工期和成本估算以及估算的理由

 

估计了规模之后，基于规模估计工作量和成本，基于估计的工作量与任务之间的先后顺序关系，估计工期，并记录估算的理由。

从规模到工作量得到工作量的方法有多种：

经验估算，如：宽带Delphi方法、三点估算法、类比法、定额法、故事点方法等；

规模/生产率；

历史的回归方程；

不同类任务之间的比例关系；

等等。

成本的估算对于软件项目而言主要是人工成本，有的项目有采购成本、差旅等费用。

在估计工期时，可以识别出关键路径，然后采用蒙特卡洛模拟的方法模拟出工期的分布区间。

 

EST 3.1制定并保持更新文档化的估算方法

组织级要根据历史的经验教训，定义统一的估算方法，项目组基于组织级统一的方法进行估算，本基于自己项目的特点进行调整或裁剪。

 

EST 3.2在估算任务时，使用组织级的度量库和过程资产

组织级的历史类似项目的数据、组织级历史的生产率数据、各类任务的工作量分布数据、组织级建立的规模与工作量之间的回归方程等帮助新的项目进行估算。

 

九、策划（PLAN）

 

基本理念

1 凡事预则立，不预则废。无论采用什么方法管理任务、项目，都必须事先做计划。

2 计划包含了管理设计的活动，要定义项目组自己的过程。

3 计划要逐步细化，不可能在项目初期，就事无巨细的都计划到位，要随着时间的推移，项目的进展，外部环境的变化，逐步细化，调整计划。

4 计划要分层次。有阶段（里程碑）计划，有详细的日程表。

5 计划要经过了相关参与人的讨论、评审，达成一致后，做出承诺。

 

实践列表

 

通俗解释 

 

PLAN1.1制定任务列表。

任务分解，列出所有该做的事情。

 

PLAN1.2为任务分配人员。

每个任务责任到人。

 

PLAN2.1制定并保持更新完成工作的方法。

选择开发方法，包括：

选择生命周期模型，瀑布，迭代，还是增量？

选择技术实现方法，是结构化方法、还是面向对象的方法，或是模型驱动的方法？

是否需要将软件开发外包出去？

是否要采用原型方法？

是采用传统的开发模式，还是敏捷的开发方法？

等等。

这是对项目或任务如何做进行顶层的、宏观的管理设计！

 

PLAN2.2策划完成工作需要的知识和技能。

这条实践是要求项目组思考：

Ø 项目组成员有哪些应知应会？

Ø 有哪些应知不知，应会不会的？

Ø 如何获得这些不知不会的？培训、从其他项目组或部门抽调人过来、还是外部招聘？

Ø 培训计划、人员配备计划、招聘计划

 PLAN2.3基于文档化的估算，制定和保持更新预算和进度。

参考EST PA执行了估算，有估算的记录。

基于需求的优先级、任务之间的依赖关系等，对任务排列先后顺序，识别项目的关键路径。

分配资源给每项任务，识别项目的关键链。

关键路径是在资源无限的前提下，在活动图中，识别出来的完成项目的最长路径。

关键链是在分配了资源之后，由于资源有限，不能独占，而形成的完成项目的最长路径。

这2者决定了项目的最快工期。如果要想缩短工期，就必须要缩短关键链。

预算是对成本估算的审批结果，是管理者给出的成本上限，并且分配到时间上，即什么时间，投入哪些资金，投入在什么方面。

进度计划有阶段计划与详细日程之分。在敏捷方法中有发布计划与迭代计划，至少2个层次。

 

PLAN2.4策划所识别的干系人的参与。

干系人分为几类：

负责人

参与人

受影响的人

影响人

也有的公司采用RASCI的方式识别干系人：

A（A=Accountable）：牵头人，领导人，布置批准任务的人。

R（R=Responsible）：具体负责人，具体实施者，完成A布置的任务。

S（S=Support）: 参与者，支持者，配合R完成任务的人。

C（C=Consulted）：负责为各个相关的角色提供咨询服务。

I（I=Informed）：被告知者，信息的接受者，与任务的关系最为间接。

在计划中要定义清楚谁参与，什么时间参与，做什么事情。要把任务责任到人。

在敏捷方法中是自己领用任务，而不是管理者分配任务。

 

PLAN2.5策划向运维和支持的移交。

开发向运维的移交活动如：

准备系统配置手册；

准备紧急情况应对方案；

设计系统备份方法；

确定移交接口人；

密码权限移交；

基础数据移交；

对运维人员进行技术培训；

和运维人员并行支持一段时间；

运维人员确认测试报告、系统安装配置手册、应急方案等；

交接手续确认；

  ……

这些活动要有计划。

 

PLAN2.6通过协调可用的和估计的资源，确保计划可行。

资源包括人、软硬件工具、设备、开发环境、资金等。资源总是有限的，比如有些公司测试设备有限，不能给每个项目组、每个人配备足够多的样机，需要互相调配这些设施等。因此需要在估计的资源与可用的资源之间进行平衡，制定资源的使用计划，不要出现资源瓶颈而耽误项目的工期。

平衡的手段有多种：

详细排定资源使用的进度表；

减少对资源的需求；

寻求替代资源；

增加资源的供应；

资源不足时，外包任务或采购外部资源；

……

 

PLAN2.7制定工作计划，确保其元素之间的一致性，并保持更新。

工作计划包含了总体阶段计划、详细的日程计划、各个专题的计划，这些计划要彼此之间不能矛盾。比如，在开发计划中是1.1号交付第1个版本，而在测试计划中却是1月10号才开始测试，计划之间就存在不一致了。

 

PLAN2.8评审计划并从受影响的干系人处获得承诺。

任务的责任人等相关的干系人应该参与计划评审，可以评审任务识别的完备性、估算的合理性、进度的可行性、分工的合理性等，在大家达成一致的前提下，相关责任人对计划可行做出承诺。

敏捷方法有迭代策划会议，在迭代策划会议上大家一起做了估算，自己领用了任务，每个人领用的任务不超过自己的能力上限。

 

PLAN3.1使用组织级的标准过程和裁剪指南，制定、保持更新并遵从项目过程。

2级的组织不要求一定要有组织级统一的过程规范定义，3级的组织要有统一的过程规范定义了。即3级的组织做事的套路要基本一致。

本实践是基于组织级的统一的过程定义和裁剪指南，得到项目组自己的过程定义。这是在PLAN2.1的实践基础之上要求更高了，PLAN2.1是做了顶层的宏观的管理设计，这条实践是进行了下一个层次的，更细致的过程设计。

增加、删除、改变或选择方法、改变顺序、改变权限等，都是裁剪。裁剪的对象可以是过程、活动、度量元、文档、目标等。

 

PLAN3.2采用项目过程、组织过程资产和度量库开发计划并保持更新。

组织级过程资产包含了模版、方法定义、指南、检查单、典型案例、经验教训、历史项目的资料等。

组织级度量库中包含了组织级的生产率分析数据，工作量分布数据，历史项目的数据，过程性能基线，过程性能模型等，项目在做自己的计划时，可以参考之。

项目过程即在PLAN 3.1中裁剪自组织标准过程定义的项目组的过程。

PLAN3.3识别并协商关键依赖。

何谓关键依赖？

对项目的成败有重要影响的不同人之间的依赖关系。如：

关键路径上不同人承担的任务之间的依赖关系；

本项目组的成员对组织内非项目组的全职人员之间的依赖关系；

对外部采购的产品构件或服务的依赖关系。

关键依赖影响了项目的工期或质量等，典型的问题如：

关键路径上的任务延期了，造成了整个项目延期。

需要其他人配合的工作没有按时完成；

两人的工作存在技术接口，结果一方完成的工作不符合接口标准，导致链接失败；

供应商误解了需求，提供的产品不符合技术规格；

……

 PLAN3.4基于组织级的标准，策划并保持更新工作环境。

组织级要定义环境标准，参见PAD3.6，项目组根据组织级的环境标准，定义本项目的环境定义。

项目的环境包括了办公室的大小、硬件设施，开发使用的软硬件工具，网络环境等。

敏捷项目通常都配备项目组成员的作战室，足够大的看板，搭建了持续集成与交付的软硬件平台等。

 

PLAN4.1采用统计和其他量化技术，开发并保持更新项目的过程，以满足质量和过程性能目标的达成。

PLAN3.1是在PLAN2.1基础上的更高要求，而PLAN4.1则是在3.1基础上的更高要求，2.1、3.1都是经验判断、经验决策，而4.1则要求采用统计和其他量化技术进行管理设计，以确保达成项目的目标。达到4级的策划要求计划的更合理，不做无用功，较大程度的减少浪费，选择了最优的过程、子过程、方法来达成项目的目标。统计技术指采用了回归分析、方差分析、假设检验、蒙特卡洛模拟等与概率分布有关的技术，其他量化技术则是传统的分析技术，如饼图、折线图、20-80分析等。此实践要求一定采用了统计技术进行分析。

比如：

我们对项目的工期进行了蒙特卡洛模拟，判断了达成项目工期目标的概率，如果概率比较低，我们增加了资源，或者裁剪了需求，或者细分了任务，增加了任务的并行性，缩短了关键链，提高了达成工期目标的概率。

再如：

我们根据历史的过程性能基线与模型，对关键工程活动的方法做了组合，从N多组合中选择了最优的一套方法帮我们达成项目的目标。

还可以：

基于历史的过程性能模型y=f(x1,x2,…)，选择了最优的x的取值，帮我们达成

 

十、监督与控制（MC）

 

监督与控制PA，简写为MC（Monitor and Control），是对照计划监督与管理计划的执行情况。 

实践列表 

MC	1.1	Record task completions.	记录任务完成情况
MC	1.2	Identify and resolve issues.	识别并解决问题
MC	2.1	Track actual results against estimates for size, effort, schedule, resources, knowledge and skills, and budget.	对照规模、工作量、进度、资源、知识技能和预算的估计结果跟踪实际结果
MC	2.2	Track the involvement of identified stakeholders and commitments.	跟踪已识别的干系人的参与和承诺
MC	2.3	Monitor the transition to operations and support.	监督向运维和支持的移交
MC	2.4	Take corrective actions when actual results differ significantly from planned results and manage to closure.	当实际结果与计划的结果有显著偏离时，采取纠正措施并管理至关闭
MC	3.1	Manage the project using the project plan and the project process.	使用项目计划和项目过程管理项目
MC	3.2	Manage critical dependencies and activities.	管理关键依赖和活动
MC	3.3	Monitor the work environment to identify issues.	监督工作环境以识别问题
MC	3.4	Manage and resolve issues with affected stakeholders.	和受影响的干系人一起管理和解决问题

通俗解释

 

MC 1.1记录任务完成情况。

任务是否完成了？

任务完成百分比是多少？

是否延期了？

 

MC 1.2识别并解决问题。

跟踪关闭问题。

 

MC 2.1对照规模、工作量、进度、资源、知识技能和预算的估计结果跟踪实际结果。

估算了什么，计划了什么，就跟踪什么。

定量估算的，就定量对比跟踪。没有定量计划的，就跟踪状态。

 

MC 2.2跟踪已识别的干系人的参与和承诺。

跟踪参与情况：干系人是否做了某项任务？是否投入了足够的时间？

承诺：完成的结果是否满足了要求？包括技术与管理的要求，比如接口需求，工期要求等。

 

MC 2.3监督向运维和支持的移交

完成的解决方案要移交给运维或售后服务人员，进入生命周期的维护阶段，移交给运维的活动需要做计划(参见PLAN2.5) ，需要监督执行情况。

 

MC 2.4当实际结果与计划的结果有显著偏离时，采取纠正措施并管理至关闭。

何谓显著偏离？在项目策划时需要定义出来(参见PLAN 2.3)，可以是工期、工作量、成本、质量、需求变更等方面的阈值定义。

纠正措施可以是：

修改承诺；

调整计划；

裁剪需求；

加大投入；

采用新的工作方法等等。

 

MC 3.1使用项目计划和项目过程管理项目。

项目计划就是用来作为参照物管理项目的，否则做计划的意义何在？

此处的项目是指综合的项目计划，包含了各个领域的，各个层次的计划。

项目过程即参考组织级的流程裁剪后得到的本项目的流程。

 

MC 3.2管理关键依赖和活动。

参见PLAN3.3。

 

MC 3.3监督工作环境以识别问题。

组织级定义了环境标准，项目组裁剪得到自己项目组的环境定义，要求项目组每个岗位都要按照统一的工作环境进行配置。

 

MC 3.4和受影响的干系人一起管理和解决问题。

前面的那些实践是发现问题，这条实践是解决问题，关闭问题。

 

业内案例

 

跟踪手段不同，时机不同，关注的侧重点也不同，每个公司可以整理自己的跟踪策略，如：

 

十一、风险与机会管理（RSK）

 

风险与机会管理，简写为RSK，在以往的CMMI版本中都是描述为风险管理，在2.0中增加了机会管理。风险是意料之外的坏事，机会是意料之外的好事，风险是惊吓，机会是惊喜。我们要抓住机会，规避风险，趋利避害。风险与机会都不是一定发生的，发生的概率都是大于0小于1的。

 

基本理念

1 风险与机会是事先的，不是事后的，事后的是事件管理，问题管理。

2 要尽早报告风险，处理风险。

3 风险与机会在项目或任务执行过程中是持续的，不是一次性的，是贯穿始终的。

4 对风险与机会的管理，要平衡成本与收益，不是所有的风险或机会都事先采取措施。

 

 实践列表

 

RSK	1.1	Identify and record risks or opportunities and keep them updated.	识别、记录风险或机会，并保持更新
RSK	2.1	Analyze identified risks or opportunities.	分析所识别的风险或机会
RSK	2.2	Monitor identified risks or opportunities and communicate status to affected stakeholders.	监督识别的风险或机会并和受影响的干系人沟通状态
RSK	3.1	Identify and use risk or opportunity categories.	识别并使用风险或机会分类
RSK	3.2	Define and use parameters for risk or opportunity analysis and handling.	为风险或机会的分析和解决，定义和使用参数
RSK	3.3	Develop and keep updated a risk management strategy.	制定和保持更新风险或机会管理策略
RSK	3.4	Develop and keep updated a risk or opportunity management strategy.	制定和保持更新风险或机会管理计划
RSK	3.5	Manage risks or opportunities by implementing planned risk or opportunity management activities.	通过实施已计划的风险或机会来管理风险或机会

  

通俗解释

 

RSK1.1识别、记录风险或机会，并保持更新

1级的实践只是要求了识别、记录风险与机会，是否对风险采取应对措施没有做要求。

 

RSK2.1分析所识别的风险或机会

这条实践两层含义：首先要是识别风险或机会，其次要分析风险或机会。

如何识别风险或机会呢？有多种方法，如：

分类法：把风险与机会进行分类，针对每一类风险或机会，思考在本项目或任务中是否存在；

头脑风暴法：群策群力，大家一起开会讨论存在哪些风险或机会；

调查问卷法：制定调查问卷，分发给团队的人员，让大家思考是否存在某些风险或机会；

检查单法：列出历史上各种类型的风险或机会，让相关人员考虑是否在本项目或本任务中是否存在这些风险或机会；

WBS驱动法：针对任务列表中的每项任务，思考是否存在风险；

……

对识别出的风险或机会进行描述时，要描述清楚前因后果与环境，便于理解风险或机会，制定应对措施。

对风险或机会进行分析时，往往要从三个维度进行分析：

影响的严重性、发生的可能性、发生时间的远近紧迫性。

风险分析的结果是对风险或机会划分了优先级，优先级高的要制定应对措施。

 

RSK2.2监督识别的风险或机会并和受影响的干系人沟通状态

这条实践也是有两层含义：

一是监督风险或机会状态的变化，此时也可能识别出新的风险或机会；

二是要和相关人员沟通状态的变化。

上述的两个活动通常都是周期性的，比如按周或月等。

 

RSK3.1识别并使用风险或机会分类

两层含义：

一是对风险或机会进行分类，分类的目的是为了把相近的风险合并应对措施，以节约成本，因此通常是按照风险或机会的来源进行分类。

二是要按照统一的分类定义对识别风险进行类别划分。

 

RSK3.2为风险或机会的分析和解决，定义和使用参数

本实践也包含了两层含义：

一是对风险或机会分析的三个参数进行统一的定义：

影响的严重性：何谓高、中、低？或者是不同等级的分值，怎么划分这些分值？

发生的可能性：概率到底有多大，划分成几个等级？

时间的紧迫性：远，中，近期，如何划分？

二是在实践中要使用这些参与的定义，按定义执行。

 

RSK3.3制定和保持更新风险或机会管理策略

风险与机会的管理策略包含了：

风险与机会管理的责任分配；

风险与机会管理的时机；

风险与机会管理的方法；

三个参数的统一定义；

划分优先级的方法；

应对措施的启动条件；

常见风险或机会的应对措施；

风险或机会的跟踪频率；

采集哪些与风险与机会有关的度量数据等等。

 

RSK3.4制定和保持更新风险或机会管理计划

风险的管理计划包括：

缓解措施：用来降低风险发生的概率或延迟风险发生时间的措施；

应急措施：当风险即将发生或已经发生后，用来降低风险危害的措施；

以及上述措施的责任人，触发时机等。

机会的管理计划其实也包括两种措施：

创造机会的计划：没有机会创造机会，增加其发生概率。

应对计划：即一旦来了机会，如何充分使其利益最大化，做哪些事情？

 

RSK3.5通过实施已计划的风险或机会来管理风险或机会

在对风险或机会的管理计划中定义相关措施，本实践就是对照计划落实那些措施。

 

十二、组织级培训（OT）

 

人、技术、过程三者并重。技术靠人来使用，过程靠人来执行，人是地基，是基础。同样的技术、同样的过程由不同人去落地，效果差别很大，因此要重视对人的能力的培养。 

 

实践列表

 

通俗解释

 

OT1.1培训人员

在组织内要对人员进行培训。

 

OT2.1识别培训需要

培训需要有多种搜集途径：

自顶向下：

公司战略分析；

能力地图；

胜任力分析；

……

由底向上：

问卷调查；

人员访谈；

……

搜集上来的需求要划分优先级。

 

OT2.2培训人员并保存记录

培训的目的有三种：

改变思想；

增长知识；

提升技能；

不同目的培训手段不同。

在培训之前要做好准备工作，对照检查单进行细致的检查是很多培训专员常用的方法。

哪些人参与了培训要保存好记录。

 

OT3.1制定并保持更新组织级的战略和短期培训需要

战略培训需求是侧重于长远的组织级能力的培养。每个组织有自己的3-5年的发展规划，根据发展规划，可以识别出来需要什么样的人才，这些人才可以从外部引进，可以自己培养。

短期培训需求是侧重于当前的具体业务问题如何解决。

长远与当前要进行平衡，要划分优先级。

 

OT3.2在项目和组织之间，协同培训需要和交付物

有些培训是整个组织统一组织安排的，有些培训是在某个部门内部组织安排的，有些培训是项目组自己安排的。在采集了培训需求之后，可以根据培训的主题、重要性、紧迫性等，     在组织的不同范围内决策如何分配这些培训的职责。

 

OT3.3制定，保持更新并遵从组织级战略和短期培训计划

战略培训计划是长期的，着眼于未来的培训计划。比如2年的甚至更长远的培训计划。有公司建立了后备人才的培养计划，这就是战略培训计划。

短期培训计划可以是本年内的，季度的，月度的培训计划等。

培训计划中要包含培训的主题、时长、预算、责任人、培训方式等。

培训方式有很多种：

课堂培训；

脱产培训；

师徒制；

特别兴趣小组；

网络在线培训；

……

 

OT3.4制定，保持更新并使用培训能力以处理组织级培训需要

培训能力建设包括：

培训讲师的筛选与评价；

培训课程的设计要求；

培训方法的选择；

培训课程的设计评审；

试讲；

培训的支持工具、平台、设备、环境等；

对培训的讲师及组织者进行培训；

……

 

OT3.5评价组织级培训计划的有效性

培训效果评价的方法有多种：

随堂考试；

培训满意度调查；

培训效果访谈；

……

培训效果的评价有短期评价和长期评价。长期评价主要侧重对实际工作业绩的影响。如：

对年度、季度等培训计划执行情况的有效性进行评价，做过的这些培训是否对实际的工作业绩、工作方法、工作习惯有影响？

是否还需要继续做这些培训？

有哪些改进之处？

 

OT3.6记录、保持更新并使用组织级培训记录集

·要为每位员工建立培训档案，便于查阅每位员工的能力提升情况。

 

十三、配置管理（CM）

 

和CMMI V1.3相比，CMMI V2.0中配置管理的实践基本没有变化。CMMI DEV 2.0 的20个PA中，CM是唯一一个没有3级实践的PA。

 

基本概念

 

这个PA涉及到的基本概念比较多，我们挑选部分基本概念，做通俗解释：

配置管理：通过配置标识、版本控制、版本管理、基线管理和配置审计来管理工作产品的完整性。

配置项：配置管理的对象，包括各种文档资料，代码等工作产品。包括：给客户的交付物、公司内部指定的输出、采购来的各种产品、构件以及开发需要的各种工具环境等。

基线：经过正式认可的、作为后续开发基础的一组配置项，其变更需要经过正式的批准。

配置控制委员会：对配置项的变更进行评审认可的一个小组。

配置审计：检查基线中的配置项版本是否正确一致、位置是否正确、是否与其功能说明一致。

 

 实践列表

 

CM	1.1	Perform version control.	执行版本控制
CM	2.1	Identify items to be placed under configuration management.	识别置于配置管理之下的配置项
CM	2.2	Develop, keep updated, and use a configuration and change management system.	建立、保持更新并使用配置和变更管理系统
CM	2.3	Develop or release baselines for internal use or for delivery to the customer.	建立或发布内部使用或交付给客户的基线
CM	2.4	Manage changes to the items under configuration management.	管理配置项的变更
CM	2.5	Develop, keep updated, and use records describing items under configuration management.	建立、保持更新并使用描述了配置项的记录
CM	2.6	Perform configuration audits to maintain the integrity of configuration baselines, changes, and content of the configuration management system.	执行配置审计以维持配置基线、变更和配置管理系统内容的完整性

 

通俗解释

 

CM 2.1 识别置于配置管理之下的配置项。

配置项的包含了交付给客户的、不交付给客户的文档、代码等。不交付给客户的文档是开发公司所需要的资料。这些配置项可能是自己开发的，也可能是采购来的。实践中往往忽略的是生成源代码的编译环境、构件库、类库等也是配置项。有的对日外包公司专门承接这种将几十年前的源代码进行重新编译链接的项目，因为历史的旧的编译环境，函数库没有保存，或者已经升级了。

 

CM 2.2 建立、保持更新并使用配置和变更管理系统。

这里所说的配置和变更管理系统包含了工具、规程、物理的存储介质、实际的配置项等。

可以是纯手工的管理配置项，并非一定采用工具。但是现在几乎不存在不使用工具管理配置项的组织了。

常用的工具有：SVN，Git, CC, CQ, Jira, confluence, Seafile等。

在配置管理系统中要定义清楚：

控制级别

目录结构

权限分配

备份机制

 

CM 2.3 建立或发布内部使用或交付给客户的基线。

交付给客户基线如产品基线，内部使用的基线如设计基线。

基线的命名可以有意义，比如需求基线，设计基线，产品基线等，也可以直接序号，比如基线1.0，基线2.0等。

后建立的基线，逻辑上包含了先建立的基线的内容。

 

CM 2.4 管理配置项的变更

变更可以分级，有需要经过CCB批准的变更，有需要经过PM的变更等。

发生配置项的变更时，要识别变更影响的范围，包括对技术、对管理、对人员的影响。对技术的影响包括对需求、设计、代码、测试用例的影响，对管理的影响包括对工作量、工期、质量、风险的影响，对人员的影响包括了对项目组各个角色的影响，需要哪些角色参与进来，变更要及时通知到相关人员。

变更影响分析可能会使用到需求跟踪矩阵辅助完备地识别变更的影响分为。

实施变更的步骤通常包括：

提出变更申请；

变更评审与审批；

变更执行；

变更结果确认；

更新配置库；

通知相关人员。

 

CM 2.5 建立、保持更新并使用描述了配置项的记录

配置项变更记录包含了：

什么时间；

变更提出者；

变更实施者；

变更了什么；

为什么变更；

验证人；

验证结论；

入库时间；

……

每次向配置库中提交配置项时应该详细记录上述信息，这样可以通过配置管理工具生成配置项状态报告。

 

CM2.6 执行配置审计以维持配置基线、变更和配置管理系统内容的完整性

所谓的完整性是指：配置库中的配置项不多、不少、版本一致、命名规范、位置正确、内容符合要求、记录完备。根据检查重点的不同，执行检查的人可以是质量保证人员，配置管理人员或者是其他专家

 

十四、原因分析与解决方案（CAR）

 

原因分析与解决方案（CAR）是对选中的现象识别原因，并采取纠正措施或预防措施。

 

基本的思想

组织内的好事和坏事都可以做CAR，并非仅仅是对坏事做CAR。可以在计划阶段做CAR，也可以在事情发生后再做CAR， 前者是根据估计的结果做CAR，后者是根据实际执行的结果做CAR。

在做原因分析时，是从现象，到数据，然后再到原因。数据准确刻画了现象，并有助于识别真正的原因。

原因有浅层次的直接原因，也有深层次的根本原因，对直接原因采取纠正措施，对根本原因采取预防措施。

 

实践列表

 

CAR	1.1	Identify and address causes of selected outcomes.	识别并处理选中现象的原因
CAR	2.1	Select outcomes for analysis.	选择要分析的现象
CAR	2.2	Analyze and address causes of outcomes.	分析并处理现象的原因
CAR	3.1	Determine root causes of selected outcomes by following an organizational process.	遵从组织级的流程确定选中现象的根因
CAR	3.2	Propose actions to address identified root causes.	提出行动建议以处理识别的根因
CAR	3.3	Implement selected action proposals.	实施选中的行动建议
CAR	3.4	Record root cause analysis and resolution data.	记录根因分析和解决方案的数据
CAR	3.5	Submit improvement proposals for changes proven to be effective.	为已经证明有效的变更提交改进建议
CAR	4.1	Perform root cause analysis of selected outcomes using statistical and other quantitative techniques.	采用统计和其他量化技术对选中的现象执行根因分析
CAR	4.2	Evaluate the effect of implemented actions on process performance using statistical and other quantitative techniques.	采用统计和其他量化技术评价已实施行动的对过程性能的变化效果
CAR	5.1	Use statistical and other quantitative techniques to evaluate other solutions and processes to determine if the resolution should be applied.	使用统计和其他量化技术评价其他解决方案或过程以确定是否应用某解决方案

 

实践通俗解释

 

CAR 2.1 选择要进行原因分析的现象

并非所有的事情都要做正式的原因分析，原因分析也是有成本的，要挑选值得分析的现象做原因分析。比如：

预计项目的目标达成概率比较低；

有些错误重复发生；

交给给客户以后发生了严重缺陷；

发生了客户投诉；

某大型项目顺利结题；

等等。

 

案例：进行根因分析的常见事件

 

需要进行根因分析的事件
	事先预测（to do )	执行中(doing)	事后总结(done)
坏事	Cpk小于1，能力不足 蒙特卡洛模拟预测项目目标无法达成，或者回归方程预测项目目标无法达成时 寻找提升组织级过程性能时 组织级过程能力不足时	项目进度延期超过了上限 代码走查问题过多，超过基线上限 需求变更率异常超过了组织级上限 测试缺陷一直不收敛或收敛周期过长 项目目标未达成 共性缺陷太多	发生了质量事故 频繁再现的缺陷 漏测的缺陷 共性不符合项、软件缺陷 组织级的目标无法达成时
好事		代码走查零缺陷的模块 过程能力优于目标或好于目标基线 测试零缺陷的模块、子系统或项目	零缺陷的项目 按时交付的项目 客户满意度比较高，客户提出表扬的项目

 

CAR 2.2 分析并采取措施

分析原因的方法有多种：鱼骨图、5-whys法、头脑风暴等等。

措施与纠正措施与预防措施之分。

 

CAR 3.1 采用组织级的流程识别根本原因

何为根本原因？两种判定方法：

方法一，比较简单直观，MIN process法：

Missing process:没有定义流程；

Incomplete process: 流程定义不完整；

Not followed: 定义了流程，没有按流程执行。

方法二，从预防问题的角度思考：

当解决了这个原因，是否这个问题还会发生？

    当解决了这个问题，是否类似的问题还会发生？

组织级要定义了根因分析的相关流程。

 

CAR 3.2 针对根本原因提出预防措施。

 

CAR 3.3 实施预防措施。

 

CAR 3.4 记录过程的中的相关数据。

 

CAR 3.5 验证了预防措施成功后，修改组织级体系流程或推广到其他项目组。

 

CAR 4.1 进行根因分析时，要采用统计技术，如：相关性分析，回归分析，假设检验，方差分析等。 

 

CAR 4.2 采用统计技术分析预防措施的效果。 

有效的预防措施会改变：

过程性能基线：分布的位置移动（均值，中位数等）或分布的离散程度（方差，标准差，四分位差等）变小。

过程性能模型：对于线性回归方程而言，斜率改变或截距改变。

 

CAR 5.1 采用统计技术分析其他的解决方法、其他过程是否可以将预防措施推而广之。

除了采取的解决方案，是否还有更优的方案能比当前的方案效果更好？

除了改进的这个流程，是否还有其他流程也可以进行类似的改进？

可借鉴的具体做法：

可以参考福特公司的8D方法进行根因分析：

 

注：上述两张图片来自网络

十五、类比透解决策分析与解决方案（DAR）

 

DAR：决策分析与解决方案

 

决策就是多选一：

买不买房子？yes or no？这是做决策。

买哪个楼盘的哪个户型？这也是做决策。

决策可以是技术决策，也可以是管理决策：

技术决策：采用哪种技术路线？哪种中间件？

管理决策：采用哪种生命周期模型？要不要做灰度发布？

决策有大事有小事：

小事：早餐吃什么？

大事：买哪套房子？

小事可以快速决策，非正式决策，充分放权决策。大事需要慎重决策，科学决策，多人参与的决策。

所以：

并非所有的决策都需要走正式的流程，DAR 2.1！

决策流程可以划分为不同的正式级别，DAR 3.1！

小事走正式的决策流程是浪费，是官僚主义，是形式主义。

大事不走正式的流程、随意决策是灾难，是不负责任，早晚要后悔。

 

本PA的实践列表

 

 

2级的实践中包含了1级的实践，所以不详细描述1.1与1.2的实践。

 

买房子是大事，要做正式决策，早饭吃什么是小事，不需要做正式决策，这是DAR 2.1 要定义的决策事项的筛选规则。

买房子时要考察地址位置，面积，价格，环境，户型，物业品牌等，这是评价指标，DAR 2.2。

要从2套，3套还是5套房子中选中一套？这是识别候选方案， DAR 2.3。

买房子是你一人独裁，还是全家人投票？还是多套房子，针对每个评价指标进行打分，最后汇总，选择总分最高者？是否要现场考察？夜间考察？这是评价方法，DAR 2.4。

根据选定的评价指标，评价方法，对多套房子进行比较评价，最终选择出一套中意的房子，这是DAR 2.5。

 

买房子、孩子上哪所大学、孩子学什么专业 这是需要全家人一起决策的。

买什么车，可能是家里的男主人决策即可。

因此：

1）决策要分级（分类）

2）不同级别（类别）的决策参与角色人不同、决策人不同

3）不同级别（类别）的决策流程不同

这是DAR 3.1。

 

十六、白话治理（GOV）

 

GOV与II是CMMI V2.0中新增的两个PA，实施CMMI V2.0的组织需要准确理解这2个PA的含义，然后才能知道如何映射到自己的实践。我对GOV的理解整理如下，供大家在实践中参考。

首先我们强调的一下这个PA中隐藏的基本观点：

1 过程管理是一把手工程，高层管理者一定要参与。

2 过程管理包含的活动：

 

图1 过程管理活动

 

高层管理者的职责就是围绕上述5个活动的。

注意不要忽略度量过程！

3 过程实现了目标，过程管理要聚焦于组织的目标。

组织级的过程要有效地实现了组织级的目标。

4.过程是人执行的，要培养人的能力，对人员做奖惩。

其次，我们列出来这个PA的所有实践，以了解一下该PA的核心内容。

第三，我们通俗的解释一下这些实践。

 

GOV是CMMI DEV 2.0模型的20个PA中唯一一个每条实践都定义了主语的PA，主语就是：高层管理者。这里的高层管理者是谁呢？PM的上司，掌握了资源的管理者，比如公司的CxO们，总监们，事业部总经理们，部门经理们等。

本PA定义了他们与过程管理有关的事情，没有定义技术的、市场的活动，比如：如何提升公司的技术水平，如何提高公司的销售额等这些职责不在本PA的范围内。

高层管理者们应该做什么呢？

 

GOV 1.1 定方向和方法论

我们往往忽略了每个PA的1级实践，但是这条实践，恰恰需要我们仔细读读。

这条实践需要高层管理做了两件事：

1 定方针：高层管理者定义了组织级的方针（directives)，包括：政策（policy)，策略，使命，愿景，价值观，目标等。

2 定方法（论）：实现组织级方向的方法是什么。

读到这条实践，我就想起来北京我们有一个客户，他们的老板曾经有一个名言：我定战略，你们（部门经理）找实现战略的方法论！

 

GOV2.1 定方针

基于组织级的需求确定过程实施的基本要求，即所谓的directives，注意这些方针是和过程有关的，即过程管理的：政策、策略、使命、愿景、价值观、目标、方法论等。

 

GOV2.2 给资源

为图1的5类活动提供资源：人、财、物。包括：人员、资金、软件或硬件工具、设备、环境、消耗品、以及高层管理者投入的过程管理的时间！清注意：时间是最重要的资源。

资源需求和实际可用的资源是有差距的，是需要平衡的，所以此实践是需要做能力平衡的。

 

GOV2.3 客观治理、监督过程 

高层管理者要识别自己的信息需要，通过客观的数据来治理、监督过程的执行情况。

管理者的信息需要可以通过定量的，也可以是定性的信息来满足。但是，一定要有定量的信息。

 

GOV2.4 确保通过方针、过程的实施实现目标

发现过程实施问题，解决问题，制定奖惩措施！

 

GOV 3.1 用数据说话

组织级的数据采集，分析，使用！建立组织的度量库。

采集多个项目组的数据、进行横向对比分析，得到结论，采取措施。

 

GOV3.2 能力建设

两个含义：

过程能否满足目标，如果不行，优化过程。

人员的能力能否满足目标，如果不行，做培训或其它提升能力的活动。

 

GOV4.1统计管理

高层管理者也要学习统计技术和量化技术，要用统计技术辅助决策，科学决策。

 

十七、实施基础设施（II）点睛

 

II(implementation infrastructure)可以翻译为：实施基础设施。基础设施包括了资源、资金、培训、流程定义、经验教训总结等方面的实践，总之，就是要建立进行持续过程改进的能力。

 

实践列表

1.1	Perform processes that address the intent of the Level 1 practices.	执行了满足1级实践意图的过程
2.1	Provide sufficient resources, funding, and training for developing processes.	为制定过程提供充足的资源、资金和培训
2.2	Develop and keep processes updated, and verify they are being followed.	定义、保持更新过程，并验证过程是否被遵从了
3.1	Use organizational processes and process assets to plan, manage, and perform the work.	使用组织级的过程和过程资产策划、管理以及执行任务
3.2	Evaluate the adherence to and effectiveness of the organizational processes.	评价对组织级过程的符合性和组织级过程的有效性
3.3	Contribute process related information or process assets to the organization.	向组织级提交过程相关的信息或过程资产

II的实践中也隐含了PDCA循环的思想：

计划：plan

执行：do

检查: check

调整: adjust (act)

 

通俗地讲，II中包含了：

要有执行过程的人、财、物的支持；

要有过程定义；

要使用过程资产执行过程；

要检查过程是否执行了；

要评价过程是否真的有用；

要积累过程有关的经验教训，持续优化过程；

上述的实践与通俗含义的映射是显然的，不赘述。

II和GOV是对其他每个流程都起到管理、支持作用的，所以可以把这2个PA的实践解释到每个过程上。

 

十八、过程资产开发（PAD）

 

PAD, process assesses development 过程资产开发，也可以翻译为过程财富开发。过程资产指什么？与过程有关的组织级方针、过程描述、裁剪指南、检查单、模版、规程定义、培训材料以及项目组裁剪后的过程定义、经验教训、典型案例、计划等资料都是过程资产。要注意：组织级的过程资产库中包含了组织的过程定义。过程定义在哪里要求的？在II的SP2.2和PAD3.3！

 

实践列表

 

PAD	1.1	Develop process assets to perform the work.	开发过程资产以执行工作
PAD	2.1	Determine what process assets will be needed to perform the work.	确定哪些过程资产是完成工作所必须的
PAD	2.2	Develop, buy, or reuse process and assets.	开发、购买、复用过程资产
PAD	2.3	Make process assets available.	确保过程资产可获得
PAD	3.1	Develop, keep updated, and follow a strategy for building and updating process assets.	制定、保持更新和遵从创建和更新过程资产的策略
PAD	3.2	Develop, record, and keep updated a process architecture that describes the structure of the organization’s processes and process assets.	建立、记录和保持更新描述了组织过程结构和过程资产结构的过程架构
PAD	3.3	Develop, keep updated, and make processes and assets available for use.	制定、保持更新并确保过程和资产可用
PAD	3.4	Develop, keep updated, and use tailoring criteria and guidelines for the set of standard processes and assets.	制定、保持更新并使用标准过程集的裁剪准则和指南
PAD	3.5	Develop, keep updated, and make the organization’s process asset library available for use.	建立、保持更新并确保组织过程资产库可用
PAD	3.6	Develop, keep updated, and make work environment standards available for use.	制定、保持更新并确保工作环境标准可用
PAD	3.7	Develop, keep updated, and make organizational measurement and analysis standards available for use.	制定、保持更新并确保组织度量和分析标准可用

 

通俗解释

 

PAD1.1开发过程资产以执行工作

在开始工作之前，定义好模版、检查单或过程。

 

PAD2.1确定哪些过程资产是完成工作所必须的

可能的过程资产包括模版、检查单、过程资产、工具等。

 

PAD2.2开发、购买、复用过程资产

 

PAD2.3确保过程资产可获得

让大家知道过程资产在哪？设置好权限并确保大家可以使用这些资产。

 

PAD3.1制定、保持更新和遵从创建和更新过程资产的策略

创建和更新过程资产的策略包括：

过程资产的范围：哪些模版？哪些检查单？使用哪些工具等等；

过程资产的责任人；

过程资产的宏观管理思想，如：

先模版再过程，还是先过程定义再模版定义？

通过工具固化过程；

模版尽可能简单还是尽可能完备？

……

过程资产的更新流程与审批权力；

……

 

PAD3.2建立、记录和保持更新描述了组织过程结构和过程资产结构的过程架构

过程架构可以从两个维度来刻画：

1 过程，子过程，过程元素，这3者之间的关系。比如评审过程划分为评审准备、评审执行、评审总结三个子过程，在评审准备子过程中又包含了：计划制定、会议室准备、专家准备、评审材料准备、会议通知四个过程元素，这些子过程、过程元素是如何协同构成一个评审过程的？不同过程或子过程之间也可能具有相同的过程元素。通常在实践中是通过流程图来描述他们之间的关系。

 

2 过程描述的基本属性，常见的描述方法有：

i) ETVX模式：

输入、进入准则、任务、输出、退出准则以及检验活动。

ii) 12元素法：

除了ETVX中6个元素以外，还包括：目的，参与角色，度量元，裁剪准则，遵循的标准，衔接的流程。

iii) 最简五要素法：

要解决的问题是什么？

最基本的成功原则是什么？

最简单的活动是什么？

可见的结果或输出有哪些？

补救的措施有哪些？

 

PAD3.3制定、保持更新并确保过程和资产可用

建立过程和过程资产时可以参考各种标准、模型和规范，比如ISO的标准，各种敏捷框架，APH，IPD，CMMI等等。组织建立的是自己的过程，执行的也是自己的过程，自己的一套过程可以符合、服从各种标准、模型和规范。

过程和过程资产的维护可以责任到人，并定义变更的流程。

 

PAD3.4制定、保持更新并使用标准过程集的裁剪准则和指南

裁剪指南比过程定义本身更重要，如果没有裁剪指南，指望一套过程适合所有的项目，所有的场景是不现实的，因此必须定义裁剪指南，在标准化与灵活性之间进行平衡，从而确保体系的实用性。

 

PAD3.5建立、保持更新并确保组织过程资产库可用

此条实践和PAD3.3可以联系起来理解。本实践要求把过程资产分类管理，纳入配置管理，建立过程资产库。在实践中可以使用一些工具来管理过程资产库，如Sharepoint，Eclipse Process Framework, Confluence等。从而便于使用者进行检索和使用。

 

PAD3.6制定、保持更新并确保工作环境标准可用

组织级的工作环境标准包括了：软件工具、硬件设备、网络环境、组织级的安全保密措施与规定等。

 

PAD3.7制定、保持更新并确保组织度量和分析标准可用

该实践是让我们思考并定义：

组织级要求统一采集哪些度量元？

这些度量元的准确含义是什么？

这些数据如何采集？

这些数据采集上来之后，如何分析？

项目组如何裁剪组织级的度量定义？

 

十九、过程管理（PCM）

 

Process management，过程管理，简写为PCM。这个PA是对过程进行持续改进的。

学习这个PA就必须深刻理解PDCA循环的4个阶段，8个活动。PCM的实践可以映射到这8个活动上。 

 

实践列表

PCM	1.1	Develop a support structure to provide process guidance, identify and fix process problems, and continuously improve processes.	建立支撑体系以提供过程指南、识别并修复过程问题、持续改进过程
PCM	1.2	Appraise the current process implementation and identify strengths and weaknesses.	评价当前的过程实施并识别强项和弱项
PCM	1.3	Address improvement opportunities or process issues.	处理改进机会或过程问题
PCM	2.1	Identify improvements to the processes and process assets.	识别对过程和过程资产的改进点
PCM	2.2	Develop, keep updated, and follow plans for implementing selected process improvements	为实施选中的过程改进，制定、保持更新和遵从计划
PCM	3.1	Develop, keep updated, and use process improvement objectives traceable to the business objectives.	建立、保持更新和使用可回溯到商业目标的改进目标
PCM	3.2	Identify processes that are the largest contributors to meeting business objectives.	识别对满足商业目标最大贡献的过程
PCM	3.3	Explore and evaluate potential new processes, techniques, methods, and tools to identify improvement opportunities.	探索和评价潜在的新过程、技术、方法和工具以识别改进机会
PCM	3.4	Provide support for implementing, deploying, and sustaining process improvements.	为实施、部署和维持过程改进提供支持
PCM	3.5	Deploy organizational standard processes and process assets.	部署组织标准过程和过程资产
PCM	3.6	Evaluate effectiveness of deployed improvements in achieving process improvement objectives.	评价已部署的改进措施在达成过程改进目标方面的有效性
PCM	4.1	Use statistical and other quantitative techniques to validate selected performance improvements against proposed improvement expectations, business objectives, or quality and process performance objectives.	对照建议的改进期望、商业目标、或质量和过程性能目标，采用统计和其他量化技术，确认选中的性能改进

   通俗解释

 

PCM1.1建立支撑体系以提供过程指南、识别并修复过程问题、持续改进过程

在CMMI V2.0的官方翻译中将support structure翻译为了支持团队，我这里翻译为了支撑体系。在支撑体系中包含了：

人：即从事过程改进的人员，包括了管理指导组、过程改进组、过程行动组，过程责任人，过程的执行人等等；

财：为过程改进提供的资金支持，用以购买工具、设备、培训等；

物：过程改进所需要的工具、设备等。

 

PCM1.2评价当前的过程实施并识别强项和弱项

评价当前的过程时，可以参照各种标准，未必一定是CMMI模型。

评价的目的是判断当前执行的过程是否能满足组织的商业目标，判断是否有更好的做法满足目标？有的企业每年都做内审，如果内审时仅仅检查各各岗位、各项目组、各部门是否按照组织级的流程执行了，则只是做了本实践的一半要求。

 

PCM1.3处理改进机会或过程问题

有过则改，择善从之。

 

PCM2.1识别对过程和过程资产的改进点

识别改进点的方法有很多种：

识别出的改进点有很多，这些改进点也要划分优先级。

 

PCM2.2为实施选中的过程改进，制定、保持更新和遵从计划

实施过程改进也要有计划。对体系流程的修改、新工具方法的引入等要责任到人，需要试点时要制定试点计划。

 

PCM3.1建立、保持更新和使用可回溯到商业目标的改进目标

所有的改进都要围绕着商业目标进行，这样才不会浪费，不会做无用功。

过程改进的目标尽量定量化。

 

PCM3.2识别对满足商业目标最大贡献的过程

过程实现了目标，过程确保成功可重复，过程也要区分关键的少数，也服从80-20原则，要识别对目标贡献最大的过程进行事半功倍的管理，少做无用功。

 

PCM3.3探索和评价潜在的新过程、技术、方法和工具以识别改进机会

人，技术，过程并重，找短板进行改进。要不断引入新的技术、方法、工具与过程。

 

PCM3.4为实施、部署和维持过程改进提供支持

需要购买工具的就购买工具，需要培训的就培训，需要高层投入时间参与的就利用高层的时间，需要宣传的就宣传。

 

PCM3.5部署组织标准过程和过程资产

采用各种手段推广组织级的标准过程或过程资产。

推广时可能分批推广，未必是一次性的。

 

PCM3.6评价已部署的改进措施在达成过程改进目标方面的有效性

PCM3.1定义了过程改进的目标，PCM3.6是用实际结果与目标进行对比分析。

 

PCM4.1对照建议的改进期望、商业目标、或质量和过程性能目标，采用统计和其他量化技术，确认选中的性能改进

采用统计和其他量化计划判定过程性能的改变，可以从两个方面来判定：

1 过程性能基线的变化：

性能数据分布位置的变化，如均值；

性能数据离散程度的变化，如标准差；

二者数据分布位置、离散程度二者同时变化；

2 过程性能模型的变化：

对于线性回归方程而言，可能是斜率的变化、截距的变化、或者二者同时变化。

 

二十、管理性能和度量数据（MPM）

 

MPM（managing performance and measurement）是CMMI DEV V2.0中实践最多的一个实践域。它将组织级的、项目级的度量实践，以及统计的和非统计的量化管理都融合到了一个PA中。它合并了CMMI V1.3版本中的MA， QPM等过程域的实践。

本实践域在落地时，需要使用到一些具体的量化技术，如：

基本的量化分析方法：

饼图；

柱状图；

横条图；

折线图；

雷达图；

……

统计技术：

回归分析；

方差分析；

假设检验；

箱线图；

蒙特卡洛模拟；

统计过程控制；

可靠性增长模型；

……

因此需要组织内进行这些量化管理技术的专题培训。

 

基本思想

 

所有的度量活动都是要紧紧围绕商业目标，所有的度量活动都要有价值。尽管任何活动都可以度量，但是我们不能有什么就度量什么，要有度量目标，度量要能帮助解决管理问题。

在软件组织中，有太多误用度量的案例了，比如：

有数据没分析；

有分析没结论；

有结论没行动；

仅仅为考核度量数据等等。

这些都导致度量活动不能在组织中真正发挥价值。

在此PA的意图中就特别强调了为商业目标而度量，在价值描述中强调了度量是帮我们提高投资回报率。CMMI高成熟度级别的组织就应该是通过量化管理减少无用功，不浪费，做最正确的事情，用经济的活动来提高效率和质量。

 

基本概念

 

对三个与过程性能有关的核心概念：

过程性能：遵循已定义过程的历史结果的度量元。几层含义：

1) 过程是自己的过程，不是其他组织的过程。所以不能用业内的标杆数据作为自己组织的过程性能数据。

2) 是过程的性能，不是人的性能，不是业务性能，一定要可以具体到某个过程。

3) 是历史的表现，是历史的结果，不是未来，不是期望，不是目标。

4) 过程性能是定量刻画，定量表达的。

 

过程性能基线：执行已定义过程的过程性能的分布规律，包括集中趋势（如均值，中位数等）与离散程度（如标准差、四分位差等）的刻画。几层含义：

1） 一定是执行本组织的过程的结果的度量，不能是业内的标杆数据；

2） 过程性能基线是个区间，不是单点值，包含了数据分布的位置与离散程度，仅仅是平均值不代表过程性能基线。

3） 刻画过程性能分布规律的方法有多种，不限定于某一种方法。

 

过程性能模型：执行已定义过程的过程性能与影响因子之间的因果规律，可以通过回归方程、模拟、概率网络等刻画这种因果规律。几层含义：

1） 过程性能模型是执行本组织过程的因果规律，不能是业内的其他组织的模型；

2） 过程性能模型的影响因子中一定要有可控因子，所谓可控因子一定是可以根据需要任意改变的因子。

3） 过程性能模型的输出结果是一个区间或概率分布，不是一个单点值，过程性能模型不是确定性的函数关系。

 

三个与目标有关的核心概念：

在本实践域中提到了三种类型的目标：

商业目标 BO，这是组织的高层定义的、宏观的总体目标，是由整个组织、或某个部门、某个单元来达成的目标；

度量和性能目标MPO：此类目标可以定量，也可以定性，但是一定要有定量的，是非高成熟度的实践中使用的术语；

质量和过程性能目标QPPO，这是定量的，统计管理的目标，是高成熟度的实践中使用的术语；

各类目标都可以层层分解，度量元帮助我们客户目标、了解目标达成的程度、识别影响目标达成的因子。

 

实践列表

  

MPM	1.1	Collect measures and record performance.	采集度量数据，并记录性能
MPM	1.2	Identify and address performance issues.	识别并处理性能问题
MPM	2.1	Derive and record measurement and performance objectives from selected business needs and objectives and keep them updated.	从选中的商业需求和目标中，派生并记录度量和性能目标，并保持更新
MPM	2.2	Develop, keep updated, and use operational definitions for measures.	制定、保持更新并使用度量元的操作定义
MPM	2.3	Obtain specified measurement data according to operational definitions.	依据操作定义获得特定度量数据
MPM	2.4	Analyze performance and measurement data according to the operational definitions.	依据操作定义分析性能和度量数据
MPM	2.5	Store measurement data, measurement specifications, and analysis results according to the operational definitions.	依据操作定义存储度量数据、度量规格和分析结果
MPM	2.6	Take actions to address identified issues with meeting measurement and performance objectives.	采取行动以处理所识别的问题，并满足度量与性能目标
MPM	3.1	Develop, keep updated, and use organizational measurement and performance objectives traceable to business objectives	制定、保持更新并使用可回溯到商业目标的组织级的度量和性能目标
MPM	3.2	Follow organizational processes and standards to develop and use operational definitions for measures and keep them updated.	遵从组织级的过程和标准，开发和使用度量元的定义并保持更新。
MPM	3.3	Develop, keep updated, and follow a data quality process.	制定、保持更新并遵从数据质量过程
MPM	3.4	Develop, keep updated, and use the organization’s measurement repository.	建立、保持更新并使用组织级度量库
MPM	3.5	Analyze organizational performance using measurement and performance data to determine performance improvement needs.	使用度量与性能数据，分析组织级性能以确定性能改进需求
MPM	3.6	Periodically communicate performance results to the organization.	向组织周期性地沟通性能结果
MPM	4.1	Using statistical and other quantitative techniques, develop, keep updated, and communicate quality and process performance objectives that are traceable to business objectives.	使用统计和其他量化技术制定、保持更新和沟通可以回溯到商业目标的质量和过程性能目标
MPM	4.2	Select measures and analytic techniques to quantitatively manage performance to achieve quality and process performance objectives.	选择度量元和分析技术，来定量管理性能以达成质量和过程性能目标
MPM	4.3	Using statistical and other quantitative techniques, develop, keep updated, and use process performance baselines.	使用统计和其他量化技术建立、保持更新和使用过程性能基线
MPM	4.4	Using statistical and other quantitative techniques, develop, keep updated, and use process performance models.	使用统计和其他量化技术建立、保持更新和使用过程性能模型
MPM	4.5	Using statistical and other quantitative techniques, determine or predict achievement of quality and process performance objectives.	使用统计和其他量化技术确定或预测质量和过程性能目标的达成
MPM	5.1	Using statistical and other quantitative techniques, ensure that business objectives are aligned with business strategy and performance.	使用统计和其他量化技术确保商业目标与商业战略和性能协调一致
MPM	5.2	Analyze performance data using statistical and other quantitative techniques to determine the organization’s ability to satisfy selected business objectives and identify potential areas for performance improvement.	采用统计和其他量化技术，分析性能数据以确定组织满足选中的商业目标的能力，并识别潜在的性能改进领域
MPM	5.3	Select and implement improvement proposals, based on the statistical and quantitative analysis of the expected effect of proposed improvements on meeting business, quality, and process performance objectives.	基于对满足商业目标、质量目标和过程性能目标的改进建议的期望效果的统计和量化分析，选择和实施改进建议

MPM 1.1 采集度量数据并记录性能数据

采集哪些度量数据？首先要识别需要的数据的角色，比如高层经理、部门经理、项目经理、测试人员等等。然后识别这些角色要解决的问题，他们向通过数据解决哪些问题？比如项目经理要控制进度、节约成本，部门经理希望提高产品质量等。最后根据这些问题识别需要采集的度量数据。在模型中对度量数据有定义：可以被记录、沟通和分析的定性的或基于定量的信息。

而性能如前面所讲，分为过程性能与业务性能。过程性能是对执行过程结果的度量，可以是表征过程的度量元，如工期、缺陷清除率等；也可以是表征过程输出物的度量元，如缺陷密度、响应时间等。过程性能是项目级的、任务级的，归集起来可以到业务性能，业务性能是组织级的、业务级的。业务性能数据如：客户满意度、销售额、利润等。这里说的归集不是单纯的累加，而是综合作用的含义。

关于从过程性能归集得到业务性能的方法举例如下：

 

	过程性能	业务性能	归集方法
情形1:求平均	每个产品的缺陷逃逸率	整个公司的平均缺陷逃逸率	每个产品都有缺陷逃逸率，求出其总的平均值，得到整个公司的平均缺陷逃逸率。
情形2:累加求比例	每个产品都有交付后的缺陷个数，都有内部发现的缺陷个数	整个公司的缺陷逃逸率	每个产品都有交付后的缺陷个数，都有内部发现的缺陷个数，分别累加，然后相除，得到整个公司的缺陷逃逸率
情形3:求比例	项目延期与否	整个公司的项目延期率	每个项目都延期或不延期，公司1年有200个项目，合计有50个项目延期，整个公司的项目延期率是25%。
情形4:直接累加	某个项目交付的需求规模	组织级交付的需求规模	把每个项目交付的需求规模累加起来得到整体交付规模。
情形5:直接采集		组织级的客户满意度	组织级的客户满意度是针对所有的用户直接进行客户满意度调查得到的结果。

 

MPM 1.2识别并处理性能问题

对采集的数据通过横向对比分析与纵向对比分析发现问题，并解决问题。

纵向对比分析是和历史、和计划对比，横向对比分析比较同一时刻，不同对象之间的对比。

 

MPM 2.1从选中的商业需求和目标中，派生并记录度量和性能目标，并保持更新

围绕商业目标识别度量需求、度量元。采集了度量数据后，有可能会优化商业目标，互相影响。

 

MPM 2.2制定、保持更新并使用度量元的操作定义

度量元的操作定义即对度量元的详细定义，包括：

度量元的类型：基本度量元、派生度量元；

度量元的刻度：定类数据、定序数据、定距数据、定比数据；

度量元的含义；

度量元的计量单位；

基本度量元的采集方法；

派生度量元的计算方法；

数据采集的责任人；

数据采集的时机；

数据校验的方法；

数据存储的位置；

数据展示的方法；

通过数据识别问题的方法；

数据分析周期；

数据存取额权限分配；

……。

操作性定义的目的是：确保大家对度量元理解一致，确保度量数据可以可重复的准确采集。

 

MPM 2.3依据操作定义获得特定度量数据

采集数据以及校验数据。

 

MPM 2.4依据操作定义分析性能和度量数据

对度量数据分析时，通常可以采用七种图形：

 

MPM 2.5依据操作定义存储度量数据、度量规格和分析结果

存储数据及分析结果。存储时要注意把数据采集的一些背景信息也要保存完整，便于将来的分析与使用。比如：项目的类型、生命周期类型、客户的特点、采集人、采集时间等等。

 

MPM 2.6采取行动以处理所识别的问题，并满足度量与性能目标

根据数据的分析结果，识别问题，解决问题。

 

MPM 3.1制定、保持更新并使用可回溯到商业目标的组织级的度量和性能目标

对组织级的商业目标进行层层分解细化，得到组织级的度量和性能目标。

和2级不同的是，2级是项目级的，不是组织统一的。

 

MPM 3.2遵从组织级的过程和标准，开发和使用度量元的定义并保持更新。

组织级统一定义度量元，所有的项目组按照统一的定义采集数据，这样才能进行组织级的统一数据分析。

 

MPM 3.3制定、保持更新并遵从数据质量过程。

校验数据的正确性。

 

MPM 3.4建立、保持更新并使用组织级度量库。

组织级建立度量库。

 

MPM 3.5使用度量与性能数据，分析组织级性能以确定性能改进需求。

组织级通过定量数据识别改进点。

 

MPM 3.6向组织周期性地沟通性能结果。

定期在组织内分享、沟通度量分析的结果。

 

MPM 4.1使用统计和其他量化技术制定、保持更新和沟通可以回溯到商业目标的质量和过程性能目标。

质量与过程性能目标是定量的，而且要满足SMART原则：

S：specific， 明确的，文档化的，可以详细描述的，可以细拆分的；

M：measurable，量化的，定量表达的；

A：attainable，可实现的，可行的，具有比较高的达成概率的；

R：relative，有关的，相关的，来自于商业目标的；

T：time-bounded，有时间限制的。

可以通过过程性能基线、过程性能模型、模拟等方法与历史的性能进行比较，判断目标达成的概率，确保目标是可行的。

 

MPM 4.2选择度量元和分析技术，来定量管理性能以达成质量和过程性能目标。

在实践中常用的定量技术如：

统计过程控制；

通过回归方程计算预测区间；

蒙特卡洛模拟；

 

MPM 4.3使用统计和其他量化技术建立、保持更新和使用过程性能基线。

建立过程性能基线的方法常用的有如下几种：

1 控制图法

2 箱线图法

3 置信区间法

        建立过程性能基线时，要注意进行细分类，不同特征的对象建立不同的过程性能基线。可以通过箱线图、方差分析帮助识别这种应该分类的现象。

 

MPM 4.4使用统计和其他量化技术建立、保持更新和使用过程性能模型。

建立过程性能模型常用的方法有如下几种：

1 回归方程

2 方差分析

3 logistics回归

4 模拟

5 概率网络

建立过程性能模型时也要注意分类建立模型，不同的部门、不同的产品线、不同的开发平台、不同类型的项目、不同的生命周期模型、对组织级流程的不同裁剪可能过程性能的因果规律是不同的。

 

MPM 4.5使用统计和其他量化技术确定或预测质量和过程性能目标的达成。

预测目标达成概率的方法：

1 通过回归方程等执行what-if分析，得到过程性能的预测区间，使其有比较高的概率达成目标。

2 通过性能基线预测目标达成的概率。

3 通过蒙特卡洛模拟预测目标达成的概率。

在项目或任务执行过程中可以：

1 通过控制图或目标的实际值是否落在预测区间内，识别造成离群点的特殊原因；

2 通过计算过程能力指数判断过程能力是否需要提升；

3 通过what-if分析可以改变可控因子的数值以提高达成目标的概率；

4 通过原因分析识别异常的原因、能力不足的原因、目标不能达成的原因；

 

MPM 5.1使用统计和其他量化技术确保商业目标与商业战略和性能协调一致。

平衡历史性能与未来目标，确保目标切实可行。

 

MPM 5.2采用统计和其他量化技术，分析性能数据以确定组织满足选中的商业目标的能力，并识别潜在的性能改进领域。

通过统计技术识别改进点，确保不做无用功，少做无用功，精准定位问题。

 

MPM 5.3基于对满足商业目标、质量目标和过程性能目标的改进建议的期望效果的统计和量化分析，选择和实施改进建议。

通过统计技术对改进建议进行定量分析，选择投入产出比最高的改进措施。

 

过程映射与定义建议

 

本实践域中包含了项目级与组织级的实践，将组织级的具体做法向本实践域映射时，或者参考本实践域建立组织自己的过程时，可以参考如下的图形：

 

 

后记

 

在CMMI V2.0发布之前就想针对2.0的每个PA进行解释，但是拖延了下来，恰好春节之前有客户开始实施了CMMI V2.0，有客户和同事与我探讨2.0中的内容，在解释的过程中，就形成了文字，索性就想把每条实践都解释一下。于是，就给自己定了目标，在春节期间把20个PA都解释完成。实际去做的时候，发现没有那么容易。一是时间是否有保证，二是我自己也需要对模型的某些描述反复阅读，提炼，查阅资料。所以，弄的自己也很紧张，承诺了，就要兑现，自我加压。

本系列的博客，我是侧重于解释模型的含义，并没有给出更多的实例，限于CMMI V2.0的版权限制，也仅仅是列出了模型的实践，并没有列出模型中的详细描述，所有的通俗解释，也是我自己的理解，并非拷贝模型中的描述，如果需要阅读原文，需要购买模型的版权。如果大家要检索每个PA的how to do，可以在我的博客中检索历史的文章。有的实践很简单，所以就没有进行过多的解释。有的实践中有些关键字眼不是很好理解，我就仅对这些关键字眼做了说明。

本资料会继续修订文字，补充案例，供各位参考。

 

 

 

任甲林

2019年2月12日

 

 

【麦哲思科技介绍】

麦哲思科技(北京)有限公司（Measures Technology LLC.），一家以改善中国软件质量为使命的实效咨询公司，诞生于2007年，中国·北京！

麦哲思科技(北京)有限公司（简称：麦哲思科技）一直致力于软件过程能力提升的实效咨询服务，是集项目管理咨询、技术咨询、IT类培训以及软件过程研究于一体的高新技术企业，客户遍布于金融保险、汽车电子、通信、能源、航空、税务、装备制造等众多国民经济支柱性产业领域。

麦哲思科技总部设立于中国·北京，在上海、济南及美国明尼苏达州都设有分公司，在国际上拥有两大授权资质：CMMI Institute （SEI-Partner）和国际通用软件度量协会中国区代表(COSMIC IAC委员会委员单位)。

麦哲思科技十多年来专注实效咨询和过程改进相关业务外，还联合兄弟公司开展专项培训、人力外包等相关产业链，争做国内本土化技术培训与咨询服务公司。