敏捷團隊成熟度的思考

一、敏捷團隊成熟度的目的

這裡參考CMMI的相關內容並結合敏捷特點可知，使用敏捷團隊成熟度的目的是透過某種建模方式(敏捷團隊成熟度模型)來描述其敏捷能力的分級，從而讓團隊知道其當前能力(as is)，以及在敏捷團隊成熟度模型的定義範圍內，找到未來的發展方向和目標(to be)。

簡而言之，敏捷團隊成熟度的目的是為了幫助團隊定位其在其所處環境下的能力。

二、敏捷團隊成熟度的特殊性

這裡的特殊性，其實是敏捷自身的特殊性帶來的──敏捷本身不是流程、框架、方法論，更多的是一種理念(mindset)，因此，在度量敏捷團隊成熟度時候，無法絕對的透過文件、流程、交付物來進行定義，畢竟在實施敏捷的過程中，情景(context)起到的作用非同凡響。

因此在度量敏捷團隊成熟度的時候，我們需要回歸到敏捷自身的特點，而不能寄希望於所謂的“標準”、“流程”、“方法論”。

這裡還有一個需要注意：定義敏捷團隊成熟度的時候，最好不要將其約定到某種框架或者方法，比如Scrum 或者Kanban或者XP，我們沒有能力或者必要為他們分別建立一個成熟度模型。這裡我們要定義的是敏捷團隊成熟度。

既然定義的是敏捷團隊成熟度，那麼此時就需要回歸到敏捷的自身特點，這也是下面我在設計某個敏捷團隊成熟度模型中的主要思考方向。

三、一種成熟度模型初步構想

結合敏捷特點，以及ITIL 4中給我的一些啟示，這裡做了一個簡單的敏捷團隊成熟度模型。

這裡的模型思考點從PPTV 四個角度出發：

P，People，人的因素

P，Process，過程因素

T，Tool，工具因素

V，Value，價值因素

這裡有一點需要注意，敏捷本身不是流程，以及該模型需要相容不同的框架，所以第二個流程P會被機制Mechanism 代替，所以最後的模型就會變成PMTV(完美逃開了蘇寧的律師函。

V，Value，價值因素

把價值因素放到最前面，相信沒有人會反對，畢竟敏捷一直在強調“交付價值”。

但“統一價值度量”基本上是不可能完成的任務，而且如同我們前面所說，敏捷需要嚴格考慮情景，所以這裡我們放棄對價值的直接度量，轉而開始度量“是否具有完備的價值交付度量體系”，即確保團隊的交付物是具備價值並且可以度量，避免團隊進入一種渾渾噩噩只知道做事，不知道做的怎麼樣以及價值在哪裡的情況。

至於敏捷自身的價值，我個人並沒有將其思考在內。畢竟敏捷是否有價值，必須是依賴於敏捷是在團隊交付過程中提供幫助，否則就會變成“為了敏捷而敏捷“。

M，Mechanism，機制因素

這裡機制所代替的基本上都是對敏捷強調的一些原則相關，具體包括：

交付週期是否足夠短──每個故事(或者需求、任務、Bug)流動時間是否滿足組織對團隊的訴求，具體數值可以根據不同環境自行定義;

是否具備持續交付能力──每個交付物，是否可以持續的被驗收，甚至被髮布上線(這裡其實是已經是持續部署了，根據不同團隊情況可選)，這裡可以透過百分比的方式進行定義，有多少需求是開發完成後就可以交付或者釋出，透過不同的百分比來進行本項的評分;

是否具備持續改善的機制──團隊是否會在開發過程中對團隊的績效表現進行反思並提出改進方案。本項無法透過絕對的客觀指標進行評分，只能透過詢證(找到對應的證據，包括但不限於參加改進過程、審查改進過程留下的文件、與團隊進行訪談等方式)的方式進行評分，重要的是在詢證的過程中給予改進建議;

是否具備研發過程資訊同步機制──團隊是否在開發過程中，有資訊同步機制。資訊同步機制不一定是站會，可以是團隊認可的任意形式。同時本項還包括了對資訊發射源的更新及時程度與更新機制的考量。本項無法透過絕對的客觀指標進行評分，需要詢證並給出改進建議;

是否具備完備的工作計劃機制──團隊在開發過程中，是否使用了符合當前團隊的計劃方式，並儘可能的根據計劃完成工作。這一項需要將計劃的週期、計劃完成率、計劃透明度等考慮在內。本項無法透過絕對的客觀指標進行評分，需要詢證並給出改進建議;

是否具備需求變更與應對機制──變更不可避免，團隊是否選擇了適當的變更與應對機制，對團隊交付價值有著莫大的幫助。這裡要注意，應對變更並非需要如同敏捷軟體開發宣言第二條說的欣然接受變更，需要根據團隊與開發工作自身特點來制定合適的方法。本項無法透過絕對的客觀指標進行評分，需要詢證並給出改進建議;

是否具備完備的反饋機制──不論是日常工作中還是使用者驗收後給出的反饋，是否可以無障礙的傳遞給團隊，並且團隊可以根據實際情況對反饋即時調整(adapt)工作優先順序。本項無法透過絕對的客觀指標進行評分，需要詢證並給出改進建議。但是有一點需要注意，詢證過程中，業務方的反饋至關重要，不可或缺;

團隊是否使用了良好的研發實踐──這裡是較為少見的可以絕對度量的指標，包括是否使用TDD、測試程式碼覆蓋率、是否使用自動化工具等。可以根據團隊實際情況以及引導方向，進行適當的定製。一般認為沒有TDD 的團隊，本項得分必須是0分。

P，People，人的因素

人的因素應該是比較複雜的因素，大機率是因為人的因素太多。不過我們有辦法做點事情：

研發人員能力──這一項的關注點在於研發人員是否有能力、按時按量的完成工作交付。這裡將短交付週期剝去(在機制因素中體現過了)，單純的關注團隊能力是否足夠。這裡可以考慮的點是：技能覆蓋面(是否包含了所有的能力)、T型人才佔比、團隊自我學習意願等方面考慮。本項無法透過絕對的客觀指標進行評分，需要詢證並給出改進建議;

團隊教練能力──這一項關注的是團隊教練(Scrum Master 或同等角色)在敏捷開發過程中能力與價值體現。本項考核點在於團隊教練對敏捷框架的認知、研發流程的認知、教練技術、引導技術以及相關敏捷領導力的表現。本項取決於組織對團隊教練的期待，可以根據實際情況增刪考核點。本項無法透過絕對的客觀指標進行評分，需要詢證並給出改進建議;

產品人員能力──這一項關注的是產品人員(包括但不限於PO、產品經理、BA等角色)在敏捷開發過程中能力與價值體現。本項考核點集中在行業知識、需求編寫(包括使用者故事)、與業務方溝通表現、優先順序排序等方面。本項無法透過絕對的客觀指標進行評分，需要詢證並給出改進建議。

T，Tool，工具因素

目前來說工具因素只考慮一項，即對資訊發射源的使用。

是否正確使用資訊發射源──資訊發射源可以由團隊自行選擇與使用，但是需要確認團隊是否正確認知了資訊發射源，並且正確的使用了相關的資訊發射源。本項無法透過絕對的客觀指標進行評分，需要詢證並給出改進建議。

四、寫在最後

這個模型肯定是有不適用的地方，包括但不限於缺失、錯誤等情況，這只是我針對現在看到的場景進行一些思考，以及在實踐中做的一些嘗試。有問題歡迎討論，如果噴我，那麼你就是對的。

在設計這個模型的時候，我的原則包含了幾項：

減少對”技術動作“的要求。比如對是否開站會、回顧會等內容完全不在意，追到這些事件背後的目的並具有相關的方案即可;

減少對團隊工作模式的改變。比如團隊氛圍不可以作為直接的要求，團隊與團隊之間就是會有不同，無法一刀切。只有當其他的指標有問題，比如”交付週期過長“的時候，才會將團隊氛圍當做考慮因素進行思考，並作為改進建議提出即可;

成熟度評估不可以過於頻繁，一般認為最少也需要6個月時間才可以評估一次，甚至一年評估一次也是可以接受的。評估者與被評估者都需要明確知道，成熟度目的不是為了評估而評估，真正重要的是透過評估過程，得到團隊改進的建議。而這些建議的追蹤與改善應該交由團隊教練跟蹤與執行;

這個模型肯定有問題，比如定量因素太少、定性偏多、訪談偏多導致的評估時間過長等。這些在對敏捷團隊成熟度評估中，目前來看都是無法迴避或者解決的問題，只能在評估過程中，逐步將工作交付給團隊級教練，由團隊級教練日常追蹤，最後由PMO 或者企業級敏捷教練抽查或者評審即可;這個過程中必然會有弄虛作假，因此一定量的抽查也是有必要的;

該模型本質上是從不同層面來對團隊進行檢查，而這些指標最終還是需要結合團隊實際情況進行修訂，所以評估成熟度的過程，本身也是一個敏捷的過程。