敏捷与CMMI的同与不同

    CMM我是从1998年开始接触的，到现在大概20年了，自己亲自实施过CMMI，也辅导了很多企业做基于CMMI的过程改进。2013年我成为了CMMI的评估师，后来成为高成熟度的评估师，去年又成为了教员。

    敏捷我是2005年接触的，到现在14个年头了，2008年左右也成了认证的Scrum Master, 去年成为认证的大规模敏捷顾问，2018年成为敏捷性能合弄模型的评估师。10多年来，给多家客户辅导导入了敏捷方法。

    在咨询过程中我秉承实用、实效的原则，别管黑猫白猫，逮住老鼠就是好猫，基于这样的思想，我们的客户大都同时吸收了两种方法论的有益成分，有成功的，也有失败的。

    在多次和客户、同行碰撞、沟通的过程中我进行了一些思考，整理我对两者的认识如下：

一 目标定位

    CMMI是用来评价组织级能力的模型，是指导组织持续进行过程改进的模型，它给出了过程改进的路线图。

    敏捷方法是用来指导解决快速高质量交付高价值产品的思想与框架。

    所以：

    1） CMMI给出了what to do, 敏捷给出了how to do。

    CMMI给出了很多实践，敏捷也给出了一些仪式，但二者的详细程度、抽象层次不同。例如：

    二者都要做计划，CMMI要求做任务拆分，要做规模估算、工作量估算，要有进度表，要做计划评审等。敏捷给出了迭代策划会议的解决方法，实现了CMMI中EST，PLAN实践域的实践。

    二者都要做计划跟踪，敏捷给出了每日站立会、迭代评审、迭代回顾会议实现了CMMI中MC实践域的实践。

    CMMI要做验证与确认，敏捷要做检视，CMMI中有VV与PR两个实践域，敏捷有结对编程、测试驱动的开发、迭代评审等仪式。

    ........

    what to do 与how to do 是对具体做法的不同抽象层次，how to do 可以有很多种不同的做法，敏捷实践是其中一种。CMMI并不排斥敏捷，它只是定义了what to do。

    敏捷中有价值观、原则，在符合敏捷的价值观与原则之下，有各种各样的敏捷方法、敏捷仪式，敏捷价值观与原则抽象了仪式背后的目的，是对how to do的思想的提炼，但是仍然是处在how to do的层次上。

    以吃饭来举例：

                                                                     图一 what to do与how to do的类比

     CMMI模型的鼻祖Watts Humphrey老先生是伟大的，他负责开发了CMM，还继续开发了小组软件过程（TSP）与个体软件过程（PSP），试图解决团队级与个人级的how to do的问题，解决CMMI落地的问题。PSP给出开发人员能力提升的路线图，包括了个人的技术能力与管理能力，TSP给出了不超过10人的团队如何采用迭代的生命周期模型进行开发，PSP与TSP试图解决CMMI在项目级、在个人级如何做的问题，但是它们并没有吸收更多的敏捷元素，没有在业内流行开来，很是可惜。

    企业可以采用CMMI+TSP+PSP搭建自己的管理体系，当然也可以采用CMMI+看板+XP+Scrum+LeSS搭建自己的管理体系。what to do 与how to do 本身并不矛盾。

    how to do 不能否定what to do， 比如你笃信过午不食是最正确的，但是你不能据此来否定人要吃饭。

    2） CMMI侧重于建立组织级的能力，大多数敏捷方法侧重于团队级的能力。

    CMMI最初是美国国防部为评价一个组织的开发能力而定义的模型，它是站在组织级的角度看待过程能力。它定义了高层管理者的治理职责，要求组织级要定义管理的方针、流程、裁剪指南、模版等，组织级要进行流程执行情况的检查，要给团队提供资源、工具、培训等支持，组织级要采集经验教训、典型案例、改进建议、度量数据等进行持续改进，要将组织的规范固化为大家的工作习惯。

     TSP是侧重于建立团队级的能力，PSP是侧重于建立个人级的能力。

     SCRUM，XP等敏捷方法大都是侧重于构建团队级的能力，给出了一个小团队的角色划分、管理实践与技术实践，如果需要进行大产品的开发，可以采用规模化敏捷的方法，如LeSS， SAFe等。当团队规模越大时，需要的管理活动就越多，SAFe之类的大规模敏捷框架受到的质疑就比较多。组织级敏捷文化的形成需要借助变革管理的理论、方法来辅助Scrum, XP, LeSS, SAFe等敏捷方法构建组织级的能力，在组织内如果不能形成敏捷文化，敏捷不能持久。

                                                                        图2 各种模型与方法的定位矩阵

     上述这个分类图，可以厘清各种模型、框架、标准的定位。

     没有必要绝对的评价各种方法的谁好谁坏，只能讲在某种场景下，谁最适合。

二 思想焦点

     1） 流程的重要程度。

     CMMI强调通过规范的流程，将人、技术、工具集成在一起，从而产生好的结果。

    敏捷依赖人的经验+做事的原则快速交付高质量的产品，敏捷并不否定流程的重要，只是和个体与协同相比，不如后者重要。

    CMMI重视流程的重要性，但是没有强调简洁的流程、增值的流程、无浪费的流程更有价值！QA要对项目的合规性进行检查，而敏捷认为非增值的合规活动是一种浪费。

    在实践中，很多项目追求合规时，往往迷失了目标，为规范而规范。而敏捷认为为了产生好的结果，应该灵活地配置流程，灵活的配置流程比预定义的流程更重要。

    从本质上来讲，二者都是为了解决更好、更快交付的问题，但是解决问题的方式不同。这是在对待流程的认识上与实践中，敏捷与CMMI的本质差别。

    2）文档的重要性与多少。

    敏捷宣言中明确提到：能够工作的软件胜过完备的文档。不是没有文档，而是可以工作的软件比文档更重要。

    敏捷中的文档数量少，文档内容简化、文档形式灵活，编写刚刚好的文档即可。

    CMMI的每条实践在评估时，要从制品和访谈两个维度进行考察。

    CMMI并没有要求文档一定要有多少个，一定要包含什么内容，一定要什么格式，一定有多么正式。

    但是：

          a） 由于CMMI内容的完备性，需要证明某些PA是否满足了，需要有证据。

          b）由于实践中大家对CMMI的误解，很多组织过度准备了证据。

    所以第1种原因造成的文档增加与第2种原因造成的文档增加其必要性是不同的。

    敏捷认为面对面的沟通传递信息比文档传递信息更高效。而CMMI并没有在how to do的层级强调这一点。

    需求、设计、测试用例这些工程制品无论敏捷还是CMMI都是有的，只不过在敏捷里给出了明确的建议而已，采用product backlog、 用户故事、CRC卡片、设计草图、测试代码等。拿需求文档来举例：CMMI要求有客户需求、产品需求，可以映射为敏捷中的用户故事、用户故事的验收标准。CMMI要求要区分必须的需求与期望，可以映射为敏捷中的需求划分优先级。CMMI要求要包含接口需求与约束，要有系统的操作概念。接口需求与约束在敏捷中可以表现为技术故事或约束故事，操作概念可以映射为在制作故事地图时梳理出来的客户的作业流程。

    计划书、计划跟踪记录这些管理制品无论是敏捷还是CMMI也是有的，只不过在敏捷里给出了明确的建议而已，采用产品路线图、发布计划、迭代计划、任务白板、燃尽图等。但是CMMI对计划的内容做了比较完备的要求，比如要有人员能力的获取计划（培训计划或人员配备招聘计划）、资料的管理计划、风险的管理计划等等。而在敏捷策划时，这些计划是根据需要来定义的，团队根据经验想到了就做，没想到就等出了问题再去解决。

    从主要的工程制品与管理制品的要求上，其实二者并没有本质的差别。那CMMI的文档多在什么地方呢？

          a）文档内容的完备性。如上面我们所举的项目计划的例子。

          b）CMMI中有支持类的PA，包含了质量保证、配置管理、决策与解决方案、度量与分析、根因分析与解决方案，这些PA的活动都要有计划，这些活动计划可以是单独的文档，也可以是scedule中的活动，这些活动的实际执行也要有记录。

         c) CMMI中有组织级的过程管理类的PA，包含了组织过程焦点、组织过程定义、组织过程性能、组织级培训、组织性能管理。这些PA的制品是敏捷方法中没有涉及到的。

    对于文档的多少，我们需要冷静分析：

               该不该有？

               如果需要，完备到什么程度？

    CMMI说了要有某些证据，说了，让大家听起来觉得需要好多文档。

    敏捷没说，没说不代表实践中不需要有！不能回避，不能视而不见，否则就是皇帝的新装了。

    在实践中，可以根据文档的价值来决定文档的多少、表现形式与内容多少：

        a) 用户需要的文档必须有。

        b) 工程类的文档，直接辅助我们来开发产品的文档，如需求，设计，测试用例等，尽量有。

        c) 管理类的文档，帮助团队来开发产品，交付产品的文档，如计划，计划跟踪结果等，尽量少。

        d) 记录类的文档，只是记录我们的工程活动与管理活动的结果的文档，尽量无。

    敏捷就是平衡灵活性与稳定性，平衡的能力，至关重要。

    3）如何应对变化？

    敏捷的流程是随需而变，是经验型过程控制，是在团队级灵活变化的，是以变化应对变化，拥抱变化，不是以不变应万变。不变的是原则，变化的是具体做法。

    CMMI的三级强调已定义的流程，组织级统一定义了流程，项目组可以裁剪，但是如果组织级的约束太多，项目组就懒得去裁剪，而是表面上合规，实际自己按自己的套路去做。当外部环境发生了改进，需要对流程修改时，需要在组织级统一修改流程，经过多个作业环节的认可后才可以变更，这影响了应对变化的速度。

    如果CMMI的组织级流程是一套原则+简化的流程而不是一套完备的流程，赋予团队更多的流程决策权力、提供更大的灵活性，是否就敏捷化了呢？这个问题值得思考。

    CMMI在what to do给出了实践，但是对how to do并没有给出融合敏捷思想的建议，这是导致大家对CMMI有误解的原因之一。虽然在CMMI 1.3中和CMMI2.0中给出了一些在特定敏捷环境下，CMMI从what to do 到how to do的解释说明，但是并没有触及根本。

三 核心理念

    敏捷宣言，敏捷的12个原则以及各种敏捷方法自己的原则，构成了敏捷的价值观，这些是敏捷的思想理念，是敏捷的根本。

    CMMI推崇的价值观，理想以及自己的原则是什么？CMMI没有明确的喊出来！CMMI的共性实践可以认为代表了它的一些核心理念，不是全部，它是通过实践来描述的，没有提炼、抽象出来。CMMI2.0推出以后，我试图概括了CMMI的核心价值观如下，这仅是我的理解，并非CMMI的官宣：

           a)商业目标驱动改进

           b)转型过程实现目标

           c)定量数据量化性能

           d)固化习惯成为文化

           e)高层支持全员参与

           f)循序渐进持续优化

    敏捷的价值观描述的比较简单、清晰，辨识度很高，更接地气，更容易打动人！这对于敏捷的宣传推广起到了很好的助力！不容易让人误解。

    当人们一提到敏捷时，首先想到的是快速交付产品，而提起CMMI时首先想到的是文档和过程。这种第一印象未必准确、未必正确，但是却是有很大的舆论效应。

四 内容范围

    1）CMMI完备，敏捷简单。

    CMMI试图规避在开发与管理中遇到的各种风险，所以总结了很多实践，是相对完备的集合，在完备性上鲜有类似的模型。CMMI的实践覆盖了管理、技术、支持、过程改进的活动，一个组织内的采购、开发、服务、人力资源管理的业务都可以参照进行改进。CMMI中包含了组织级支持团队交付产品或服务的基础设施的建立、企业文化的形成。单一的敏捷方法中则缺少这些基础设施与文化建立的仪式，需要融合多种敏捷方法或辅助以其他方法才可以建立敏捷的基础设施与文化。

    敏捷试图规避在开发与管理中遇到的最主要的风险，所以总结了很少的仪式。当在实践中遇到具体的问题，再来及时应对，它是探索式的管理，不是预测式的管理。不同的敏捷方法有不同敏捷仪式，百花齐放，因为不同的敏捷方法的侧重点不同。Scrum侧重于单团队的管理活动，XP侧重于单团队的技术活动，LeSS、SAFe侧重于多团队的协同活动。

    如果要做一个敏捷方法与CMMI的映射，需要将多种敏捷方法的仪式与CMMI的实践域进行映射才可以覆盖到。单一的敏捷方法在完备性是无法实现CMMI模型的实践要求的。下表是一些流行的实践与CMMI2.0实践域的简单映射：

敏捷实践\CMMI PA

EST

Plan

MC

RSK

MPM

SAM

RDM

TS

PI

PR

VV

PQA

CM

DAR

CAR

PCM

PAD

GOV

II

OT

需求梳理

√

√

团队估算游戏与策划扑克法

√

√

√

√

发布策划

√

√

√

√

√

√

冲刺策划

√

√

√

√

√

√

√

每日站会

√

√

√

√

冲刺演示/冲刺评审

√

√

√

√

√

冲刺/迭代回顾

√

√

√

√

√

√

√

结对编程

√

√

√

TDD

√

√

重构

√

√

持续集成与持续构建

√

√

√

√

Spike

√

√

√

√

史诗

√

用户故事

√

√

产品待办事项列表

√

√

迭代待办事项列表

√

√

√

技术债务

√

√

√

DoD

√

√

发布燃尽图

√

√

冲刺燃尽图

√

√

速率

√

    而一个组织的实际做法往往是介于CMMI与敏捷之间，画一个示意图大概如下：

                                                                            图四  组织自己的实际做法

 

    2）二者的很多思想都是共通的。

    CMMI的大部分实践与敏捷的仪式其实思想是相同的，在很多地方都是有共识的，都是来自于历史的成功组织的最佳实践。

    他们都要做计划，都要做计划跟踪，都需要配置管理，都要度量数据，都要根因分析，都要做反思回顾，都要做验证与确认等等。只不过是whao to do 与how to do的区别，活动的抽象层次不同。

    高成熟度的实践是CMMI特有的，它们也可以尝试应用于敏捷环境，但并非必须，当敏捷的实践在组织内成熟到一定程度后也可以做统计管理。

五 推广难度

    CMMI模型区分了连续式（自定义视图）与阶段式表示方法（预定义视图），连续式表示方法允许企业自选过程域进行改进，而阶段式表示方法则预定义了路线图，规定了要包含的PA，阶段式表示方法的评估等级称为组织的成熟度等级，连续式表示方法的评估等级称为PA的能力等级。前者在行业内进行标杆对比时，概念简单，后者则逐个PA进行比较，在实践中绝大多数的组织都选择的是阶段式比表示方法，使连续式表示方法形同虚设。这种结局也是违背了CMMI模型的初衷，它是期望组织能够针对自己的实际问题，有选择性的进行自定义改进路线图进行提升的，而不是以通过评估为目的的“改进”。

     CMMI模型1.3版本的构件中目标是评估时必须考察的，必须满足的。实践是期望的，但是企业在理解CMMI模型、实际执行时，咨询顾问在咨询时，评估师在评估时往往是把实践也作为了必须满足的。这也导致了CMMI模型的初衷与现实的巨大差距！

     从人的本性来讲，人们更喜欢简单的事物，不喜欢被约束，所以原则+少量的仪式+团队的自信这种模式更容易被开发人员认可，从而流行起来。

    但，这并不认为敏捷就比CMMI容易推广。

    CMMI在推广中面临形似而神非的现象，敏捷在推广中也面临类似的问题。

    一个组织在导入敏捷时，要选择自己认可的价值观、原则、仪式、工具等等，也要定义规范，推广规范，需要有教练指导这些原则、仪式、工具的落地。

    很多组织做了迭代策划、每日站立会议、迭代评审、迭代回顾，但是实际旁观他们的行为，却发现并没有贯彻敏捷的原则、敏捷的价值观。因为很多团队并没有理解敏捷仪式背后的原理，导致敏捷仪式走样，不能达到预期的效果。

    也有很多组织只是实施了敏捷的管理实践，而没有实施敏捷的技术实践，产品的质量并没有得到真正的提高。

    也有的企业没有建立组织级敏捷的文化，公司中高层的思想没有同步更新，团队的敏捷则无法持久。

    经验型过程控制，追求技术卓越，这些都要求团队的核心成员具有丰富的开发经验、较高的技术水平，而软件组织的很多人员并不具备这个基础。

    谴责CMMI模型不好或者谴责敏捷方法不好，都是片面的，更大程度上是我们落地方法有问题，是我们去落地的人的问题。

    在一个组织内，谁最先发起要导入CMMI与敏捷的呼吁呢？

    如果是市场的呼吁，那可能侧重的是证书，是投标的需要。

    如果是开发的呼吁，那可能侧重的是减负，是提高效率的需求。

    如果是老板的呼吁，那可能侧重的是交付高质量的产品，快速响应市场的需求。

    不同的sponsor，推动的力度，推动的结局是不同的。

    对企业而言，对老板而言，要平衡短期利益与长期利益，活下去，活得好，活得久，需要平衡。

    CMMI与敏捷都不是万能的，都有其适用场景，不能盲目迷信，盲目崇拜，要秉持开放的心态，持续发展的心态，兼收并蓄，取长补短。

    从理想到实现，都有很远的路要走，都应该聚焦于给客户带来实际效果，立足当下，扎扎实实的去解决问题。

    喧嚣之中，需要冷静思考，务实平衡！