看懂这5幅图，研发效能分析和改进就容易了
簡介：作為 CTO 或企業(yè)管理者，我們?nèi)绾稳チ私夂秃饬垦邪l(fā)團隊的研發(fā)效能呢？作為 PMO 和效能負責(zé)人，我們該從哪幾個維度來回答關(guān)于研發(fā)效能的問題呢？如何通過效能數(shù)據(jù)分析，幫助企業(yè)管理者透明化研發(fā)效能水平和變化趨勢，分析效能問題根因、指導(dǎo)改進行動、衡量改進效果。
作為 CTO 或企業(yè)管理者，我們?nèi)绾稳チ私夂秃饬垦邪l(fā)團隊的研發(fā)效能呢？
作為 PMO 和效能負責(zé)人，我們該從哪幾個維度來回答關(guān)于研發(fā)效能的問題呢？
帶著這兩個問題，我們進入到研發(fā)效能分析的場景，聊一聊我們?nèi)绾瓮ㄟ^效能數(shù)據(jù)分析，幫助企業(yè)管理者透明化研發(fā)效能水平和變化趨勢，分析效能問題根因、指導(dǎo)改進行動、衡量改進效果。
注：以下內(nèi)容分為視頻版和文字版，讀者可自選學(xué)習(xí)。
觀看地址：騰訊視頻
在云效效能洞察 Insight 中，我們可以從 3 個維度衡量和分析團隊的研發(fā)效能：
- 看交付速率：單位時間內(nèi)，團隊能夠交付多少需求，即需求交付的吞吐量；
- 看響應(yīng)能力：需求從提出到交付上線的時間長短，即需求交付周期；
- 看交付質(zhì)量：交付過程中缺陷發(fā)現(xiàn)和修復(fù)的及時性，以及缺陷數(shù)量的多少。
看交付速率
在云效Insight的效能分析場景報表，通過「需求交付速率」指標卡，我們可以：
- 看到在單位時間內(nèi)的需求交付量，及所選時間段內(nèi)平均單位時間需求交付量；
- 看到需求交付速率趨勢，根據(jù)近期交付量來合理安排團隊將來的交付節(jié)奏和對外的承諾。
圖片來源：云效效能洞察Insight
需求交付速率：橫坐標為時間，以周為單位，縱坐標是需求的數(shù)量（個），柱子高低代表一周交付需求數(shù)量的多少，柱子的顏色分布分別對應(yīng)交付周期的長短分布。
注：按需求個數(shù)統(tǒng)計的方式，因需求大小不一致會出現(xiàn)一些統(tǒng)計偏差，因此期望做需求交付統(tǒng)計時能夠?qū)⑿枨罅６炔鸱值南鄬^小且均勻。
在「需求交付速率」指標卡中，我們可以深入分析：
1. 根據(jù)團隊交付速率，評估團隊交付能力
我們可以根據(jù)團隊近期的交付速率，預(yù)測團隊將來的交付速率，以便更好地安排團隊未來可接納需求的工作量。比如最近 6 周，每周交付需求數(shù)量為 10，12，15，13，11，17，平均值為 13，我們可以預(yù)測團隊每周可交付需求數(shù)量在 13 個左右，當我們知道這個數(shù)據(jù)時，可以更好的安排需求交付的節(jié)奏和時間，并對外部承諾。
2. 通過觀測發(fā)布頻率，推進團隊持續(xù)交付
如果每周都有柱子，說明每周都有發(fā)布，如果柱子有間隔性，即每兩周有一個柱子，說明是兩周一次發(fā)布，以此類推。
看響應(yīng)能力
通過云效Insight效能分析報表中的「需求交付分布」、「需求累積流圖」指標卡，我們可以看響應(yīng)能力。
首先，在「需求交付分布」指標卡中，我們可以：
- 看到各需求上線時間的分布情況，反映團隊的需求發(fā)布頻率；
- 看到需求交付周期的趨勢，反映團隊對需求響應(yīng)能力及變化趨勢；
- 通過歷史數(shù)據(jù)分析，預(yù)測將來的響應(yīng)能力。
圖片來源：云效效能洞察Insight
指標卡中數(shù)據(jù)含義：
需求交付分布，也叫需求控制圖，橫坐標為時間，縱坐標為需求交付周期（天），圖中：
- 圓點：代表一個已交付的需求，它所在的橫坐標為交付時間，縱坐標為該需求交付時長；
- 折線：代表需求交付周期的滾動均值，取該點以及前后各1/3/5/7/9 點（隨區(qū)間事項數(shù)變動）的平均值；
- 面積：藍色陰影區(qū)域代表滾動標準差，即實際數(shù)據(jù)與滾動平均值的偏差量；
- 橫線：所選時間區(qū)間內(nèi)，需求交付周期的平均值。
在看到「需求交付分布」的數(shù)據(jù)時，我們可以從 5 個方面進行理解和分析：
1、縱向上，交付需求的圓點越向下越好，反映出周期時間越短、響應(yīng)能力越快，可預(yù)測性越好；
2、橫向上，交付需求的圓點分布越密越好，反映出需求在頻繁地交付，即發(fā)布頻率越高；
3、橫向上，交付需求的圓點分布越均勻越好，反映出需求在持續(xù)穩(wěn)定地交付，更趨向于持續(xù)交付；如果圓點分布間斷而交付集中，可反映出是批量地交付需求；
圖片來源：云效效能洞察Insight
注：每個批量的間隔時間比較長（譬如2周或1個月以上），可采取減少需求進出的批量和增加發(fā)布窗口的措施。
4、交付周期線，代表在所選時間段內(nèi)，交付周期的一個基本水位，該水位越低越好；
5、動均值折線，展示需求交付周期的變化趨勢，期望是有往下走的趨勢，代表團隊的響應(yīng)能力在持續(xù)地提升。
「需求交付分布」可以反映出團隊是否已具備持續(xù)快速交付需求的能力，幫助團隊回顧和分析隊的效能情況，并根據(jù)歷史效能情況，設(shè)定團隊的效能目標。其次，對業(yè)務(wù)人員來說，可隨時查看交付團隊的效能情況，預(yù)測需求的上線時間。
「需求交付分布」是針對交付的結(jié)果進行度量，如果需要對整個交付過程進一步了分析，我們可以中點關(guān)注「需求累積流圖」，可綜合反映了前置時間（交付周期）、在制品數(shù)量、交付速率等指標，并體現(xiàn)了團隊協(xié)作、計劃和交付需求的模式，常用以發(fā)現(xiàn)系統(tǒng)性的改進機會，下面就對該圖進行進一步介紹。
通過「需求累積流圖」指標卡，我們可以：
- 看平均交付周期：需求在各階段的停留時長之和，指需求交付之前，從開始到結(jié)束所經(jīng)歷的時間；
- 看在制品數(shù)量：需求在各階段的停留數(shù)量，可以反應(yīng)出處理需求批量大小和并行度情況；
- 看交付速率：發(fā)布階段曲線的整體斜率，可以反應(yīng)出團隊的需求交付速率。
圖片來源：云效效能洞察Insight
指標卡中數(shù)據(jù)含義：
累積流圖：橫坐標為日期，縱坐標為各個階段累積的需求數(shù)量；從左到右的每個階段，都是需求按順序變化的階段，相應(yīng)的，曲線對應(yīng)的分別是這些階段的累積完成的需求數(shù)量。
「需求累積流圖」同時具備整體性和動態(tài)性，它既反映了團隊整體的協(xié)作模式，端到端的動態(tài)交付過程，同時還反映了交付模式和交付能力的變化趨勢。我們可以從累積流圖中，分析團隊的協(xié)作和交付模式，并發(fā)現(xiàn)改進機會。我們從下面 3 個方面進行分析：
1. 團隊的計劃模式
主要看需求進入開發(fā)階段的數(shù)量和頻率，如一個項目中，進入開發(fā)階段的批量大，而且頻次低（譬如每月一次），往往是大批量的輸入，很容易出現(xiàn)大量需求并行，導(dǎo)致需求交付周期變短。反之，如果是小批量，多頻次的輸入，讓在制品數(shù)量變低，縮短需求交付周期；
2. 需求的轉(zhuǎn)測模式
需求大批量轉(zhuǎn)測，帶來的問題是，開發(fā)完成的需求，要等待較長時間才開始測試，導(dǎo)致更多在制品，并延長了需求交付周期；
3. 需求的發(fā)布模式
需求發(fā)布會出現(xiàn)階梯狀，階梯的間隔越長，代表發(fā)布的頻率越少，也就是每個發(fā)布的間隔時間比較長。同時也可以看出來，發(fā)布間隔越長，則每次發(fā)布需求的數(shù)量就越多，而發(fā)布的難度隨著需求的增加而增加。
看交付質(zhì)量
通過云效Insight效能分析報表中的「缺陷趨勢」和「缺陷修復(fù)分布」指標卡，我們可以：
- 看到缺陷被發(fā)現(xiàn)和修復(fù)的趨勢，反映團隊的交付模式；
- 看到存量缺陷的變化趨勢，發(fā)現(xiàn)與修復(fù)分布是否趨于合理，反映項目的質(zhì)量狀況；
- 看到缺陷修復(fù)周期的變化趨勢，反映團隊對缺陷的及時修復(fù)能力。
首先，我們來看一下「缺陷趨勢」，如下圖：
圖片來源：云效效能洞察Insight
指標卡中數(shù)據(jù)含義：
缺陷趨勢圖：橫坐標為日期，縱坐標為缺陷數(shù)量，橫坐標上方紅色柱子代表這一天發(fā)現(xiàn)缺陷數(shù)量；橫坐標下方綠色柱子代表這一天解決的缺陷數(shù)量；橙色曲線代表缺陷存量。
在「缺陷趨勢」指標卡中，我們可以分析：
1. 看團隊的交付模式
如果長時間沒發(fā)現(xiàn)缺陷，而到某一段時間集中新增大量缺陷，能夠反映出是瀑布交付模式。如果缺陷被持續(xù)發(fā)現(xiàn)和持續(xù)解決，且存量缺陷處于較低水位，這種情況更容易形成持續(xù)交付模式。
2. 看存量缺陷的多少，判斷交付質(zhì)量
需求在上線前，一般需要把缺陷數(shù)量清零，如果項目的存量缺陷一直處于較低水位，反映出交付質(zhì)量比較高。
舉一個從小瀑布模式向持續(xù)交付模式轉(zhuǎn)變的例子，如圖：
圖片來源：云效效能洞察Insight
左半部分
團隊屬于小瀑布的開發(fā)模式。前期，團隊集中設(shè)計、編碼，引入缺陷，但并未即時地集成和驗證。缺陷一直掩藏在系統(tǒng)中，直到項目后期，團隊才開始集成和測試，缺陷集中爆發(fā)。越到后期發(fā)現(xiàn)的缺陷，修復(fù)難度大幅提升，修復(fù)成本大幅增加。
小瀑布模式下，過程質(zhì)量差，帶來大量的返工、延期和交付質(zhì)量問題。該模式下，產(chǎn)品的交付時間依賴于何時缺陷能被充分移除，無法做到持續(xù)交付，也無法快速響應(yīng)外部的需求和變化。并且，這一模式通常都導(dǎo)致后期的趕工，埋下交付質(zhì)量隱患。
右半部分
團隊開始向持續(xù)交付模式演進，質(zhì)量得到控制。在整個迭代過程中，團隊以小粒度的需求為單位開發(fā)，持續(xù)地集成和測試它們，即時發(fā)現(xiàn)和解決問題。缺陷庫存得到控制，系統(tǒng)始終處于接近可發(fā)布狀態(tài)。這一模式更接近持續(xù)發(fā)布狀態(tài)，團隊對外的響應(yīng)能力隨之增強。
接下來我們來看「缺陷修復(fù)分布」：
圖片來源：云效效能洞察Insight
指標卡中數(shù)據(jù)含義：
缺陷修復(fù)分布，也叫缺陷控制圖，橫坐標為時間，縱坐標為缺陷修復(fù)周期（天），圖中：
- 圓點：代表一個已修復(fù)的缺陷，它所在的橫坐標為修復(fù)時間，縱坐標為該缺陷的修復(fù)時長；
- 折線：代表缺陷修復(fù)周期的滾動均值，取該點以及前后各1/3/5/7/9個點（隨區(qū)間事項數(shù)變動）的平均值；
- 面積：紅色陰影區(qū)域代表滾動標準差，即實際數(shù)據(jù)與滾動平均值的變偏差量；
- 橫線：所選時間區(qū)間內(nèi)，缺陷修復(fù)周期的平均值。
在看到「缺陷修復(fù)分布」圖的數(shù)據(jù)時，我們可以從 4 個方面理解和分析：
缺陷修復(fù)分布圖，對于團隊來說，可用于在回顧會上分析團隊過去的質(zhì)量情況，也可根據(jù)歷史的情況，來設(shè)定團隊的缺陷修復(fù)目標。
整體回顧
我們可以從產(chǎn)能、效率和質(zhì)量 3 個維度來觀測團隊的研發(fā)效能現(xiàn)狀，并進行針對性分析，重點觀測 5 幅圖：
- 需求交付速率：反應(yīng)團隊歷史的需求交付吞吐量，可對未來的交付產(chǎn)能進行預(yù)測；
- 需求交付分布：反應(yīng)團隊歷史的需求響應(yīng)能力，可對未來的需求交付速度進行預(yù)測；
- 需求累積流圖：反應(yīng)團隊整體的協(xié)作模式，可分析團隊的交付模式和交付能力；
- 缺陷趨勢圖：反應(yīng)團隊歷史的過程質(zhì)量情況，可分析團隊的交付模式和質(zhì)量狀況；
- 缺陷修復(fù)分布：反應(yīng)團隊歷史的缺陷修復(fù)速度，可對團隊的缺陷修復(fù)速度進行預(yù)測。
如果需要更多數(shù)據(jù)進行分析，也可以參考：需交付時長按階段分布、 需求累積流圖、存量缺陷按成員排名、存量缺陷占比等。
不管在阿里內(nèi)部，還是我們接觸的大部分客戶，大家通常以縮短需求交付周期為目標。阿里提出的“ 211” 目標中，第一個 2 就是要把需求交付周期縮短到到兩周。
原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?
總結(jié)
以上是生活随笔為你收集整理的看懂这5幅图，研发效能分析和改进就容易了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【ClickHouse 技术系列】- C
- 下一篇： Quick BI V4.0功能“炸弹”来