摘要： 本文介紹了成熟度模型在軟體開發行業的應用，重點闡述了成熟度模型對于靈活和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在企業規模化推廣的利器。存在即合理，對包括成熟度模型在内的任何方法和工具的使用，我們應秉承實用主義而不是教條主義，同時持有批判性思維和開放态度；“不管黑貓白貓，能捉老鼠的就是好貓”。
本文作者：Hi-Agile 靈活和DevOps咨詢總監 孫長虹
點選關注，第一時間了解華為雲新鮮技術~