深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
簡介：研發效能提升不知從何下手、一頭霧水？阿里資深技術專家一文為你揭秘研發效能提升的系統方法。
注：本文是對云棲大會何勉分享內容的整理
這幾年“研發效能”一直是熱詞，很多組織都會啟動研發效能提升專項。我與其中的很多有過深入的交流，他們中達成最終目標的并不多，經常是高調開始，草草收尾。為什么什會這樣呢？
提升研發效能，首先要弄清楚要解決的問題是什么，然后才是落地解決問題的實踐方法。否則問題沒定義清楚，就很難有好的結果。
那提升研發效能究竟要解決什么問題？
我將提升效能要解決的問題，歸納為3個效能不等式。
三個不等式揭秘研發效能的本質
第一個不等式，局部效率不等于高效交付？
這一點，大家應該會感同身受。當我們去問各個部門或者個人時，都覺得他們很忙，效率很高。但是，我們去問業務部門或用戶，卻是另外一回事，他們會抱怨產品研發響應慢、交付遲、質量也不好。
這就是組織內部視角的局部效率并不等于用戶視角的高效交付。這個是提升研發效能要面對的首要問題。解決它需要更有效的組織協同、更合理的交付模式，和更好的過程質量。
接下來的問題是，高效交付就夠了嗎？這就引出了第二個效能不等式。
第二不等式，高效交付能不等于持續高效
有的時候，為了高效的交付，我們可以采取臨時動作，比如把一群人關在一起，成立一個臨時項目，這樣溝通協作會更便捷，這可能會達成一時的高效。但是，如果缺乏長期質量思維，當我們在做下一個項目，往往會發現問題，之前的代碼和設計存在各種問題，比如可修改、可復用性很差，它們成為后續項目的負債而不是資產，長期的效率無法維持。
如何從高效交付轉變成持續的高效，這是研發效能要解決的第2個問題。它對我們的工程和技術能力和實踐都提出了要求。
第三個不等式，高效交付不等于業務成功
產品交付的目的是支持業務發展和業務創新。我們必須保證交付的東西，能解決用戶問題，并構建可持續的商業模式，否則交付再多也沒有意義。
今天，市場和用戶的不確定持續增加，破解這一問題不容易。它需要整個組織能夠聚焦用戶問題，快速交付和試錯，并形成有效反饋調整的閉環。做到這三點才能讓高效交付轉化為業務成功，這是提升研發效能要解決的第三個核心問題。
我們認為，研發效能提升的本質就是要解化解上面的三個不等式，從而把組織內的局部效率轉化為用戶可感知的高效交付，并保障持續的高效和帶來業務的成功。最終實現：“持續地順暢高質量交付有效的價值”。這是效能提升的根本目標。
研發效能提升實踐體系
明確問題是開始，解決它們需要系統的實踐方法。接下來，我們分享這些實踐方法，它是我們對過去的實踐的提煉和總結，并概括為這個圖。
整個圖分為三個模塊：
左側是協作和需求實踐。左上方我們稱之為業務驅動需求的協作模式和產品導向的交互模式，下邊是以終為始的需求分析和設計。左側這部分實踐解決的是局部效率如何帶來高效的交付。
右側是工程與技術實踐。右上方我們稱為領域驅動的架構和實現，中間是標準化的工程基礎設施，下面是應用為中心的持續交付，這部分實踐解決的問題是如何讓我們高效交付帶來持續。
中間這部分是創新實踐。它包含：如何高效探索業務、如何持續快速地完成業務交付，并形成有效的反饋和調整的閉環。創新實踐要解決的問題就是高效交付如何帶來業務的成功。
接下來，我們一步步展開，看一下各部分的關鍵效能提升實踐。
協作和需求實踐
首先我們來看協作需求實踐。
在介紹協作之前，我們需要弄清楚協作的上下文——也就是當我們談協作時，我們在談什么。
讓我們先從梳理需求交付的內在結構開始。
首先，產品交付都是源于目標，有可能是用戶目標，如：更高效的完成某項工作；也有可能是業務目標，如：實現業務的增長，提高用戶的黏性等。我們基于用戶目標和業務目標規劃業務需求。除了業務目標外，客戶的具體訴求也會轉化為業務需求。
業務需求的實現需要落地到產品中，它會被分解為一個個的產品需求。產品需求會進一步被分解為技術任務，通過實現技術任務來交付產品需求，最終實現對應的業務需求。
當然，產品需求并不一定都直接來自業務需求，產品也會做出自己的規劃，包括架構的升級和技術重構，或者面向未來的前瞻性技術布局，如AI算法、區塊鏈平臺等。這部分產品需求，雖然不來自當下的業務需求，但它同樣服務于業務目標，只不過是長期和未來的業務目標。
了解了產品交付的結構之后，接下來，我們看在這樣的結構下，如何實現團隊的高效協同。
業務驅動的協作模式
首先，我們協同的結構應該和前面的產品交付需求層次結構一致。業務需求、產品需求和技術任務由不同的職能的人來負責，例如業務人員負責創建業務需求，業務人員和產品經理一起把業務需求規劃分解為產品需求。
業務需求、產品需求、技術任務，這是交付需求過程中的基本價值單元。而文檔、代碼、測試、數據等都是為它們服務的，與應該向它們關聯，并沉淀為資產。
業務需要被收集、管理、規劃和交付，完成這些工作需要有獨立的空間,它對應研發協同工具中的“業務空間”。在業務空間中，還要能看到業務需求是如何拆分為產品需求的。我們稱之為管一層也要向下看一層，這樣才能保證業務需求交付。
業務需求交付是一個動態的過程，需要清晰的工作流，它定義了業務需求從提出、接收、規劃，直到發布、驗收的整個過程。順暢高質量地交付就是要讓這個工作流更加順暢，減少過程中的阻礙和等待。
與業務需求一樣，產品需求也需要被收集、管理、規劃和交付，研發管理工具，同樣要為產品人員提供專屬的產品交付空間，并定義產品交付的工作流。技術開發者也需要對他們友好的工作臺。在這里，他們接受、管理、計劃和完成技術工作。
更重要的是，我們需要讓這三個層次三者變成有機的整體，讓大家真正的協同起來，順暢的交付業務需求。這三個層次的工作流是相互關聯，業務需求規劃后被拆分為產品需求，產品需求會被進一步拆分為任務，這些是自上而下的。
再看自下而上的，下層的工作完成后，它的狀態要能夠被自動卷積上去，比如產品需求下所有的任務完成后，對應的產品需求進入待測試狀態。業務需求所有產品需求完成后，業務需求的狀態也需要自動變更。
這三個層次的聯動和透明，讓問題和阻礙更容易被識別，比如業務需求交付延期或者出現問題時，能清晰的看到是哪一個產品造成的，應該在哪里采取動作。
我們把這稱為業務驅動的協作模式。組織中不同的職能和團隊，必須相互協同完成業務交付，達成用戶或者業務的目標，業務驅動的協作模式，讓這一過程更加透明和高效。
產品導向的交付模式
前面講的是協作模式，企業的業務需求最終還是要到落實到產品交付團隊中交付的。以前我們更多把IT交付團隊看成成本中心，先確定需求范圍，再確定時間，然后分配資源、成立項目、完成交付這也被稱為項目導向的交付模式。
項目導向的交付本質是把人作為資源分配到事情上。其背后的假設是未來是確定的，在確定的時間內交付確定的內容。它強調計劃和執行，追求交付的確定性。
確定性今天已經越來越不現實，組織必須學會與變化共舞。另外，項目導向的交付導致短期思維，缺乏工程、技術長期改進意識。同時，因為團隊的臨時性，也無法持續團隊的交付效能。
數字化時代，我們需要從項目導向的交付模式向產品導向的交付模式遷移。產品導向的交付模式本質是把事情交給跨功能的特性團隊，由相對穩定的特性團隊持續的接受并完成需求的交付。
特性團隊對產品的迭代負責，他們擁抱業務的不確定性，并為此不斷演進產品。特性團隊要維護產品，必須建立長期思維，注重代碼資產和工程資產，并持續改進團隊交付能力和交付流程，提升交付效能。
但這還不夠，因為如果各個產品各自為政，任何特性團隊的需求過載都會讓它成為整個業務瓶頸，解決辦法是，同一業務領域的多個特性團隊，共享同一需求列表。這就讓一個團隊出現資源瓶頸時，需求可以分配到另一個團隊，這與今天很多服務行業中實行的，“一個隊列多個服務窗”的本質是一致的。
以終為始的需求分析和設計
前面，我們講了，企業的協同模式應該是業務驅動的，團隊的交付模式應該是產品導向的，它們解決協同流程的問題，但光有流程是不夠的，我們還必須保證輸入的質量。
IT行業有一句著名的話：“輸入的是垃圾，輸出的也會是垃圾“ 。需求的輸入，是交付過程是源頭，也是最關鍵的部分。如果輸入的有問題，交付的中間過程也不可能順暢。那我們應該怎么做呢？
“輸入垃圾，輸出垃圾”的反面是以終為始，——也就是在需求輸入的時候，團隊要知道最終要做成什么樣子，并在業務、產品和技術之間達成一致。
那么，怎樣才叫以終為始呢？以終為始分為3個方面：
第一，對于業務需求，要有明確的業務目標，并基于目標定義清晰的業務流程，確保業務流程可以支持業務目標的實現，這是業務分析要完成的工作。
第二，對于產品需求，它要能支持業務流程的實現，為此我們要基于業務流程，明確定義產品的功能，對于每一個產品功能，首先要明確用戶使用的交互流程，并在交互流程的基礎上，明確驗收標準。
第三，明確業務需求、產品需求之間的結構，也就是業務需求和產品需求之間的層級關系。這對后面的團隊協作都很重要，我們協作交付的目標不是產品需求而是業務需求，只有結構清晰，協作的時才知道這些產品需求如何協同向業務對齊，完成快速交付業務需求。
總結一下，業務分析和產品設計分是一個金字塔的結構：
需求永遠源自業務目標，基于業務目標分析業務流程，基于業務流程分解產品需求，并對產品需求進行設計。
金字塔的上面兩層：是業務分析關注的。我們引入了“事件驅動的分析”方法，——基于目標和業務事件分析業務流程，并基于業務流程拆分定義產品需求，并劃分最小可行產品（MVP）。
金字塔的下面兩層：是產品設計所關注的。在業務流程設計的基礎上，分解出產品需求，并對產品需求進行澄清。澄清和設計需求最好的方式是以用戶使用實例來說明操作流程、驗收規則是什么樣，也就是用戶在什么情況下，做什么操作，將得到什么結果。我們引入了“實例化需求”分析方法來支持這一過程。
通過系統的業務分析和產品設計方法，在需求上從GIGO轉變為以終為始，這是局部效率轉化為高效交付的重要一環。
下面，讓我們在從另一維度，解釋一下協作和需求實踐，以上圖的產品截圖為例，總結一下，我們在協作部分要做到的三點：
第一點，我們要看到并且要管理端到端的業務需求的交付過程，我們稱之為前后職能拉通。這些職能可能是業務、產品、開發、測試，部署和運維。我們要拉通這些職能，讓他們更高效的配合，讓業務需求從左到右順暢的流動和交付。
第二點，左右模塊對齊。一個業務需求可能會分解到不同的產品里面，每個產品都有自己的工作流，產品的交付要向業務的交付對齊。 ? ?
我們的目標不是讓某一個產品忙起來，而是讓業務需求的交付更順暢。所以各個產品都要向業務需求的交付對齊。研發管理工具上也要能實現這一點，包括，規劃上對齊產品和業務需求，以及在執行過程中對齊產品和業務，并即時發現因無法對齊帶來的阻礙和等待。
第三點，內建過程質量。需求在每個階段應該有明確的質量標準并執行到位，例如需求輸入的質量要做到以終為始，需求測試的質量、測試轉發布等都應該有明確的標準。質量應該建立在每個需求的每個階段之上，而不是成批的依賴于最后的檢測階段。
我們要做到前后職能拉通，左右模塊對齊，內建過程質量。最終形成這樣下圖所示的協作模式。
圖中每個節點都是一個具體活動，這些活動有它的節奏、負責人、輸入輸出，以及實踐方法的支持，如前面提到的事件驅動的業務分析和實例化需求等，這樣才能讓業務、產品、技術真正形成一個整體，做到這樣順暢和高質量的交付業務需求。
技術和工程實踐
技術和工程部分，我們究竟要解決什么問題呢？我們先看一幅圖。
上圖橫軸是時間，縱軸是生產效率。我們希望效率是沿著綠色線一路向上的，但是現實中可能隨著時間的推移、產品變得復雜、團隊規模變大，而效率反而降低。
區分這兩條線的核心就是在工程和技術實踐上，它決定我們積累的到底是資產還是債務，也最終決定了長期的效率。
領域驅動的架構和實現
在技術方面，我們要持續積累并維護好領域資產，讓它易于理解、擴展、維護和復用，今天業界普遍都認識到領域驅動設計的重要性，也愿意投入精力。然而，領域驅動設計要發揮作用并不容易。
領域驅動設計不僅僅是設計的問題，它是涉及需求、架構和實現的系統工程。需求和業務是源頭，架構是樞紐，而他們都需要落地到現實當中。最重要的是如何把需求、架構和實踐真正連接起來，連接他們的是領域模型。
如上圖所示，我們從業務需求開始去分析業務流程，基于業務流程分解和設計產品需求，通過實例化需求定義驗收測試，澄清和細化產品需求。更重要的是，在整個的需求分析的階段中，我們要不斷地提取和精化領域模型。因為對領域的認識和抽象來自于每個具體的業務、具體的需求，所以被稱為“業務引領的領域建?！?。
領域模型應該成為應用架構設計的基礎。我們基于領域模型去劃分子域，設定子域的上下文，基于領域模型去定義接口的設計契約，劃分子域和限界上下文，并約束微服務的邊界，讓微服務成為可復用的領域資產。限界上下文和服務契約最終保障領域資產的可復用。所以我們稱為“領域引領的微服務架構”。
在實現上，領域模型、驗收測試、服務設計契約都是高質量代碼的約束和指導。我們的代碼要體現領域模型，與架構和接口契約一致，并符合相關驗收標準。
同時，測試先行的方式，讓我們有更靠譜的自動化測試，而自動化測試會讓我們的重構更有保障。持續的重構又保證代碼資產不會快速腐化，維持系統健康。
今天分享的更多還停留在概念層面，但是我希望能在思考規劃上給大家帶來啟發。除非你認為你可以犧牲長期的質量，你不需要積累一個長期可重復的資產，那么上述這些都是不可或缺的。
標準化的工程基礎設施
接下來我們看工程部分。今天比較幸運的是，我們看到工程部分的技術趨勢正在收斂。
我們看到基于容器管理和分發制品，基于k8s編排環境資源,這一部分已成為了一個事實，大家都不再考慮要不要做，而是什么時間做，或者怎么做的問題。這個方向大概率不會改變。但問題是，我們講容器，更多還是站在資源的視角去看，即站在運維的視角，但是在開發視角，看到的是代碼，代碼對應的是應用。如果僅做到這一點，開發和運維之間還是有隔閡，他們所面對的對象就不同。
今天我們看到另外一個趨勢，是基于OAM的標準去做應用管理。OAM的標準是阿里和微軟共同提出的叫做開放應用模型，基于OAM可以管理應用的開發、編排和運維。OAM是一個標準，基于這個標準，開發可以聲明式地編排應用，運維也可以基于已有的聲明進行自動化的運維。
OAM 面向應用的部署和運維的終態，統一了應用開發和運維的基本模型。它首先提出了應用描述的基本模型，包括應用的拓撲、資源依賴、部署方式、運維方式等，然后定義聲明式的應用編排、部署和運維方式。OAM基于應用，統一了開發和運維的基本語言，讓應用成為開發和運維共同的關注和操作的基本對象，解決了技術基礎實施的問題，讓真正的DevOps 成為可能。
但是這個離真正的DevOps還差一點，我們剛才講的只是我們有了DevOps的基礎，我們從部署這個階段基于這樣的標準，但是我們還沒有定義我們的應用是怎么交付的。如果把應用和交付這一部分也包含進去，就會實現真正的DevOps。
我們看這樣一幅圖，如下圖所示，我們這樣定義應用的變更流程
首先，我們要解耦部署和發布，部署是技術行為，發布是業務行為。我們希望每一個應用可以單獨部署，所以我們要解耦部署發布，以應用為單元，持續的集成和部署。
但是這還不夠，應用的變更從哪里來？應用來自于業務需求，業務需求拆解為產品需求，產品需求對應一系列應用的變更。
每個應用的變更都有自己的流程。當這個業務需求對應所有的應用變更部署完成之后，這個業務需求也應該能夠完成發布。
我們的工具、流程、操作要能夠連接起這些應用的變更和產品需求，直至業務需求。這樣我們就能夠做到以業務需求為單位發布——當一個業務需求下所有的變更都部署完成后，業務需求可以隨時發布。
我們認為持續交付的最佳形態是以單應用為單位變更部署，以單需求為單位，需要的時候就去發布，在此基礎上，我們就有機會建立起最快速的業務閉環。
以上是我們看到云原生持續交付的形態，也就是以應用為單位的持續部署，業務為需求單元的持續發布，前提是，我們以應用統一了開發和運維的基本單元。
總結一下，我們認為云原生下的BizDevOps的形態是什么？有三點：
- 面向終態，基于開放應用模型OAM，形成運維和開發底層模型的一致化和標準化。
? - 以應用為核心，連通應用的開發、集成過程和部署運維過程，實現云原生時代的DevOps。
? - 連接并對齊業務需求與應用變更，并完善反饋閉環，實現真正意義上的BizDevOps 。
?總結
效能提升，必須從清晰定義問題開始。
我將提升研發效能要解決的根本問題總結為三個效能不等式?；膺@三個效能不等式，需要系統的實踐。
第一，讓局部效率轉化為高效的交付。為此，我們需要落地業務驅動的協作模式和產品導向的交付，同時在需求上要做到真正的以終為始。
第二，讓高效交付可以持續，為此，在技術上要做到領域驅動的架構和實現，不斷積累和優化領域技術資產。在工程上，要建設云原生的標準化基礎設施，并以應用中心打通開發運維和連接業務的需求，最終實現以應用中心的持續部署和以業務需求為中心的持續發布。
第三，讓高效交付帶來業務成功。為此，需要建立業務探索和持續交付之間的快速執行和反饋的閉環。
以上3點的共性是，它們都以業務為起點。比如：以業務需求驅動組織中各個環節和部門的高效協同；從業務目標開始，分析業務流程，并分解設計產品；連接業務需求和產品應用變更，實現業務需求的持續發布；建立業務探索和持續交付之間的快速閉環。
落地這些實踐，必須打通業務（ Biz）、開發（Dev）和運維（Ops），讓他們成為一個高效運作的整體，建設BizDevOps實踐體系，賦能數字化時代的組織，加速業務發展和創新。
原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?
總結
以上是生活随笔為你收集整理的深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Pull or Push？监控系统如何选
- 下一篇： Apsara Stack 技术百科 |