注：本文是對云棲大會何勉分享內容的整理，稍有刪減，點擊下方鏈接觀看完整視
云效BizDevOps論壇：https://yunqi.aliyun.com/2021/agenda/session173
這幾年“研發效能”一直是熱詞，很多組織都會啟動研發效能提升專項，我與其中的很多有過深入的交流，他們中達成最終目標的并不多，經常是高調開始，草草收尾，為什么什會這樣呢？
提升研發效能，首先要弄清楚要解決的問題是什么，然后才是落地解決問題的實踐方法，否則問題沒定義清楚，就很難有好的結果，
那提升研發效能究竟要解決什么問題？
我將提升效能要解決的問題，歸納為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的最新動態，可微信搜索關注【云效】公眾號；
彩蛋：公眾號后臺回復【指南】，可獲得《阿里巴巴DevOps實踐指南》&《10倍研發效能提升案例集》；
看完覺得對您有所幫助別忘記點贊、收藏和關注呦；
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/388968.html
標籤：其他