Editor's Notes：
如何提高軟件交付效能？研發支撐部門 BP 化，項目管理流程精簡化，忘掉代碼量去構建效能度量模型。一個個富有沖擊力的理論不斷涌現，細一琢磨，又覺得個中道理正是如此。一切皆來自 KodeRover 創始人 & TGO 鯤鵬會上海分會會員李倩，她深耕效能提升領域，在研發自動化、環境服務化、全流程質效度量、魯棒性測試等基礎領域輕車熟路。本次做客 TGO 鯤鵬會杭州分會，她將關于交付效能的知識，全部奉獻給大家。口述 | 李倩整理 | 一鵬

李倩現場分享

大家好，我是李倩，來自上海，是 KodeRover 的創始人 & TGO 鯤鵬會會員。很高興能跟大家聊聊關于研發效能的話題，尤其是效能的量化和度量。通過度量認清短板固然重要，但靠度量提升效能卻很難，特別是在工程能力不足的情況下做度量，甚至依賴度量制訂績效，都很容易出現問題。

既然提升效能如此困難，我們就來探討一下，如何分步驟、階段性地真正提升效能。

一、提升軟件交付效能的關鍵之處

所謂技術研發，就是通過開發軟件為企業帶來業務價值。那么軟件交付效能是什么？它指代生產軟件持續為用戶產生有效價值的效率，可以理解為三個關鍵詞：有效性、效率、可持續性。

一、有效性：關注產品是否能為客戶、公司帶來價值；

二、效率：關注團隊能否快速生產和發布產品、快速應對市場需求變化和企業業務目標；

三、可持續性：小團隊做小業務，可能沒問題；隨著業務規模和團隊規模的成倍增長，還能有效控制研發效能嗎？這就是可持續性探究的問題，也是很容易忽略的一點。

為什么要提升軟件交付效能？這主要為了企業長遠發展和讓企業有持久競爭力。

如何提高軟件交付效能？首要任務，就是改善研發人力投入結構，動態平衡時間、成本、質量三者之間的關系。

常有人問，研發團隊到底應該怎么搭建，或者說，成熟團隊的結構是什么樣的？其實沒有標準答案，一切取決于業務形態，組織結構要圍繞業務或企業成本來規劃建設。舉個例子，如果企業要推出一款產品，就應該圍繞產品建立交付架構，如常見的 PO(Product Owner)?模式，產品負責人為產品的 ROI 負責。如果預算是 1000 萬，就要用 1000 萬 去搭建一個可以完成產品商業目標的團隊。團隊角色可能只有開發人員，也可能包含產品經理、QA、開發人員，甚至可以招募運營人員。

一個商業單元，一切要以價值為導向改善人力投入，沒有固定的崗位比例建議。以完成確定的商業目標為依據，制造所有可能的、必要的資源和崗位。

軟件交付效能不是技術團隊可以單獨決定的，尤其在涉及到 ToB 環節時，鏈路很長。分析一下鏈路中的利益相關方就會發現，CPO 對企業生存發展負責，通過識別商業價值，使產品經理能夠完成實際的需求定義；接下來，技術團隊才能推進實現和研發交付；最后，市場和銷售觀測、驗證市場反饋，服務團隊進行客戶支持和響應，接著開始新的一輪軟件交付周期。

所以，軟件交付管理的過程，要從商業識別到客戶服務的端到端開始管理，是端到端的價值流動和需求響應，既不是從產品經理拿到需求的那一刻開始，也不是到代碼上線就結束了。

在研發交付環節，最大的痛點是如何在保證研發速度的情況下，兼顧質量。一個相對完整的產品上線之前需要大量的驗證與運維工作，開發完成后有很多工作要做，比如部署測試驗證時間經常會超過代碼編寫時間，環境和構建問題也是團隊消耗大量精力的地方。

代碼質量差，導致測試人員投入大量精力用來驗證和返工；交付流程管理不規范、不合理，導致從上游傳遞下來的信息缺失，讓運維非常痛苦，承擔了很大的上線風險。

綜合看來，效能低的外在表現就是需求響應慢、交付周期長、事故多、服務能力下降，進而導致企業無法快速進行創新創造。

如何解決交付困境，大家也想了很多辦法，比如說有些企業通過規范一整套流程來約束每個階段的產出規范，也有團隊為了驗證業務隔離環境，實現了七、八套測試環境，但這樣真的能提高效率嗎？

二、交付的挑戰和變革

做軟件研發的核心是處理人、技術、流程之間的關系，目標是在三者間建立良好的關系與合理的機制。

其中包含四個關鍵點：

1、人的服務化：建立面向開發者的服務體系，將支撐部門 BP 化；2、組織效能的數字化：面向流程、工程、業務指標、技術建立多層次的效能度量體系；3、技術的云原生化：充分運用云技術提升 IT / Infra 使用效率與開發人員生產力；4、流程的工程化：簡化流程體系，用工程代替流程，流程越精簡越好。

最終四個關鍵點回歸一個最簡單的邏輯：幫助開發者生產高質量的代碼，上線到生產環境，并為客戶提供服務。大家對 HRBP(HR BUSINESS PARTNER)?的概念耳熟能詳，其實研發內部也一樣。開發者是主體，其他都是 BP，只要能幫助優質代碼上線，無論怎樣為開發者提供服務都不為過。

按照這樣的思路，所有面向業務交付的部門都應該是一個單元。也就是說，QA、SRE 都應該下沉到業務，而不是業務方層層審批獲得資源。當某個部門、組織不是面向業務交付時，它就只是一種職能化的存在，無法很好地體現價值。

支撐部門 BP 化以后服務目標如何定，核心價值又如何體現呢？這里效能度量體系提供了一種思路。通過建立度量，整個過程清晰可見，知道到底發生了什么，比如說效率和質量怎么樣，中間協作過程是否順利，哪些因素有利于開發者上線，哪些因素是瓶頸？支撐部門也逐步從成本中心轉向服務中心，與業務建立關聯，體現核心價值。

我們回到本質，提升研發效能要解決的是開發者的問題，而不是管理者的問題。大部分技術管理者，很容易從自己的角度出發，思考應該怎么去管理研發。實際上恰恰相反，開發者才是主體，管理者應該思考如何將他們的價值發揮到最大。所謂的“996”，只是一種形式而已。

面向開發者建立服務體系的思路，在國外已經非常成熟，Facebook 的持續開發過程聚焦的正是讓開發者毫不費力地完成代碼的提交和驗證過程。

Facebook 的持續開發過程大體如下：

1、開發人員負責 UT 和 IT，在本地開發機器上進行開發、包括本地的編碼、調測、單元測試等；提交 PR(Pull Request)，云端執行完整的測試過程，并行運行包含靜態檢查、單元測試、集成測試、安全測試，以及性能測試等；

2、測試通過后，是 Phabricator 的機器 CR(Code Review)?和人工 CR 環節，人工 CR 選擇性的觸發端到端的系統測試、調測，并具有一票通過和否決權，通過后入庫；

3、入庫后進行持續交付的自動化測試驗證、灰度上線驗證，目前已經能支持到 CR 級別的持續部署能力。

我們可以看到代碼入庫前經過的本地、云端、機器自動化測試案例和實時質量檢測及基礎設施都是以服務化的形式提供，可以靈活的調用。入庫后的運維過程也是高度自動化的。

可見，硅谷頂尖互聯網企業的流程非常輕量、靈活，而國內很多公司則設定了大量的流程框架，看上去好像是在幫助管理者明確工程師的工作內容和開發進度，實際則不然。提升效能的根源在于開發者能否順暢的寫完代碼并上線。

又有些人質疑說國內外工程師有差異。那么國內外工程師水平真的相差很大嗎？我不這么認為，我們中國工程師非常聰明，這種差別其實源于工程交付思維的不同。在國內，一些發展迅猛的互聯網公司流程也逐漸開始采用硅谷研發方式，完成從“寫完代碼就完事” 到 “代碼上線服務客戶了才算成功” 的意識轉變。工程師為自己的代碼負責，沒有人為其擔保和托底。就像 Facebook 擁有 一萬多名開發人員，卻只有為數不多的產品工程師，寥寥幾名運維，沒有 QA，更沒有繁重的流程。

三、軟件交付效能演進

讓我們看看，目前有哪些影響交付的因素呢？上圖展示的是從想法到用戶之間的距離，也展示了我們技術團隊日常工作各個環節的內容。持續集成是指代碼的集成，驗證代碼邏輯沒問題。持續交付是做業務的集成，驗證代碼交付了正確的業務，重點關注業務的集成成功率和驗證效率，目標是持續驗證業務價值。

很多團隊在持續集成工程實踐上做的很好了，但有相當一部分團隊測試或部署過程是人工的、非連續的。實現全流程的自動化是軟件持續交付、效率提升的關鍵。

業務團隊可以通過業務拆分、采用微服務架構進行并行開發，但不能連續測試、持續部署到環境中。建立持續交付能力幫助 QA 不間斷地進行業務校驗，提供環境或者業務驗證機制，或幫助開發自主驗證。優秀的工程實踐是把共性的部分，即每個人都要花大量時間的部分自動化掉。

我在長期做一個“工程師自己認為時間花在何處”的調查。統計結果顯示，仍然有 55% 的工程師認為自己在做雜事，很少有時間安心寫業務相關的代碼。這很奇怪，作為工程師大部分時間卻不在寫代碼。如果我們能將沒有時間寫代碼的問題解決掉，效率就能提升。

上圖展示的是持續交付的演進階段。這里非常有必要提一下分支管理，分支管理與工程成熟度密切相關，比如 Facebook 是主干分支模式，合并負擔和流程都非常輕量，可以把持續集成和持續交付做到極致，頻繁入主倉集成檢驗，而大部分公司采用主干分支加功能分支或者 Git Flow。

根據圖示大家可以對比下，當前很多公司還處在第二、第三階段，有一定的自動部署能力，但沒有持續交付能力。到智能部署階段，基本具備了全面的管理能力。至于混沌工程，如果沒有全量的監控能力和對整體變更的管控能力，混沌工程也很難采用。只有基礎設施相對完善的情況下，混沌工程才可以常態化的實施，每個季度或者每個月提升一次系統健壯性，比如模擬炸機房故障演練等。

四、效能度量建議

我從事質量或效率工程很多年，一直在尋找一個答案：有沒有一種基于指標的度量模型可以準確衡量一家公司的軟件交付效能 。通過這么多年的探索，發現代碼量、PR 量、覆蓋率、需求數量、缺陷數量等指標都不合適，無法提升效能甚至帶來副作用。那么什么樣的指標更有價值？我發現基于不同的改進目標，面向人、流程、技術建立多視角的度量，根據成熟度選擇適合自己企業特性和現階段發展的指標，不僅可以提升效能還可以增進工程文化。

首先要面向過程改進，也就是流程改進，尤其需要注意打回率和各種測試的平均耗時。QA 的高打回率指標可以推動研發自測，減少返工情況。各種測試的平均耗時則顯示了你花費了多少時間在驗證，比如花了很長時間在 UT 上，一個同學提了一個 PR，運行了 20 分鐘，如果每個人都耗 20 分鐘，那其他人等這個代碼集成，時間損耗就很大了，這是特別容易忽略的效率。

我很推崇從工程技術角度度量，首先這些指標最能代表核心效能，比如 CI/CD 是交付核心的效率，覆蓋率是交付核心的質量指標。另外，對于工程師而言，客觀邏輯至上。相比”寫了多少代碼，解決了多少個缺陷，完成了多少個需求“這些指標，客觀技術指標非但不會損傷開發者的尊嚴，反而給大家更強的目標感，完全可以用于關鍵績效的依據。

同時，每個企業都應該有核心的 North Star（北極星）指標，這是可以建立績效的點，是老板關注的點，也是員工可以努力的方向。比如云服務核心服務 SLA 承諾指標，可以用做績效考量。

當然，還要考慮事故處理能力。事故就是針對企業內在流程機制的考驗，故障恢復時間可以作為核心內部作為績效指標。

其他的指標在這里就不詳細闡述了。如何選擇度量指標，要取決于企業階段性的研發運營目標是什么。比如最近對外缺陷很高，可以拿缺陷性指標去度量。另外，想要建立這樣的度量體系，還需要注重自動化體系的搭建，需要有自動化能力，并且可以持續收集數據。

但請注意，不要陷入一個誤區：在自動化能力不強的情況下，就去統計指標，指望通過 1-2 個月去收集到全團隊指標來度量團隊效能和評比，真正的度量和優化需要長久的運營。

隨著時間的推移，問題驅動轉向數據驅動，團隊通過數據可以清楚短板在哪里，就可以定向解決這個短板，最終讓研發團隊從軟件生產過程的數據中成長獲益。

如果你也想知道你的企業處于持續交付演進的哪一個階段？歡迎點擊「閱讀原文」回答問卷，KodeRover 將告訴你答案。

活動推薦

• 10 月 23 日，探秘探索游戲互聯網企業高效發展引擎在天府軟件園舉行。成都游戲龍頭企業數字天空 CTO覃小春、獨角獸企業麥麥養老?CTO李光朋以及成都互聯網技術領導者集聚一堂，共同討論企業高效發展思路，歡迎成都游戲與互聯網行業人士參與討論。

• 10 月 26 日，查看 GTLC 成都站相關內容，現在購買 3 張以上門票還可以享受團購優惠——169 元 / 張，多買多優惠哦！

總結

以上是生活随笔為你收集整理的如何提升软件交付效能？答案未必如你所想的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。