云效研發效能度量體系，如何展示和解讀交付效能資料，一個迭代或者一個周期結束后，團隊需要回顧復盤驅動效能改進，在回顧復盤前需要展示團隊當前的效能資料，通過研發效能度量來度量團隊是否具備了交付價值的能力， 作者：舍衛｜阿里巴巴集團技術專家 阿里巴巴研發效能度量體系（如下圖），通過五個維度來度量團隊是否具備了「順暢、高質量交付價值的能力」，包括需求回應周期、持續發布能力、交付吞吐率、交付程序質量和交付質量，期待能又快又多又好地交付需求，
1. 需求回應周期
具體包含兩個細分的指標，分別是：
?交付周期：指的是從確認用戶提出的需求開始，到需求上線所經歷的平均時長，它反映團隊（包含業務、開發、運營等職能）對客戶問題或業務機會的回應速度；
?開發周期：指的是從開發團隊理解需求開始，到需求可以上線所經歷的平均時長，它反映技術團隊的回應能力，
區分交付周期和開發周期，是為了解耦并明確問題，以做出針對性的改進，其中，交付周期是最終的目標和檢驗標準，
需求累計流圖
云效有豐富的報表統計功能，接下來，我將帶領大家一起來學習如何在云效上配置上面的報表，
如下圖所示，從「統計」進入，點擊「新建報表」，可以看到云效的新建報表串列，
說明 立即體驗：云效專案管理
選擇「效能分析」，然后點擊「需求累計流圖」出現如下圖所示的報表：
每一個藍色的點代表一個已經發布的需求，橫軸是日期，縱軸是天數，這些藍色的點越朝下越好，代表需求的交付時間越短，回應力也越好；散點的密度越高代表交付頻率越高，散點橫向上更均勻分布代表持續交付的穩定性越好，
交付周期趨勢圖
選擇「效能分析」，然后點擊「交付周期報表」
如下圖，選擇按月統計，任務選擇「需求」，開始狀態選「已選擇」，結束狀態選「已發布」，更新左上角的圖表名稱為「交付周期趨勢圖」后保存，即可展現，
開發周期趨勢圖
選擇「效能分析」，然后點擊「交付周期報表」
如下圖，選擇按周統計，任務選擇「需求」，開始狀態選「就緒（待開發）」，結束狀態選「待發布」，更新左上角的圖表名稱為「開發周期趨勢圖」后保存，即可展現，
下圖是開發周期趨勢圖示例，橫軸是時間，按照自然周排列，縱軸是需求個數，每個柱子代表的是當周已到待發布狀態需求的數量，各柱子由不同的顏色堆積而成，藍色代表需求的開發周期時長小于1周，綠色代表需求的開發周期時長在1-2周之間，橙色代表需求的開發周期時長在2-4周之間，紅色代表需求的開發周期時長大于4周，
從上圖可以看出，需求開發周期在1周內的需求數量在持續增長，同時一周內的占比也在逐步提升，由于該資料是在8月15日取的，所以最后一周的資料還不全，
2. 持續發布能力
具體包含兩個細分指標，分別是：
?發布頻率：團隊對外回應的速度不會大于其交付頻率，發布頻率約束團隊對外回應和價值的流動速度，它的衡量標準是單位時間內的有效發布次數，
?發布前置時間（也被稱為變更前置時間）：也就是從代碼提交到功能上線花費的時間，它體現了團隊發布的基本能力，如果時間開銷很大，就不合適加大發版頻率 發布頻率 從需求控制圖上可以看出持續發布能力的變化，如果需求散點的密度越高，則交付頻率越高，反之則越低，
發布前置時間
發布前置時間，與團隊的工程能力有很大的關系，這和云效新品代碼平臺和流水線強相關，這里暫不做講解，
3. 交付吞吐率
指的是單位時間內交付需求的數量，關于這一點，常見的問題是，個數能準確反映交付效率嗎？這是個問題，所以，我們更多強調單個團隊的需求吞吐率的前后對比，統計意義上它足以反映趨勢和問題，
需求吞吐率趨勢圖（按周） 在需求回應周期的圖表中，需求吞吐率的趨勢也已呈現，下圖中縱軸代表這一周發布需求的數量，所以柱子越高代表這一周交付的需求越多， 這里吞吐率的計算是按照需求的數量來統計的，在需求顆粒度大小差別很大的時候，吞吐率資料會出現偏差，所以在統計這個之前，期待團隊能對需求進行拆分，拆分到作業量在2周之內，
需求吞吐率趨勢圖（按迭代）
在自定義圖表中選擇按迭代和任務狀態，然后添加兩個篩選條件：迭代和狀態，迭代選擇需要比較的幾個迭代，狀態只選已發布的需求，出現如下按照迭代進行比較的吞吐率趨勢圖，
4. 交付程序質量
它包含兩個細分的指標，分別是：
?開發程序中缺陷的創建和修復時間分布：我們希望缺陷能夠持續和及時地被發現，并且在發現后盡快修復； ?缺陷庫存：我們希望在整個開發程序中控制缺陷庫存量，讓產品始終處于接近可發布狀態，奠定持續交付的基礎， 交付程序質量的核心是內建質量，也就是全程序和全時段的質量，而非依賴特定的階段，如測驗階段；或特定的時段，如專案后期，內建質量是持續交付的基礎，關于其具體度量方法，下文會給出詳細實體， 缺陷趨勢圖
如上圖所示，圖中的橫坐標是日期，橫坐標上方紅色豎條代表這一天發現缺陷數量；橫坐標下方綠色豎條代表當天解決的缺陷數量；橙色曲線代表缺陷存量，圖中左右兩個部分比較了兩種交付模式，
左半部分，團隊屬于小瀑布的開發模式，“迭代”前期，團隊集中設計、編碼，引入缺陷，但并未即時地集成和驗證，缺陷一直掩藏在系統中，直到專案后期，團隊才開始集成和測驗，缺陷集中爆發，
小瀑布模式下，程序質量差，帶來大量的返工、延期和交付質量問題，該模式下，產品的交付時間依賴于何時缺陷能被充分移除，當然不能做到持續交付，也無法快速回應外部的需求和變化，并且，這一模式通常都導致后期的趕工，埋下交付質量隱患，
右半部分，團隊開始向持續交付模式演進，在整個迭代程序中，團隊以小粒度的需求為單位開發，持續地集成和測驗它們，即時發現和解決問題，缺陷庫存得到控制，系統始終處于接近可發布狀態，這一模式更接近持續發布狀態，團隊對外的回應能力隨之增強，
缺陷趨勢圖從一個側面反映了團隊的開發和交付模式，它引導團隊持續且盡早發現缺陷并及時移除它們，控制缺陷庫存，讓系統始終處于接近可發布狀態，保障了持續交付能力和對外回應能力，
在專案「統計」中，選擇「缺陷分析」，然后點擊「缺陷變化趨勢」出現如下圖所示，
5. 對外交付質量
它包含兩個細分的指標，分別是：
- 單位時間的故障（線上問題）數；
- 故障平均解決時長
小結
阿里巴巴研發效能度量體系，通過五個維度來度量團隊是否具備了「順暢、高質量交付價值的能力」，通過以上五組指標，從流動效率、資源效率和質量三個方面講述了一個完整的故事，回答了目前組織持續交付價值的能力如何這個核心問題，其中，持續發布能力和需求回應周期這兩組指標反映價值的流動效率；吞吐率反映資源效率；交付程序質量和對外交付質量這兩組指標共同反映質量水平，轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/301195.html
標籤：其他