被遺漏的度量指標

DevOps的4個關鍵指標（4 key metrics），似乎已經成爲能解釋一切軟件開發生產力（或研發效能）問題的“北極星”指標。

我們知道，收集每個指標的數據，都需要投入成本，所以指標不是多多益善，需要識別關鍵的北極星指標。另外，當北極星指標沒有符合預期目標時，也需要參考其他羣星指標，以便爲團隊提供當時的上下文，識別合理的改進時機。

比如，當生產環境某個用戶故事交貨時長這個北極星指標很長時，可以看看該“用戶故事所經歷的SIT測試次數”是否多，來了解這是否因爲返工多導致的。如果不是，那麼再看看是否用戶故事拆分粒度可以優化，等等。

所以，指標數量和維度需要取得平衡，既要少到能恰好代表軟件開發生產力關鍵要素，也要多到恰好能提供用於持續改進的上下文。爲了更好地用度量驅動改進，我們需要平衡式的指標。

要設計平衡式的指標，首先要確定平衡式的指標所應涵蓋的維度。

DevOps 4個關鍵指標的維度

可以先看看DevOps的4個關鍵指標屬於哪些維度，然後思考這些維度是否恰好能滿足爲度量驅動改進提供上下文。如果不能完全滿足，再尋找被遺漏的度量維度，並設計對應的羣星指標。

DevOps的4個關鍵指標，在一定程度上，體現了“流速快”和“質量好”這兩個維度。

“生產環境業務系統部署頻率”和“生產環境用戶故事交貨時長”，體現了價值端到端流速是否快。因爲前者越高，流速越快；後者越短，流速越快。

“業務系統嚴重故障修復時長”和“業務系統發佈用戶故事的嚴重故障率”，則體現了所交付的軟件產品質量是否好。因爲前者越短，用戶感知的故障時長越短，質量越好；後者越低，質量越好。

被遺漏的羣星指標的維度

爲了找到用於提供改進上下文的羣星指標，有些團隊會將DevOps的4個關鍵指標所涵蓋的“流速快”和“質量好”這兩個維度的指標進行擴充，增加了諸如“迭代完成率”（流速快）、“構建時長”（流速快）、“代碼重複率”（質量好）、“測試覆蓋率”（質量好）等指標，作爲羣星指標。但增加了這些羣星指標後，能否恰好代表軟件開發生產力的關鍵要素？是否有遺漏？

我們知道，“個體與互動，高於流程和工具”，被放到了敏捷宣言的第一條。在敏捷項目中，反映個人自身的“個體”，與反映團隊成員之間協作的“互動”，能否作爲代表軟件開發生產力的關鍵要素呢？當度量軟件開發生產力時，有些團隊是否遺漏了這兩個要素及其所對應的維度？

研究顯示，軟件開發生產力與開發者對於工作的滿意度和幸福指數高度相關（參見參考資料2和3）。

如果團隊忽視其成員的工作“幸福感”，不僅有損生產力，還會使人離心離德，導致背叛。當下熱門動漫《中國奇譚》第一集“小妖怪的夏天“鍾所講述的故事，就生動地描繪了這一場景。在“大王洞”打工的小豬妖，用夥伴烏鴉怪的羽毛製作弓箭搞技術革新，但卻被熊教頭看作是“無視上級”而罰去重做；被熊教頭當作豬鬃刷子刷鍋，導致毛髮變禿；目睹了夥伴烏鴉怪因爲偷看了大王佈置的捉拿唐僧的陷阱，而慘遭大王毒手。這些遭遇讓他完全喪失了工作的“幸福感”，最後冒着生命危險，棄暗投明，阻止了唐僧師徒四人落入大王設下的陷阱。

如何度量“個體”與“互動”呢？我們可以粗略地用開發者（本文所說的開發者，包括Dev、QA、BA、UX、Ops等各個角色）的工作倖福指數來度量“個體”，用會議成效、知識獲取和工具便利這些有關溝通協作的指標來度量“互動”。

另外，軟件開發生產力的終極目標，是滿足用戶價值。那麼用戶對產品的滿意度，是不是就是有些團隊所遺漏的第三個關鍵要素及其所對應的維度？

平衡式度量指標的5個維度

上面談到的被有些團隊遺漏的3個關鍵要素及其所對應的維度，在GitHub、加拿大維多利亞大學和微軟研究院於2021年所聯合撰寫的文章The SPACE of Developer Productivity（參見參考資料1）中獲得了印證。

這篇文章中所提到的SPACE，代表度量軟件開發生產力的5個維度——Satisfaction & well-being, Performance, Activity, Communication & collaboration, Efficiency & flow。這5個維度，大致可以一一對應到本文所提到的下面5個度量維度——幸福感（幸福指數，Satisfaction & well-being）、協作佳（溝通協作，Communication & collaboration）、價值準（價值成效，Performance）、流速快（價值流速，Efficiency & flow）、質量好（過程產出，Activity）。

從下圖中能夠看出，如果僅侷限於DevOps的4個關鍵指標所涉及的那2個維度，來設計羣星指標，那麼就會將“幸福感、協作佳和價值準”這3個重要的維度遺漏掉。爲什麼這3個維度很重要？因爲團隊所交付的軟件產品，是要靠人這個“個體”，以及個體之間的“互動”來交付的。如果把DevOps的4個關鍵指標所涉及的“流速快”和“質量好”看作某種中間狀態的“果”，那麼“個體”所對應的“幸福感”，以及“互動”所對應的“協作佳”這兩個維度，就是“因”。沒有“因”，哪來“果”呢？雖然在項目的中後期，“幸福感、協作佳”可以與“流速快、質量好”互爲因果，但在項目的初期，我們是可以通過規劃，讓“幸福感、協作佳”成爲“因”的。最後那個“價值準”維度，是所有4個維度的最終狀態的“果”，更值得我們關注。本着以終爲始的原則，我們應該在關注“流速快、質量好”這兩個維度之前，先關注“價值準”。

圖：軟件開發生產力平衡式度量維度之間的關係

本文的目的，就是要找回這3個被遺漏的度量維度，並補充其他維度的一些重要的度量指標，從而獲得一份平衡式的度量維度和指標，進而便於敏捷團隊通過度量驅動改進。注意，下面的5個指標維度，相對完整。但每個維度下的指標，並沒有包括全部指標，團隊需要根據自身實際情況，進行取捨。

平衡式的度量指標

維度1：幸福感（幸福指數）

指標1：開發者對於工作的幸福指數。

工作倖福指數越高，軟件開發生產力就越高。

可以每週問每位開發者：“如果從0到10打分，你向其他開發者推薦入職我司做開發工作的可能性有多大？”

維度2：協作佳（溝通協作）

指標2：開發者對於會議成效的滿意度。

會議越有成效，溝通協作就越好，軟件開發生產力就越高。

可以每週問每位開發者：“如果從0到10打分，你對本週所參與的所有會議的成效的綜合滿意度打幾分？”

指標3：開發者對於知識獲取的滿意度

獲取所需知識（包括文檔質量和知識分享）越便利，軟件開發生產力就越高。

可以每週問每位開發者：“如果從0到10打分，你對本週獲取知識的便利情況（包括文檔質量和知識分享）的綜合滿意度打幾分？”

指標4：開發者對於工具及工具平臺的滿意度

工欲善其事，必先利其器。溝通協作所需工具越趁手，軟件開發生產力就越高。

可以每週問每位開發者：“如果從0到10打分，你對本週使用工具及工具平臺的便利情況的綜合滿意度打幾分？”

維度3：價值準（價值成效）

指標5：用戶對產品的滿意度

用戶對產品越滿意，說明軟件開發生產力成效就越高。

可以每月問用戶代表：“如果從0到10打分，你向他人推薦使用這款產品的可能性有多大？”

維度4：流速快（價值流速）

指標6：生產環境業務系統部署頻率

當部署與發佈不分離時，生產環境業務系統部署頻率越高，說明業務能更小批地部署上線，這樣能更早地將業務價值交付給用戶，軟件開發生產力就越高。

當部署與發佈分離時，生產環境業務系統部署頻率越高，能間接反映自動化迴歸測試、特性開關、藍綠部署等機制更強，軟件開發生產力就越高。

可以每次生產環境部署時，問運維人員：“業務系統生產環境本次部署距上次部署之間的間隔時長有多長？”

指標7：生產環境用戶故事交貨時長

生產環境用戶故事交貨時長越短，說明用戶故事拆分越合理，中間返工少，工序間等待少，軟件開發生產力就越高。

可以每次投產上線後，請運維人員統計本次成功投產上線的所有用戶故事的交貨時長，即從提交第一行代碼到代碼庫到成功投產上線之間的時長。

指標8：用戶故事所經歷的SIT測試次數

開發者在修復SIT測試階段所發現的用戶故事缺陷後，還應該再次提交給QA在SIT階段驗證。用戶故事所經歷的SIT測試次數越少，說明該故事開卡驗卡等質量內建做得好，返工少，軟件開發生產力就越高。

可以在每次用戶故事通過了SIT測試後，請測試人員記錄該故事所經歷的SIT測試次數。

指標9：並行工作數（Work-In-Progress, WIP）

開發者每日並行的工作越少，工作切換所消耗的時間就越少，軟件開發生產力就越高。

可以每日問每位開發者：“當天手中並行安排了幾個工作？”

維度5：質量好（過程產出）

指標10：業務系統嚴重故障修復時長

業務系統嚴重故障修復時長越短，可以間接反映生產環境系統運行觀測能力越強，故障響應、切換和回滾機制越強，軟件開發生產力就越高。

可以每次解決完生產環境的嚴重故障後，請運維人員統計修復時長，即從故障出現（而非發現）到成功修復或回滾之間的時長。

指標11：業務系統發佈用戶故事的嚴重故障率

業務系統發佈用戶故事的嚴重故障率越低，說明所發佈的用戶故事質量越好，軟件開發生產力就越高。

可以在每次投產上線後，請運維人員統計本次投產的用戶故事中無法正常使用的比例。

指標12：通過代碼評審的commit比例

通過代碼評審的commit比例越高，或許能反映代碼質量會更好（取決於開發者的整潔代碼意識和代碼評審質量）。

可以在每個迭代結束前，請每位開發者統計自己提交到主幹的commit中，通過代碼評審的比例。

指標13：迭代迴歸測試案例執行率

迭代迴歸測試案例執行率越高，或許能反映業務系統已有功能的缺陷就越少（取決於迴歸測試覆蓋關鍵業務場景的質量）。

可以在每個迭代結束前，請測試人員統計迭代實際執行的迴歸測試案例，佔本應執行的比例。

指標14：迭代迴歸測試執行時長

該指標需要與“迭代迴歸測試案例執行率”結合起來看，當“迭代迴歸測試案例執行率”爲100%，且使用了自動化迴歸測試，那麼迭代迴歸測試執行時長越短，能間接表明軟件開發生產力就越高。

可以在每個迭代結束前，請測試人員統計本迭代迴歸測試執行時長。

總結

度量軟件開發生產力的指標維度和數量，需要取得平衡，既要少到能恰好代表軟件開發生產力關鍵要素，也要多到恰好能提供用於持續改進的上下文。只使用DevOps的4個關鍵指標，而忽視“幸福感、協作佳和價值準”這3個維度，會導致團隊僅關注“流速快”和“質量好”這兩個中間狀態的“果”，而失去對“幸福感、協作佳”這兩個“因”的關注，且失去對用戶滿意度這樣的最終狀態的“果”的關注，無法看到軟件開發生產力的全貌，也就難以用度量驅動改進。