今天來聊一個有點難度的主題——「如何評量 DevOps 的進展與成效？」

嗯，好難喔，我們今天就聊到這裡嘍，明天見～（揍飛）

通常在談論這種主題時，在早一點的年代，我們可能會聽過過一個詞——能力成熟度模型（CMM, Capability Maturity Model）。

簡單來說，它通常會是一個表格，將團隊的某項或多項「能力」分成數個層級（多半是 5 個），然後依據團隊可以做到多少事情、做的速度、品質⋯⋯等多項條件做出評比，評定團隊的能力落在哪個等級。

舉例來說，跟 DevOps 很有關係的持續交付成熟度模型（The Continuous Delivery Maturity Model），就分成五個等級 base、 beginner、 intermediate、 advanced 和 expert，評定 Culture & Organization、Design & Architecture、Build & Deploy、Test & Verification、Information & Reporting 五個面向。

（圖片來自 infoq.com 的文章。）

除了持續交付之外，還有哪些成熟度模型呢？只要去 Google 搜尋 Maturity Model，就能找到許許多多不同主題的「成熟度模型」例如：Test Maturity Model、Automation Maturity Model、Release Management Maturity Model⋯⋯，其中有一些確實是經過一些專家或大神們訂定的，當然也有一些是不知哪來的公司或顧問自己訂定的。

總之，成熟度模型是一個在概念上歷史悠久，過往會被拿來評定團隊各種能力的一項工具。

不過這種歷史悠久的工具，並非所有人都接受它，也是有一些不同的聲音出現，例如：

• 成熟度模型無法因應現在 IT 圈的高度不確定性、變動性與複雜性。
• 成熟度模型無法反映出個別團隊的差異與獨特性，它是一種僵化、固定的標準。
• 就算達到了成熟度模型的最高等級，依然對於企業能否成功沒有直接幫助。
• 成熟度模型只是一種變相的「認證」，不過是從個人換到了團隊層級而已。
• 成熟度模型會導致團隊只重視那些可以被評比的項目，忽略了還有其他同樣重要的項目需要被精進與改善。
• 成熟度模型會阻礙團隊的長遠發展，難道能力只能有 5 個等級嗎？

那目前市面上有沒有 DevOps 的成熟度模型呢？

哼哼，怎麼可能會沒有呢？就像市面上有著 DevOps 職缺、DevOps 認證，當然也會有 DevOps 成熟度模型。就像上面說的，成熟度模型就像認證一樣，這東西背後可是有商機與市場的。

（老樣子，只要 Google devops maturity model，就可以找到一堆。）

好了，最後讓我們聊一下對於成熟度模型的看法。

基本上就跟 Day21 的內容「你真的需要一張 DevOps 認證？」雷同，請先蒙心自問「你真的需要找一間顧問機構，幫你評定團隊的 DevOps 能力成熟度？」

筆者覺得成熟度模型跟認證很像，它們都能提供一套已經整理齊全的知識體系，幫助我們認識事物的整體輪廓，並提供一個學習與比較的基準。

但這個「基準」就是我們必須謹慎面對的東西，這就好比 KPI 的萬年老梗，「你訂定了錯誤的 KPI，就會得到錯誤的結果。」

重要的不是「成熟度模型」，而是你團隊目前具備的能力，以及團隊打算如何持續改善與成長。「成熟度模型」可以是一項可供我們參考與學習的資源，就是別忘了那句老話「役物而不役於物」啊！

連續假期第三天，今天一樣不多聊嘍～
DevOps 輕鬆聊，我們上班日再見～