一年半之前，我一直在 Bizzabo 領導研發團隊。
自從成為負責人，我就在尋找衡量研發團隊績效的最佳方法，從而反映出團隊提供的真正價值。我們最初是使用行業标準度量來跟蹤團隊績效：度量計劃和交付。
下面是我們的團隊 KPI：
我面臨的挑戰是，這些 KPI 與研發團隊的真正價值沒有直接聯系。我們很容易實現這些 KPI，即使速度很慢，質量很低。
經過 6 個月的叠代和修改，我決定定義研發 KPI，以便更好地反映一個運轉良好的研發團隊的價值——團隊的速度和質量。
我想暫停一下，了解下CodeClimate團隊的産品 Velocity。它幫助我們走到今天。
讓我們來回顧一下，術語“研發速度”包含了什麼。
工作習慣
代碼質量
效率
為了選出可以實現最快速 ROI 的 KPI 并優先關注，我們深入地了解了每一項。
每周編碼天數
團隊成員每周編碼的平均天數（定義為至少一個提交的推送）。你可能認為一個提交不能很好地反映情況，但是，我建議你從簡單的開始，或者提出一個更好的、容易量化的指标。
每周編碼天數
每天代碼推送次數
每一名活躍的貢獻者在單位時間内有多少拉取請求（PR）被合并。
每天代碼推送次數
PR 大小
對我們來說，PR 多大合适，這需要我們更深入一點地了解。但是，我們不确定如何設置一個明确的數值。關鍵是找到一個代碼行數，我的同事用不到一個小時的時間就可以完成代碼審查和 PR 審批。
代碼審查超過一個小時就會成為一項具有挑戰性的任務，這樣，審查可能會不徹底。反過來，随着更多的 Bug 進入生産環境，節省 33 小時将成為一項挑戰。最佳的 PR 大小是小于 250 行代碼。實際上，我們大部分的 PR 都更小一些。
PR 大小分布
從請求審查到合并的時間
把 PR 為發布到生産環境需要經過的每個步驟想象成一個漏鬥：審查時間 > 審批時間 > 合并時間。
我們希望有一個明确的内部 SLA，這樣，80% 的 PR 将在已知的時間内通過這個漏鬥。這是一種平衡，可能每個團隊的心态和文化會有所不同。一方面，我們不希望開發人員因為審查等待太長時間，另一方面，我們希望防止審查人員被迫暫停當前任務進行上下文切換。我們的目标是：
我們還規定，審查人員最多 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 所具有的屬性：
2. 在進行了上述所有分析之後，我們決定使用以下團隊 KPI：
查看英文原文：Stop measuring R&D planning VS execution. Start measuring team velocity
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
