?寫完上文 《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和敏捷了。 對于具體企業來說，那就都是可供參考、借鑒的。

總結

以上是生活随笔為你收集整理的再论CMMI和敏捷的对话的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。