雖然把CMMI和敏捷類的開發方法放在一起比較，尤其是做出“取舍”，已被業(ye) 界證明為(wei) 是完全沒有必要，也是不正確的，但就兩(liang) 者如何互相配合，共同發揮作用，目前還是相關(guan) 企業(ye) 比較關(guan) 注的問題。站在不同的出發點看，當前主要有兩(liang) 類場景，一是原來較多使用敏捷開發的企業(ye) ，如何使用CMMI去更好的實現敏捷的價(jia) 值和規模化，二是原來比較少使用敏捷開發的企業(ye) ，根據業(ye) 務的需要導入敏捷方法，該如何利用CMMI實現敏捷開發理念和方法的導入。但無論哪一種情況，了解CMMI在敏捷開發中是如何發揮作用的都非常必要。

CMMI強調過程，專(zhuan) 注於(yu) 不斷改善過程性能，提高過程能力，適應業(ye) 務需要。CMMI模型在內(nei) 容組織上，將一個(ge) 組織的能力（Capability）分為(wei) 執行（DOING）、管理（Managing）、賦能（Enabling） 和改進（Improving）四個(ge) 大的能力板塊，包含12個(ge) 能力域（Capability Area），能力域下再劃分實踐域（Practice Area）以及更加細分的實踐組（Practice Group）和實踐（Practice）。在這個(ge) 強大的結構中，組織的各方麵的過程要求都得到全麵的體(ti) 現。例如，在CMMI看來，每個(ge) 組織都需要有“保證質量（Ensuring Quality)”的能力，其中，需求開發與(yu) 管理是一個(ge) 重要的實踐領域，組織除了需要定義(yi) 如何開發和管理產(chan) 品/服務需求之外，還要考慮圍繞這個(ge) 需求過程的一係列用於(yu) 保障、支持和持續改進的其他過程，這樣的過程要求才是全麵的。

另外，CMMI表述的是要求（WHAT），而不是具體(ti) 的方法（HOW），敏捷方法是一種“HOW”，也可能有其他的方法。不要誤會(hui) ，CMMI模型中其實有大量的關(guan) 於(yu) “HOW”的內(nei) 容，例如所謂的“說明性內(nei) 容”（Explanatory)以及“背景”（Context），Agile with SCRUM就是第一種加進去CMMI模型裏的方法類Context，即在基於(yu) SCRUM的敏捷的環境中，如何理解並應用某一個(ge) CMMI實踐域的內(nei) 容。這些“HOW”的內(nei) 容，要麽(me) 通過大量的例子解釋說明實踐的要求，要麽(me) 比較係統的介紹在某一種環境下的CMMI實踐要求。相對於(yu) 實踐（Practice），目標（Intent）和價(jia) 值（Value）這幾個(ge) CMMI模型要素來說，都不是核心要求，但在理解和使用模型時很有用。

敏捷開發方法，實際上是一係列的方法和技術的集合（例如SCRUM），它強調人的因素（例如自我激勵的開發團隊，團隊內(nei) 部，團隊與(yu) 客戶之間的高效溝通），利用小規模的頻繁的交付，提高開發的效率和客戶滿意度。與(yu) CMMI比較，敏捷方法比較專(zhuan) 注於(yu) HOW。

CMMI如何增強敏捷開發呢？

首先，CMMI明確了組織級應該未敏捷開發提供的支持和保障能力要求。先看下圖，是業(ye) 界做的一個(ge) 關(guan) 於(yu) 敏捷方法現狀的調查中關(guan) 於(yu) 目前企業(ye) 應用敏捷方法麵臨(lin) 的主要挑戰的結果：

根據這個(ge) 調查的反饋，排在前麵的幾個(ge) 主要挑戰是：

●流程和實踐的不一致

●敏捷價(jia) 值觀與(yu) 企業(ye) 文化衝(chong) 突

●組織層麵對變更（Change）的抵觸

●缺乏敏捷方法的技能和經驗

●缺乏管理層的參與(yu)

●來自管理層的支持和資助不足

這些挑戰，以及其他沒有列出的其他挑戰，其實都是CMMI模型中的改進（Improving）類能力域關(guan) 注的問題。例如：

●治理（GOV）強調管理者在過程體(ti) 係的製定和改進過程中的主導發起、參與(yu) 和支持的職責。

●實施基礎（II）強調流程得以持久實施的所需的基礎條件，例如充足的資源、準確完整的流程描述、實施經驗的收集和分享、足夠的培訓等等。

●管理性能和度量（MPM）強調組織的度量能力，以及基於(yu) 度量對過程性能進行管理的能力

●過程資產(chan) 開發（PAD）專(zhuan) 注於(yu) 提煉最佳實踐並建立組織的標準、過程、方法和指南等，確保正確的方法以及成功的經驗在組織層麵得到推廣和使用。

●過程管理（PCM）專(zhuan) 注於(yu) 過程改進，包括如何管理新的技術和方法（例如敏捷方法）的導入和管理。

●組織級培訓（OT）確保擔任不同標準流程（包括敏捷開發）角色的員工，其培訓需求得以識別從(cong) 而勝任其角色和崗位等等。

按照這些CMMI的實踐域要求，組織可以為(wei) 敏捷開發提供的組織層麵的保障和支持環境。

其次，在CMMI的每一個(ge) 實踐域層麵，特別是工程和管理方麵的實踐，可以直接給敏捷方法提供支持。不可否認的是，目前敏捷方法在支持大型的、複雜的項目方麵還是麵臨(lin) 較大的挑戰的，而這恰恰是CMMI的強項，在敏捷開發的環境中，借鑒CMMI的工程和管理實踐（例如集成項目管理、風險管理，結構化的決(jue) 策分析與(yu) 解決(jue) 等），對當前的敏捷過程進行梳理，就可以完善敏捷開發的過程，進一步強化敏捷的效果，降低其在大型項目中應用時的風險。

例如，敏捷實踐中出於(yu) 快速交付高優(you) 先級需求的考慮，往往形成技術債(zhai) （Technical Debt），這些技術債(zhai) 需要管理，才能確保穩定的持續的，並且高質量的交付。技術債(zhai) 的管理可以用到CMMI模型中的多個(ge) 相關(guan) 實踐：是否應該引入技術債(zhai) ，可以應用技術解決(jue) 方案（TS）/決(jue) 策分析與(yu) 解決(jue) （DAR）中的結構化決(jue) 策相關(guan) 實踐；估算（EST）和計劃（PLANNING）實踐域的時間，支持敏捷小組規劃技術債(zhai) 的解決(jue) ，例如估算技術債(zhai) 帶來的成本、優(you) 先級、獲得相關(guan) 幹係人的共識和承諾，以及具體(ti) 的解決(jue) 計劃（Backlog）；最後，使用風險與(yu) 機會(hui) 管理（RSK）實踐，對技術債(zhai) 的風險進行分析，支持對技術債(zhai) 的決(jue) 策和管理等等。

綜上所述，企業(ye) 可以參考CMMI的框架，建立組織級對敏捷開發的支持和保障，同時根據每個(ge) 實踐域的要求，對敏捷開發的各方麵進行增強，完善過程，控製風險。CMMI模型中的關(guan) 於(yu) SCRUM敏捷有專(zhuan) 門的內(nei) 容（Context），解讀CMMI每個(ge) 實踐域對基於(yu) SCRUM的敏捷開發的支持，有興(xing) 趣的讀者可以參考一下。

以上文章轉載自公眾(zhong) 號《CMMI研究院》

了解更多CMMI認證