文章來自：ThoughtWorks，世界經理人經授權轉載。
長久以來，如何有效衡量軟件研發效能是所有研發管理者心心念念的事，但也一直是個(ge) 未解的難題。從(cong) 早期的人均代碼行到人均功能點公式計算，再到基於(yu) 故事點的迭代速率或人均吞吐量，業(ye) 界一直在探索。
有失偏頗的指標
人均代碼行，若作為(wei) 關(guan) 鍵指標，與(yu) 更優(you) 秀程序員應該用更優(you) 雅和少的代碼這一邏輯相悖，且將軟件編程這一腦力勞動等同於(yu) 砌磚速度，顯然是不合理的。
功能點計算，通過基於(yu) 需求分析和設計後確定要修改的頁麵數、接口數等多種因素構成的複雜公式計算，看似客觀，然而忽視了軟件研發工作的多樣性。渠道側(ce) 應用的界麵更多，功能點數容易更大，但還有偏後端開發、基礎平台開發、數據和報表開發、算法開發等多種類型的工作，前端開發也存在采用不同框架帶來的差異性，不可能用幾個(ge) 公式客觀衡量團隊的產(chan) 能；另外，越來越複雜的計算公式要依賴準確的設計，且很難讓每個(ge) 人都理解，需要人投入專(zhuan) 門的時間來計算，這種沒有價(jia) 值創造的工作本來就是一種浪費。
隨著的發展，故事點作為(wei) 一種基於(yu) 團隊集體(ti) 評估複雜度的工具可用於(yu) 衡量細粒度需求的大小。一些管理者於(yu) 是考慮用人均故事點來衡量產(chan) 能。然而故事點沒有單位、不同團隊故事點基準可以不同，以及評估的主觀性特點，讓人均故事點、迭代速率很難作為(wei) 令人滿意的。
關鍵的研發效能指標集
經過多年的探索總結，DevOps社區提出了衡量IT績效的四個(ge) 關(guan) 鍵指標，包括前置時間（或交付周期）、部署頻率、部署失敗率和線上失敗恢複時長，簡稱“4 Key Metrics”。這是一個(ge) 很好的方向。不過在實踐中，我們(men) 發現實際要關(guan) 心的關(guan) 鍵指標其實不止這四個(ge) ，例如生產(chan) 缺陷率就是必不可少的關(guan) 鍵結果，需求吞吐量也常常很受關(guan) 注。下麵是實踐中常見的研發過程度量指標，其中部分是反映最終結果的關(guan) 鍵效能指標。
的關鍵原則
要觀察和評價(jia) 研發效能，就首先要定義(yi) 什麽(me) 是效能？簡單一句話，效能就是團隊能持續快速交付價(jia) 值的能力。目的是交付價(jia) 值，其研發核心能力在於(yu) “響應力”與(yu) “穩健性”，同時，響應力這一概念又可以從(cong) “流動速率”和“資源速率”兩(liang) 個(ge) 維度來觀察。前者是指價(jia) 值從(cong) 明確到交付用戶的周期時間，而後者是單位人力資源在單位時間裏交付價(jia) 值的數量，對創新與(yu) 敏捷的要求使得前者的重要性更勝於(yu) 後者。
因此，要評價(jia) 效能，這裏就有幾個(ge) 關(guan) 鍵原則：
1.任何單一指標並不能合理地觀察和評價(jia) 一個(ge) 團隊的效能，否則會(hui) 產(chan) 生副作用。例如單一看吞吐量，會(hui) 驅使團隊一味拆需求，或犧牲質量；若單一看交付周期時間，可能驅使團隊減少需求流入。
2.評價(jia) 效能盡可能看全局結果，而非階段性表現，例如一次轉測通過率這樣的指標通常很重要，反映開發階段內(nei) 建質量的效果，然而用於(yu) 評價(jia) 效能不合適，它反映的不是團隊整體(ti) 表現。
3.效能評價(jia) 原始數據應該是來自工具的客觀記錄，不需要人工計算，不需要為(wei) 評價(jia) 浪費時間，且對所有團隊是一視同仁的。
4.考慮到軟件研發工作種類的多樣性和以腦力勞動為(wei) 主的工作性質，研發效能的觀察更多應關(guan) 注團隊的改進趨勢，而非橫向對比的絕對數值。
那怎麽(me) 才能更合理有效地達成觀察和評價(jia) 效能的目的呢？最直接的辦法，也是最理想的，就是學會(hui) 觀察分析一組核心指標，例如同時拿出4 Metrics的數據趨勢，或者上麵圖中的關(guan) 鍵效能指標數據趨勢進行分析和觀察。一些成熟的企業(ye) 會(hui) 將這些關(guan) 鍵指標做成Dashboard（儀(yi) 表盤），便於(yu) 觀察者一目了然分析全局狀況。這就像做數字化運營的數據分析一樣，隻有通過一組數據的對比分析才能得到相對有效的洞察。強烈建議每一位效能管理者、過程改進者以驅動改進為(wei) 目標，學會(hui) 和習(xi) 慣以這種方式來評價(jia) 一個(ge) 團隊的效能情況。
觀察效能的綜合評價指標
但這一理想方式對觀察者要求較高，需要充分理解每一個(ge) 指標的含義(yi) 和內(nei) 在邏輯，並且這樣一組核心指標對於(yu) 反映宏觀的效能改進趨勢還是不夠直觀，認知負載有點高。尤其對於(yu) 一些管理層和外部人員，看不出整體(ti) 效能到底是變好還是變差了。想要解決(jue) 這個(ge) 問題，我想到了一些類似的解決(jue) 方案。
國家需要一些指標來持續觀察一個(ge) 經濟體(ti) 的整體(ti) 經濟狀況，典型的像居民消費價(jia) 格指數（CPI）、購買(mai) 力平價(jia) 指數（PPP），都是采用一籃子指標基於(yu) 某種內(nei) 在邏輯構成的複合指標。好處是：
1.雖然不能說明問題根因在哪裏，但能更直觀反映全局表現
2.其變化可綜合多種因素的影響，可體(ti) 現不同因素對整體(ti) 評價(jia) 的影響程度
3.降低了為(wei) 使得單一指標好看而采取片麵行為(wei) 的可能性
於(yu) 是，在實踐案例中，我們(men) 設計了下麵這樣的概念公式，綜合了六個(ge) 要素來產(chan) 生一個(ge) 綜合評價(jia) 指數（研發效能CEI），可以以周或月進行統計：
綜合效能 = （交付吞吐量 部署頻率 發布成功率） / （需求交付周期 線上穩定性 債(zhai) 務積壓）
交付吞吐量
反映資源速率，通常是指單位時間交付需求的個(ge) 數，但這是六個(ge) 要素中最難以有效計算的，因為(wei) 與(yu) 需求顆粒度有關(guan) 。功能點、故事點都需要人為(wei) 評估，且存在以上一些問題。於(yu) 是采用一個(ge) 自然產(chan) 生的近似值：故事開發時長，即從(cong) 開始開發到開發完成的時間，依靠看板中的故事拖動產(chan) 生。盡管這一時長可能受個(ge) 體(ti) 開發效率影響，但在統計學意義(yi) 上可以近似代表需求大小。開發時長還受到同時並行工作的故事數的影響，同樣大小，並行越多，時長越長。因此交付吞吐量的人均值計算如下：
交付吞吐量 = 交付故事個(ge) 數 * （平均故事開發時長 / 平均的人均故事開發WIP）/ 團隊Size
部署頻率
這個(ge) 指標就是人均的發布單元部署次數，理論上團隊規模越大能夠交付越多的需求，應該更頻繁地交付特性。為(wei) 了提高頻率，這個(ge) 指標會(hui) 驅使團隊拆分部署單元。考慮到部署頻率相對吞吐量和周期時間對整體(ti) 效能評價(jia) 的重要性相對較低，因此其影響通過冪函數降級。部署頻率 = （部署單元部署次數 / 團隊Size）^（1/e）
發布成功率
這一指標較簡單，即每次上線發布的成功率，隻要發生回滾或新版本產(chan) 生重要故障即視為(wei) 不成功。由於(yu) 這一指標是百分率，比率越高提升困難越大，因此采用以下指數函數參與(yu) 計算：
發布成功率 = e ^ 版本發布成功率
需求交付周期
這是反映流動速率的關(guan) 鍵指標，即從(cong) 需求確認到需求上線的周期時長，衡量團隊對價(jia) 值的響應速度。這裏對需求的統計尺度不采用故事，而是采用可獨立上線的特性或用戶需求。需求交付周期 = 平均特性交付周期
線上穩定性
對線上穩定性的衡量可以綜合幾個(ge) 不同角度的基礎指標，人均生產(chan) 缺陷、停機時長和線上失敗恢複時長。考慮到人均生產(chan) 缺陷、停機時長和線上失敗恢複時長數值可能為(wei) 0，且數字越小越難提升，以及這幾個(ge) 指標數值的波動性很大，因此通過以下冪函數降級。線上穩定性 = （（（生產(chan) 缺陷個(ge) 數+1）/ 團隊Size （停機時長+1）（線上失敗平均恢複時長+1））^ （1/e）
債務積壓
最後一個(ge) 因素我認為(wei) 需要加進來。這裏所謂的“債(zhai) 務”是指各類團隊應當及時解決(jue) 然而未解決(jue) 的問題，包括需求積壓、缺陷積壓、技術債(zhai) 務。團隊在快速交付過程中可能欠下很多債(zhai) 務。如果忽略了技術債(zhai) 務、缺陷積壓，一段時間裏的高速率其實隻是掩蓋了問題。而對於(yu) 需求積壓，即便團隊自己認為(wei) 效能很高，然而站在業(ye) 務方角度，其效能仍無法滿足需要，其感知到的效率不高。缺陷積壓即未解決(jue) 的缺陷；需求積壓是業(ye) 務提出但超過一定時限仍未進入交付的需求；技術債(zhai) 務目前容易量化的是代碼債(zhai) 務，例如Sonar掃描的結果，如果可能也可以包括架構債(zhai) 務的數量。當然，考慮到這幾類積壓的重要性差異，賦予一定權重。人均的積壓計算如下：
債(zhai) 務積壓 = （需求積壓 50% + 缺陷積壓 30% + 技術債(zhai) 務量 / 10 * 20%）/ 團隊Size
最後，綜合考慮到分子和分母計算中均有兩(liang) 次團隊Size參與(yu) 計算，可考慮簡化將其相互抵消，形成如下最終計算公式：
下麵是實踐中基於(yu) 實際度量數據形成的綜合評價(jia) 指數曲線和源數據示例。我們(men) 能夠直觀的看到綜合多種因素後團隊整體(ti) 效能的變化。在圖中額外自動生成了一條紅色趨勢線（虛線），能夠體(ti) 現一段時間周期內(nei) ，效能的總體(ti) 變化趨勢是變好還是變差以及變化幅度大小。由於(yu) 團隊工作的多樣性，可能不同類型的團隊計算出的指數結果數值差異較大，因此該曲線主要用於(yu) 團隊與(yu) 自己過往相比，或者在工作性質類似的研發團隊之間做橫向比較。
綜合指標應用場景和意義
通過統計和觀察該綜合指標，可以有效解決(jue) 前麵單一指標、人工統計的問題，且能反映出不同維度指標因素對綜合效能的影響程度。那麽(me) 該指標趨勢對誰有用呢？實踐中有以下幾種應用場景：
1.對於(yu) 高層管理者或不熟悉效能數據分析的人，可以向其直觀展現團隊和組織的效能變化，作為(wei) 溝通研發效能的基礎；
2.對於(yu) 部門和團隊負責人、教練，能夠快速了解團隊的效能總體(ti) 變化；當曲線發生顯著波動時，再深入展開分析是哪幾個(ge) 因素導致了整體(ti) 結果波動，從(cong) 而采取改進措施；
3.當部門或團隊設定效能提升的目標時，如OKR，可以用綜合指數作為(wei) 衡量目標達成的關(guan) 鍵結果，避免團隊片麵地關(guan) 注單一指標提升，而是關(guan) 注綜合結果，在重點提升個(ge) 別指標的同時，也要確保其它關(guan) 鍵指標不下滑。
該指標公式也還有很多改進空間，例如不同的企業(ye) 、部門對效能的解讀不同，或者對不同關(guan) 鍵指標的重視程度不同，可以適當調整公式中的影響程度因子或權重。或者，在對發布成功率、生產(chan) 缺陷等因素如何作用於(yu) 最終結果的算法上，可能有更科學準確的公式，也可以改進它，歡迎提出建議。
