作為 CTO 或企業管理者，我們如何去了解和衡量研發團隊的研發效能呢？
作為 PMO 和效能負責人，我們該從哪幾個維度來回答關于研發效能的問題呢？
帶著這兩個問題，我們進入到研發效能分析的場景，聊一聊我們如何通過效能資料分析，幫助企業管理者透明化研發效能水平和變化趨勢，分析效能問題根因、指導改進行動、衡量改進效果，
注：以下內容分為視頻版和文字版，讀者可自選學習，
觀看地址：https://v.qq.com/x/page/j3324np3qir.html
在云效效能洞察 Insight 中，我們可以從 3 個維度衡量和分析團隊的研發效能：
- 看交付速率：單位時間內，團隊能夠交付多少需求，即需求交付的吞吐量；
- 看回應能力：需求從提出到交付上線的時間長短，即需求交付周期；
- 看交付質量：交付程序中缺陷發現和修復的及時性，以及缺陷數量的多少，
看交付速率
在云效Insight的效能分析場景報表，通過「需求交付速率」指標卡，我們可以：
- 看到在單位時間內的需求交付量，及所選時間段內平均單位時間需求交付量；
- 看到需求交付速率趨勢，根據近期交付量來合理安排團隊將來的交付節奏和對外的承諾，
圖片來源：云效效能洞察Insight
需求交付速率：橫坐標為時間，以周為單位，縱坐標是需求的數量（個），柱子高低代表一周交付需求數量的多少，柱子的顏色分布分別對應交付周期的長短分布，
注：按需求個數統計的方式，因需求大小不一致會出現一些統計偏差，因此期望做需求交付統計時能夠將需求粒度拆分的相對較小且均勻，
在「需求交付速率」指標卡中，我們可以深入分析：
1. 根據團隊交付速率，評估團隊交付能力
我們可以根據團隊近期的交付速率，預測團隊將來的交付速率，以便更好地安排團隊未來可接納需求的作業量，比如最近 6 周，每周交付需求數量為 10，12，15，13，11，17，平均值為 13，我們可以預測團隊每周可交付需求數量在 13 個左右，當我們知道這個資料時，可以更好的安排需求交付的節奏和時間，并對外部承諾，
2. 通過觀測發布頻率，推進團隊持續交付
如果每周都有柱子，說明每周都有發布，如果柱子有間隔性，即每兩周有一個柱子，說明是兩周一次發布，以此類推，
看回應能力
通過云效Insight效能分析報表中的「需求交付分布」、「需求累積流圖」指標卡，我們可以看回應能力，
首先，在「需求交付分布」指標卡中，我們可以：
- 看到各需求上線時間的分布情況，反映團隊的需求發布頻率；
- 看到需求交付周期的趨勢，反映團隊對需求回應能力及變化趨勢；
- 通過歷史資料分析，預測將來的回應能力，
圖片來源：云效效能洞察Insight
指標卡中資料含義：
需求交付分布，也叫需求控制圖，橫坐標為時間，縱坐標為需求交付周期（天），圖中：
- 圓點：代表一個已交付的需求，它所在的橫坐標為交付時間，縱坐標為該需求交付時長；
- 折線：代表需求交付周期的滾動均值，取該點以及前后各1/3/5/7/9 點（隨區間事項數變動）的平均值；
- 面積：藍色陰影區域代表滾動標準差，即實際資料與滾動平均值的偏差量；
- 橫線：所選時間區間內，需求交付周期的平均值，
在看到「需求交付分布」的資料時，我們可以從 5 個方面進行理解和分析：
1、縱向上，交付需求的圓點越向下越好，反映出周期時間越短、回應能力越快，可預測性越好；
2、橫向上，交付需求的圓點分布越密越好，反映出需求在頻繁地交付，即發布頻率越高；
3、橫向上，交付需求的圓點分布越均勻越好，反映出需求在持續穩定地交付，更趨向于持續交付；如果圓點分布間斷而交付集中，可反映出是批量地交付需求；
圖片來源：云效效能洞察Insight
注：每個批量的間隔時間比較長（譬如2周或1個月以上），可采取減少需求進出的批量和增加發布視窗的措施，
4、交付周期線，代表在所選時間段內，交付周期的一個基本水位，該水位越低越好；
5、動均值折線，展示需求交付周期的變化趨勢，期望是有往下走的趨勢，代表團隊的回應能力在持續地提升，
「需求交付分布」可以反映出團隊是否已具備持續快速交付需求的能力，幫助團隊回顧和分析隊的效能情況，并根據歷史效能情況，設定團隊的效能目標，其次，對業務人員來說，可隨時查看交付團隊的效能情況，預測需求的上線時間，
「需求交付分布」是針對交付的結果進行度量，如果需要對整個交付程序進一步了分析，我們可以中點關注「需求累積流圖」，可綜合反映了前置時間（交付周期）、在制品數量、交付速率等指標，并體現了團隊協作、計劃和交付需求的模式，常用以發現系統性的改進機會，下面就對該圖進行進一步介紹，
通過「需求累積流圖」指標卡，我們可以：
- 看平均交付周期：需求在各階段的停留時長之和，指需求交付之前，從開始到結束所經歷的時間；
- 看在制品數量：需求在各階段的停留數量，可以反應出處理需求批量大小和并行度情況；
- 看交付速率：發布階段曲線的整體斜率，可以反應出團隊的需求交付速率，
圖片來源：云效效能洞察Insight
指標卡中資料含義：
累積流圖：橫坐標為日期，縱坐標為各個階段累積的需求數量；從左到右的每個階段，都是需求按順序變化的階段，相應的，曲線對應的分別是這些階段的累積完成的需求數量，
「需求累積流圖」同時具備整體性和動態性，它既反映了團隊整體的協作模式，端到端的動態交付程序，同時還反映了交付模式和交付能力的變化趨勢，我們可以從累積流圖中，分析團隊的協作和交付模式，并發現改進機會，我們從下面 3 個方面進行分析：
1. 團隊的計劃模式
主要看需求進入開發階段的數量和頻率，如一個專案中，進入開發階段的批量大，而且頻次低（譬如每月一次），往往是大批量的輸入，很容易出現大量需求并行，導致需求交付周期變短，反之，如果是小批量，多頻次的輸入，讓在制品數量變低，縮短需求交付周期；
2. 需求的轉測模式
需求大批量轉測，帶來的問題是，開發完成的需求，要等待較長時間才開始測驗，導致更多在制品，并延長了需求交付周期；
3. 需求的發布模式
需求發布會出現階梯狀，階梯的間隔越長，代表發布的頻率越少，也就是每個發布的間隔時間比較長，同時也可以看出來，發布間隔越長，則每次發布需求的數量就越多，而發布的難度隨著需求的增加而增加，
看交付質量
通過云效Insight效能分析報表中的「缺陷趨勢」和「缺陷修復分布」指標卡，我們可以：
- 看到缺陷被發現和修復的趨勢，反映團隊的交付模式；
- 看到存量缺陷的變化趨勢，發現與修復分布是否趨于合理，反映專案的質量狀況；
- 看到缺陷修復周期的變化趨勢，反映團隊對缺陷的及時修復能力，
首先，我們來看一下「缺陷趨勢」，如下圖：
圖片來源：云效效能洞察Insight
指標卡中資料含義：
缺陷趨勢圖：橫坐標為日期，縱坐標為缺陷數量，橫坐標上方紅色柱子代表這一天發現缺陷數量；橫坐標下方綠色柱子代表這一天解決的缺陷數量；橙色曲線代表缺陷存量，
在「缺陷趨勢」指標卡中，我們可以分析：
1. 看團隊的交付模式
如果長時間沒發現缺陷，而到某一段時間集中新增大量缺陷，能夠反映出是瀑布交付模式，如果缺陷被持續發現和持續解決，且存量缺陷處于較低水位，這種情況更容易形成持續交付模式，
2. 看存量缺陷的多少，判斷交付質量
需求在上線前，一般需要把缺陷數量清零，如果專案的存量缺陷一直處于較低水位，反映出交付質量比較高，
舉一個從小瀑布模式向持續交付模式轉變的例子，如圖：
圖片來源：云效效能洞察Insight
左半部分
團隊屬于小瀑布的開發模式，前期，團隊集中設計、編碼，引入缺陷，但并未即時地集成和驗證，缺陷一直掩藏在系統中，直到專案后期，團隊才開始集成和測驗，缺陷集中爆發，越到后期發現的缺陷，修復難度大幅提升，修復成本大幅增加，
小瀑布模式下，程序質量差，帶來大量的返工、延期和交付質量問題，該模式下，產品的交付時間依賴于何時缺陷能被充分移除，無法做到持續交付，也無法快速回應外部的需求和變化，并且，這一模式通常都導致后期的趕工，埋下交付質量隱患，
右半部分
團隊開始向持續交付模式演進，質量得到控制，在整個迭代程序中，團隊以小粒度的需求為單位開發，持續地集成和測驗它們，即時發現和解決問題，缺陷庫存得到控制，系統始終處于接近可發布狀態，這一模式更接近持續發布狀態，團隊對外的回應能力隨之增強，
接下來我們來看「缺陷修復分布」：
圖片來源：云效效能洞察Insight
指標卡中資料含義：
缺陷修復分布，也叫缺陷控制圖，橫坐標為時間，縱坐標為缺陷修復周期（天），圖中：
- 圓點：代表一個已修復的缺陷，它所在的橫坐標為修復時間，縱坐標為該缺陷的修復時長；
- 折線：代表缺陷修復周期的滾動均值，取該點以及前后各1/3/5/7/9個點（隨區間事項數變動）的平均值；
- 面積：紅色陰影區域代表滾動標準差，即實際資料與滾動平均值的變偏差量；
- 橫線：所選時間區間內，缺陷修復周期的平均值，
在看到「缺陷修復分布」圖的資料時，我們可以從 4 個方面理解和分析：
- 縱向上，代表已修復缺陷的圓點越向下越好，反映出修復周期越短、修復能力越快；
- 橫向上，代表已修復缺陷的圓點數量越少越好，越少代表缺陷的數量越少，開發提測的質量比較高；
- 平均修復時長線，代表團隊缺陷修復周期的一個基本水位，越低越好，很多團隊會設定缺陷修復目標，譬如缺陷要日清，即缺陷要在發現后的 24 小時內修復；
- 滾動均值折線，展示缺陷修復周期的變化趨勢，期望有往下走的趨勢，代表團隊修復缺陷的速度越來越快，
缺陷修復分布圖，對于團隊來說，可用于在回顧會上分析團隊過去的質量情況，也可根據歷史的情況，來設定團隊的缺陷修復目標，
整體回顧
我們可以從產能、效率和質量 3 個維度來觀測團隊的研發效能現狀，并進行針對性分析，重點觀測 5 幅圖：
- 需求交付速率：反應團隊歷史的需求交付吞吐量，可對未來的交付產能進行預測；
- 需求交付分布：反應團隊歷史的需求回應能力，可對未來的需求交付速度進行預測；
- 需求累積流圖：反應團隊整體的協作模式，可分析團隊的交付模式和交付能力；
- 缺陷趨勢圖：反應團隊歷史的程序質量情況，可分析團隊的交付模式和質量狀況；
- 缺陷修復分布：反應團隊歷史的缺陷修復速度，可對團隊的缺陷修復速度進行預測，
如果需要更多資料進行分析，也可以參考：需交付時長按階段分布、 需求累積流圖、存量缺陷按成員排名、存量缺陷占比等，
不管在阿里內部，還是我們接觸的大部分客戶，大家通常以縮短需求交付周期為目標，阿里提出的“ 211” 目標中，第一個 2 就是要把需求交付周期縮短到到兩周，
如果你想要體驗云效Insight 的敏捷專案度量場景報表，點擊下方鏈接，前往云效Insight 即可「免費試用」，
https://www.aliyun.com/product/yunxiao/insight?channel=yy_yc
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/431031.html
標籤：其他
上一篇：AndroidNavigationDrawer和Toolbar在所有Fragment中，加上TabLayout合二為一