作者 | 吾真本

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) 指標1：開發者對于工作的幸福指數。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(13) 指標13：迭代回歸測試案例執行率

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

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

(14) 指標14：迭代回歸測試執行時長

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

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

總結

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