敏捷項目度量怎麼做？

敏捷不僅有度量，度量還是敏捷項目非常重要的一部分，但敏捷度量和傳統的度量存在很大的區別。敏捷度量不是以評估和考核為目的的，它是為了幫助團隊拉通目標和行動、指導指定工作計劃和任務、協助團隊持續改進而發生的。

一提起度量，很多人可能會馬上想到評估和考核，在很多人的工作經歷裡，這兩個字如（YIN）影（HUN）隨（BU）形（SAN），終於，這幾年乘著「轉型」的東風，很多組織開始實踐敏捷，有人可能會想，敏捷擁抱變化、快速反應，推崇試錯和迭代，面對如此不確定的場景，應該不會有以評估和考核為目的的各種度量了吧？

答案是又不是，「不是」的原因是敏捷不僅有度量，度量還是敏捷項目非常重要的一部分；「是」的原因是敏捷的度量和傳統的度量存在很大的區別，敏捷度量不是單純意義上的評估和考核。

下面通過4個問題帶你揭秘敏捷度量的那些事

問題1：敏捷項目為什麼要做度量（Why）？

回顧一下敏捷宣言：個體與交互優於流程和工具，可工作的軟體優於面面俱到的文檔，客戶協作優於合同談判，響應變化優於遵循計劃，也就是說，儘管右項有其價值，我們更注重左項的價值。

深入理解一下敏捷宣言，不難看出，「個體和交互」是敏捷實施的方式（關注合作），「可工作的軟體」是敏捷項目的交付物（目標導向），「客戶協作」是服務提供的方式（公開透明），「響應變化」是追求靈活的反應機制（靈活機動）。

這幾條宣言簡單易理解，也被許多人認可，但事實勝於雄辯，在實際工作中，如何證實左項所注重的價值：關注合作、目標導向、公開透明、靈活機動，並儘可能的優化行為不斷讓敏捷的價值最大化呢？

這些就是度量要做的事情。

總的來說，度量能幫助敏捷項目做下面三件事情：

第一，拉通目標和行動

可工作的軟體長什麼樣子，它具備什麼功能，它為誰提供價值，採取什麼樣的行動能獲得這些價值，這些都是敏捷團隊需要回答的問題，敏捷團隊不僅僅要知道問題的答案，為了快速實現目標，敏捷團隊還需要定期評估行動的效果，為了拉通目標和行動，度量的引入能幫助團隊及時糾偏，少走彎路，減少浪費。

第二，定位當下的位置，計劃下階段的任務

實際工作中，經常會有客戶邀請我們的顧問評估一下他們的現狀，他們基於現狀做下一個階段或者下一年度的計劃，這樣的訴求在接近季度末或者年底的時候尤其多。

正如人需要定期做體檢一樣，體檢結果讓我們對自己的身體狀況有更好的了解，敏捷項目也需要定期的健康度評估，這些評估和度量的結果，除了揭示項目存在的問題，還能夠幫助團隊總結經驗反思教訓，從而更好的指導下一階段的計劃。

第三，改進，改進，改進

敏捷項目推崇持續改進，以更好的方式、更快的速度交付更優的價值，這是很多團隊追求的目標，這個目標不是一蹴而就的，有的時候團隊需要引入更好的工具，有的時候團隊需要借鑑更豐富的經驗，有的時候則依賴團隊持續的成長。

敏捷項目引入工具和他人經驗的過程也是不斷試錯的過程，在試錯的過程中團隊需要知道哪些改變是成功的，哪些是失敗的，這個評估通常是通過度量來完成的，所以引入度量也是為了更好的改進。

一句話總結，敏捷項目通過度量來拉通目標和行動、指導團隊制定工作計劃和任務，並協助團隊持續改進。

敏捷項目為什麼要做度量

問題 2：敏捷項目度量什麼（What）？

試想一下，如果敏捷項目是一個長方體的話，長方體的體積代表團隊所要交付的目標，那麼這個體積由什麼來決定呢？

根據常識，長方體的長、寬、高決定了長方體的體積。

長度代表交付的速度，也叫交付的效能，長度越長，交付的效率越高，團隊也就能更快的接近目標，實際工作中，我們經常聽到的研發效能、測試效能、管理效能，cycle time（需求提出到上線所用的時間）等等，都和速度有關，這些指標決定了團隊以多快的速度實現目標，這是度量中非常關鍵的指標。

寬度代表團隊的能力，實際工作中，我們提到的測試質量，代碼覆蓋率，敏捷實踐實施，持續集成和交付，統一配置管理，灰度發布，債務管理，鬆耦合架構，等等，和團隊實踐以及工具相關的指標都和能力有關，這些指標決定了團隊能不能應對不確定性帶來的挑戰，能不能解決各種複雜、繁雜甚至混沌的問題，能不能做到持續優化和改進。

高度又叫深度，代表產品（軟體）價值，實際工作中，我們做的需求價值分析、MVP拆分、產品願景、優先級排序、價值驗證等等，都是團隊基於自己的經驗展現出的對業務的理解，並在此基礎之上準確無誤的給出方案，交付客戶期望的價值，這些指標決定了團隊能不能基於自己深度的積累，精準的幫助客戶實現目標，並且能在極少浪費的情況下實現目標。

以上三個維度決定了長方體的體積，但是一個成熟的敏捷項目，光有這三個維度還不夠，因為這三個維度不能保證團隊是健康的，我們還需要第四個維度的指標來度量團隊（敏捷項目）的健康。

這個維度就如同我們給這個長方體上的顏色，是沮喪的灰色，焦慮的紅色，抑鬱的藍色，還是生機勃勃的綠色？團隊是什麼成熟度，項目整體是否健康，這些也需要度量，常見的指標，比如，項目滿足的財務指標，干係人管理，團隊協作，團隊成長，管理的透明化，成員的穩定性等等，敏捷團隊健康度這個維度決定了團隊能否長期穩定的以此種方式工作，團隊能不能自我優化。

一句話總結，敏捷項目度量的是交付效能、團隊能力和產品的價值，以及保證這這些目標能夠達成的團隊健康度。

團隊健康

問題 3：敏捷項目裡面誰來做度量（Who）？

這個問題可以從Scrum 的 5 個核心價值觀裡找到答案：承諾、專注、開放、尊重、勇氣。

這幾個價值觀指導著敏捷項目輕職權、重協作；輕命令、重自組織。

也因此，很多成熟的敏捷團隊是自組織的，是在一種扁平文化下工作的團隊，在這種團隊裡，無論是短周期的任務還是長周期的結果交付，團隊共同承諾，共同行動，共同負責。

度量作為非常關鍵的任務之一，也是團隊協同工作來完成的。

在這裡，有幾個小建議給到想做度量的敏捷團隊：

第一個建議是，角色之間交叉度量。團隊負責不代表不能有分工，如果團隊自行組織度量的話，建議角色互換來度量，比如開發人員做價值交付維度的發起者，需求人員提供信息；測試人員做開發相關指標度量的發起者，開發人員輸入信息，這樣做能更好的保證度量的客觀性，對團隊來講，也是一次不錯的知識和經驗分享的過程。

第二個建議是，引入外部的顧問來做度量。外部的顧問可以是其他團隊的人員，也可以是獨立的第三方顧問，這樣做的好處除了保證度量的客觀性，外部顧問還能帶來更多的經驗，甚至會把跨行業和領域的經驗帶給團隊，幫助團隊改進和優化，建設能力。這個方法實施的注意事項是，一定要保證兩次度量的評價標準一致，否則會失去度量的價值。

第三個建議，無論是團隊自組織做還是引入外部顧問，都需要全員參與。因為度量不僅是團隊拉（XI）通（NAO）目標、明確任務、統一行動的機會，度量還能夠幫助團隊提高凝聚力。

一句話總結，敏捷項目的度量由團隊共同承諾、共同行動和共同負責來完成。

團隊

問題 4：敏捷項目在什麼時候做度量（When）？

這個問題如同問「我們通常什麼時候做體檢？」，答案無外乎幾種：生病的時候；一段時間的專項鍛鍊或治療之後（比如，3個月的體能）；例行的年度或者半年度體檢。

敏捷項目度量也是。

第一種情況是項目在經歷重大的事件之後，這裡專指風險事件或者危機事件，團隊需要集體反思、總結教訓，這個時候項目需要做一次度量，找到那些把風險帶給團隊的指標，以此來尋找優化和解決問題的方法。

第二種情況是裡程碑事件之後，或者一個關鍵的MVP 發布之後，團隊積累了大量的經驗，當然也有教訓，這個時候也應該引入度量，評估一下和目標的差距，制定下個階段的計劃，帶著經驗繼續優化和改進。

第三種情況就是周期性的度量，建議3-6個月，之所以選擇這樣一個周期，是因為少於3個月，很多持續性的行動還很難產出效果，長於6個月的話，某些行為具備了慣性，掉頭的難度比較大，綜合考慮，3-6個月是比較合適的周期，具體選擇多長時間，由團隊來決定。

一句話總結，敏捷項目除了例行的度量之外，在經歷了大的危機、重大的裡程碑事件之後也是執行度量、總結經驗和教訓來優化和改進的好時機。

周期性的度量

有一句話是這樣說的：「我們不能測量我們不能控制的東西」。敏捷度量亦是，敏捷度量無法幫助團隊度量未知的東西，但如果團隊想更好的了解自己和未知，或許它能夠幫到你。

敏捷度量的Why、What、Who、When

總結一下：敏捷不僅有度量，度量還是敏捷項目非常重要的一部分，但敏捷度量和傳統的度量存在很大的區別，敏捷度量不是以評估和考核為目的的，它是為了幫助團隊拉通目標和行動、指導指定工作計劃和任務、協助團隊持續改進而發生的。

文/ThoughtWorks陳慶敏