865
加班越久故障越多，如何跳出程序員的惡性循環？
如何讓每一位可愛的工程師少加班、不加班？阿裏巴巴技術專家張冠楠，在質量保障體係建設、持續集成領域、敏捷實踐領域和研發效能領域方麵具有豐富的經驗和心得。今天，冠楠將用阿裏研發團隊的實際案例，生動說明如何用數據驅動研發效率提升。
本文是我利用雲效公有雲度量功能，加上敏捷部分的方法指導，實踐於某事業部幾十人團隊沉澱的成果，希望能給大家一些借鑒意義。我會就各種具有關鍵表征的數據進行介紹，但是詳細數據，包括具體研發團隊的數據，還需要訪問雲效公有雲度量功能頁麵。
數據展現
先直接給大家數據，我是4月份開始進入這個團隊的。大家重點看這個團隊3月份的數據：
問題分析
上麵幾張圖比較容易看出來，這個團隊的明顯特征是：
- 3月份完成需求數明顯上升，且團隊負載較重。
- 質量不高-缺陷數、reopen率以及線上發布成功率。
- 需求平均完成時長特別長。
- 突增故障。
於是我們帶著數據暴露出來的這幾個問題，和團隊一線研發人員、PD、TL進行溝通，分析數字背後的意義。大家很快達成一致，發現團隊存在的主要問題是：
- 需求deliver傳統瀑布模型，要1個半到2個月去完成一個特別大的需求，最後卻和用戶期望偏差較大，數據表征上就是之前需求數量較少，3月份突然完成了很多而且時間很長的需求。
- 大家加班加點幹活，負載較重，引入的缺陷也較多，PD和用戶不滿意帶來的修改又會加重工作量，如此惡性循環。
- 缺陷重視度不高，管理不規範，優先級劃分不清楚，甚至殘留重要缺陷，留在bug列表裏未解決而流到了線上引發故障。
上麵三點形成了惡性循環，結果就是越做越多，越多越錯，越錯越改，越改越多。
解決方案落地和數據運營
發現問題之後，有針對性的進行解決和落地就相對容易，我們給到團隊的解決方案是：
- 需求細化：拆分成最小可交付產出，盡量避免一個需求做了1個多月，才去找PD和用戶驗收。
- 隨時擁抱用戶：迭代式產出，交付即驗收，讓不準確性降到最低，在錯誤誤差最小的時候修正。
- 重點跟進質量管理和運營：透明數據，鼓勵團隊盡早盡快修複bug，並有嚴格的上線前bug解決率標準。
- 盡全力保證線上發布成功率。
同時輔助於團隊的決策，我們進行定期的數據運營，每周都會去統計和分析數據，包括質量和效率相關的，確保我們能在第一時間發現問題，糾正偏差。所以在3個多月的時間裏，我重點關注了如下數據。關於這些數據的解讀和分析，內容比較深入，我這裏隻做簡單的概括性介紹：
- 需求的吞吐量：團隊指定時間段內完成的需求數，可大體反應出團隊的產出趨勢。
- 需求的平均完成時長：需求從創建到終態的平均時長，時間越多，需求交付粒度越小效率越高。
- 新增缺陷的數量 ：統計時間段內團隊被新增指派的缺陷數量，結合存量缺陷以及缺陷平均解決時長，反應團隊產品的質量以及對於缺陷解決的效率。
- 缺陷的平均解決時長 ：缺陷從創建到解決的平均時長，表征解決缺陷的效率。
- 線上發布的成功率：線上發布成功次數與總次數之比，越高證明產品上線質量越高。
- 缺陷的reopen率 ：缺陷被reopen的次數與缺陷數目之比，該值越高證明修複缺陷的質量越差，reopen率是表征產品質量的一個重要指標。
結果分析和總結
大家回到上麵的6張圖以及下麵的一張缺陷解決時間圖，我們3月底進入，重點看從4月份開始的數據：
- 團隊的負載得到了控製，需求的完成數下降了，後續3個月保持一個相對平穩的狀態。
- 需求細化拆分後，交付的時長下降了，團隊以更快的速率去和用戶交付需求。
- 缺陷的數量下降，reopen率下降，線上發布成功率上升，質量在好轉。
- 缺陷的平均解決時間明顯上升，團隊更快的交付，更快的反饋問題，更快的解決問題。
總體而言，就是需求交付的快，得到的反饋快，修正錯誤/缺陷的成本低，缺陷也慢慢收斂，質量也隨之提升，缺陷修複的也快了，這就是一個良性循環，概括總計就是：效率提高了，質量也保證了。團隊的人幹活也是更加努力啦！
如何進一步提升？
根據對需求數量以及平均完成時長的數據顯示，團隊還是有上升空間的，對於需求的交付粒度和速率上，還是略顯波動，要想更快的知道我們做的是否是用戶需要的，就要快速的、迭代式的交付需求，以免用戶想要個車，我們給了他4個輪子。
所以能否徹底解決此團隊需求的交付和用戶期望偏差的問題，還是需要再向前走一步，需求繼續細化，提升交付速率。 參見敏捷中推薦的，快速迭代，快速交付，快速得到用戶反饋，隻為了更快更準確。
總結
數據有魅力，研發數據也一樣，我們使用它就是為了兩個目的：一是保證質量；二是確保交付的速率。行走過程中深度使用了雲效度量新功能，結合敏捷中部分理念，配合傳統測試方式保障，來助力研發團隊。
可能有的人會質疑，需要用這麼冰冷冷的數字去衡量我們可愛的程序員哥哥嗎？ 我的回答是：這不是衡量。數據隻是手段，是幫助我們去診斷團隊的一個切實有效的手段。學會利用它並駕馭它。因此我們隻需要：
- 關注數據，讀懂數據。
- 重點問題重點解決，優先解決，一段時間隻關注一個或很少的幾個問題。
- 相信團隊的自驅能力，同時結合TL的管理與激勵，養成良好的團隊建設力。
歡迎交流討論
研發團隊每天打交道最多的就是需求、缺陷、代碼、發布、應用、測試等等，這些和我們研發人員息息相關的數據，雲效現在以研發大盤、團隊空間、人員效能、質量分布等多種維度數據整合到了數據平台上，後續更會以定製化的方式滿足研發團隊對於研發數據的需求。利用好這個工具，能幫助我們清晰的了解團隊的現狀，暴露問題，找到改進措施，提升團隊效率和產品質量。
我是一個敏捷愛好者，在深入研發團隊做測試以及質量管理的時候，也是吸取和借鑒了敏捷的部分思想去落地。我的感受是：拿最切實有用比如站會、看板、快速迭代式交付需求，再加上數據輔助，都是能幫助到團隊更快、更準確的交付高質量產品的手段。
最後貼幾張我在度量上截的某研發團隊的數據展示，這個團隊是我們最近接觸的團隊，通過數據我們對這個團隊的推測是：團隊在質量上需要提升，在缺陷的管理上需要加強。首先團隊缺陷的數量逐月上升，這已經是質量不好的趨勢體現。
另外缺陷的解決時間也沒有加快，這樣會導致越來越多的缺陷流到線上去，可見團隊除去1月份無故障，後續幾個月都有故障。而且這個團隊的線上發布成功率持續走低，開發對上線的代碼把控程度較低。 所以，找到這些數據表征的背後原因，並且著手去解決掉，是這個團隊近期最迫切的事情了。
養成良好的研發習慣，保持高效的團隊協作，應該是每個研發同學持之以恒的追求。
原文發布時間為：2017-10-30
本文作者：冠楠
本文來自雲棲社區合作夥伴“阿裏技術”，了解相關信息可以關注“阿裏技術”微信公眾號
最後更新：2017-10-30 10:04:28