敏捷与CMMI

 转载引言：最近公司在推敏捷，有幸参与了这个推行实践小组，经过一些实践和交流，感觉目前小组已经陷入到了CMMI和敏捷的抉择中。自己也不断思考，如何在CMMI中添加敏捷的元素，让开发过程更加高效、可控，毕竟公司的CMMI的实施在业界也是算非常成功的了。今天有幸看到一下的文章，先收藏起来，作为下面对CMMI与敏捷继承的研究材料吧。

--------------------------------------------------------------------------------------------------------------------------------------

在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之间过渡的能力非常重要。