如何定義研發KPI：以團隊速度為標準

一年半之前，我一直在Bizzabo領導研發團隊。

自從成為負責人，我就在尋找衡量研發團隊績效的最佳方法，從而反映出團隊提供的真正價值。我們最初是使用行業標準度量來跟蹤團隊績效：度量計劃和交付。

下面是我們的團隊KPI：

• 偏差最多20%：為了更好的計劃；
• 每項任務平均兩天：我們認為，小任務更好處理，也更好執行；
• 系統正常執行時間99.95%

我面臨的挑戰是，這些KPI與研發團隊的真正價值沒有直接聯絡。我們很容易實現這些KPI，即使速度很慢，質量很低。

經過6個月的迭代和修改，我決定定義研發KPI，以便更好地反映一個運轉良好的研發團隊的價值——團隊的速度和質量。

我想暫停一下，瞭解下CodeClimate團隊的產品Velocity。它幫助我們走到今天。

讓我們來回顧一下，術語“研發速度”包含了什麼。

工作習慣

• 每週編碼天數
• 每天程式碼推送次數（儘早推送，少量推送）
• 拉取請求（PR）大小
• 從請求審查到合併的時間

程式碼質量

• 程式碼複雜度
• 程式碼文件
• 測試覆蓋率
• Bug數量
• 系統正常執行時間

效率

• 返工比例
• PR放棄數量
• 回退次數

為了選出可以實現最快速ROI的KPI並優先關注，我們深入地瞭解了每一項。

每週編碼天數

團隊成員每週編碼的平均天數（定義為至少一個提交的推送）。你可能認為一個提交不能很好地反映情況，但是，我建議你從簡單的開始，或者提出一個更好的、容易量化的指標。

每週編碼天數

每天程式碼推送次數
每一名活躍的貢獻者在單位時間內有多少拉取請求（PR）被合併。

每天程式碼推送次數

PR大小

對我們來說，PR多大合適，這需要我們更深入一點地瞭解。但是，我們不確定如何設定一個明確的數值。關鍵是找到一個程式碼行數，我的同事用不到一個小時的時間就可以完成程式碼審查和PR審批。

程式碼審查超過一個小時就會成為一項具有挑戰性的任務，這樣，審查可能會不徹底。反過來，隨著更多的Bug進入生產環境，節省33小時將成為一項挑戰。最佳的PR大小是小於250行程式碼。實際上，我們大部分的PR都更小一些。

PR大小分佈

從請求審查到合併的時間

把PR為釋出到生產環境需要經過的每個步驟想象成一個漏斗：審查時間 \u0026gt; 審批時間 \u0026gt; 合併時間。

我們希望有一個明確的內部SLA，這樣，80%的PR將在已知的時間內通過這個漏斗。這是一種平衡，可能每個團隊的心態和文化會有所不同。一方面，我們不希望開發人員因為審查等待太長時間，另一方面，我們希望防止審查人員被迫暫停當前任務進行上下文切換。我們的目標是：

• 審查時間：12小時（同一天審查）
• 審批時間：第一次審查後3小時
• 合併時間：審批後12小時

我們還規定，審查人員最多2名，以防止廚房裡的廚師過多。

程式碼複雜度

定義——控制結構（如if語句、迴圈等）中巢狀深度至少為4層的應用程式程式碼的行數。

KPI—每千行程式碼中複雜程式碼的數量。

從下圖中，你可以看到多年來我們是如何簡化程式碼庫的。在很大程度上，這是通過採用新技術（React/Redux、Kotlin、微服務、Dockers和K8s）和改進我們的程式碼文化來實現的。

程式碼複雜度隨時間的變化

程式碼文件

我們秉承“無文件”的理念。我們認為，應該編寫簡單的程式碼，每個人都能輕鬆理解（不過，公平地說，我們確實有一些註釋）。

測試覆蓋率

我們的研發團隊沒有專門的QA團隊。每個開發人員都自己編寫測試（單元測試和端到端測試），Squad負責釋出質量。沒有覆蓋的新程式碼就不會發布。全自動化測試會在每個構建上執行。

Bug數量

Bug很難度量。你是什麼時候跟蹤它們？什麼算是一個Bug？我們優秀的客戶支援團隊做得非常好（首次響應時間不到1.5小時），只會將相關問題升級到我們的研發升級團隊（我們有一個團隊負責人的職位空缺）。我們每個月都要度量Bug的數量和嚴重程度。但是，隨著團隊的成長，你會做些什麼呢？我們都知道，編寫的程式碼越多，Bug就越多。

我們會進行深入分析，查詢某個月的程式碼行數與Bug之間的關係，釋出次數（我們有一個完整的CI/CD）與Bug之間的關係，等等。

最後，我們決定度量合併的PR總量與Bug數量的比率。

客戶根據嚴重程度報告的Bug數量

合併的PR總量隨時間的變化

我們將KPI定義為0.2（每合併5個PR一個Bug），無緊急Bug

系統正常執行時間

這個很簡單。我們的目標是度量我們每個月的正常執行時間，以確保我們的客戶得到最高質量的服務可用性。為此，我們使用了statuscake。

返工比例

返工程式碼行是指同一作者在3周內提交併編輯的任何程式碼行。返工比率使用以下公式計算：（不同返工的總行數）/（不同修改或新增總行數）。

度量返工的方法沒有對或錯，因為這更多的是一個特定於團隊或公司的指標。當一些團隊的工作從裡到外返工率更高時，或者當一些團隊在周密計劃之後開展工作時，有時正在進行快速的產品迭代，尤其如此。

主要的思想是回顧每個特性的開發，看看返工是不是由於需求的變化，或者缺乏足夠的技術指導。

PR放棄數量

如果拉取請求在未合併的情況下開啟並關閉，則認為它被“放棄了”。我們還把超過3天不活動的拉取請求包含了進來。這可以確保我們專注於最重要的任務，同時最小化上下文切換，保證我們的工作不會浪費。

當我們按年齡來觀察放棄的PR時，很明顯，超過30天的PR可能有90%永遠都不會再合併，換句話說，它是失落的程式碼。清理完管道後，除去那些從未打算合併的PR（比如POC、測試和其他一些內部需求），我們將回顧任何老去的PR，並理解其原因。我們可以確定這是否是產品優先順序的改變，或者我們從來沒有因為錯誤的估計而終止一項計劃，等等。

你可以看到，專注於這個KPI並制定好流程，使我們的小組工作習慣更加一致；團隊之間的偏差變得更小了（自7月份以來，我們就啟用了新的KPI流程）。

每個Squad放棄的PR

回退次數

合併後有多少程式碼回退？回退通常是即時Bug（質量）或對產品/功能缺失的快速瞭解所直接導致的結果。我們的目標不是一個特定的數值，但是，我們確實會把每次回退作為一個觸發器，進行一次專門的回顧。

那麼，我們用什麼作為我們的KPI？

1. 我們定義了良好的研發KPI所具有的屬性：

• 從個人到Squad（我們使用了Spotify模型）再到整個團隊都可度量；
• 反映並能促進吞吐量的增長；
• 與工作（程式碼）質量相關；
• 挑戰團隊，使他們變得更好；
• 在最短的時間內交付最高質量的產品。

2. 在進行了上述所有分析之後，我們決定使用以下團隊KPI：

• 吞吐量：每位貢獻者每月有15個PR被合併；（每名活躍貢獻者單位時間內被合併的PR數量）
• 效率：PR放棄率小於5%；（如果拉取請求在未合併的情況下開啟並關閉，則認為它被“放棄了”。我們還把超過3天不活動的PR包含了進來。）
• 質量：正常執行時間99.98%；
• 質量：每個合併的PR平均0.2個Bug，無緊急工單。

檢視英文原文：Stop measuring R\u0026amp;D planning VS execution. Start measuring team velocity