在Scrum Alliance的网站上看到Cindy Shelton写的一篇文章：Agile and CMMI: Better Together（http://www.scrumalliance.org/articles/100-agile-and-cmmi-better-together）。文章中的观点让我有些共鸣，所以不辞冒昧，翻译了出来，希望能给大家一点启发。

因为自己的英语水平有限，翻译的过程中深感不易。原文中许多习惯用语没找到非常贴切的中文说法，某些段落的上下文也不容易理解。许多地方我按照自己的理解进行了意译，但我有点担心是否正确地表达了原文的意思，因此有兴趣对这篇文章深入了解的朋友请阅读原文。

敏捷与CMMI：双剑合璧，更具威力！

在追求卓越的过程中，组织会尝试多种途经，采用不同的原则、方法及技术。一个对敏捷实践感兴趣的组织可能也会对PMI的OPM3、ISO或能力成熟度模型集成（CMMI）感兴趣，因为这些都是通向卓越的手段。不过，我曾经看到一些组织同时尝试敏捷和PMI模型，但没有谁成功。实际上，去年我观察了两个很大的公司，它们主动在公司内同时采用敏捷与CMMI。在两家公司里，分别实施这两种方法的两个小组都把对方当作竞争对手，这令这两家公司严重受挫。（译注1）其实没必要这样子。CMMI与敏捷框架至少能够而且应该和平共处，甚至可能协同工作 - 我知道这对你们许多人来说是一种震动。

许多人认为敏捷与CMMI是极端对立的，彼此抵消对方的成效。在传统方式与敏捷框架之间一直持续的论战中，各自的支持者纷纷列举出与对方水火不容的观点。但是这种对抗的态度不但毫无道理，也会对我们的工作-在尽可能短的时间内开发出高质量的软件-产生妨碍。想要获得最好的投资收益，最好是创建一组混合模型和方法，选择合适的技术来应对特定的挑战。

CMMI回顾

能力成熟度模型集成（CMMI）（注1）是一个过程改进方法，它为组织提供了实现高效的过程所必需的基本元素。它可以用来指导一个项目、一个部门甚至整个组织的过程改进。CMMI能帮助我们整合以往各自为政的组织功能，建立过程改进的目标与优先级，指导我们进行质量改进，还提供了评价现有过程的参照点。

有趣的是，创建CMMI的初衷是为了应付一些软件开发相关的问题，而提出敏捷实践也是为了解决这些问题。在80年代早期，在SEI的资助下美国空军成立了一项研究来分析为什么许多软件合同都会超出工期和预算。他们的结论是：糟糕的过程。而另一方面，承包商认为无法按照预定的工期和预算完成合同的原因在于需求不断变更。研究中，为了在软件开发生命周期的后期应付这些变更而不增加返工，一个小组试图建立更多的过程，而另一个小组尝试应用不同的方法。这项研究一直持续到1998年，这一年，作为CMMI的补充，TSP诞生了。针对CMMI提出的“需要做什么”的目标，TSP指导团队“如何去做”，这加快了它的普及。但很多人忽视了敏捷实践也能指导我们“如何去做”。

对新一代的敏捷实践者来说，CMMI似乎太臃肿、太枯燥、太缺乏创造性了。有人批评CMMI太官僚，过于关注过程而不是问题本身，削弱了应付日益严峻的需求变更的能力。同样，也有人批评敏捷对开发过程控制不力，导致隐性的变更和混乱。

批评者还声称在CMMI提出的经典工程方法中，一些令项目成功的人类认知能力、组织及文化等方面的基本要素都没有考虑到。对于这些批评者（也是敏捷实践者）来说，从装配线式的过程模型中解脱出来，关注人与人的交流就是一种进步。Paulk (2001)（注2）更深入地探讨了为何这两种方法并非绝对冲突，并阐述了一个开发小组如何在遵循极限编程原则的同时拥抱CMM第3级。在第3级中，两种方法都可以衍生出不同的措施。Boehm and Turner（注3）强调不但要平衡地应用这两种方法相关的措施，而且要知道如何正确地应用才能显著改进组织的开发过程。

CMMi提出，在组织中必须建立开发过程，必须采用同行评审来提高质量，必须有版本控制系统。如果我们发现一个跨国公司至今仍缺乏这些基本的“常识性”的控制手段，肯定不只我一个人会感到震惊和失望。如果能合理地应用两种方法中的原则、方法及技术，我们不至于陷入两难的境地。然而，要在现有的成熟度级别上同时应用敏捷，以及为敏捷团队找到最佳的成熟度级别都会是挑战。

实施敏捷的最佳时机

一项敏捷实践应该经过裁剪以适应组织实际的成熟度级别；特别是，如果组织的成熟度处于CMMI第3级，实施敏捷不但可以获得敏捷带来的重要好处，还可以减少返工，并全面提高推行CMMI的积极性。如果实施的软件开发过程既能遵循CMMI规范，又能符合敏捷原则，我们就可以真正获得CMMI提出的可重复性和可预测性的好处。敏捷特意设计得非常灵活，因此它可以在不违反敏捷宣言所规定的主要目标的前提下，裁剪为遵循CMMI规范的软件开发过程。

当成熟度处于CMMI第3级，组织应该已经选定了适合团队及环境的过程，这些过程主要关注如何交付可正常运行的软件。此外，针对特定的项目，还要从组织的标准过程集中裁剪出相应的标准、过程描述及流程。因此，实施敏捷的主要工作就是为集成敏捷实践而修改那些标准过程。实施敏捷的风险集中在管理开销上，因为组织的管理模式可能会限制团队的自主决策权及灵活性。

在CMMI第3级上实施敏捷的挑战

如果成熟度未达CMMi第3级，说明组织缺乏稳定的项目管理、需求分析及配置管理相关的过程。正因为企业各个方面都缺乏训练，要实施敏捷还得提供缺失的软件开发过程。如果组织的成熟度未达CMMI第2级，过程常常会因为人为原因或外来事件而被迫改变。在这样的环境中，敏捷项目可能会成功，但成功的经验不见得能重用。如果组织没有一种稳定的环境，可能是因为组织还不清楚建立这样的环境需要哪些东西。这导致成功依赖于个人的专业知识、能力及英雄主义，而这些成效却可能被团队的其它因素抵消。

CMMI第2级中的一些过程号称是可重复的，然而它们未必能在组织的所有项目中重用。实施敏捷实践和度量可以为组织提供达到CMMI第3级所需的管理架构和训练。在这一级，尽管实施敏捷可能导致成本增加，但也能获得与单独实施同样的好处。通过使用Burndown图和任务板，敏捷进度跟踪让组织很容易看到这种训练的效果，从而加快采用它的速度。敏捷框架的总体思想、方法及实践自然地解决了CMMI第2级的时间和成本超支的风险，能明显缩短提升到第3级的时间。我曾经成功地通过实施敏捷把成熟度级别从0提升到第2级，提高了客户满意度，最终达到了预期的效果。

如果组织的成熟度高于第3级，流程已经基本可以在组织内通用了。这种情况下除非大幅改动那些在CMMI第4级中必需的成文的流程，否则敏捷所带来的灵活性将非常有限。其实，管理层希望能迅速找到合适的度量来控制项目的成本、进度与范围，而敏捷项目的进度已经是可视的，这与管理层的意图已经非常吻合了。此外，成熟度第3级与第4级之间的一个重大差别就是采用某组过程后的效果的可预测性：对于后者来说，过程的效果是通过统计及其它量化技术来控制的，可定量地预测。所以现在我还没兴趣在成熟度已达CMMI第4级的组织中推行敏捷。

结论

至此已经写了够多的内容来讲明CMM与敏捷实践之间的关系和协作效果。为了取得最好的效果，学习CMMI的各个过程域、各个成熟度级别并掌握如何在敏捷与CMMI之间过渡的能力非常重要。

注：

1. 为了尽可能地准确，大多数关于CMMi的材料是从软件工程研究所（SEI）的网站（http://www.sei.cmu.edu/cmmi/）上照搬的。（译注2）其它来源的材料则单独说明。

2. Paulk, 2001. M. Paulk, Extreme programming from a CMM perspective. IEEE Software 18 6 (2001), pp. 1–8.

3. Boehm, B. and R. Turner (2003). Using Risk to Balance agile and Plan Driven Methods. Computer, IEEE Computer Society.

译注：

1. 该句原文是I left both organizations frustrated.，我认为句首的I是It的笔误。因为我不是Scrum Alliance的会员，我没法跟帖或发邮件给作者求证。

2. 经过我的翻译，这些材料是否还能与SEI网站上提供的材料保持一致，需要各位朋友鉴别。