如何用數據驅動企業研發效率提升？雲效2.0新品度量實踐解讀

下圖是阿裏某研發團隊近半年的數據，這三張圖尤其是紅框的部分，你會得到什麼樣的信息呢？

根據這三張圖的數據，我們可以得到以下信息。

（1）3月份完成的需求數量是最多的，比其他最高的月份也要高40%左右。

（2）3月份的缺陷數也是各個月份最高的。

（3）3月份線上發布的成功率是最低的。

結合3月份這個對於阿裏很特別的日子，我們可以大膽做一些推測：這個月研發人員的負載是相當重的，大家可能會去趕工完成更多的工作（需求），帶來的副作用就是質量上的下滑，缺陷數增加、發布成功率減少。

所以，數據是會說話的，那我們該怎麼去聽它說呢？今天阿裏巴巴技術專家張冠楠將帶我們一起，學習如何利用雲效上的研發數據，去了解團隊現狀，發現團隊中可能存在的問題，再結合團隊具體實際情況去做調整和改進，從而達到提升團隊整體效率和質量的目標。

張冠楠：阿裏巴巴技術專家。負責過阿裏巴巴集團運維係統、研發中台係統以及阿裏雲持續發布係統的質量保障工作，致力於如何保障研發團隊產品質量，同時提升研發團隊的研發效率。在質量保障體係建設、持續集成領域、敏捷實踐領域和研發效能領域方麵均有研究。

本文是我充分利用雲效公有雲度量功能，加上敏捷部分的方法指導，實踐於某事業部幾十人團隊沉澱的成果，希望能給大家一些借鑒意義。團隊效率高，質量好，所以數據表征好。我會就各種具有關鍵表征的數據進行介紹，但是詳細數據，包括您的研發團隊的數據，還需要訪問雲效公有雲度量功能頁麵。

注：本文數據來自雲效度量數據功能頁麵截圖（部分數據功能雲效暫未開放給所有用戶，所以截圖會有些許區別）。

先直接給大家數據，我是4月份開始進入這個團隊的。大家重點看這個團隊3月份的數據：

上麵幾張圖比較容易看出來，這個團隊的明顯特征是：

（1）3月份完成需求數明顯上升，且團隊負載較重。

（2）質量不高-缺陷數、reopen率以及線上發布成功率。

（3）需求平均完成時長特別長。

（4）突增故障。

於是我們帶著數據暴露出來的這幾個問題，和團隊一線研發人員、PD、TL進行溝通，和大家一起分析數字背後的意義。大家很快達成一致，發現團隊存在的主要問題是：

（1）需求deliver傳統瀑布模型，要1個半到2個月去完成一個特別大的需求，最後卻和用戶期望偏差較大，數據表征上就是之前需求數量較少，3月份突然完成了很多而且時間很長的需求。

（2）大家加班加點幹活，負載較重，引入的缺陷也較多，PD和用戶不滿意帶來的修改又會加重工作量，如此惡性循環。

（3）缺陷重視度不高，管理不規範，優先級劃分不清楚，甚至殘留重要缺陷，留在bug列表裏未解決而流到了線上引發故障。

上麵三點形成了惡性循環，結果就是越做越多，越多越錯，越錯越改，越改越多。

發現問題之後，有針對性的進行解決和落地就相對容易，我們給到團隊的解決方案是：

（1）需求細化：拆分成最小可交付產出，盡量避免一個需求做了1個多月，才去找PD和用戶驗收。

（2）隨時擁抱用戶：迭代式產出，交付即驗收，讓不準確性降到最低，在錯誤誤差最小的時候修正。

（3）重點跟進質量管理和運營：透明數據，鼓勵團隊盡早盡快修複bug，並有嚴格的上線前bug解決率標準。

（4）盡全力保證線上發布成功率。

同時輔助於團隊的決策，我們進行定期的數據運營，每周都會去統計和分析數據，包括質量和效率相關的，確保我們能在第一時間發現問題，糾正偏差。所以在3個多月的時間裏，我重點關注了如下數據，這些數據也都可以在雲效上得到。關於這些數據的解讀和分析，內容比較深入，我這裏隻做簡單的概括性介紹：

（1）需求的吞吐量：團隊指定時間段內完成的需求數，可大體反應出團隊的產出趨勢。

（2）需求的平均完成時長：需求從創建到終態的平均時長，時間越多，需求交付粒度越小效率越高。

（3）新增缺陷的數量 ：統計時間段內團隊被新增指派的缺陷數量，結合存量缺陷以及缺陷平均解決時長，反應團隊產品的質量以及對於缺陷解決的效率。

（4）缺陷的平均解決時長 ：缺陷從創建到解決的平均時長，表征解決缺陷的效率。

（5）線上發布的成功率：線上發布成功次數與總次數之比，越高證明產品上線質量越高。

（6）缺陷的reopen率 ：缺陷被reopen的次數與缺陷數目之比，該值越高證明修複缺陷的質量越差，reopen率是表征產品質量的一個重要指標。

大家回到上麵的6張圖以及下麵的一張缺陷解決時間圖，我們3月底進入，重點看從4月份開始的數據：

（1）團隊的負載得到了控製，需求的完成數下降了，後續3個月保持一個相對平穩的狀態。

（2）需求細化拆分後，交付的時長下降了，團隊以更快的速率去和用戶交付需求。

（3）缺陷的數量下降，reopen率下降，線上發布成功率上升，質量在好轉。

（4）缺陷的平均解決時間明顯上升，團隊更快的交付，更快的反饋問題，更快的解決問題。

總體而言，就是需求交付的快，得到的反饋快，修正錯誤/缺陷的成本低，缺陷也慢慢收斂，質量也隨之提升，缺陷修複的也快了，這就是一個良性循環，概括就是：效率提高了，質量也保證了，團隊的人幹活也更加努力了！

根據對需求數量以及平均完成時長的數據顯示，團隊還是有上升空間的，對於需求的交付粒度和速率上，還是略顯波動，要想更快的知道我們做的是否是用戶需要的，就要快速的、迭代式的交付需求，以免用戶想要個車，我們給了他4個輪子。所以能否徹底解決此團隊需求的交付和用戶期望偏差的問題，還是需要再向前走一步，需求繼續細化，提升交付速率。 參見敏捷中推薦的，快速迭代，快速交付，快速得到用戶反饋，隻為了更快更準確。

數據有魅力，研發數據也一樣，我們使用它就是為了兩個目的：一是保證質量；二是確保交付的速率。行走過程中深度使用了雲效度量新功能，結合敏捷中部分理念，配合傳統測試方式保障，來助力研發團隊。

可能有的人會質疑，需要用這麼冰冷冷的數字去衡量我們可愛的程序員哥哥嗎？ 我的回答是：這不是衡量。數據隻是手段，是幫助我們去診斷團隊的一個切實有效的手段。學會利用它並駕馭它。因此我們隻需要：

（1）關注數據，讀懂數據。

（2）重點問題重點解決，優先解決，一段時間隻關注一個或很少的幾個問題。

（3）相信團隊的自驅能力，同時結合TL的管理與激勵，養成良好的團隊建設力。

研發團隊每天打交道最多的就是需求、缺陷、代碼、發布、應用、測試等等，這些和我們研發人員息息相關的數據，雲效現在以研發大盤、團隊空間、人員效能、質量分布等多種維度數據整合到了數據平台上，後續更會以定製化的方式滿足研發團隊對於研發數據的需求。利用好這個工具，能幫助我們清晰的了解團隊的現狀，暴露問題，找到改進措施，提升團隊效率和產品質量。

我是一個敏捷愛好者，在深入研發團隊做測試以及質量管理的時候，也是吸取和借鑒了敏捷的部分思想去落地。我的感受是：拿最切實有用比如站會、看板、快速迭代式交付需求，再加上數據輔助，都是能幫助到團隊更快、更準確的交付高質量產品的手段。

最後貼幾張我在度量上截的某研發團隊的數據展示，這個團隊是我們最近接觸的團隊，通過數據我們對這個團隊的推測是：團隊在質量上需要提升，在缺陷的管理上需要加強。首先團隊缺陷的數量逐月上升，這已經是質量不好的趨勢體現，另外缺陷的解決時間也沒有加快，這樣會導致越來越多的缺陷流到線上去，可見團隊除去1月份無故障，後續幾個月都有故障。而且這個團隊的線上發布成功率持續走低，開發對上線的代碼把控程度較低。 所以，找到這些數據表征的背後原因，並且著手去解決掉，是這個團隊近期最迫切的事情了。

養成良好的研發習慣，保持高效的團隊協作，應該是每個研發同學持之以恒的追求。

---

雲效，一站式企業協同研發雲，源於阿裏巴巴多年先進的管理實踐理念（精益創業、看板方法、Scrum、中台戰略、狼團隊）和工程實踐（微服務、DevOps、CI/CD、自動化測試），提供從“需求->開發->測試->發布->運維->運營”端到端的協同服務和研發工具支撐。升級後的雲效2.0支持公有雲、專有雲和混合雲的協同研發，助力企業產品快速創新迭代和研發效能升級。

（掃描/長按識別圖中二維碼）

• 11月02日20:00：Mock平台讓測試插上翅膀
  
• 11月02日20:30：測試數據中心-互聯網模式下新型的數據準備引擎
  
• 11月03日15:00：玩轉《阿裏巴巴開發手冊》 P3C插件
  
• 11月09日20:00：智能運維——百萬級服務器自動化運維怎麼玩？
  

（掃描/長按識別圖中二維碼）