看懂这5幅图,研发效能分析和改进就容易了
簡介:作為 CTO 或企業管理者,我們如何去了解和衡量研發團隊的研發效能呢?作為 PMO 和效能負責人,我們該從哪幾個維度來回答關于研發效能的問題呢?如何通過效能數據分析,幫助企業管理者透明化研發效能水平和變化趨勢,分析效能問題根因、指導改進行動、衡量改進效果。
作為 CTO 或企業管理者,我們如何去了解和衡量研發團隊的研發效能呢?
作為 PMO 和效能負責人,我們該從哪幾個維度來回答關于研發效能的問題呢?
帶著這兩個問題,我們進入到研發效能分析的場景,聊一聊我們如何通過效能數據分析,幫助企業管理者透明化研發效能水平和變化趨勢,分析效能問題根因、指導改進行動、衡量改進效果。
注:以下內容分為視頻版和文字版,讀者可自選學習。
觀看地址:騰訊視頻
在云效效能洞察 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 個方面理解和分析:
缺陷修復分布圖,對于團隊來說,可用于在回顧會上分析團隊過去的質量情況,也可根據歷史的情況,來設定團隊的缺陷修復目標。
整體回顧
我們可以從產能、效率和質量 3 個維度來觀測團隊的研發效能現狀,并進行針對性分析,重點觀測 5 幅圖:
- 需求交付速率:反應團隊歷史的需求交付吞吐量,可對未來的交付產能進行預測;
- 需求交付分布:反應團隊歷史的需求響應能力,可對未來的需求交付速度進行預測;
- 需求累積流圖:反應團隊整體的協作模式,可分析團隊的交付模式和交付能力;
- 缺陷趨勢圖:反應團隊歷史的過程質量情況,可分析團隊的交付模式和質量狀況;
- 缺陷修復分布:反應團隊歷史的缺陷修復速度,可對團隊的缺陷修復速度進行預測。
如果需要更多數據進行分析,也可以參考:需交付時長按階段分布、 需求累積流圖、存量缺陷按成員排名、存量缺陷占比等。
不管在阿里內部,還是我們接觸的大部分客戶,大家通常以縮短需求交付周期為目標。阿里提出的“ 211” 目標中,第一個 2 就是要把需求交付周期縮短到到兩周。
原文鏈接
本文為阿里云原創內容,未經允許不得轉載。?
總結
以上是生活随笔為你收集整理的看懂这5幅图,研发效能分析和改进就容易了的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 【ClickHouse 技术系列】- C
- 下一篇: Quick BI V4.0功能“炸弹”来