摘要： 本文介紹了成熟度模型在軟體開發行業的應用，重點闡述了成熟度模型對於敏捷和DevOps在企業中進行規模化推廣的價值，探討了成熟度模型的設計原則，並對於如何明智使用成熟度模型給出了建議。

導言

在敏捷和DevOps社群，儘管對成熟度模型一直有些爭議，但使用各種成熟度模型來指導轉型的嘗試卻從未停止過；從筆者的從業經歷來看，謹慎地使用成熟度模型，對敏捷和DevOps在企業中的規模化推廣具有很重要的現實意義。

成熟度模型簡介

“團隊定期地反思如何能提高成效，並依此調整自身的舉止表現”，這是敏捷宣言的一個原則，它鼓勵我們持續地對軟體開發方法進行改進。這種改進直接表現在提升團隊的效能（更多的價值，更快的交付速度，更高的交付質量，以及更低的成本等），最終服務於企業的業務目標。改進通常由團隊交付業務價值所面臨的問題或挑戰觸發，團隊共同識別改進點，採取改進措施，檢查改進成效，再發起新的改進；周而復始，永不停歇。

針對軟體開發方法的改進沒有終點，這個漫漫長路需要指引，成熟度模型正是為了滿足這一需求。所謂成熟，意思是長大和成長，指生物體發育到完備的階段，或事物發展到完善的程度。雖然成長的過程是連續的，但還是可以通過觀察主體特徵的明顯變化來確定一些階段，譬如人類成熟的過程可以分為嬰幼兒、兒童、青少年、成年、老年等階段。基於這個隱喻，成熟度模型使用一個結構化的框架，描述所關注的主體如何隨著時間的推移而發展(成熟)；演進的每個階段，被稱為成熟度的一個級別，表明了在成長路徑上的進展。

在軟體開發領域，歷史最悠久，也是最著名的成熟度模型是CMMI。CMMI及其前身CMM，是受美國國防部委託，由Wattss Humphrey在軟體工程研究所(SEI)領導的團隊所建立，以評估供應商有效交付軟體專案的能力。該模型定義了五個漸進的成熟度階段，從級別1(最不成熟)開始，到級別5(最成熟)結束；根據其成熟度特徵對每個階段進行描述，包含目標、實踐和例項等。自上世紀九十年代初被提出之後，CMM迅速為軟體開發行業所接受，它所應用的成熟度模型結構，也被很多其它成熟度模型所借鑑，譬如PMI的組織專案管理成熟度模型等。

當敏捷運動興起，並逐漸成為軟體開發的主流之後，雖然CMMI並沒有被市場拋棄，但其深刻的瀑布模式烙印，成為相當一部分敏捷實踐者們眼中的反面教材，也導致敏捷和DevOps社群對成熟度模型的爭議不斷；但不可否認的是，伴隨著敏捷和DevOps在企業的推廣，成熟度的應用從一開始就出現，且一直沒有停止過；敏捷教練的工具箱裡少不了各種成熟度模型。

成熟度模型的型別

針對任何具有持續演進特徵的主體，我們都可以設計一個成熟度模型。主體範圍可大可小，取決於應用的需要；譬如，可以分別為敏捷或DevOps設計一個模型，也可以設計一個範圍更廣的研發效能成熟度模型來涵蓋它們；或者，對於某些特定領域，例如持續整合或者看板方法，也可以建立一個輕量級的成熟度模型。

成熟度模型主要有階段式和連續式兩種型別。其中，階段式模型在整體上把成熟度分成多個階段，每個階段都有一組考察點；每個考察點用目標或滿足目標的實踐進行描述，展示了成熟度所關注的某個方面。

圖一是階段式成熟度模型的示例，簡明地描述了持續整合的五個成熟度級別；持續整合能力的提升，是通過自低而高，逐一滿足各級成熟度中所有考察點的目標來實現的，每個級別都建立在上一級的基礎之上。

圖一：階段式成熟度模型示例

連續式模型同樣包含多個考察點，每個考察點為一個獨立的評估項；與階段式模型不同，每個考察點都包含成熟度的幾個階段，各階段可以用階段性的目標，滿足該目標的實踐，或能夠體現該階段成熟度的行為進行描述。

圖二是一個連續性模型的示例；這是一個DevOps成熟度模型，考察點包括6大領域36個子領域，每個具體考察點（子領域）包含五個成熟等級的描述，圖二展示了其中的一部分（需求領域）：

圖二，連續式成熟度模型示例

對於連續式模型，原則上成熟度的提升可以從每個考察點獨立開展（實際實施要考慮實踐的相互依賴和支撐），評估時針對每個考察點都給與一個等級。一種常見的結果展示方式是雷達圖，如圖三展示了某專案團隊兩次評估的結果，直觀反映了：1）每次評估各考察點的等級；2）兩次評估之間各考察點成熟度的變化；3）團隊的薄弱點和優勢等。這些資訊對於團隊規劃和跟進改進，具有很強的指導意義。

圖三：連續式成熟度模型的評估結果示例

成熟度模型的價值

成熟度至少回答了三個問題：“我在哪？”（當前成熟度），“我要去哪裡？”（目標成熟度），“我怎麼樣才能到達那裡？”（中間經歷哪些步驟）。而這，是團隊實現持續的效能改進所需要解決的核心問題。

理想情況下，給研發團隊設定有挑戰性的目標，輔以信任和支援，提供必要的資源，團隊自己在目標的驅動下實現改進；但現實情況是，這種自發的改進往往不會如期而來。在組織中進行敏捷和DevOps的規模化推廣，最常見的問題是，多數的團隊不知道怎麼持續改進，不知道自己要改進什麼，甚至不知道自己究竟做得怎麼樣。

敏捷和DevOps教練可以彌補這種缺失，在轉型早期幫助團隊順利上路，但受限於教練資源（譬如幾位常駐敏捷中心的教練服務數千人的研發組織），教練離開團隊之後，更漫長的持續改進之路需要團隊自己走下去。我們都知道，教練最重要的產出是成熟的團隊，特別是培養出合格的具有敏捷意識的領導者，能夠帶領團隊持續改進。正如豐田所倡導的“造物先造人”，當有優秀的人才出現，什麼事情都會變得簡單；然而，“十年樹木，百年樹人”，培養出合格的團隊和卓越的敏捷領導者是何其之難。

毫無疑問，企業一方面要有長遠視角持續不斷地在人才培養進行投入；但另一方面，也要應對眼前向業務交付價值的壓力，快速提升團隊效能。如何在教練資源有限的情況下，積極尋找出在整個組織層面投入產出比高，能夠提供普及型服務，快速見效的辦法？這是敏捷和DevOps規模化推廣必須回答的問題。通常做法是提供基礎性賦能（培訓、短期輔導）後，鼓勵團隊基於行為結果不斷嘗試，即建立一種持續改進的機制，允許團隊犯錯，在業務目標的引領下，嘗試各種新的做法，快速迭代，不斷反思，有用則強化，無效則拋棄。

然而，正如心理學家，社會學習理論的創始人班杜拉所言：“如果人們不得不單純依賴自己的行為結果來告知自己應該如何行為的話，學習將非常艱苦，更不用說其危險性了”。所幸的是，人類具有模仿的天賦，學習不一定要親身經歷。班杜拉的一系列觀察學習研究告訴我們，通過模仿他人的成功，我們可以學會各種各樣的社會行為。對於敏捷和DevOps的實施而言，成熟度模型實際上提供了一個理想的模仿物件。企業的敏捷推廣團隊（譬如敏捷卓越中心，DevOps教練組，轉型領導團隊等），可以通過開發、維護、釋出成熟度模型；答疑，評估和給出建議，來撬動組織轉型。

具體來說，應用成熟度模型可以在以下幾個方面對轉型具有重大促進作用：

第一，明確效能主張。

通過成熟度模型，向研發團隊發出什麼是期望的高效能研發行為的明確主張；模型所提供的框架，系統性給出了在研發主要過程域（考察點）的效能改進的目標，是組織效能改進的思想綱領；圍繞如何實現各考察點的目標，模型同時也提供了大量優秀的敏捷和DevOps實踐建議，是組織效能改進的行動指南。成熟度模型的釋出，能快速地為整個組織的持續改進建立參照體系。

第二，認清現狀。

通過與成熟度模型的對照，團隊可以很容易地評估出自己在敏捷和DevOps實施上所達到的水平（處在怎樣的階段），這成為團隊進一步改進的起點。在組織層面收集各研發團隊的成熟度資料，能夠勾勒出組織整體的敏捷和DevOps實施水平，一方面可以發現在效能提升上的共性問題，集中力量攻堅薄弱點；另一方面也能夠將當前的水平作為組織改進的基線，以此為基礎規劃下一步的改進。

第三，設定改進目標。

目標驅動已經寫進現代組織的基因之中，小到Scrum小組，大到整個研發組織，如果擁有敏捷或DevOps成熟度的目標，將使得改進得到關注並更有保障（無論是時間還是資源的投入）。成熟度模型的高階段要求，是各團隊的具體改進目標；在組織層面，也可以基於組織現狀，設定一個總體改進目標，譬如達到不同等級的團隊比例等，作為OKR自上而下分解到各團隊（在設定OKR目標這件事情上必須慎重，避免造成改進行動的形式化）。

第四：規劃改進路線。

成熟度模型給出了團隊從現狀（低階成熟度）到目標（成熟度高階段）的路徑（即需要經過哪些階段）；攀登高峰不止一條路，但有的崎嶇陡峭，而有的更為平坦，有經驗的登山者知道要走前人走過的路。成熟度模型所規劃的路徑，是前人實踐的經驗總結。誠然，團隊採用敏捷或DevOps的成熟過程與生物體的成熟過程有很大不同，後者必須連續經過所有階段，而敏捷的採用則不受這個限制；因此，在規劃上不能教條，團隊完全可以根據自己的情況，形成特定的改進路徑。

第五，營造競爭氛圍。

以適當的方式，在整個組織層面展示彙總的成熟度資料；識別在提升成熟度過程中湧現出的優秀團隊並給與適度的表彰；鼓勵親歷者講述通過成熟度的提升而帶來效能提升的成功故事並大力宣傳等。這些舉措，都承載在企業的敏捷或DevOps成熟度模型之上，不同團隊之間容易產生共鳴，並存在一定的可比性，能夠在團隊之間創造正面的競爭氛圍，帶來改進的緊迫感。

第六，度量改進進展。

通過敏捷和DevOps來進行全面的效能改進，是一個持續、漫長和沒有終點的旅程；團隊要經常檢視自己做得怎麼樣，是不是走在正確的道路上，而成熟度模型在這個過程之中可以成為衡量改進進度的標準；通過在改進過程中的持續評估，團隊可以清晰地瞭解自己在改進路線上所處的位置，為後續改進活動的設計提供依據。

成熟度模型設計原則

設計什麼樣的成熟度模型決定了組織要定義什麼樣的研發效能標準，將怎樣的行為作為團隊模仿的物件。成熟度模型的設計必須迴歸使用成熟度模型的目的，即能夠引導團隊和組織持續提升效能，進而改善業務產出。為了實現這一目標，需要遵循以下原則：

第一，基於企業現狀。

成熟度模型的通用性越高，則越是抽象，落地指導的價值越低。鑑於敏捷和DevOps方法和實踐的多樣性，以及其推廣實施的靈活性，很難出現一個適應各種場景的敏捷或DevOps成熟度模型；為了能夠指導改進，模型的設計一定要基於企業現狀來，考慮企業的業務訴求、技術路線、人員水平和研發治理模式等約束，而不是簡單地瞄準理想的敏捷或DevOps狀態。

第二，具有導向性。

模型所包含的考察點，對各考察點目標的定義，以及對不同階段的評價標準，都要具有明確的導向性，反映了組織的效能目標（交付速度優先，還是效率優先？更好的使用者體驗還是更低的成本？），效能關注點（彈性的組織，優化的流程，先進的工具，專業的人員等），以及組織對於達成目標的實踐經驗總結和洞察；通過這種導向性，引導團隊表現出組織所期望的行為。

第三，關注目標。

對各考察點的設計，重要的是明確指明目標，而不是嚴格限定是否採用了某種具體實踐。每個考察點從低到高的各階段，反映的是達到目標的程度；不同階段的評價標準可以舉出一些最佳實踐的例子，但最佳實踐不是重點，重點是通過這些實踐幫助團隊達成階段目標。通過對目標的關注，使得團隊更能夠了解差距，自己決定採用何種措施達成目標，並在通往目標的征程中不斷調整措施，而不是教條地採用實踐。

第四，相對客觀。

不同的評估者，在同一時期，對同一個團隊，基於相同的事實，應該能夠給出近似的評價結果。量化數字要求自然能夠達成這目標，但不必太強求量化，只要考察點的目標描述明確的，其支援實踐或表現得行為是可觀測的即可。成熟度模型設計之初，可以考慮通過對試點專案的應用，對其信度和效度進行檢驗。再次提醒，不必追求完全客觀，這不是考核；存在一些模糊，有一定爭議，引發一些討論是有益的。

第五，保持動態演化。

組織業務目標和所處的環境在變化，組織的內部環境在變化，軟體開發方法和實踐本身也在快速變化，今年還備受追捧的方法和實踐可能明年就過時；因此，成熟度模型必須適應這種變化，保持演化，以吸收業內最新的成果，來更好地適應你的環境，幫助企業達成目標。

如何運用成熟度模型

團隊從自己的現狀出發，沿著成熟度模型的階梯，不斷追逐高的等級，實現持續改進；成熟度的等級本身在這個過程中自然而地成為焦點。但如果以成熟度等級為根本，特別是以拿證為目的進行評估，則很容易帶來運動式，一刀切的“改進”。這個時候對等級目標的片面追求很容易讓改進行動脫離團隊的現狀，非但違背應用成熟度模型的根本目的（即提升效能），而且評估活動本身會成為團隊的負擔（準備各種證據），對團隊的正常工作形成干擾；一陣風之後，留下一堆作為證據的文件和棄之不用的流程工具，團隊的一切行為照舊。等級本身並不重要，持續地改進以使得團隊能夠更好地服務業務才是根本，不可以本木倒置。

成熟度模型是工具，工具本身通常是沒有對錯的；刀既可以傷人，也能夠救人，就看握在誰的手中，為了什麼目的。所以，對成熟度模型的應用要慎重：我們可以用它來作為參照和模仿物件，但卻不能把它設計成標準強迫大家遵守；我們可以用它來設定改進目標，但用來考核績效可能事與願違；我們可以把優秀團隊秀出來能夠激勵其他團隊效仿，但如果把暫時墊底的團隊也公佈出來卻不是個好主意。

成熟度評估是模型應用和實現改進的手段之一，它基於模型提供的持續改進的藍圖，幫助我們在改進的征途上進行檢查（識別當前所在的位置）和調整（確定進一步改進的方向）。成熟度評估不是為了獲得一個期望的等級，然後結束；而是要通過評估建立一個基線，成為進一步改進的新起點，並給出下一步行動的建議。

評估活動本身可以有多種方式，拋開外部認證評估不談，在企業內部有團隊自我評估，交叉評估（利用敏捷和DevOps社群力量，不同團隊交叉評估），以及集中評估（由企業敏捷中心的教練統一評估）等多種方式。特別推薦交叉評估的實踐，它一方面解決了集中評估的資源緊張問題（想象一下幾個教練對上百個團隊進行評估的場景）；另一方面，也是更重要的是，它可以使不同團隊有機會相互學習。

評估的結果包括團隊在成熟度模型中所處的等級，做得優秀的地方，以及不足之處。團隊基於這個結果，對標模型更高等級，分析可能的改進點，馬上採取行動，投入下一輪的改進之中。作為敏捷和DevOps推廣團隊，既要基於評估結果發現共性問題，針對性提供集中培訓和專項輔導；也要識別湧現出來的優秀實踐，在組織層面進行分享。評估的結果建議匯聚起來，形成整個組織的成熟度畫像；各團隊成熟度的具體等級可以不公佈，但整體水平的透明有利於各團隊判斷自己在整個組織中所處的位置，增強各團隊的改進緊迫感。

需要警惕的是，成熟度模型通常是基於經驗、觀點，甚至假設所做的構建，而不是應用科學方法的結果。評估結果所給出的改進建議，僅僅是一種你的團隊可以如何成長的假設，它的作用在於讓你擁有一個相對靠譜的參照物，幫助你快速決斷和採取行動；你要驗證這個假設在你的環境中是有效的，或者是無效的（判斷標準是能否能夠提高效能指標）；然後快速調整，進行新一輪的嘗試，從而實現持續改進研發效能的目的。

結束語

儘管成熟度模型的應用在敏捷和DevOps社群的爭議不會停息，但還是有組織能夠從中獲益；我們可以通過明智地使用它，使其成為撬動敏捷和DevOps在企業規模化推廣的利器。存在即合理，對包括成熟度模型在內的任何方法和工具的使用，我們應秉承實用主義而不是教條主義，同時持有批判性思維和開放態度；“不管黑貓白貓，能捉老鼠的就是好貓”。

點選關注，第一時間瞭解華為雲新鮮技