CMMI 原則和值
作者 David J. Anderson。 David J. Anderson 是兩本書籍的作者：《軟體工程的敏捷式管理：套用條件約束的理想商務結果》[1] (2003 年發行) 和《看板：為您的科技企業展開成功的演進式變革》[2] (2010 年發行)。 他是 1997 年和 1999 年間於新加坡建立敏捷式軟體開發方法、功能導向開發之小組的成員。 他是《2005 年相互依賴宣言》(Declaration of Interdependence, 2005) 中所定義之敏捷式專案管理原則的作者。 David 創立了 MSF for CMMI Process Improvement，他是共同撰寫軟體工程學院《CMMI 或 Agile：何不兩個都接受！》[3] 之＜技術提示＞的其中一位作者，目前擔任 Lean Software & Systems Consortium (http://www.leanssc.org) 的副總裁，並經營一家國際管理訓練和顧問公司 David J.。 Anderson & Associates Inc. (http://www.agilemanagement.net)，可協助科技企業透過較佳的管理原則和決策制定改善其績效。
2012 年 1 月
Anderson 說明透過 CMMI 的觀點審視組織如何為管理員、製程工程師和所有外部專案關係人 (包括客戶、投資者、主管機關和稽核單位) 提供寶貴的深入資訊。
套用至
應用程式生命週期管理; CMMI
Introduction
The Meaning of Organizational Maturity
Inspiration for the CMMI Model
CMMI is a Model
Understanding CMMI Made Simple
CMMI Appraisals
原始 Capability Maturity Model (CMM) 在 1991 年首次發行。 十年之後已演進成「能力成熟度整合模式」(Capability Maturity Model Integration，CMMI)。 CMMI 現在是有三個群集 (Constellation，如實際所稱) 的家族，本文特別提到 CMMI for Development 群集 (CMMI-DEV)。 CMM 開發的目的是協助美國國防部更瞭解在大型政府採購計畫內，因軟體專案失敗而造成的昂貴費用。 根據 CMM 所做的評估已用來判斷政府合約的「適切性」。 日後這會在 CMMI 的基礎上演變為已定義的評鑑計劃。
組織成熟度的概念仍然有爭議。 例如，如何評估組織的成熟度？ 此外，組織的行為是否真的與個人的行為和動作有所區別？ 這個組織可以評估特定成熟度層級的概念，也是一種功能的指標，能夠提供可靠的工作給政府，也是持續爭論的重要因素。 不過，我仍然是 CMMI 的信徒和支持者，而且相信透過 CMMI 的觀點審視組織，可以為管理人員、製程工程師和所有外部專案關係人 (包括客戶、投資者、主管機關和稽核單位) 提供寶貴的深入資訊。
組織成熟度的意義。
CMMI 中的成熟度適合表示用來評定和管理風險的方法與能力，以及進行決策時使用的判斷。 「成熟」一詞的實際用法與描述個人行為的方式相同。 例如，保險公司可能告訴我們，18 歲的男性會比 55 歲的婦女更容易發生車禍。 這位 18 歲的男性可能決定駕駛汽車時展現出較差的判斷力，也可能沒有足夠的經驗去完整地評估採取行動的風險。 這可能會導致 55 歲的女性可以避免的意外。 因為保險公司會收集統計資料和相關聯證據，所以特別擅長於評估風險。
CMMI 的問題在於「成熟度」一詞會讓人感到有貶損的意味，好像成熟度低就比較不優。 而且應該永遠追求更高的成熟度。 如果我們要以個別詞彙考慮這點，就不一定有什麼意義。 保險公司在汽車險上可能對越成熟穩重的人索價越低，但是對開輪式賽車 (Open-wheel Racing) 車隊很可能要估價青春活力和風險承擔。 就賽車小組而言，車禍是這個行業的一部分。 實際上，從未撞車的車手會被炒魷魚。
此處的訊息是所需的成熟度層級應該符合條件和內容。 愈多不一定表示愈好，但是正確地識別和評定組織成熟度的能力，有助於評估企業是否能夠在進行專案和產品決策時，管理風險和發揮適當的判斷力。
成熟度和達到或產生所需結果的可能性之間應該有非常高的相互關係。 高成熟度的組織應該要有非常篤定的勝算，可以交付接近理想結果的成果。 這包括以成熟度和功能評估可能的，可以的和可達到的結果，以及設定適當的目標。 低成熟度的組織不太可能設定可達成的目標，而且比較不容易交付符合預期的理想結果。 硬幣的反面是成熟度較高的組織可能變成風險規避及只設定輕鬆可達到的目標，而低成熟度的組織可能要靠運氣及辛苦工作才能有預期的表現。
CMMI 模型的啟示
原始 CMM 是由 Watts Humphrey 開發，最先出現 (沒有 CMM 名稱) 在他的 Managing the Software Process[4]書籍。 這是受到 20 世紀製造品質保證運動和 Joseph Juran, W. 著作的啟發。 Edwards Deming 和 Philip Crosby 的著作。 「成熟模式」一詞和其中的五個層級由 Crosby 的製造業成熟模式啟發。 不過，您必須將 CMM 當做真正的統合概念看待。 「功能」這個詞彙幾乎確定是受到 Deming 的啟發。
Deming 使用「能力」(Capability) 一詞非常特殊，深藏的意義可能無法用一般話語來解釋。 較正確地說，「能力」可以視為系統或系統內作業的「自然哲學」。 Deming 鼓勵經理人「研究能力」並以統計方式進行分析。 他發展了他的「淵博知識體系」(System of Profound Knowledge)[5]，這個系統適合用來做為決策架構以協助管理人員行適當的系統設計介入。 Deming 是正宗的系統思想家。 在這種情況下，「系統」這個字意指人員執行的流程。 沒有暗示技術或任何自動化的意圖。
Deming 認為 (而且其所匯集的證據也顯示) 系統效能差不多有 95% 來自系統的設計，並非來自工作於該系統內之個人的能力。 換句話說，若要產生改善，就必須著重於變更流程 (即人員工作所在的系統)，而非關注個人績效的改善。 因此，他不支持目標、目標管理、誘發性海報或懲罰績效不佳的個人。
因此 Deming 在他的 System of Profound Knowledge 提供一個能力模型，而 Crosby 也提供了 成熟模型。 Humphrey 企圖將這些概念綜合在一起並運用在軟體工程領域，結果產生「能力成熟度模型」(Capability Maturity Model)。
有鑑於評估與追求成熟度層級以取得政府合約資格的重點，「能力模型」和 Deming 的影響多半從 CMM 和 CMMI 的許多相關文獻中消失。 不過，Deming 的影響在較高成熟度等級上定義的流程區域中還是清晰可見。
CMMI 一向是鼓勵在組織內彰顯進行持續改善之文化特性的架構，而且永遠標榜系統考量方法。 CMMI 的根目錄有明顯與 Lean 相似的項目。
CMMI 是一種模型
CMMI 是了解組織成熟度和功能的模型。 這不是標準，也不是軟體開發或專案管理流程定義。 本文所述的一般作法是參考這個處理功能且沒有提供任何特定專案或開發下的產品。 例如，只要下表中提到計劃，就是指流程實作的計劃，而不是任何專案或產品交付項目的計劃。
CMMI 模型包含 22 個流程區域，再加上所有組織都期望達成的 3 個一般目標。
3 個一般目標如下：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
22 個流程區域會分成 4 類:技術工程、專案管理、流程管理和支援。 每個流程區域包含一至三個特定目標和所有的三個一般目標。 對於每個目標，需要一些通用的做法，使該目標可以實現。 在實作中，可能有建議的子作法 CMMI 只需要或規定目標。 CMMI 模型內的目標所定義的作法是預期的，但非強制。 如果不存在，就必須以相當的替代作法來取代這些作法。 下表顯示將流程區域的分組。
組織重點 |
流程區域 |
|---|---|
精心設計 |
需求開發 技術方案 產品整合 驗證 驗證 |
專案管理 |
專案規劃 專案監控 整合式專案管理 供應商合約管理 需求管理 風險管理 量化專案管理。 |
流程管理 |
組織流程重點 組織流程定義 組織訓練 組織流程效能 組織創新與部署 |
支援 |
組態管理 流程與產品品質保證 測量與分析 決策分析與解決 原因分析與解決 |
因此這個原則很簡單：如果組織能夠展現能力來完成每個流程區域內的目標，則他們可以被認定具備該特定流程區域內的能能力。
流程區域也分成成熟度層級，用來提供可以描述成熟度的簡略方法。 雖然將流程區域群組成各個層級在許多層級上仍然有爭議，我在過去二十年間對各組織的觀察是現行的 1.3 版模型 (就 CMMI 實際上是 CMM 的第 2 版來說) 廣泛而言是正確的。 低成熟度、混沌的組織通常先在成熟度等級 2 中定義的流程區域上發展能力，然後才會發展以更高等級定義之流程區域中的能力。
下表顯示將流程區域分組成層級。
成熟度等級 |
流程區域 |
|---|---|
5 |
CAR - 原因分析與解決 OPM：組織績效管理 |
4 |
OPP - 組織流程效能 QPM - 量化專案管理。 |
3 |
RD：需求開發 TS - 技術方案 PI - 產品整合 VER - 驗證 VAL - 驗證 IPM - 整合式專案管理 RSKM - 風險管理 OPF - 組織流程重點 OPD - 組織流程定義 OT - 組織訓練 DAR - 決策分析與解決 流程與產品品質保證 |
2 |
CM - 組態管理 MA - 測量與分析 SAM - 供應商合約管理 PP - 專案規劃 PMC - 專案監控 RM - 需求管理 |
1 |
模型層級 1 中沒有流程區域。 層級 1 表示未定義的流程，沒有任何可透過了解產生結果之流程來定義流程或重現結果的內省或能力。 技術上來說，在 CMMI 評估中，不符合模型層級 2 的流程區域中訂定目標組織仍然是模型層級 1。 因此採用新興流程的組織技術上將會被視為模型層級 1，即便他們比起過去的混亂已有大幅的成熟。 |
下表顯示的是每個流程區域主旨或目的置放詞彙的總覽:
流程區域 |
用途 |
|---|---|
CAR - 原因分析與解決 |
調查例外處理問題的根本原因 (各種形式的特殊原因，要使用 W. Edwards Deming 的詞彙)，並建議和實作流程變更以避免再次發生。 注意力會轉向以數量表示之穩定流程上的不尋常行為。 每天的意外事項或許可以視為風險管理 (RSKM) 而非 CAR 的一部分。 |
組態管理 |
不只是原始程式碼版本控制，這個流程區域涵蓋所有與系統環境、元件組態、平台、中介軟體、應用程式及文件相關的管理。 能夠成功地在這個流程區域中建置和部署工作程式碼。 |
DAR - 決策分析與解決 |
對於專案或產品開發中的所有重要決定，表示已考量一組替代方法或選項，以及已使用內容項目來評定不同選項適合與否。 記錄決策和抉擇的原因。 |
IPM - 整合式專案管理 |
CMMI 模型中的這個第二層專案管理表示組織有能力同時管理多個可能相依的專案。 這通常可透過使用程式或專案組合管理辦公室達成。 |
MA - 測量與分析 |
收集處理序、專案和產品效能的資料。 根據資料產生報表形式的度量和指標。 |
OPD - 組織流程定義 |
組織應該具備內容中定義的一或多個流程定義。 內容將會說明風險概況。 每個專案的風險都可以進行評估，並針對個別專案從組織目錄中選取流程定義，然後進行適當設定。 |
OPF - 組織流程重點 |
組織應該相信流程定義會定義及影響功能，以及改善功能主要是透過改良過流程而驅動。 因此，組織會主動管理其流程定義並監視 (使用 PPQA 流程區域) 以確保遵循這些定義。 |
OPM：組織績效管理 |
這個流程區域會封裝對於流程交付預期能力程度的統計了解概念。 變更為預定要改善可加以評估之功能的流程，以及考慮當流程定義已做變更時，是否觀察到的結果無法反映基礎處理模型所預測的那些結果之流程的基礎模型。 組織透過本身流程管理其效能，以便滿足業務需求。 |
OPP - 組織流程效能 |
這個流程區域會封裝效能比較的概念，通常稱為「基準」。OPP 會利用基準資料建立流程模型，以進行比較。 這讓組織能夠回答諸如「我們該選擇哪三個產品小組來負責 [這項特定專案]」之類的問題。 |
組織訓練 |
在特定實務作法中，個人能力對流程效能與系統功能來說是很重要的。 具有強大效能的正常運作系統具備強而有力的訓練能力，可以在本機實務層級上降低功能的變異性。 |
產品整合 |
能夠將多個元件整合成完整產品以及管理需要的項目，讓它變成可能。 |
專案監控 |
收集有關進行中專案的資料，與計畫、投影和模擬相比較，並根據資料採取適當動作。 |
專案規劃 |
根據估計、刺激或需求分析規劃專案。 |
流程與產品品質保證 |
主要是流程符合稽核職務。 預定要示範系統正依照所設計的方式在運作。 在目前流程實際上未依照預定方式進行時，協助避免可能為了更正問題而變更流程的管理錯誤。 |
量化專案管理。 |
這是 CMMI 模型中的第三級專案管理，也是最高層級。 這表示會使用統計學上完備的量化方法來計劃，監視和管理專案。 |
需求開發 |
有明確的重複性流程，用於徵求、協商、分析與記錄需求。 |
需求管理 |
在整個專案生命週期內都會追蹤需求，最好是已交付組態或原始需求要求之間有首尾相承的可追蹤性。 |
風險管理 |
雖然整個 CMMI 模型可以視為管理風險的架構，但是這個流程區域會專門處理「事件驅動風險」或特殊原因變化及日常意外事項的可能性與影響。 這個流程區域需要降低風險、減輕、規劃應變、管理問題和解決方式。 |
供應商合約管理 |
能夠處理外部廠商、訂定協議、處理合約以及輸送需要的產品或服務。 |
技術方案 |
所有與軟體架構、設計和程式碼撰寫有關的必要技能。 |
驗證 |
針對客戶需求的接受度測試。 |
驗證 |
對設計進行測試 (從技術方案)。 尋求確保產品是依照預想和設計所建置，總而言之，要符合使用者的需求而且可在其環境中正常運作。 |
在每個流程區域中，可以評定能力等級。 CMMI 1.3 版中定義的四個能力等級：
0. 未完成
1. 已執行
2. Managed
3. 已定義
如果每個特定目標都已達到且部分一般目標達到，則特定流程區域的能力將會至少評鑑為等級 1：已執行。 能力等級 1 表示小組成員知道要做什麼且正在執行它。 不過，如果以統計方式分析，特定作法就不太可能顯示穩定性。 作法已遵行，但是仍缺乏一致性。 能力等級 2 表示小組了解項目的運作方式，且具有某個等級的技巧讓做法效能可預測並可能展示統計控制。 訓練或共同作業的工作實務很有可能都已安排妥當，可以跨小組成員產生更廣泛的一致性。 能力等級 3 表示精通開發要達成目標之全新或改善技術的技巧和功能。 層級 3 功能表示每當基礎技術或實務作法明確變更之後，所有統計分析都需要重新設定基準。
輕鬆了解 CMMI
因此 CMMI 模型基本上陳述新和未成熟度的組織，一開始將會在開發實務的功能的流程設定和原始檔控制，收集有關專案的資料和工作，規劃專案，追蹤需求，監視專案的進度和採用根據比較實際資料的動作物件配置。 這是成熟度 2 的基本要義。
當成熟度層級 2 功能就緒時，組織及其人員就會將注意力轉移到其他問題，因此定義需求、測試、架構與設計的能力、整合以及定義可重複的流程等問題開始浮現。 當事態逾穩定時，對於文化特性和管理方式影響效能的理解會更為明朗，希望也能進一步領悟提高效能改善所需的系統考量方法。 工作更加穩定、規劃及專案監控等日常問題越來越自然之後，就該考量風險管理，以及在決策之前分析替代方案與選項。 協調多個相依專案，並改善管理可能形成之共用資源的方式。 或許訓練計劃、導師配置、師徒指導配置或只是形式上的協力合作會脫穎而出，可以強化能力並提升整體效能層級。 必要時，某個內部稽核或流程品質保證的職務可能會應運而生。 這整個就是成熟度層級 3 的基本要義。
組織的運作成熟度達層級 3 時，一切都會順利進行。 組識依諾地交付產品，看來是非常地可信賴和可靠。 高度的信任會顯露在與客戶的關聯性之中。 資深管理人員開始提出問題，例如「我應該致力於何處做進一步改善？」和「哪一個小組產生最好的經濟績效所述？」。 管理人員開始培養對能力和績效更深入的洞察力，並了解他們可以使用模擬和統計分析來改善產品品質、客戶交付項目和滿意度。 管理決策現在是完全客觀的，有統計資料可做辯護。 這是成熟度 4 組織的基本要義。 對於大部分資深管理人員，成熟度層級 4 表示他們的理想狀態。 所有事情都像鐘錶一樣規律地進行，他們有相當的效能資料，可以按照承諾以高度的正確性完成交付。 大幅改善經濟效能，並且組織的效能大多可預測。
成熟度等級 5 的行為通常在組織實際達到等級 5 之前很早就已顯露。 根本原因分析在成熟度層級 3 組織比較常見。 層級 5 功能的意義在於是否使用量化資料完成根本原因分析且在統計上是有道理的。 在組織可以真正視為成熟度層級 5 之前，也可能出現創新程序和改良開發的正式化流程。 在層級 5，流程改善已制度化且深植於組織的文化特性中。 文化特性是一個永遠挑戰該狀態並找出已增強功能、改善的產品品質和改進的經濟表現。
CMMI 評鑑
CMMI 成熟度評鑑是由評鑑作業所建立。 有標準的評價執行流程，那就是 SCAMPI - Standard CMMI Appraisal Method for Process Improvement (SCAMPI)。 引進這個以增加處理序的可重複性及結果的可信度。 評鑑的三個嚴密度層級稱為類別 A、B 和 C，類別 A 最嚴格。 等級 A 評鑑對於政府機構或美國國防部的需求可接受的模型層級評等是必要的。
所有的等級 A 評鑑和大部等級 B 與等級 C 評鑑都是由 CMMI 主任評鑑員 (CMMI Lead Appraiser) 執行，這些人員是由軟體工程學院 (Software Engineering Institute) 授權執行評鑑。 這些顧問接受過完整的訓練，才能獲得實作授權。 有些評估人員已通過額外的訓練，並且被指定為 CMMI 高成熟度主任評估人員。 尋求模型等級 4 或 5 評鑑的組織必須與高成熟度主任評鑑員合作。
評鑑作業會搜尋所執行的做法可達到 CMMI 流程區域內之目標的證據。 在執行專案組合且可能有多個業務部門的組織中，會使用複雜的公式判斷必須評估哪一個範圍中的多少個專案。 這目標是確保完整涵蓋了一組用來演示該組識的範例專案，可以在每個必要的流程區域內有個標準化的功能。 首席評估人員會根據公式來決定評估的專案。
在每個評估的專案中，必須收集能夠證明示範作法已完成的證據，在流程區域中顯示足夠的能力。 對於每個實務作法，評鑑員會尋找確實具體的證據，這稱為成品，通常會在書面證據 (例如計畫、原始程式碼、設計和架構文件) 中找到。 此外，他們還會尋找證言。 證言通常只是道聽塗說的根據，例如工作人員談論某個職務的品行，例如參與計劃會議的軼事。 證言是由參與受評估專案的採訪人員所收集。 證言可以強化或反駁書面證據，使評估人員對文件的有效性表示不確定。
不論是否有 CMMI 評鑑，CMMI 模型都很有用。 CMMI 協助軟體開發組織了解其功能與成熟度，以及跟客戶和其他外部專案關係人的期望做比較。 有了組織與 CMMI 模型相對應的粗淺概念，就有方法可以評定它在壓力下的可能反應以及其按照預期完成交付的能力。 經觀察正在執行較高成熟度活動而沒有較低成熟度行為之堅實基礎的組織，可能通常是無法預期的。 也就是，當成熟度較高的行為是存在時且是可以稱讚的，這些成熟度較高的作法因為不是建立在堅固的基礎上，所以是不可信賴。
CMMI 評鑑通常用來做為驗證整體組織流程改善行動的方法。 這樣會產生「通過測試」的壓力。焦點會顯示出遵循每個流程區域內的每個做法並顯示此類證據。 有可能會模糊真正重要的焦點 (根據客戶的期望顯示能力)，而且透過明確的管理行動增強該能力。 著重於「通過測試」往往會造成嚴重的副作用，並且破壞組織功能。 因此，CMMI 在業界發展成壯大的嚴苛評判團體。 可惜，因為我相信 CMMI 模型是有用的，而且能夠提供珍貴的見解給組織中的經理，進而讓他們能夠提高能力、改善效能並提高客戶滿意度。
[1] Anderson, David J. 原著《軟體工程的敏捷式管理：套用條件約束的理想商務結果》(英文)，Prentice Hall PTR，2003
[2] Anderson, David J. 原著《看板：為您的科技企業展開成功的演進式變革》(英文)，Blue Hole Press，2010
[3] Glazer, Hillel 和 Jeff Dalton, David J. Anderson, Michael D. Konrad, Sandra Shrum 原著《CMMI 或 Agile：何不兩個都接受！》(英文)，軟體工程學院，2008 年 11 月
[4] Humphrey, Watts S. 原著《管理軟體流程》(英文)，Addison Wesley Professional，1989
[5] Deming, W. Edwards 原著《產業、政府和教育的新經濟學，第 2 版》(英文)，MIT Press，2000