下圖是一個某研發(fā)團(tuán)隊(duì)近半年的數(shù)據(jù)，您看到這三張圖尤其是框了紅色的部分，會得到什么樣的信息呢?大家可以先看一下然后再往下面去看我對這些數(shù)據(jù)的認(rèn)識。

??

根據(jù)上面這三張圖的數(shù)據(jù)，我們可以得到的關(guān)于這個團(tuán)隊(duì)的信息是：

(1)3月份完成的需求數(shù)量是最多的，比其它***的月份也要高40%左右。

(2)3月份的缺陷數(shù)也是各個月份***的。

(3)3月份線上發(fā)布的成功率是***的。

結(jié)合3月份這個對于我們阿里很特別的日子，我們可以大膽做一些推測：這個月份我們研發(fā)人員的負(fù)載其實(shí)是相當(dāng)重的，大家可能會去趕工完成更多的工作(需求)，趕工干活可能引起的副作用就是質(zhì)量上的下滑，增多了很多的缺陷數(shù)和下降了不少的發(fā)布成功率也是印證了這一點(diǎn)。

so數(shù)據(jù)是會說話的，那我們該怎么去聽它說話呢?如果你覺得，哎呦，這個挺有意思，那么，就讓我?guī)е阕咭槐槿绾卫迷菩系倪@些研發(fā)數(shù)據(jù)，去了解團(tuán)隊(duì)現(xiàn)狀、發(fā)現(xiàn)團(tuán)隊(duì)中可能存在的問題、再結(jié)合團(tuán)隊(duì)具體實(shí)際情況去做調(diào)整和改進(jìn)，從而達(dá)到提升團(tuán)隊(duì)整體效率和質(zhì)量的目標(biāo)。

前言

先表示感謝和敬意：本文中所有數(shù)據(jù)都來自云效度量數(shù)據(jù)功能頁面截圖(部分?jǐn)?shù)據(jù)功能云效暫未開放給所有用戶，所以截圖會有些許區(qū)別)。我會在本文就各種具有關(guān)鍵表征的數(shù)據(jù)進(jìn)行介紹，但是詳細(xì)數(shù)據(jù)包括您的研發(fā)團(tuán)隊(duì)的數(shù)據(jù)，還是需要您親自訪問云效公有云度量功能頁面。

我是傳送門：??https://rdc.aliyun.com/my/metric??

這個推導(dǎo)我深信不疑：團(tuán)隊(duì)效率高，質(zhì)量好-> 數(shù)據(jù)表征好

于是我也是充分的利用了云效公有云度量功能，加之以偷師學(xué)來的敏捷部分方法指導(dǎo)，實(shí)踐于某事業(yè)部幾十號人的團(tuán)隊(duì)，3月有余，所沉淀下來的一些asset，以及取得的成果，希望能有一些借鑒意義給到大家。

數(shù)據(jù)展現(xiàn)

先直接給大家數(shù)據(jù)，我是4月份開始進(jìn)入這個團(tuán)隊(duì)的。大家重點(diǎn)看這個團(tuán)隊(duì)3月份的數(shù)據(jù)：

??

??

問題分析

上面幾張圖比較容易看出來，其實(shí)跟引子里面提到的情況差不多，這個團(tuán)隊(duì)明顯特征是

(1)3月份完成需求數(shù)明顯上升，且團(tuán)隊(duì)負(fù)載較重

(2)質(zhì)量不高 - 缺陷數(shù)、reopen率以及線上發(fā)布成功率

(3)需求平均完成時長特別長 ，很多需求都是很久之前的3月份才完成

(4)突增故障

于是我們帶著數(shù)據(jù)暴漏出來的這幾個問題走進(jìn)了團(tuán)隊(duì)，和團(tuán)隊(duì)一線研發(fā)人員、PD、TL都進(jìn)行了溝通，并把數(shù)據(jù)展現(xiàn)給他們和大家一起去分析數(shù)字背后的意義，大家比較快的達(dá)成了一致，發(fā)現(xiàn)團(tuán)隊(duì)存在的主要問題是：

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

(2)大家加班加點(diǎn)的干活，負(fù)載較重，引入的缺陷也較多，PD和用戶不滿意帶來的修改又會加重工作量，如此惡性循環(huán)。

(3)缺陷重視度不高，管理不規(guī)范，優(yōu)先級劃分不清楚，甚至殘留重要缺陷留在bug列表里面未解決而流到了線上引發(fā)故障。

上面三點(diǎn)相當(dāng)于形成了個閉環(huán)，惡性循環(huán)，其結(jié)果就是，越做越多，越多越錯，越錯越改，越改越多。

解決方案落地和數(shù)據(jù)運(yùn)營

發(fā)現(xiàn)了大家的問題之后，有針對性的進(jìn)行解決和落地就相對容易，給到團(tuán)隊(duì)的解決方案是：

(1)需求細(xì)化，拆分成最小可交付產(chǎn)出，盡量避免一個需求做了1個多月才去和PD和用戶驗(yàn)收。

(2)隨時擁抱用戶，迭代式產(chǎn)出，交付即驗(yàn)收，讓不準(zhǔn)確性降到***，在錯誤誤差最小的時候修正。

(3)重點(diǎn)跟進(jìn)質(zhì)量管理和運(yùn)營，透明數(shù)據(jù)，鼓勵團(tuán)隊(duì)盡早盡快修復(fù)bug，并有嚴(yán)格的上線前bug解決率標(biāo)準(zhǔn)。

(4)盡***力量保證線上發(fā)布成功率。

同時輔助于團(tuán)隊(duì)的決策，我們進(jìn)行定期的數(shù)據(jù)運(yùn)營，每周都會去統(tǒng)計(jì)和分析數(shù)據(jù)，包括質(zhì)量和效率相關(guān)的，確保我們能在***時間發(fā)現(xiàn)問題，糾正偏差，所以我這邊在整個3個多月的過程中，重點(diǎn)關(guān)注了如下的數(shù)據(jù)，這些數(shù)據(jù)都在云效上可以得到，云效還包括別的較為豐富的數(shù)據(jù)，期間如果別的數(shù)據(jù)反應(yīng)或者暴漏了問題，我也會納入進(jìn)來進(jìn)行整體分析，關(guān)于這些數(shù)據(jù)的解讀和分析，其內(nèi)容也比較深入，可以專門開一篇文章來講了，我這里只做簡單的概括性介紹：

(1)需求的吞吐量 - 團(tuán)隊(duì)指定時間段內(nèi)完成的需求數(shù)，可大體反應(yīng)出團(tuán)隊(duì)的產(chǎn)出趨勢。

(2)需求的平均完成時長 - 需求從創(chuàng)建到終態(tài)的平均時長，時間越多，需求交付粒度越小效率越高。

(3)新增缺陷的數(shù)量 - 統(tǒng)計(jì)時間段內(nèi)團(tuán)隊(duì)被新增指派的缺陷數(shù)量，結(jié)合存量缺陷以及缺陷平均解決時長，反應(yīng)團(tuán)隊(duì)產(chǎn)品的質(zhì)量以及對于缺陷解決的效率。

(4)缺陷的平均解決時長 - 缺陷從創(chuàng)建到解決的平均時長，表征解決缺陷的效率。

(5)線上發(fā)布的成功率 - 線上發(fā)布成功次數(shù)與總次數(shù)之比，越高證明產(chǎn)品上線質(zhì)量越高。

(6)缺陷的reopen率 - 缺陷被reopen的次數(shù)與缺陷數(shù)目之比，該值越高證明修復(fù)缺陷的質(zhì)量越差，reopen率是表征產(chǎn)品質(zhì)量的一個重要指標(biāo)。

結(jié)果分析和總結(jié)

大家回到上面的6張圖以及下面的一張缺陷解決時間圖，我們3月底進(jìn)入，重點(diǎn)看從4月份開始的數(shù)據(jù)：

(1)團(tuán)隊(duì)的負(fù)載得到了控制，需求的完成數(shù)下降了，后續(xù)3個月保持一個相對平穩(wěn)的狀態(tài)。

(2)需求細(xì)化拆分后，交付的時長下降了，團(tuán)隊(duì)以更快的速率去和用戶交付需求。

(3)缺陷的數(shù)量下降，reopen率下降，線上發(fā)布成功率上升 - 質(zhì)量上在好轉(zhuǎn)。

(4)缺陷的平均解決時間明顯上升，團(tuán)隊(duì)更快的交付，更快的反饋問題，更快的解決問題。

??

總體而言，就是需求交付的快，得到的反饋快，修正錯誤/缺陷的成本低，缺陷也會慢慢收斂，質(zhì)量也會隨之提升，缺陷修復(fù)的也快了，這就是一個良性循環(huán)，概括總計(jì)就是：效率提高了，質(zhì)量也保證了。團(tuán)隊(duì)的人干活也是更加努力啦!~

進(jìn)一步提升

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

總結(jié)

數(shù)據(jù)有魅力，研發(fā)數(shù)據(jù)也一樣，我們使用它就是為了兩個目的：一是保證質(zhì)量;二是確保交付的速率。行走過程中深度使用了云效度量新功能，結(jié)合敏捷中部分理念，配合傳統(tǒng)測試方式保障，來助力研發(fā)團(tuán)隊(duì)。

可能有的人會質(zhì)疑，說用這么冰冷冷的數(shù)字的數(shù)字去衡量我們可愛的程序員哥哥嗎? 我的回答是：這不是衡量，數(shù)據(jù)只是手段，是幫助我們?nèi)ピ\斷團(tuán)隊(duì)的一個切實(shí)有效的手段。學(xué)會利用它并駕馭它。因此只需要我們：

1. 關(guān)注數(shù)據(jù)，讀懂?dāng)?shù)據(jù)

2. 重點(diǎn)問題，重點(diǎn)解決，優(yōu)先解決，一段時間只關(guān)注一個或很少的幾個問題

3. 相信團(tuán)隊(duì)的自驅(qū)能力，同時結(jié)合TL的管理與激勵，養(yǎng)成良好的團(tuán)隊(duì)建設(shè)力

***

研發(fā)團(tuán)隊(duì)那點(diǎn)事，每天打交道最多的就是需求、缺陷、代碼、發(fā)布、應(yīng)用、測試等等，這些和我們研發(fā)人員息息相關(guān)的數(shù)據(jù)，云效所擁有的，現(xiàn)在以研發(fā)大盤、團(tuán)隊(duì)空間、人員效能、質(zhì)量分布等多種維度整合到了數(shù)據(jù)平臺上，后續(xù)更會以定制化的方式滿足研發(fā)團(tuán)隊(duì)對于研發(fā)數(shù)據(jù)的需求。利用好這個工具，能幫助我們清晰的了解團(tuán)隊(duì)的現(xiàn)狀，暴漏問題，找到改進(jìn)措施，去提升團(tuán)隊(duì)效率和產(chǎn)品質(zhì)量。

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

***的***

絮絮叨叨說了很多，***貼幾張我在度量上截的某研發(fā)團(tuán)隊(duì)的數(shù)據(jù)展示，這個團(tuán)隊(duì)是我們最近接觸的團(tuán)隊(duì)，通過數(shù)據(jù)我們對這個團(tuán)隊(duì)的推測是：團(tuán)隊(duì)在質(zhì)量上需要提升，在缺陷的管理上需要加強(qiáng)。首先團(tuán)隊(duì)缺陷的數(shù)量逐月上升，這已經(jīng)是質(zhì)量不好的趨勢體現(xiàn)，另外缺陷的解決時間也沒有加快，這樣會導(dǎo)致越來越多的缺陷流到線上去，可見團(tuán)隊(duì)除去1月份無故障，后續(xù)幾個月都有故障。而且這個團(tuán)隊(duì)的線上發(fā)布成功率持續(xù)走低，開發(fā)對自己上線的代碼把控程度較低。 所以，找到這些數(shù)據(jù)表征的背后原因，并且著手去解決掉，是這個團(tuán)隊(duì)近期最迫切的事情了。

??

養(yǎng)成良好的研發(fā)習(xí)慣，保持高效的團(tuán)隊(duì)協(xié)作，應(yīng)該作為每個研發(fā)同學(xué)持之以恒的追求。

作者簡介：張冠楠，阿里巴巴技術(shù)專家，負(fù)責(zé)過阿里巴巴集團(tuán)運(yùn)維系統(tǒng)、研發(fā)中臺系統(tǒng)以及阿里云持續(xù)發(fā)布系統(tǒng)的質(zhì)量保障工作，致力于如何保障研發(fā)團(tuán)隊(duì)產(chǎn)品質(zhì)量，同時提升研發(fā)團(tuán)隊(duì)的研發(fā)效率。在質(zhì)量保障體系建設(shè)、持續(xù)集成領(lǐng)域、敏捷實(shí)踐領(lǐng)域和研發(fā)效能領(lǐng)域方面均有研究。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

??戳這里，看該作者更多好文??