如何讓每一位可愛的工程師少加班、不加班？阿里巴巴技術(shù)專家張冠楠，在質(zhì)量保障體系建設(shè)、持續(xù)集成領(lǐng)域、敏捷實(shí)踐領(lǐng)域和研發(fā)效能領(lǐng)域方面具有豐富的經(jīng)驗(yàn)和心得。今天，冠楠將用阿里研發(fā)團(tuán)隊(duì)的實(shí)際案例，生動(dòng)說(shuō)明如何用數(shù)據(jù)驅(qū)動(dòng)研發(fā)效率提升。

張冠楠：阿里巴巴技術(shù)專家。負(fù)責(zé)過阿里巴巴集團(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)域方面均有研究。


本文是我充分利用云效公有云度量功能，加上敏捷部分的方法指導(dǎo)，實(shí)踐于某事業(yè)部幾十人團(tuán)隊(duì)沉淀的成果，希望能給大家一些借鑒意義。團(tuán)隊(duì)效率高，質(zhì)量好，所以數(shù)據(jù)表征好。我會(huì)就各種具有關(guān)鍵表征的數(shù)據(jù)進(jìn)行介紹，但是詳細(xì)數(shù)據(jù)，包括您的研發(fā)團(tuán)隊(duì)的數(shù)據(jù)，還需要訪問云效公有云度量功能頁(yè)面。
注：本文數(shù)據(jù)來(lái)自云效度量數(shù)據(jù)功能頁(yè)面截圖（部分?jǐn)?shù)據(jù)功能云效暫未開放給所有用戶，所以截圖會(huì)有些許區(qū)別）。
數(shù)據(jù)展現(xiàn) 先直接給大家數(shù)據(jù)，我是4月份開始進(jìn)入這個(gè)團(tuán)隊(duì)的。大家重點(diǎn)看這個(gè)團(tuán)隊(duì)3月份的數(shù)據(jù)：




問題分析
上面幾張圖比較容易看出來(lái)，這個(gè)團(tuán)隊(duì)的明顯特征是： （1）3月份完成需求數(shù)明顯上升，且團(tuán)隊(duì)負(fù)載較重。 （2）質(zhì)量不高-缺陷數(shù)、reopen率以及線上發(fā)布成功率。 （3）需求平均完成時(shí)長(zhǎng)特別長(zhǎng)。 （4）突增故障。
于是我們帶著數(shù)據(jù)暴露出來(lái)的這幾個(gè)問題，和團(tuán)隊(duì)一線研發(fā)人員、PD、TL進(jìn)行溝通，和大家一起分析數(shù)字背后的意義。大家很快達(dá)成一致，發(fā)現(xiàn)團(tuán)隊(duì)存在的主要問題是：
（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)形成了惡性循環(huán)，結(jié)果就是越做越多，越多越錯(cuò)，越錯(cuò)越改，越改越多。
解決方案落地和數(shù)據(jù)運(yùn)營(yíng)
發(fā)現(xià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)問題，糾正偏差。所以在3個(gè)多月的時(shí)間里，我重點(diǎn)關(guān)注了如下數(shù)據(jù)，這些數(shù)據(jù)也都可以在云效上得到。關(guān)于這些數(shù)據(jù)的解讀和分析，內(nè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月份開始的數(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ì)更快的交付，更快的反饋問題，更快的解決問題。


總體而言，就是需求交付的快，得到的反饋快，修正錯(cuò)誤/缺陷的成本低，缺陷也慢慢收斂，質(zhì)量也隨之提升，缺陷修復(fù)的也快了，這就是一個(gè)良性循環(huán)，概括就是：效率提高了，質(zhì)量也保證了，團(tuán)隊(duì)的人干活也更加努力了！
進(jìn)一步提升
根據(jù)對(duì)需求數(shù)量以及平均完成時(shí)長(zhǎng)的數(shù)據(jù)顯示，團(tuán)隊(duì)還是有上升空間的，對(duì)于需求的交付粒度和速率上，還是略顯波動(dòng)，要想更快的知道我們做的是否是用戶需要的，就要快速的、迭代式的交付需求，以免用戶想要個(gè)車，我們給了他4個(gè)輪子。所以能否徹底解決此團(tuán)隊(duì)需求的交付和用戶期望偏差的問題，還是需要再向前走一步，需求繼續(xù)細(xì)化，提升交付速率。 參見敏捷中推薦的，快速迭代，快速交付，快速得到用戶反饋，只為了更快更準(zhǔn)確。
總結(jié)
數(shù)據(jù)有魅力，研發(fā)數(shù)據(jù)也一樣，我們使用它就是為了兩個(gè)目的：一是保證質(zhì)量；二是確保交付的速率。行走過程中深度使用了云效度量新功能，結(jié)合敏捷中部分理念，配合傳統(tǒng)測(cè)試方式保障，來(lái)助力研發(fā)團(tuán)隊(duì)。
可能有的人會(huì)質(zhì)疑，需要用這么冰冷冷的數(shù)字去衡量我們可愛的程序員哥哥嗎？ 我的回答是：這不是衡量。數(shù)據(jù)只是手段，是幫助我們?nèi)ピ\斷團(tuán)隊(duì)的一個(gè)切實(shí)有效的手段。學(xué)會(huì)利用它并駕馭它。因此我們只需要：
（1）關(guān)注數(shù)據(jù)，讀懂?dāng)?shù)據(jù)。 （2）重點(diǎn)問題重點(diǎn)解決，優(yōu)先解決，一段時(shí)間只關(guān)注一個(gè)或很少的幾個(gè)問題。 （3）相信團(tuán)隊(duì)的自驅(qū)能力，同時(shí)結(jié)合TL的管理與激勵(lì)，養(yǎng)成良好的團(tuán)隊(duì)建設(shè)力。
研發(fā)團(tuán)隊(duì)每天打交道最多的就是需求、缺陷、代碼、發(fā)布、應(yīng)用、測(cè)試等等，這些和我們研發(fā)人員息息相關(guān)的數(shù)據(jù)，云效現(xiàn)在以研發(fā)大盤、團(tuán)隊(duì)空間、人員效能、質(zhì)量分布等多種維度數(shù)據(jù)整合到了數(shù)據(jù)平臺(tái)上，后續(xù)更會(huì)以定制化的方式滿足研發(fā)團(tuán)隊(duì)對(duì)于研發(fā)數(shù)據(jù)的需求。利用好這個(gè)工具，能幫助我們清晰的了解團(tuán)隊(duì)的現(xiàn)狀，暴露問題，找到改進(jìn)措施，提升團(tuán)隊(duì)效率和產(chǎn)品質(zhì)量。
我是一個(gè)敏捷愛好者，在深入研發(fā)團(tuán)隊(duì)做測(cè)試以及質(zhì)量管理的時(shí)候，也是吸取和借鑒了敏捷的部分思想去落地。我的感受是：拿最切實(shí)有用比如站會(huì)、看板、快速迭代式交付需求，再加上數(shù)據(jù)輔助，都是能幫助到團(tuán)隊(duì)更快、更準(zhǔn)確的交付高質(zhì)量產(chǎn)品的手段。
最后貼幾張我在度量上截的某研發(fā)團(tuán)隊(duì)的數(shù)據(jù)展示，這個(gè)團(tuán)隊(duì)是我們最近接觸的團(tuán)隊(duì)，通過數(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í)間也沒有加快，這樣會(huì)導(dǎo)致越來(lái)越多的缺陷流到線上去，可見團(tuán)隊(duì)除去1月份無(wú)故障，后續(xù)幾個(gè)月都有故障。而且這個(gè)團(tuán)隊(duì)的線上發(fā)布成功率持續(xù)走低，開發(fā)對(duì)上線的代碼把控程度較低。 所以，找到這些數(shù)據(jù)表征的背后原因，并且著手去解決掉，是這個(gè)團(tuán)隊(duì)近期最迫切的事情了。


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

---

云效，一站式企業(yè)協(xié)同研發(fā)云，源于阿里巴巴多年先進(jìn)的管理實(shí)踐理念（精益創(chuàng)業(yè)、看板方法、Scrum、中臺(tái)戰(zhàn)略、狼團(tuán)隊(duì)）和工程實(shí)踐（微服務(wù)、DevOps、CI/CD、自動(dòng)化測(cè)試），提供從“需求->開發(fā)->測(cè)試->發(fā)布->運(yùn)維->運(yùn)營(yíng)”端到端的協(xié)同服務(wù)和研發(fā)工具支撐。升級(jí)后的云效2.0支持公有云、專有云和混合云的協(xié)同研發(fā)，助力企業(yè)產(chǎn)品快速創(chuàng)新迭代和研發(fā)效能升級(jí)。

總結(jié)

以上是生活随笔為你收集整理的加班越久故障越多，如何跳出程序员的恶性循环？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。