最近幾年 “軟件研發(fā)效能” 成了業(yè)界的熱詞 ，頻繁出現在各個行業(yè)大會艺智，被各大廠倘要、傳統(tǒng)行業(yè)數字化部門、追求高效能的團隊不斷的提及并迭代十拣，比如阿里的效能改進211愿景封拧，騰訊的智研平臺，百度工程能力白皮書夭问。
那么為什么軟件研發(fā)效能會成為熱詞泽西，有哪些合適的軟件研發(fā)效能指標呢? 本文想嘗試回答這兩個問題。(本文是此系列的上篇甲喝，后續(xù)兩篇將嘗試構建一個根據團隊上下文的軟件研發(fā)效能推薦指標圖表尝苇，和一些實際度量指標的案例铛只。)
為什么軟件研發(fā)效能會成為熱詞埠胖？
咱們先看看現有的問題， 與傳統(tǒng)制造業(yè)相比淳玩，軟件研發(fā)行業(yè)還很年輕直撤，并沒有達到傳統(tǒng)行業(yè)的大規(guī)模流水線的生產方式，這解釋了為什么沒有一種統(tǒng)一的蜕着，被廣泛認可的方法來衡量開發(fā)人員或研發(fā)小組的效能谋竖。研發(fā)效能的度量很大程度上取決于公司的類型，規(guī)模承匣，文化蓖乘，與之合作的項目類型以及其它諸多因素。 甚至某些小而精韧骗，依靠聰明才智和資深經驗的創(chuàng)業(yè)團隊嘉抒，不用度量研發(fā)效能，團隊依然非常高效袍暴。
很顯然些侍，10年前使用代碼行數(Lines of code)來度量研發(fā)效能的方式已經不適用現代敏捷過程對軟件研發(fā)的理解了。以前關注代碼產出政模，而不是業(yè)務成果岗宣，以前關注個人績效，而不是團隊效能淋样。例如: 隨著公司和開發(fā)人員向著價值驅動和基于團隊開發(fā)方向的轉變耗式，代碼行數不再具有任何意義。100行代碼是否比20行好？行數是否告訴你取得了良好的進展刊咳，還是只是一個沒有上下文的抽象指標措嵌？軟件企業(yè)都在尋求其它有效的指標來度量研發(fā)效能。
同時芦缰，如今的軟件行業(yè)已經不再是“以大吃小”的時代了企巢，而是轉變成了“以快吃慢”的時代。對于很多大型軟件企業(yè)让蕾、傳統(tǒng)行業(yè)的數字化部門浪规。原本“大”是優(yōu)勢，現在卻陷入了“大船難掉頭”的尷尬探孝。如何破局笋婿？研發(fā)效能具體來講就是從需求轉化成軟件或者服務的能力。改善研發(fā)效能從某種方面也在試圖解決“大船難掉頭”的尷尬顿颅。
研發(fā)效能試圖在解決度量和讓研發(fā)變快的問題缸濒，那為什么會成為熱詞? 為什么最近幾年各大廠、傳統(tǒng)行業(yè)數字化部門粱腻、追求高效能的團隊庇配，都紛紛開始在研發(fā)效能領域發(fā)力，我認為這背后的原因有以下四點：
- 從外部技術視角來看：研發(fā)效能的土壤和環(huán)境已經就緒绍些，類似高速移動網絡的普及為智能手機和App培育了土壤和環(huán)境捞慌。4G移動網絡的普及，讓人們可以方便柬批、快速的接入互聯網啸澡，為智能手機和App鋪好了路。現代軟件研發(fā)的各個環(huán)節(jié)已經全面數字化氮帐，為研發(fā)效能的數據收集和度量做好了準備嗅虏。比如: 電子看板管理任務狀態(tài)，可數字化團隊協作情況上沐。Git等工具管理代碼提交皮服，可數字化開發(fā)過程。持續(xù)部署流水線管理發(fā)布過程奄容，可數字化發(fā)布情況冰更。DevOps云上編排、監(jiān)控昂勒，可數字化產品運行狀態(tài)蜀细。
- 從組織內部視角來看：很多公司都有“谷倉” (The Silo Effect)，伴隨著市場競爭的日趨激烈戈盈，“谷倉” 效應越發(fā)突出奠衔，局部優(yōu)化但是無法全局優(yōu)化谆刨，破局“大船難掉頭”的尷尬勢在必行。開發(fā)到測試的銜接完成了優(yōu)化归斤，但是當用戶需求被設計好以后需要很長時間才能傳遞到開發(fā)痊夭，當產品上線后，線上問題需要很久才能從運維傳遞給開發(fā)并修復脏里，影響了全局效率她我。基于協作流程的優(yōu)化迫横，打破流程中的“谷倉”番舆，去除不必要的等待，讓價值流動快起來矾踱，也是研發(fā)效能試圖解決的問題恨狈。
- 從公司業(yè)務視角來看：組織發(fā)展規(guī)模化呛讲，技術驅動商業(yè)差異化禾怠，然而IT交付工廠化，難以應對市場的快速變化贝搁。傳統(tǒng)企業(yè)對于IT投資吗氏，追求ROI最大化以及交付過程的透明化，從而緩解市場帶來的壓力徘公，提升差異化競爭力牲证。研發(fā)效能度量的核心是提供數據支撐這個目標的達成哮针，基于數據持續(xù)改進关面。
- 從外部資源視角來看：以前業(yè)務的快速發(fā)展靠燒錢、人海戰(zhàn)術換取更快的市場占有率十厢，從而達到贏家通吃等太。那時候關心的是軟件產品功能產出，研發(fā)效率可以用人蛮放、用錢填上缩抡。 但是隨著時間的推移，還有這么多從業(yè)人員可填嗎包颁？即便有了這么多人還能砸這么多錢嗎瞻想？每年從事軟件研發(fā)的畢業(yè)生有限，然而行業(yè)對人才的需求從沒削減過娩嚼，當抽干一線城市的人才蘑险，各個大廠已經開始熱衷去二、三線城市的大學招人了岳悟。同時佃迄，隨著產品利潤的下降泼差，需要更多的獲客，回饋客戶呵俏，需要開始節(jié)流了堆缘，節(jié)流就是研發(fā)效能的提升，同樣的資源普碎，同樣的時間來獲得更多的成果吼肥。
有哪些合適的軟件研發(fā)效能度量指標呢?
上面基本回答了研發(fā)效能為什么會成為熱詞，那什么才是軟件研發(fā)效能中合適的指標呢? 要度量哪些指標和數據呢麻车？根據不同的場景和目標人群需要給出相應的度量指標潜沦。正如《關鍵對話》中建議的，需要根據信息接收者的興趣點來構建溝通策略和溝通內容绪氛。從研發(fā)效能DevOps角度 《Accelerate》 這本書給出了4個指標和評價標準唆鸡。研發(fā)效能是一個比較大的話題，如何根據不同的關注點枣察，給出不同的指標呢争占？ Roy Osherove 的 “Lies, Damned Lies, and Metrics”也給出了很好的歸類。根據我們在項目中的實際使用和經驗總結序目，這里把當前常用的度量指標歸類如下：
- 規(guī)劃進度：評估進度臂痕，獲取背景信息和上下文，知道任務何時完成猿涨，預測問題（未來）握童，對問題復盤與回顧（過去）。
- 燃盡圖 (每個迭代/每個發(fā)布) （Burn down chart sprint/release)
- 速率圖 (Velocity chart)
- 標準差 (Standard deviation)
- 吞吐量（Throughput)
- 累積流程圖 (Cumulative flow diagram)
- 控制圖 (Control chart)
- 看板 在制品限制圖 (Kanban WIP board)
- 快速反饋：持續(xù)集成叛赚，持續(xù)部署澡绩。
- 構建與部署速度 (Build & Deploy speed)
- 測試速度 (Test speed)
- 代碼簽審時長 (PR approval Time)
- 單元測試通過速率 (Unit tests passed)
- 集成測試通過速率 (Integration tests passed)
- 團隊轉型：使用特定指標來衡量不同工作方式的方法，可以影響行為俺附，幫助改變人們的行為方式肥卡。也可以向管理層說明某些事情不合理，需要改變事镣，或者說明需要更多的時間和預算步鉴。
- 結對編程的時長 (Pairing Time)
- 手工測試的時長 (Time spent manual testing)
- 代碼簽審時長 (PR approval Time)
- 修復失敗構建的耗時 (Fix red build time)
- 修復Bug的耗時 (Cost of fixing bug in Dev/Prod)
- 測試覆蓋率 (Coverage test count)
- 功效分配比率 (Effort allocation, New work / Unplanned work or rework / Other work)
- 輔助決策：可進行實驗并不斷尋找新的度量指標，幫助做決策璃哟。
- 前置時長 (Lead time)
- 發(fā)布出去的Bug數 (Escaped bugs 線上逃逸Bug數)
- 功效分配比率 (Effort allocation, New work / Unplanned work or rework / Other work)
- 交付的價值 (Valued delivered)
- 工程能力： 4 key metrics 度量并找出團隊工程實踐的弱點氛琢。
- 變更前置時長 (Lead Time for Changes)
- 部署頻率 (Deployment Frequency)
- 變更失敗率 (Change Fail Rate)
- 服務恢復耗時 (Time to restore service)
當您在為團隊尋找研發(fā)效能指標時，其實并沒有一個恒定不變的模板随闪，需要分析多個因素阳似，選擇最適合您的指標，并與團隊一起不斷的使用它們蕴掏，不斷的根據價值交付為導向來修改和迭代障般。您自己團隊的度量指標很可能與其他公司或團隊的指標完全不同调鲸，這是完全正常的事情。 因為正如前面提到的挽荡，研發(fā)效能的度量很大程度上取決于公司的類型藐石，規(guī)模，文化定拟，與之合作的項目類型以及其它因素于微。
下篇，將嘗試使用項目類型青自，合作方式株依，等因素做為維度，放入已知的這些指標延窜，構建一個推薦圖表恋腕。幫您在了解這些情況之后，選擇合適的指標逆瑞。同時也會列舉一些實際度量指標的案例（中篇）荠藤，并討論前置業(yè)務不明朗時 (fuzzy front end)，如何統(tǒng)計前置時長(lead time)的起始時間获高。
