天天看點

資料說話,鍋别都讓程式員背

作者:石磊,阿裡巴巴産品專家,2014年加入阿裡巴巴,負責過阿裡巴巴測試平台Kelude,持續內建服務引擎CISE,阿裡巴巴研發協同平台Aone以及阿裡雲雲效率等産品, 對研發協同、測試、傳遞、效能度量領域都有很深的見解。
資料說話,鍋别都讓程式員背

如何提升組織效率一直是阿裡巴巴追求的目标之一,雲效作為企業一站式協同研發雲,積累了豐富的研發活動相關資料,如何利用這些資料,來助力于組織的研發效能提升,也是企業一直思考的問題。從2016年開始,雲效(在阿裡内部叫Aone)就開始逐漸的對組織的研發資料,從團隊,組織,項目等各個次元,按照研發實踐流程進行改進的思路,結合了靈活和過程改進的理念,逐漸沉澱出雲效的度量産品。并且真實的在不少阿裡的團隊,通過資料驅動的方式,輔助了團隊效能提升。

1.1 如何透明研發效能 - 主觀預測 VS 确定分析

資料說話,鍋别都讓程式員背

雲效度量産品的基本思路是: 透明研發效能,診斷研發瓶頸,輔助研發提效。 就像醫生看病,首先得找到問題,才能解決問題。

我們追求的高效研發: 更好的品質,更短的傳遞周期,更高的效率,更準的承諾兌現。但往往我們都很難去定量的描述,我們的品質,效率,傳遞到底如何。 是以,就像一個鏡子一樣,将研發效能透明出來,通過資料化的方式來定性的分析,是我們研發效能提升的第一步,也是最重要的一步。

資料說話,鍋别都讓程式員背

通過資料化的手段,可以讓我們從主觀的預測轉變成确定性分析。 那哪些名額對于我們定性的去分析是非常有效的名額呢?

1.2 有效的研發度量名額 - 品質,效率,進度,人員

資料說話,鍋别都讓程式員背

我們從度量的需求中會把名額分為4各大類:品質,效率,進度,人員。

(1)需求的吞吐量 – 大體反應出團隊的産出趨勢。

(2)需求的平均完成時長 - 需求從建立到終态的平均時長,時間越多,需求傳遞粒度越小效率越高。

(3)新增缺陷的數量 - 統計時間段内團隊被新增指派的缺陷數量,結合存量缺陷以及缺陷平均解決時長,反應團隊産品的品質以及對于缺陷解決的效率。

(4)缺陷的平均解決時長 - 缺陷從建立到解決的平均時長,表征解決缺陷的效率。

(5)線上釋出的成功率 - 線上釋出成功次數與總次數之比,越高證明産品上線品質越高。

(6)缺陷的reopen率 - 缺陷被reopen的次數與缺陷數目之比,該值越高證明修複缺陷的品質越差,reopen率是表征産品品質的一個重要名額。

我們會用2016年張冠楠同學在阿裡的某事業部内部通過Aone的度量産品推動效能提升的過程來給大家具體的介紹一下,拿到了這些資料,我們會怎麼樣去用資料來幫助我們分析瓶頸并找提升的關鍵的。

我們利用資料通常會有以下4個步驟:

1)通過團隊效能趨勢透明目前團隊的效能現狀

2) 通過具體的人員分析來定位效能瓶頸

3)針對具體的瓶頸給出改進政策

4) 通過持續的度量來确定是否改進生效

2.1 通過團隊效能趨勢透明目前團隊的效能現狀

阿裡某研發團隊,20+人問題:傳遞老Delay,團隊士氣不高,老加班,品質差。 讓我們來看看當時他們的度量資料:

資料說話,鍋别都讓程式員背

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

(1)3月份完成需求數明顯上升,且團隊負載較重

(2)品質不高 - 缺陷數、reopen率以及線上釋出成功率

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

(4)突增故障

2.2 通過具體的人員分析來定位效能瓶頸

帶着資料,走進了團隊,和團隊一線研發人員進行訪談,也對整個資料中的具體資料去做了細分,我們可以看到整個團隊存在的問題:

1)到底需求時間長,是卡在PD,還是開發還是測試? 是否相應的團隊可以去改進。

2)任務負載重,是否可以将任務配置設定更合理。 配置設定不均,單個人容易成為整個團隊的瓶頸。

3)品質差,原因是什麼?

通常這些瓶頸的定位是不能通過趨勢來告訴我們,必須的深入到團隊中,這個時候按照人員分布的度量報表就能友善的幫助我們定位到瓶頸人員。

資料說話,鍋别都讓程式員背
資料說話,鍋别都讓程式員背

2.3 針對具體的瓶頸給出改進政策

當我們發現了瓶頸和問題,就要針對性的進行改進。 具體的改進方法,靈活有很多的實踐,這裡不做多闡述,文章的最後加了不少集團靈活團隊的最佳實踐傳送門,大家可以參考

資料說話,鍋别都讓程式員背

2.4 通過持續的度量來确定是否改進生效

最後,我們要持續的關注度量資料來幫助我們進行跟蹤,是否我們的改進能夠真正的解決問題。 如果我們改進得體, 團隊整體效率和品質提升必然會在度量資料上有所展現。

資料說話,鍋别都讓程式員背

3.1. 資料隻是手段,是幫助我們去診斷,而不是衡量。

可能有的人會質疑,度量的資料是不是要去衡量一個人,其實,這個不是資料度量的目标,目标是找到我們怎麼去做改進。是以輕易拿度量的資料來衡量人,尤其對于不同的團隊和研發模式,其個人的研發資料往往會有較大的差別

3.2. 學會利用資料,不要被資料所利用

之前聽雲效的靈活教練張迎輝分享在yahoo做的一個活動,為了調高研發品質,要求所有的研發必須在送出代碼之前通過UT,結果就有的團隊直接寫空的UT,還有的無論UT是成功或者失敗都直接在UT中傳回成功。這個和資料度量是類似,如果大家都追求資料好看,肯定有各種方法把資料做好看,但是這不是我們所追求的,資料是面鏡子,隻是用來發現問題,是以,還是那句話,我們要利用資料,不要被資料所利用。

資料說話,鍋别都讓程式員背
資料說話,鍋别都讓程式員背

掃碼立即免費體驗雲效度量新功能

繼續閱讀