简述软件过程改进

——在CMMI中引入敏捷

1 CMMI概述

80年代早期，在SEI的资助下美国空军成立了一项研究来分析为什么许多软件合同都会超出工期和预算。由此得出的结论是：糟糕的过程。CMM&CMMI也因此产生。CMMI的中文名称是能力成熟度模型，是一个过程改进方法和模型，它为组织提供了实现高效的软件交付过程所必需的基本元素，关注通过切实改进过程域的成熟度，实现过程改进的目标。它可以用来指导一个项目、一个部门甚至整个组织的过程改进。CMMI能帮助我们整合以往各自为政的组织功能，建立过程改进的目标与优先级，指导我们进行质量改进，还提供了评价现有过程的参照点，最关键的一点是，它提供了过程改进的线路图，目前最主要的用途是评价一个组织的组织级能力。

2 敏捷方法概述

敏捷是用来指导解决快速高质量交付高价值产品的思想与框架，是一种允许快速业务变更的开发实践。敏捷的核心是敏捷的4个核心价值观和12条原则，外围则是满足不同团队需求的各种敏捷实践，敏捷的不同之处在于其更关注团队协作、关注质量、关注可工作的软件。敏捷来源于实践而不是理论。在追求卓越的过程中，组织会尝试多种途经，采用不同的原则、方法及技术。一个对敏捷实践感兴趣的组织可能也会对PMI的OPM3、ISO或能力成熟度模型集成（CMMI）感兴趣，反之亦然，因为这些都是通向卓越的手段。敏捷代表着一种极简的实用主义。

敏捷的本质是，项目组全体人员以及所有员工和公司，同处于一个利益集体。表现出来的特征是所有人对项目的成功负责、需求驱动地工作、跨领域合作、持续交付，迭代开发，小步前进，持续改进。

敏捷过程的特点则是：项目目标明确的过程，只做对项目进展有帮助的事，不进行额外的工作，有效和高效是项目管理原则、强调让人工作愉快，充满热情。

3 CMMI 和敏捷

经常有一种说法是 CMMI 和敏捷是对立的，这是一种错误的理解，最根本的原因是 CMMI 不是开发过程，而大部分敏捷则是具体的开发过程，这两种之间并无冲突的基础，在 CMMI 的一些过程域中，可以使用敏捷方法进行实践，也可以不使用[3]，有些时候，敏捷方法是达成某个 CMMI 过程域目标的最佳选择。其次，CMMI 存在所谓的标准化，不管是评估方法还是实施办法都有标准化的趋势。而敏捷往往拒绝标准(追求灵活)。再次，作用，即让不熟悉的第三方认可上有差异。尽管 CMMI 目前的现状不乐观，但是，毕竟这种方式提供了一些有价值的线索来了解某个软件组织的能力和成熟度的可能。而这一点敏捷过程还无法提供。有一种说法，CMMI 是主要是组织级过程，而敏捷是项目小组的过程。应该说这种说法有一定的问题，敏捷也可以是组织过程， CMMI 也可以只是关注在小组级别（2 级）。

说完本质，具体地，可以从目标，过程，关注点，适用范围，核心理念等方面来分析和对比 CMMI。

从目标上说，CMMI和敏捷都是人们为了解决在软件生产过程中出现的质量低下、进度延迟、预算超支等问题，而产生的标准或过程改进的模型或方法实践。在这一点上是一致的，这也是为什么人们认为这两种方法是完成同一件事的不同方法因此会产生冲突的原因。但是，接下来，如果从其他角度看，这两种方法思考的角度，范围完全并不一致。

比如，从过程来看，过程的四要素分别是人、方法、技术和工具，在 CMMI 中，对于人的要求涉及GP2.3提供资源、GP2.4分配职责、GP2.5培训、OT组织培训，而敏捷中对人部分的关注在于如何提高人的工作积极性和效率，这在 CMMI 中也有体现，但 CMMI 还关注人的技能，技能培养和团队资源等，明显范围更大，考虑更深。对于方法，涉及所有PA 的SP，而敏捷则强调一组价值观。对于技术和工具，CMMI在GP2.3 提供资源，工程类PA ，OT 组织培训，OPD 组织过程定义，OPM 组织性能管理中谈及了技术在GP 2.3 提供资源谈及了工具，而敏捷对于技术和工具的选择仍基于其价值观，CMMI 则是通过各种目标综合考虑，这里又是CMMI 考虑的更为全面。

从它们的关注点看，敏捷是达成商业目标的极简方法，CMMI 是达成商业目标的方法体系，也是为商业目标服务，不能为商业目标服务也就会违背 CMMI本意，可以依据需求选择执行的部分，比如一个项目是质量优先还是工期优先，该过程和执行和过程还有执行的结果和效果可以被 CMMI 评估和追踪。CMMI和ISO关注为了实现组织软件生产目标，我们应该做什么？但却不关注如何做。而敏捷开发作为一个实践性方法，更关注怎么做。因此，在具体操作过程中，可以通过有效结合，能够使组织更快、更好地实现过程改进目标。为了能够有效结合各种CMMI和敏捷开发，组织必须明确它们的区别和联系，以及每种方法的主要关注点。CMMI和敏捷开发的主要冲突来自于双方产生的环境、目标客户和团队文化要素，例如CMMI早期客户,主要关注大型项目、复杂系统、使命关键(Mission Critical)系统，而敏捷开发主要关注小项目、简单应用和灵活多变的系统；CMMI的假想市场和用户主要面向成熟市场，面向那些关注流程创新的企业，而敏捷开发主要关注在新兴市场和多变的市场环境；文化方面，CMMI强调流程和管理，而敏捷更强调高度信任的氛围中，被激励起来的个人之间的协作创新。

从最一般的适用范围来说，CMMI最初是美国国防部为评价一个组织的开发能力而定义的模型，它是站在组织级的角度看待过程能力。它定义了高层管理者的治理职责，要求组织级要定义管理的方针、流程、裁剪指南、模版等，组织级要进行流程执行情况的检查，要给团队提供资源、工具、培训等支持，组织级要采集经验教训、典型案例、改进建议、度量数据等进行持续改进，要将组织的规范固化为大家的工作习惯。SCRUM，XP等敏捷方法大都是侧重于构建团队级的能力，给出了一个小团队的角色划分、管理实践与技术实践，如果需要进行大产品的开发，可以采用规模化敏捷的方法，如LeSS， SAFe等。当团队规模越大时，需要的管理活动就越多，SAFe之类的大规模敏捷框架受到的质疑就比较多。组织级敏捷文化的形成需要借助变革管理的理论、方法来辅助Scrum, XP, LeSS, SAFe等敏捷方法构建组织级的能力，在组织内如果不能形成敏捷文化，敏捷不能持久。

从核心理念来说，敏捷宣言，敏捷的12个原则以及各种敏捷方法自己的原则，构成了敏捷的价值观，这些是敏捷的思想理念，是敏捷的根本。CMMI推崇的价值观，理想以及自己的原则并没有明确的官方描述，CMMI的共性实践可以认为代表了它的一些核心理念，不是全部，它是通过实践来描述的，没有提炼、抽象出来。可以做如下概括：商业目标驱动改进，转型过程实现目标，定量数据量化性能，固化习惯成为文化，高层支持全员参与，循序渐进持续优化。

总结一下，CMMI 和敏捷要达成的目标其实是一致的，在适用范围上，它们皆可大可小适用于组织和团队，但是由于基本价值观的不同，思考问题的角度和方式也不同，CMMI 更像是一种管理方法，而敏捷更像是一种实践的指导思想。从实际使用的角度来说，目前敏捷方法在开发软件项目的时候使用的跟多，而 CMMI 则主要用来了解一个组织的能力和成熟度，不过并非是必要条件。在一些情形下也比敏捷方法更加适用。

4 CMMI 引入敏捷的得与失

从整体上说，CMMI和敏捷开发能够很好地相互补充、相互支持。首先在关注点上CMMI关注组织级或企业级改进，关注回答项目应该做什么，而不是具体怎么做的方法，而敏捷开发则更关注项目级改进，关注项目具体怎么做的方法和最佳实践，这使双方在定位方面形成很好的相互补充的态势，一方面CMMI为敏捷提供组织级扩展的能力和必须的组织治理框架，便于组织级对敏捷最佳实践的推广和重用；另一方面，敏捷为CMMI提供了项目级的具体实践方法，确保团队在CMMI框架下能够快速响应，不断创新，持续交付价值。两者的有效结合，能够有效实现个人绩效向团队绩效、向组织绩效的转变过程。同时，也可以通过敏捷实践，规避CMMI实施过程中重文档、重流程的不良倾向，使CMMI实施时更加关注组织的实际价值、关注客户、关注创新。

需求明确，技术明确的简单项目，用传统模式管理，套用CMMI模型，成熟、没大毛病，而且效率还会更高一些。部分复杂和复杂的可以使用敏捷，拥抱变更，需求边做边涌现，于是不断进行改进，会比使用传统项目管理更灵活一些，变更成本和风险都会降低。

谴责CMMI模型不好或者谴责敏捷方法不好，都是片面的，更大程度上是落地方法有问题，是去落地的人的问题。在一个组织内，谁最先发起要导入CMMI与敏捷的呼吁呢？如果是市场的呼吁，那可能侧重的是证书，是投标的需要。如果是开发的呼吁，那可能侧重的是减负，是提高效率的需求。如果是老板的呼吁，那可能侧重的是交付高质量的产品，快速响应市场的需求。对企业而言，对老板而言，要平衡短期利益与长期利益，活下去，活得好，活得久，需要平衡。CMMI与敏捷都不是万能的，都有其适用场景，不能盲目迷信，盲目崇拜，要秉持开放的心态，持续发展的心态，兼收并蓄，取长补短。总之，这两者的目标是一致的，因此要根据实际情况，选择更加适合的方法来达成这个目标，而不是为了方法本身纠结。

CMMI 中提供了一些良好的实践，这些实践中CMMI 过程域和敏捷方法相互帮助，共同实现了对方的目标/理念，这一过程中不但具有 CMMI 的优点也兼具了敏捷方法的优点，比如说：想达到 CMMI 2（已管理级）的 SCRUM（一种迭代式增量软件开发过程）团队在日常工作中需要实施下列过程域：“需求管理”（REQM）、“项目计划”（PP）、“项目监控”（PMC）、“过程和产品质量保证”（PPQA）、“配置管理”（CM）和“度量与分析”。SCRUM 团队在 SCRUM 规划会议期间执行项目计划，在每天的 SCRUM 中执行项目监控，但他们处理积压的订单时需要执行需求管理。很多时候，他们持续交付环境需要一个好的配置管理。此外，他们还需要实施一些 CMMI 3 的过程域，为他们进行审查性会议，使用类似 TFS 和 CollabNat 平台支持他们日常活动，以提供分析标准。然而，CMMI 3 的一个集成项目管理（IPM）却要求 SCRUM 团队改变管道生产方式，放弃纯 SCRUM，这是很难实现的。集成项目管理提供了强大的良好实践过程以帮助团队满足特定项目的几乎所有需求。想象一下，一个利益相关者谁还需要一系列基于模板而编写的特定文档。这类事情本应该由产品所有者来解决，现在 CMMI 却优雅地做到了这一点。

最后再总结一下，CMMI引入敏捷方法，二者共同以最高效和完美的方式达成了本来的共同目标，即解决在软件生产过程中出现的质量低下、进度延迟、预算超支等问题。同时，由于敏捷方法为 CMMI 某个过程域的最佳实践，使得这一过程兼具了 CMMI 可监控度量追踪等优点和敏捷方法成本最小化的同时质量最优化的优点。存在的问题就是，还是存在使用敏捷方法需要让 CMMI 进行妥协的情况。但是，鉴于二者都是为同样的商业目标服务的，这样的妥协显然是十分值得的。

5 Reference

[1] Hillel Glazer, Jeff Dalton, etc. CMMI or Agile: Why Not Embrace Both!. SEI. 2008

[2] CMMI Institute. A Guide to Scrum and CMMI: Improving Agile Performance with CMMI. 2016

[3] CMMI 产品团队, CMMI开发模型，版本 1.3, 2010