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