再论CMMI和敏捷的对话

 写完上文 《CMM/CMMI的20年和敏捷十年》，想起了我在AgileChina Google Group曾有过一段对话。

起因是有网友这样说道：

1、那些用敏捷去套CMMi、瀑布模型的家伙都是大忽悠，两者根本的假设就不一样，无法融合。这种观点之所以有市场不过是让原有一套人马有安全感和归属感，让他­们支持罢了。 如果后续没真刀实枪的改变思维，只能是照猫画虎。最可悲的是，改进推动者也去相信融合这种鬼话，以为不用伤筋动骨就可以完成团队思维习惯的转变，这违反了热力学­第二定律的（天下没有免费的午餐）。这种不负责任的承诺，是有害的，失败后的失望情绪和预期的落差给敏捷过程蒙上了不白之冤。

我不赞同上述说法，就回复了如下的文字。

------回复开始-------

2001年，M.Paulk发表《Extreme programming from a CMM perspective》深入地探讨了为何这两种方法并非绝对冲突，并阐述了一个开发小组如何在遵循极限编程原则的同时拥抱CMM第3级。在第3级中，两种方法都可以衍生出不同的措施。

2003年，Boehm and Turner发表《Using Risk to Balance agile and Plan Driven Methods. Computer, IEEE Computer Society》强调不但要平衡地应用这两种方法相关的措施，而且要知道如何正确地应用才能显著改进组织的开发过程。
2008年11月 SEI发布了名为《CMMI® or Agile:Why Not Embrace Both!》的报告，作者是如下5位：Hillel Glazer,Jeff Dalton,  David Anderson,  Mike Konrad, Sandy Shrum。

<http://www.infoq.com/news/2006/11/case-for-agile-cmmi5> Scrum and CMMI Level 5: The Magic Potion for Code  Warriors.

<http://jeffsutherland.com/scrum/2006/11/scrum-supports-cmmi-level-5.html>   这是Jeff Sutherland为第1作者的文章。

2008年7月，Cindy Shelton（CSM，CSP）在Scrum Alliance发表《Agile and CMMI: Better Together》， Much has been written to map the Capability Maturity Model (CMM) to agile practices that clearly indicate the synergy between the two.  Educating ourselves on CMMI process areas, maturity levels and being able to  help transition between agile and CMMI is clearly in our best interest.

2009年3月，Neil Potter（CSM， CHMCLA） and Mary Sakry（CHMCLA）发表《一起实施Scrum(Agiel)和CMMI》，文章总结说“Scrum is a good implementation for some of the practices in Level 2. Therefore, a group can use Scrum and CMMI together, All the remaining practices in Level2 and 3 can be implemented while using Scrum”。
Neil Potter and Mary Sakry，Implementing Scrum(Agile) and CMMI Together, URL：http://www.itmpi.org/assets/base/images/itmpi/Potter-ScrumCMMI.pdf  2009年3月

2010年8月，Paul E. McMahon出版了新书《Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement》

以上列举了多位“大忽悠”。

按CMM/CMMI改进主要分成2种做法:1,为了评级  2，为了切实的改进。

在批评CMM、CMMI时，所举的例子往往是来自于为了评级的CMM/CMMI, 比如补充制作长篇的文档，补充甚至于伪造证据，安排莫名奇妙的人员担当EPG和SQA or QA，评估结束后所有规程都扔到一边，6月内一定要过级，不问真正的目的，把其他地方的全套规程、模板拿来直接使用等等。

而为了切实改进的组织 并没有上述负面例子。

CMM1.0、1.1时，CMM全文中的管控做法是比较明显的，CMM的起源就是美国国防部评价、管理其供应商的，从起源上对比CMM和敏捷，确实是来自两个相­反的方向。
CMM升级到CMMI，CMMI最新版本是CMMI V1.3，是去年11月发布的。在SEI的网站上可以免费下。
CMMI V1.3 较之原CMM，时间上已经过去了19年，内容上已经改变了很多了。由它起源所带来的在管控方面的痕迹已经很淡很淡了。

从CMMI本身看，也可以大致分为两类看法：
1，把CMMI2级到5级看成是一个整体，把按CMMI模型改进等同于按CMMI5来改进。
2，把CMMI各个级别分开来看

CMMI4、5所应对的场景是追求很高质量的，按我的理解，其对应的质量要求是关乎于人的生命（要么救人，要么杀人）。没有这样高的质量要求并配之于相应的成本­投入，按CMMI45来搞，那与敏捷肯定是背道而驰。
把CMMI各个级别分开来看，就灵活了。在CMMI连续型表示法下，可以选择过程域来进行改进。

具体到实践层面而言，CMMI2、3级一共有18个过程域，提供得更为全面一些，软件组织中碰到的问题大都能在CMMI中找到。

Agile对具体的实践提供得更为细节一些。
在面临问题解决问题时，无论在CMMI中寻求解决方法，还是从Agile中寻求，也许可能要混合敏捷和CMMI中的实践来解决，只要适合组织能解决问题，都是合适的。
这时是不必追究CMMI和敏捷是否可以融合的。

CMMIV1.3 for DEV 全文共468页，认为它能融合Agile也好，认为它不能融合Agile也好，它就在SEI的网站上公开。
按照或者不按照CMMI，试图摆脱作坊式软件开发的组织的具体实践总会有不少符合CMMI的某些过程域的某些实践。

而在读Agile之外，读读CMMI V1.3，明显有如下好处：
1，看看CMMI是说什么，有没有什么值得借鉴的地方？
2，寻找CMMI中不合理的地方，能更有理有据的批评CMMI，碰到有人说CMMI能融合敏捷时，如果是赞成的，可以有共同语言；如果是反对的，就举出CMMI­与敏捷冲突的18个甚至更多地方，第1、第2、第3...入木三分的深刻反驳这些个“大忽悠”。

----回复结束-------
 网友看到以上后，回复如下：

好吧， 我疏忽了，你说得很对。 我应当加上一个限定词：中国特色的CMMi与敏捷是不能相容的。

要问我什么是中国特色？   很多，最明显的就是受评估团队在通过认证后不久，就原地解散，分散到各个团队去，然后宣称整个组织都CMMi了。
反例有木有？   统计比例有木有？

现实的问题就是， CMMi已经被强奸了， 在这个基础上谈与敏捷的融合， 本来就是无源之水。
而且，上CMMi的目的是为了认证准入的利益，效率神马的谁关注？企业应用开发可以有领导照着，互联网行业这样搞就是脑残。
如果国内哪家互联网公司成天嚷着上CMMi，我建议尽快减持其股票。

----回复结束-----

      以下是笔者的点评。  

        CMMI和敏捷的话题是个老话题了，一般是难以达成共识的。敏捷十年、CMMI20年之际难免讨论到这个话题。

提议无论赞成什么，反对什么，都要有敏捷的mindset， 开放的，拥抱变化的，敢于尝试的。

现在中国政府对于CMMI的资助在大部分地区已经结束了。这个资助是有前文所述的中国特色的。

没有了这个资助之后，可以有更平和的心态来看待CMMI和敏捷了。 对于具体企业来说，那就都是可供参考、借鉴的。