程式碼行數、查殺 bug 數笑笑就好，技術團隊的 KPI 到底怎麼定？
Katz Boaz TGO鯤鵬會 昨天
技術團隊 KPI 衡量標準應該是什麼呢？是程式碼行數？查殺 bug 數:)？還是什麼？

一年半之前，我一直在 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 為釋出到生產環境需要經過的每個步驟想象成一個漏斗：審查時間 > 審批時間 > 合併時間。

我們希望有一個明確的內部 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，無緊急工單。