論敏捷與CMMI 的異同及敏捷中融合CMMI思想以提高敏捷性能的思路

蔡 泉

（ 沈陽東軟智睿放療技術有限公司，遼寧 沈陽110167）

近二十年來，對于軟件開發(fā)項目的從業(yè)人員來說，CMMI 和敏捷可以說是必須要了解的概念。 CMMI 全稱是Capability Maturity Model Integration，即軟件能力成熟度模型集成，是由美國國防部與卡內基- 梅隆大學和美國國防工業(yè)協會共同開發(fā)和研制的，其目的是幫助軟件企業(yè)對軟件工程過程進行管理和改進，增強開發(fā)與改進能力，從而能按時地、不超預算地開發(fā)出高質量的軟件。 早期國內軟件企業(yè)剛接觸CMMI 時多用來指導瀑布型軟件開發(fā)項目，而隨著互聯網行業(yè)的崛起，敏捷開發(fā)這種側重于構建團隊級能力，以人為核心、迭代、循序漸進的開發(fā)方法越來越受到軟件項目從業(yè)人員的歡迎。

毫無疑問，CMMI 和敏捷開發(fā)是存在很多差異的。 CMMI 把軟件開發(fā)組織的能力成熟度分為了5 個等級， 22 個過程域，通過開發(fā)過程覆蓋的過程域來描述織的成熟度級別達到了什么等級，CMMI 注重的是過程改進和組織成熟度。 而對于近年來的軟件開發(fā)項目而言，市場風向轉變很快，需要及時快速的、階段性的交付產品，這正是敏捷開發(fā)的特性，也是敏捷越來越流行的原因所在。 另一方面，CMMI 中證明滿足過程域的最佳實踐，是從制品和訪談兩個維度進行考察， 有證據即可，并沒有對證據的數量和格式有何具體的要求。 而敏捷則通過價值觀、開發(fā)原則、具體實踐等明確說明了怎樣更快、更好的交付高質量的產品。 綜上所述，CMMI 模告訴我們的是要做什么，而敏捷告訴我們的是要怎么做。

雖然差異明顯，但是敏捷和CMMI 并不是對立的。從本質上來講，CMMI 和敏捷的最終目標是一致的，都是人們?yōu)榱私鉀Q在軟件生產過程中出現的質量低下、進度延遲、預算超支等問題，而產生的標準或過程改進的模型或方法實踐。 做什么和怎么做并不矛盾，比如你知道運動減肥的道理，可以選擇慢跑也可以選擇瑜伽，但是不影響運動減肥的理論正確。

在筆者多年的軟件開發(fā)經驗中，經常遇到有人問“ 如何解決敏捷與CMMI 的沖突”，筆者的回答是，請思考一下，存在沖突是不是有哪里做的不對？CMMI 是否被過度解釋了，敏捷是否被過度簡化了？CMMI 過程域的滿足需要有證據，由于實踐中大家對CMMI 的誤解，很多組織過度準備了證據。 同時，也不是使用了Scrum、Jira 等敏捷工具， 每天組織一下站會就可以稱之為敏捷了。 我們應該以保證項目進度、符合預算，高質量交付項目產品，提高組織的開發(fā)能力為最終目標去使用CMMI 和敏捷思想，它們只是渡河達到彼岸的舟船。

隨著軟件行業(yè)的發(fā)展，需要快速迭代的產品，越來越受到市場的青睞， 很多前沿的互聯網企業(yè)將敏捷應用于開發(fā)過程，同時很多從業(yè)人員也都在思考如何提高敏捷性能。 筆者在多年的軟件開發(fā)經驗中經常接觸敏捷和CMMI 的概念， 那么在敏捷中應用CMMI 的思想來提高敏捷性能是否是一種可行的手段呢？筆者認為，這是完全可行的。其實敏捷與CMMI 存在著很多共性的東西，例如對于配置管理的高要求，提倡頭腦風暴等。

下面我們著重從幾方面論述一下敏捷中融合CMMI 思想并提高敏捷性能的思路：

1 敏捷開發(fā)項目初期通過融合CMMI 思想進行項目過程定義

CMMI 強調通過規(guī)范的流程，將人、技術、工具集成在一起，從而產生好的結果，而敏捷開發(fā)宣言中明確提到，能夠工作的軟件勝過完備的文檔。 因此，人們普遍認為CMMI 重視流程，重視文檔，而敏捷開發(fā)輕流程，輕文檔。 其實很多項目的CMMI 實踐中， 往往迷失了目標， 為了規(guī)范而規(guī)范， 恰恰忘了CMMI 的OPD 組織級過程定義過程域中的一個重要活動就是裁剪過程。而敏捷開發(fā)的輕流程、輕文檔并不是沒有流程、沒有文檔，軟件開發(fā)組織完全可以通過大量的敏捷開發(fā)項目實踐，總結出合理的流程， 針對具體的敏捷開發(fā)項目， 融合CMMI 的裁剪過程思想，靈活的配置具體項目的具體流程，編寫剛剛好的文檔即可。這樣通過組織級的經驗總結，為以后新的敏捷開發(fā)項目進行指導，達到提高敏捷開發(fā)性能的目的。

2 敏捷開發(fā)項目通過融合CMMI 思想進行風險控制

CMMI 在項目初期即要引入風險控制， 有專門的RSKM 風險管理過程域對風險控制進行描述。 敏捷開發(fā)同樣會在項目初期使用頭腦風暴的方法預估風險。 那么我們在敏捷項目中，融合CMMI 思想， 使用風險矩陣跟蹤等方式進行風險控制不正是提高敏捷性能的好方案么。 當然敏捷并不需要完全照搬CMMI，CMMI 強調項目初期即要盡量識別出全部風險并進行跟蹤，而敏捷開發(fā)的一大特色就是擁抱變化，強調即使項目末期仍可引入變化，所以敏捷不必追求窮盡風險，我們要借鑒的是先進思想，而不是思想僵化的固定流程。

3 敏捷與CMMI 思想對于需求跟蹤的共性。

CMMI 有REQM 需求管理、RD 需求開發(fā)兩個過程域， 強調在整個項目周期中的需求跟蹤。 而敏捷開發(fā)宣言中，雖然沒有明確提到需求跟蹤，但其實常見的敏捷開發(fā)工具都引入了需求跟蹤的思想。 例如對于迭代前通過對Backlog、Story 的定義，通過整個項目周期對Backlog、Story 的跟蹤來完成整體項目需求跟蹤的目標；例如每個迭代的目標制定、任務拆解，迭代中對任務進度和燃盡圖的看板展示，這也可以認為是每次迭代的“ 需求”理解和跟蹤的實際體現。

4 敏捷開發(fā)項目通過融合CMMI 思想進行成果驗收

CMMI 中存在VAL 確認過程域和VER 驗證過程域，確認是為了證明所提供的產品符合預期的使用需求，而驗證關注的則是工作產品是否恰當地反映了那些被指定了的需求。 簡單的說，驗證確保“ 你把事做對了”，而確認確保“ 你做了對的事”。 在敏捷中，每次迭代結束的成員成果展示和驗收，正是集體進行的驗證環(huán)節(jié)，對開發(fā)人員的工作成果進行驗收。 如果我們進一步引入CMMI 思想，在迭代前的目標制定、任務拆解時，進行確認過程，則能更加提高工作效率，減少返工率，保證項目進度和提高產品質量。

5 敏捷開發(fā)項目通過融合CMMI 思想進行組織級持續(xù)改進

敏捷開發(fā)中，每次迭代結束的總結會，既要展示和驗收每個成員的工作成果，也要總結該次迭代存在的問題，為之后的迭代總結經驗，提供改進建議。這與CMMI 中4、5 級成熟度的持續(xù)改進要求不謀而合， 同時CMMI 中也有MA 測量與分析過程域用于經驗數據的分析與總結。如果我們能夠融合CMMI 思想，在敏捷中，記錄和總結經驗數據，并上升為組織級經驗，在更好的服務于該敏捷項目外，還可以用于組織級經驗積累并指導組織內其他敏捷項目的開發(fā)。

結束語

綜上所述， 本文首先明確了CMMI 和敏捷并不是軟件開發(fā)項目中兩種對立的模型，只是概念抽象層次的不同，而在改善軟件生產過程的最終目標上，它們是殊途同歸的。 之后提出了在敏捷中融合CMMI 思想用以提高敏捷性能的幾點思路， 希望能對讀者有所啟發(fā)，今后在軟件開發(fā)項目中更好的開展工作。