效能度量，對于實施DevOps研發(fā)團隊來說并不是一個陌生的話題。非常多的研發(fā)團隊都想要通過效能度量提升研發(fā)團隊的效率。關(guān)于軟件研發(fā)效能度量，也有一些標準的框架，分為交付價值、交付效率、交付質(zhì)量、交付成本、交付能力五個維度。

研發(fā)效能度量的目標

研發(fā)效能度量的目標是為了幫助研發(fā)團隊了解自身的工作效率和質(zhì)量，及時發(fā)現(xiàn)問題并采取相應(yīng)措施進行改進，以實現(xiàn)高效、高質(zhì)量的產(chǎn)品交付，滿足業(yè)務(wù)需求，實現(xiàn)業(yè)務(wù)價值。

識別瓶頸：通過度量研發(fā)過程中的關(guān)鍵指標，可以及時識別生產(chǎn)效率的瓶頸和短板，從而有針對性地對研發(fā)流程進行優(yōu)化。

監(jiān)控進度：研發(fā)效能度量可以幫助團隊實時監(jiān)控項目進度，發(fā)現(xiàn)問題和風(fēng)險，并及時采取措施加以解決。

提高效率：通過度量工作量和工作效率，團隊可以識別工作流程中的低效環(huán)節(jié)，并采取相應(yīng)的措施進行優(yōu)化，提高工作效率。

提高質(zhì)量：通過度量產(chǎn)品質(zhì)量和測試覆蓋率等指標，可以發(fā)現(xiàn)產(chǎn)品質(zhì)量問題，及時進行修復(fù)和改進，從而提高產(chǎn)品質(zhì)量。

研發(fā)效能度量的思路和路徑

那么如何進行研發(fā)團隊的效能度量呢？那就圍繞指標分為五大步驟展開。

1. 確定指標：團隊和企業(yè)管理者要根據(jù)項目需求和團隊情況選擇合適的指標進行度量。

2. 設(shè)定目標：團隊和企業(yè)管理者要共同設(shè)定目標，例如每個迭代的交付頻率、產(chǎn)品質(zhì)量指標等。

3. 收集數(shù)據(jù)：團隊和企業(yè)管理者要共同收集數(shù)據(jù)，例如每個迭代的缺陷數(shù)量、交付時間等。

4. 分析數(shù)據(jù)：團隊和企業(yè)管理者要對收集到的數(shù)據(jù)進行分析，找到問題和改進方向。

5. 反饋和改進：團隊和企業(yè)管理者要將分析結(jié)果反饋給團隊成員，共同討論改進方向并進行優(yōu)化。

1、確定指標

行業(yè)內(nèi)有結(jié)構(gòu)化的指標體系，從需求、設(shè)計、開發(fā)、測試、發(fā)布、運維等不同的階段，對應(yīng)著不同的指標。但是需要提醒一點，搭建指標體系不是越全越好，而是要根據(jù)團隊所處的不同階段，遇到的不同問題，最主要的是想要通過指標解決哪些問題，然后進行指標的設(shè)計與體系的搭建。

效能度量可以采用多種指標，可以分為質(zhì)量、效率、成本、客戶滿意度等方面。以下是眾安常用的效能度量指標：

這些指標不是固定的，團隊和企業(yè)管理者可以根據(jù)項目需求和團隊情況選擇合適的指標進行度量，同時也可以結(jié)合其他指標和方法進行分析和改進。

2、設(shè)定目標

設(shè)定目標一定要遵循SMART原則：

Specific（具體的）：目標應(yīng)該是具體且明確的，能夠清晰傳達出想要達到的結(jié)果，避免模糊和含糊不清的描述。

Measurable（可衡量的）：目標應(yīng)該是可衡量的，可以使用數(shù)據(jù)和指標進行可視化，跟蹤進展情況，避免主觀性和無法量化的目標設(shè)定。

Achievable（可達成的）：目標應(yīng)該是可達成的，要考慮到實際情況和可用資源，確保目標是可實現(xiàn)的，并且具有挑戰(zhàn)性和激勵性。

Relevant（相關(guān)的）：目標應(yīng)該是相關(guān)的，與業(yè)務(wù)需求和戰(zhàn)略一致，能夠?qū)崿F(xiàn)業(yè)務(wù)目標產(chǎn)生正面影響，避免無意義的目標設(shè)定。

Time-bound（有時間限制的）：目標應(yīng)該是有時間限制的，要設(shè)定明確的截止日期和時間表，以確保目標得到及時實現(xiàn)和跟蹤。

但是，設(shè)定目標之前，要對研發(fā)團隊進行現(xiàn)狀分析，比如：當前團隊的需求平均交付周期是20天（需求從創(chuàng)建到上線），部門例會上研發(fā)負責人會經(jīng)常被業(yè)務(wù)負責人挑戰(zhàn)，20天太久，為什么提一個需求，需要做那么久。迫于壓力，研發(fā)負責人做出承諾，要在幾月份之前，將需求的平均交付周期從20天縮短到10天。這個承諾，就是為團隊設(shè)定了一個明確的、有時間限制、具體可衡量的目標。

3、收集數(shù)據(jù)

收集數(shù)據(jù)有很多方法，可以通過一些工具獲取指標需要的數(shù)據(jù)，也可以通過腳本直連數(shù)據(jù)庫獲取相應(yīng)的數(shù)據(jù)。眾安團隊搭建效能度量駕駛艙時，通過集智BI工具拉取數(shù)據(jù)源的數(shù)據(jù)，然后經(jīng)過加工處理后進行可視化配置。

4、分析數(shù)據(jù)

軟件研發(fā)效能的提升是復(fù)雜的，受到諸多因素的影響，因素與結(jié)果之間存在相關(guān)關(guān)系而不是因果關(guān)系。即使我們發(fā)現(xiàn)兩組數(shù)據(jù)之間有關(guān)聯(lián)，也不意味著其中一組必然會導(dǎo)致另一組。例如，如果某個團隊 “代碼技術(shù)債率”指標很高，一般情況下代表著代碼中存在的很多問題被暫時擱置，未來持續(xù)維護的成本和技術(shù)風(fēng)險很大，那么從較長時間周期來看，很有可能 “交付周期”的指標會持續(xù)增長，即兩組指標之間存在相關(guān)性。但這并不是必然的因果關(guān)系，雖然技術(shù)債很多，但很有可能因為人員能力、突擊加班等其他因素暫時掩蓋了問題，表面上沖抵了這種趨勢。

但從研發(fā)效能分析的角度來看，我們?nèi)匀豢梢詮臍v史數(shù)據(jù)中分析相關(guān)性，然后通過實驗的方式進行探索，找到能夠切實驅(qū)動效能提升的因素進行持續(xù)干預(yù)。比如，想提升線上質(zhì)量、降低缺陷密度，經(jīng)驗告訴我們應(yīng)該去加強單元測試的覆蓋、完善 Code Review 機制、做好自動化測試案例的補充。但是，這真的有效么？我們通過數(shù)據(jù)來看，很可能沒有任何效果！并不是說這些實踐不該做，而是可能做的不到位。也許只是為了指標好看，編寫缺少斷言的單元測試、找熟人走過場分分鐘通過的代碼評審，覆蓋一些非熱點代碼來硬湊測試覆蓋率目標等等。所以，我們需要實驗思維，要不斷檢視、反思、檢討所采用的實踐，哪些實踐的確有效，哪些實踐效果不大，哪些實踐方向正確，但因執(zhí)行不到位所以效果才不及預(yù)期。我們要通過實驗找到那些真正有用的改進活動及其與結(jié)果之間的相關(guān)性關(guān)系，有的放矢采取行動才會更有效率和有效果。

5、反饋和改進

效能度量不能止步于數(shù)據(jù)本身。研發(fā)管理者緊盯數(shù)據(jù)，可能導(dǎo)致自上而下的面子工程或教條主義，效果適得其反。

研發(fā)管理者要通過度量大盤的指標數(shù)據(jù)進行下探分析，首先對數(shù)據(jù)進行多視角的分析與解讀，獲取有效洞察；進而結(jié)合其他關(guān)聯(lián)指標和調(diào)查方法，追問根因，定位效能瓶頸和優(yōu)化機會；最終將這些洞見落地為明確、可執(zhí)行、可驗證的改進方案，規(guī)范研發(fā)過程、建立起良好的研發(fā)文化。

效能改進不能靠階段性沖刺。要達到有效且可持續(xù)的效能改進，需要將度量和改進的實踐融入日常研發(fā)流程，持續(xù)追蹤，持續(xù)改進。

效能度量是研發(fā)效能管理閉環(huán)的關(guān)鍵一環(huán)。在基于數(shù)據(jù)解讀制定改進方案后，需要持續(xù)度量觀察效能趨勢，對改進后的指標數(shù)據(jù)進一步分析解讀，對改進方案的有效性做出快速反饋。若改進推進一段時間后，繼續(xù)提升效果不明顯，邊際效應(yīng)降低，這一機制也有助于團隊快速判斷，及時將資源投入下一個改進項。

關(guān)于反饋和改進，最推薦的是回顧會+PDCA模型。這個組合也是眾安團隊在工作中使用最多的。

總結(jié)

在數(shù)字化時代的大背景下，信息技術(shù)是驅(qū)動企業(yè)發(fā)展的關(guān)鍵，依托于DevOps提升研發(fā)效能已經(jīng)成為企業(yè)的核心競爭力。堅持數(shù)據(jù)驅(qū)動，通過正確的效能度量方法，可以讓研發(fā)效能可量化、可分析、可改進、可提升。