一年半之前，我一直在bizzabo領導研發團隊。
自從成為負責人，我就在尋找衡量研發團隊績效的最佳方法，從而反映出團隊提供的真正價值。我們最初是使用行業標準度量來跟蹤團隊績效：度量計畫和交付。
下面是我們的團隊kpi：
我面臨的挑戰是，這些kpi與研發團隊的真正價值沒有直接聯絡。我們很容易實現這些kpi，即使速度很慢，質量很低。
經過6個月的迭代和修改，我決定定義研發kpi，以便更好地反映乙個運轉良好的研發團隊的價值——團隊的速度和質量。
我想暫停一下，了解下codeclimate團隊的產品velocity。它幫助我們走到今天。
讓我們來回顧一下，術語「研發速度」包含了什麼。
工作習慣
**質量
效率
為了選出可以實現最快速roi的kpi並優先關注，我們深入地了解了每一項。
每週編碼天數
團隊成員每週編碼的平均天數（定義為至少乙個提交的推送）。你可能認為乙個提交不能很好地反映情況，但是，我建議你從簡單的開始，或者提出乙個更好的、容易量化的指標。
每週編碼天數
每天**推送次數
每一名活躍的貢獻者在單位時間內有多少拉取請求（pr）被合併。
每天**推送次數
pr大小
對我們來說，pr多大合適，這需要我們更深入一點地了解。但是，我們不確定如何設定乙個明確的數值。關鍵是找到乙個**行數，我的同事用不到乙個小時的時間就可以完成**審查和pr審批。
**審查超過乙個小時就會成為一項具有挑戰性的任務，這樣，審查可能會不徹底。反過來，隨著更多的bug進入生產環境，節省33小時將成為一項挑戰。最佳的pr大小是小於250行**。實際上，我們大部分的pr都更小一些。
pr大小分布
從請求審查到合併的時間
把pr為發布到生產環境需要經過的每個步驟想象成乙個漏斗：審查時間 \u0026gt; 審批時間 \u0026gt; 合併時間。
我們希望有乙個明確的內部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。
返工比例
度量返工的方法沒有對或錯，因為這更多的是乙個特定於團隊或公司的指標。當一些團隊的工作從裡到外返工率更高時，或者當一些團隊在周密計畫之後開展工作時，有時正在進行快速的產品迭代，尤其如此。
主要的思想是回顧每個特性的開發，看看返工是不是由於需求的變化，或者缺乏足夠的技術指導。
pr放棄數量
如果拉取請求在未合併的情況下開啟並關閉，則認為它被「放棄了」。我們還把超過3天不活動的拉取請求包含了進來。這可以確保我們專注於最重要的任務，同時最小化上下文切換，保證我們的工作不會浪費。
當我們按年齡來觀察放棄的pr時，很明顯，超過30天的pr可能有90%永遠都不會再合併，換句話說，它是失落的**。清理完管道後，除去那些從未打算合併的pr（比如poc、測試和其他一些內部需求），我們將回顧任何老去的pr，並理解其原因。我們可以確定這是否是產品優先順序的改變，或者我們從來沒有因為錯誤的估計而終止一項計畫，等等。
你可以看到，專注於這個kpi並制定好流程，使我們的小組工作習慣更加一致；團隊之間的偏差變得更小了（自7月份以來，我們就啟用了新的kpi流程）。
每個squad放棄的pr
回退次數
合併後有多少**回退？回退通常是即時bug（質量）或對產品/功能缺失的快速了解所直接導致的結果。我們的目標不是乙個特定的數值，但是，我們確實會把每次回退作為乙個觸發器，進行一次專門的回顧。
1. 我們定義了良好的研發kpi所具有的屬性：
2. 在進行了上述所有分析之後，我們決定使用以下團隊kpi：
檢視英文原文：stop measuring r\u0026amp;d planning vs execution. start measuring team velocity
以評審制度促進團隊研發效率提公升
不論團隊大小，接到專案需求後，一定會對需求進行分解，進行相應設計，系統編碼，上線執行等幾個環節。在各環節中，需要進行相應的評審，在實際研發過程中，以筆者自己親身經歷，由於缺乏評審，導致專案上線後吃相很難看，客戶滿意度也不高。以下分享一下各環境的評審內容。一 系統需求評審。從客戶或者產品經理那拿到需求...
如何培養研發團隊的凝聚力
一 凝聚力的概念 凝聚力指團隊對成員的吸引力，成員對團隊的向心力，以及團隊成員之間的相互吸引。也有人把凝聚力定義力 團隊使成員積極從事團隊活動，拒絕離開的吸引力。團隊的凝聚力不僅是維持團隊存在的必要條件，而且對團隊潛能的發揮有重要作用。乙個團體如果失去了凝聚力，就不可能完成組織賦予的任務，本身也就失...
如何快速融入乙個研發團隊？
最近就要馬上入職新的公司了，離開上家公司也是迫不得已，但是為了自己的職業發展和眼界開闊，做出這樣的選擇已成自然。已經和三年多前的一次職業選擇不同了，畢竟已經有四年多的工作經驗了，需要做事有章法。關於如何快速融入乙個研發團隊？我有話說。1 適應環境，自我調整 前期以自己調整為主 融入乙個新的環境，每個...