浅谈CMMI与敏捷体系的融合

我们说CMMI是一个复杂的，标准化的，程式化的软件研发过程，是相对比较重的。然而，敏捷，是轻量级的，快速响应的一种所谓高效的研发方式。二者貌似水火不容，但是，也可以牵手成功。

在对于敏捷这件事上，很多人有几个误区：

1. 敏捷很快。

这是很多老板想使用敏捷方法做开发的根本初衷，其实并不然。敏捷是一种快速响应的开发方式，所谓的快速响应说的是，尽可能短时间的发布可交付产品增量，以获取用户或客户的反馈。所以，敏捷不是快，而是快速反馈和快速响应，实践过的人都知道，一个项目用传统瀑布方式和敏捷方式，还不一定哪个周期长呢。

1. 敏捷就是迭代开发。

敏捷从根本上来说就是一种思想，或者说通过一系列的实践来遵循这些思想的研发过程，敏捷开发过程是迭代的过程不假，但是迭代的不一定就是敏捷，因为敏捷思想是在迭代过程中起关键作用的。

1. 敏捷可以节省成本。

敏捷其实很贵，从成本的角度来说，软件开发会用人天成本来核算，也就是说，最大的成本就是人。然而现今的软件开发，已经工种繁复，专业性越来越强。在搭建敏捷软件团队的时候，对团队成员就有相对高的要求，对比传统方法，这些人一定是贵的。再者，因为快速交付和快速反馈，在每个迭代的成果叫做潜在可交付产品增量，既然是潜在的，就有一定的返工或者废弃的风险。另外，在快速迭代的过程中，既然成果叫增量，那么全量回归测试会非常消耗团队成本，所以，敏捷很贵。

       那我们再看CMMI，拿v1.3的三级来说，一共18个过程域：

1． OPD：（Organizational Process Definition）组织级过程定义。

2． OPF：（Organizational Process Focus）组织级过程焦点。

3． OT：（Organizational Training）组织培训管理。

4． PP：（Project Plan）项目计划。

5． PMC：（Project Monitoring and Control）项目监督与控制。

6．SAM：（Supplier Agreement Management）供应商协议管理。

7．IPM：（Integrated Project Management）集成项目管理。

8． RSKM：（Risk Management）风险管理。

9．RD：（Requirement Development）需求开发。

10．REQM（Requirement Management）需求管理。

11．TS：（Technical Solution）技术解决方案。

12．PI：（Product Integration）产品集成。

13．VAL：（Validation）确认。

14．VER：（Verification）验证。

15． CM：（Configuration Management）配置管理。

16．PPQA：（Process and Product Quality Assurance）过程和产品质量保证。

17．MA：（Measurement and Analysis）测量与分析。

18． DAR：（Decision Analysis and Resolution）决策分析与解决。

从这些过程域来看，CMMI是很复杂，但是有这样的一个理论是说，任何研发型企业，对项目管理都是从简单-复杂-简单，其实从另外一个角度来说，那就是不会的-规定好的-自由灵活的。CMMI的已定义过程都做不好，那是没有办法敏捷的。无论是CMMI、OPM3、PUB还是什么别的项目管理框架，首先有，是迈向敏捷的一个必然的阶段。这就是我认为CMMI跟敏捷的关系。

那么说到融合，有一点我认为大家的观点是一致的——他们是可以牵手成功的。但是具体是怎么融合的还是要看你所在的组织实际的情况。为了好描述，下面我用CMMI的几个方面来说明一下。

我们先说说需求也就是RD，在CMMI环境下，我们会有一个用户需求说明书，还有一个需求规格说明书，在这两个文档中我们知道有用户的原始需求，有系统需求，还有功能性需求和非功能性需求，另外还有验收标准。那我们到敏捷中找找这俩东西的影子。在敏捷中，我们用故事（story）。我们知道故事一般来说都是由用户去讲，那么用户需求自然也就被覆盖了，那么系统需求和非功能性需求在哪呢？其实是一样的，我们拿Scrum框架来说，通常你看到的需求会是一个叫product backlog的东西，在这个东西里面，都是一些故事，有些是用户开头的，那另外一些则是系统开头的。也就是所谓的去描述系统的质量。那这又是什么呢，不就是非功能性需求嘛。

再说系统需求，我们都知道故事很短，通常故事不是为了说明用户或者软件是怎么实现的。通常的意义上，我们认为，故事是要引发讨论的，通过讨论对故事进行进一步拆分，所谓渐进明细，系统需求也就是这么产生出来的。

在敏捷中，验收标准这个东西如果非要比对，应该属于验证（VAR）过程域，说白了，与测试相关。我们知道验收标准这种东西应该是由客户提出，团队去满足。但是在理想的敏捷团队中，应该由客户或者客户代表去构建验收测试用例。说的高大上点来说，这叫基于验收标准的测试驱动开发（ATDD）。不要问我怎么让客户配合，这算世界性难题，特别是在我国的软件环境下。但是验收标准应该随着故事一起出现在你的backlog上，或者是看板上。

无论是在CMMI环境下还是在敏捷环境下，需求总是软件开发过程中最重要的一个环节，在敏捷开发中也是一样，通常PO（product owner）消耗最大的就是与Team去研讨product backlog，然后与团队一起确定sprint backlog。

然后我们要说的另外一个方面是项目监督与控制（PMC），从CMMI的角度来说，我们要做的事是，要监督的是计划、承诺、风险、数据、干系人、进度外加一个里程碑。

我们先说里程碑，还是拿scrum来说，在scrum中里程碑更像是sprint回顾会议，我们在这个会上总结经验教训，在敏捷中里程碑评审成为了一种团队自发的行为，而不是审计行为。

那计划和承诺，我们知道在敏捷团队中，计划和承诺是由全体团队成员共同作出的，会得到全体团队成员的共同监督。

剩下的风险、数据、干系人、进度等方面，理想敏捷团队的工作是高度可视化的，风险理论上是存在的，但是都能在第一时间由团队成员发现并得到缓解，持续下去，团队也好，软件产品也好，稳定性相对比较高。剩下的三个方面都由团队全部成员共同监督。

所以，一个敏捷团队，理应是自发的，自组织的无领导小组，团队中成员能够相互促进，相互监督，共同为团队目标奋斗，在这样一个黄井下，监督和控制就是团队的事了，与第三方无关。

最后，我们说说度量（MA）。在CMMI中的度量除了收集项目数据之外还有过程数据。无非就是进度、范围、质量、成本这几个东西。

很多人觉得，敏捷要省略很多东西，首先会被忽略的估计就是度量了。其实不是这样的，所谓的省略不是不做，而是潜移默化的融合在过程中，用高效的方式去处理。

敏捷也是一样，只不过在度量元和收集的方式上需要稍作调整。团队是自组织的，那么收集的过程那就很自然了。比如说进度问题，我们可以在公共的区域绘制一张燃尽图，每天站立会的时候去更新这个燃尽图，到了迭代结束的时候，自然也就有了这些数据。这只是一个小小的实践，还有很多的方法每个团队都不尽相同，在这就不多赘述了。

其实CMMI与敏捷并不冲突，所谓的融合也是当正规化或者程式化发展到一定的阶段自然形成的，所谓的敏捷转型也就是这个道理，融合制度和过程并不难，难的是让团队都能够发生思想的转变。