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

记得在JavaEye曾经有过关于敏捷与CMM之间的激烈讨论，但讨论后似乎没有谁认为对方已经说服了自己。因为我没有CMM方面的实际经验，我对CMM的了解仅限于教材、SEI网站上的电子文档和各个论坛的讨论，我只能作壁上观。不过那时我有一种朦朦胧胧的感觉：敏捷与CMM似乎并不是绝对对立的，但我无法说清楚为什么。

在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网站上提供的材料保持一致，需要各位朋友鉴别。

翻译的不错，再次证明scrum的那些人在走骗人骗钱不务实的cmm的老路。
别的不说，如果单纯的把cmmi看作一个学说，那么跟agile结合起来并没啥不行。但是cmmi是一个标准，并且还有评估的规模和编制化的流程。如果你仅仅去说我也达到了cmmi所提出的目标，而没有实现cmmi所要求的实践，那么后果是啥你可以去问问主任。
文章中很多类似的漏洞（其实很多国内的人士在说cmmi如何跟agile不矛盾的时候，也都是这样说的），原因究竟是他们不懂cmmi，还是不懂agile，还是故意隐瞒，就不好说了。不过就我看到最近在搞scrum的那些的人的说法，我认为scrum绝对是一个新的泡泡。

很感谢你的回复！

说实话，我很期望看到你的回复，又有点怕看到你的回复，因为就我了解，你是坚定的agile支持者和CMMI反对者。而我还在学习，还没有坚定自己的立场。 如文中所说，翻译这篇文章只是想看看能否给大家一点启发。其实，我自己也觉得这篇文章还是有些空洞，缺乏具体的实例或可操作的指南来说明两者如何结合。

你提到“文章中很多类似的漏洞”，能否花点时间给大家指出来？我很希望自己能比较全面地理解文章中提出的观点，包括正面地和反面地理解它

另外，我不知道scrum是否在走cmm的老路，不过我自己就只看到这样一篇尝试把agile和cmm联系起来的文章（文章中给出的另两份参考资料中可能有一些内容，我没看），而且文章也没提到scrum。

CMMI是过程改进的
agile也是过程改进的
感觉ＣＭＭＩ偏重收集客观数据（所以成本高）来分析进行改进
而agile偏重人员主观判断随时改进（有自发自觉的意思）
从思想上说应该是相互矛盾的。
如果两者都用，怕是两方面都做不好吧？

〉 海纳百川，所有的这些东东某种程度上都可以在某个方面为我所用。。。
〉 每种理论、框架都尤其存在的前提、环境、文化、背景、局限、缺点。

好伟光正啊，您还是做政治这份有前途的工作吧，
不要跟我们程序员抢饭碗了。

sei的人也在考虑如何结合，看附件
http://www.sei.cmu.edu/cmmi/adoption/pdf/dutton.pdf
我也鄙视认证，但是这就是生活，有证，你就好混，没有就不好混。
CMMI整个体系是比较完善的，我觉得证书拿到以后，就可以结合敏捷的思路逐步实施自己的过程。

其实大家的讨论都很有局限性，因为我们的很多甚至是全部理论都是从大洋彼岸学习过来的。所以很多时候的讨论我们都是空洞的使用一种理论加以自己的理解之后去反对另外一个理论。其实这些理论都似乎针对某种特定case的一个解决方法，而我们所因该讨论不是那种解决方法就是真理，而是针对于某个case那种解决方法更加适合。

说的对

其实同很多人对我的看法相反，我是agile不坚定的支持者（至少最近对agile社区中的很多态度持否定态度），cmmi的不坚定反对者。
这篇文章中漏洞很多，其中主要集中在对cmmi的内容的曲解上——也就是说作者通过曲解cmmi的内容，将部分当作整体，将过程当作结论，以拉近同agile的距离。而具体的例子，我觉得还是你自己去研读cmmi的1.2版本，看看cmmi的结构和内容究竟是什么。
实际上就cmmi这个系统来说，自身存在巨大的内在漏洞。我们知道cmmi号称是一个标准，用于评估开发过程的标准，那么他就必须提供一套评估的方法和具体的指标。而依照我们的直觉反应，既然是标准应该更多的体现其中立于具体方法，也就是说cmmi应该提供的是希望达成的目标，而不是告诉你如何达成这个目标。当然就标准这个东西来说，也确实存在一些目标和手段都包括在内的标准，比如药品和医疗领域。但是这时其主要考虑是能够建立起一套第三方利益者的监督方式，从而保证其从过程到结果的合法性，以分担生死攸关的责任。也就是说这样的情况出现，往往是由于如果不借助第三方的力量，双方当事人根本就无法在实际中达成妥协。你可以进一步理解为什么药品的售价要大大高于其生产成本，其中一个很重要的因素就是你买到的不仅仅是药品，同时也买到的是药品背后的生产和销售流程。而就软件来说，客户其实根本就没有关心流程的需求，同时也没有实现关心的这个能力。而SEI试图担当起政府的角色，显然是自不量力，即便DoD给了他们授权，这个职责也仅仅是小范围的。
而进一步说由于cmmi是关注的流程，那么其单独仅仅给出一个指标系统来衡量过程的成熟度是否可行，也是一个值得探讨的问题。比如我仅仅是要求你建立和维护项目计划的估计数量是不是就已经足够（这个是一个SG），还需要不需要进一步检查你：建立和维护一个顶级的任务分解结构用以对项目的范围进行估计；建立并文档化对工作产品和任务的属性的估计数据；依据计划的工程量的范围定义项目的生命周期阶段；根据估计原理，对项目的工作产品和任务的属性所需要的工作量和费用进行估计——这几个具体的实践。是否你已经认识到由于这几个实践的存在，造成对于项目的理论框架和管理框架已经被绑定在一种单一的学术派别上。另外你是否意识到，在某些场景下会存在这些实践的实施恰恰可能带来对于实现其本来目标的背离。其次你是否认识到，是否存在另外一些可能更加便宜以及更加合乎要求的实践以替代这些实践（sp）。而这里存在太多的标准理论的难点。而同时把cmmi和agile结合，到底是说agile是可以到达这些关注点，还是说agile已经完成了这些实践，这也是一个问题。
以上我仅仅是从标准理论的角度简单说了这个文章的一个漏洞。如果我们进一步结合实际会发现更多的问题。
至于关于scrum的问题，我想还是等一段时间再说，免得在这个时间给robbin找麻烦。我不想再整出个啥scrum李刚来。

我知道很多人看不惯我的行事风格和说话的方式，但是如果他们能够真正的静下心来看看我究竟说了些什么，要是能跟我一样真正化那么多时间要学习cmmi和psp/tsp上会有收获的多。

最佳实践比方法论更重要，方法论是学者为了使自己在浩瀚的软件工程历史上打上自己的印记，于是就搞出了XX的方法论。纯粹是为了学术上的价值，为了出名。如果仅仅停留在某个方法论应用这个级别上，应该还说是处在低级模仿阶段。反过来，如果理解了这些方法论带来的最佳实践，就可以在实际情形下，决定使用哪些最佳实践。是无招胜有招的境界。
就像Scrum的产品负责人，每日站立会议以及燃尽图这些最佳实践完全可以应用到xp里，是不冲突的。过于教条的依赖于某个方法论，就是教条。
回头再说CMMI和敏捷，我觉得两个概念应该是正交的，没有什么关联。CMMI唯一需要的组件是必要组件，一般就是指目标。
达到目标可能有很多种方式，这些实践在CMMI里成为期望组件。我觉得可以用敏捷的实践来代替CMMI规定的实践，来实现同样的目标。