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