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

??

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

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

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

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

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

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

前言

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

我是傳送門(mén)：??https://rdc.aliyun.com/my/metric??

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

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

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

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

??

??

問(wèn)題分析

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

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

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

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

(4)突增故障

于是我們帶著數(shù)據(jù)暴漏出來(lái)的這幾個(gè)問(wèn)題走進(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ì)存在的主要問(wèn)題是：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

??

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

進(jìn)一步提升

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

總結(jié)

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

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

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

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

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

***

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

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

***的***

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

??

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

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

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

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