簡介：研發(fā)效能提升不知從何下手、一頭霧水？阿里資深技術(shù)專家一文為你揭秘研發(fā)效能提升的系統(tǒng)方法。

注：本文是對云棲大會何勉分享內(nèi)容的整理

這幾年“研發(fā)效能”一直是熱詞，很多組織都會啟動研發(fā)效能提升專項。我與其中的很多有過深入的交流，他們中達(dá)成最終目標(biāo)的并不多，經(jīng)常是高調(diào)開始，草草收尾。為什么什會這樣呢？

提升研發(fā)效能，首先要弄清楚要解決的問題是什么，然后才是落地解決問題的實踐方法。否則問題沒定義清楚，就很難有好的結(jié)果。

那提升研發(fā)效能究竟要解決什么問題？

我將提升效能要解決的問題，歸納為3個效能不等式。

三個不等式揭秘研發(fā)效能的本質(zhì)

第一個不等式，局部效率不等于高效交付？

這一點，大家應(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é)作會更便捷，這可能會達(dá)成一時的高效。但是，如果缺乏長期質(zhì)量思維，當(dāng)我們在做下一個項目，往往會發(fā)現(xiàn)問題，之前的代碼和設(shè)計存在各種問題，比如可修改、可復(fù)用性很差，它們成為后續(xù)項目的負(fù)債而不是資產(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ā)效能要解決的第三個核心問題。

我們認(rèn)為，研發(fā)效能提升的本質(zhì)就是要解化解上面的三個不等式，從而把組織內(nèi)的局部效率轉(zhuǎn)化為用戶可感知的高效交付，并保障持續(xù)的高效和帶來業(yè)務(wù)的成功。最終實現(xiàn)：“持續(xù)地順暢高質(zhì)量交付有效的價值”。這是效能提升的根本目標(biāo)。

研發(fā)效能提升實踐體系

明確問題是開始，解決它們需要系統(tǒng)的實踐方法。接下來，我們分享這些實踐方法，它是我們對過去的實踐的提煉和總結(jié)，并概括為這個圖。

整個圖分為三個模塊：

左側(cè)是協(xié)作和需求實踐。左上方我們稱之為業(yè)務(wù)驅(qū)動需求的協(xié)作模式和產(chǎn)品導(dǎo)向的交互模式，下邊是以終為始的需求分析和設(shè)計。左側(cè)這部分實踐解決的是局部效率如何帶來高效的交付。

右側(cè)是工程與技術(shù)實踐。右上方我們稱為領(lǐng)域驅(qū)動的架構(gòu)和實現(xiàn)，中間是標(biāo)準(zhǔ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é)作之前，我們需要弄清楚協(xié)作的上下文——也就是當(dāng)我們談協(xié)作時，我們在談什么。

讓我們先從梳理需求交付的內(nèi)在結(jié)構(gòu)開始。

首先，產(chǎn)品交付都是源于目標(biāo)，有可能是用戶目標(biāo)，如：更高效的完成某項工作；也有可能是業(yè)務(wù)目標(biāo)，如：實現(xiàn)業(yè)務(wù)的增長，提高用戶的黏性等。我們基于用戶目標(biāo)和業(yè)務(wù)目標(biāo)規(guī)劃業(yè)務(wù)需求。除了業(yè)務(wù)目標(biāo)外，客戶的具體訴求也會轉(zhuǎn)化為業(yè)務(wù)需求。

業(yè)務(wù)需求的實現(xiàn)需要落地到產(chǎn)品中，它會被分解為一個個的產(chǎn)品需求。產(chǎn)品需求會進(jì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ù)目標(biāo)，只不過是長期和未來的業(yè)務(wù)目標(biāo)。

了解了產(chǎn)品交付的結(jié)構(gòu)之后，接下來，我們看在這樣的結(jié)構(gòu)下，如何實現(xiàn)團(tuán)隊的高效協(xié)同。

業(yè)務(wù)驅(qū)動的協(xié)作模式

首先，我們協(xié)同的結(jié)構(gòu)應(yīng)該和前面的產(chǎn)品交付需求層次結(jié)構(gòu)一致。業(yè)務(wù)需求、產(chǎn)品需求和技術(shù)任務(wù)由不同的職能的人來負(fù)責(zé)，例如業(yè)務(wù)人員負(fù)責(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ù)工作。

更重要的是，我們需要讓這三個層次三者變成有機(jī)的整體，讓大家真正的協(xié)同起來，順暢的交付業(yè)務(wù)需求。這三個層次的工作流是相互關(guān)聯(lián)，業(yè)務(wù)需求規(guī)劃后被拆分為產(chǎn)品需求，產(chǎn)品需求會被進(jìn)一步拆分為任務(wù)，這些是自上而下的。

再看自下而上的，下層的工作完成后，它的狀態(tài)要能夠被自動卷積上去，比如產(chǎn)品需求下所有的任務(wù)完成后，對應(yīng)的產(chǎn)品需求進(jì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é)作模式。組織中不同的職能和團(tuán)隊，必須相互協(xié)同完成業(yè)務(wù)交付，達(dá)成用戶或者業(yè)務(wù)的目標(biāo)，業(yè)務(wù)驅(qū)動的協(xié)作模式，讓這一過程更加透明和高效。

產(chǎn)品導(dǎo)向的交付模式

前面講的是協(xié)作模式，企業(yè)的業(yè)務(wù)需求最終還是要到落實到產(chǎn)品交付團(tuán)隊中交付的。以前我們更多把IT交付團(tuán)隊看成成本中心，先確定需求范圍，再確定時間，然后分配資源、成立項目、完成交付這也被稱為項目導(dǎo)向的交付模式。

項目導(dǎo)向的交付本質(zhì)是把人作為資源分配到事情上。其背后的假設(shè)是未來是確定的，在確定的時間內(nèi)交付確定的內(nèi)容。它強(qiáng)調(diào)計劃和執(zhí)行，追求交付的確定性。

確定性今天已經(jīng)越來越不現(xiàn)實，組織必須學(xué)會與變化共舞。另外，項目導(dǎo)向的交付導(dǎo)致短期思維，缺乏工程、技術(shù)長期改進(jìn)意識。同時，因為團(tuán)隊的臨時性，也無法持續(xù)團(tuán)隊的交付效能。

數(shù)字化時代，我們需要從項目導(dǎo)向的交付模式向產(chǎn)品導(dǎo)向的交付模式遷移。產(chǎn)品導(dǎo)向的交付模式本質(zhì)是把事情交給跨功能的特性團(tuán)隊，由相對穩(wěn)定的特性團(tuán)隊持續(xù)的接受并完成需求的交付。

特性團(tuán)隊對產(chǎn)品的迭代負(fù)責(zé)，他們擁抱業(yè)務(wù)的不確定性，并為此不斷演進(jìn)產(chǎn)品。特性團(tuán)隊要維護(hù)產(chǎn)品，必須建立長期思維，注重代碼資產(chǎn)和工程資產(chǎn)，并持續(xù)改進(jìn)團(tuán)隊交付能力和交付流程，提升交付效能。

但這還不夠，因為如果各個產(chǎn)品各自為政，任何特性團(tuán)隊的需求過載都會讓它成為整個業(yè)務(wù)瓶頸，解決辦法是，同一業(yè)務(wù)領(lǐng)域的多個特性團(tuán)隊，共享同一需求列表。這就讓一個團(tuán)隊出現(xiàn)資源瓶頸時，需求可以分配到另一個團(tuán)隊，這與今天很多服務(wù)行業(yè)中實行的，“一個隊列多個服務(wù)窗”的本質(zhì)是一致的。

以終為始的需求分析和設(shè)計

前面，我們講了，企業(yè)的協(xié)同模式應(yīng)該是業(yè)務(wù)驅(qū)動的，團(tuán)隊的交付模式應(yīng)該是產(chǎn)品導(dǎo)向的，它們解決協(xié)同流程的問題，但光有流程是不夠的，我們還必須保證輸入的質(zhì)量。

IT行業(yè)有一句著名的話：“輸入的是垃圾，輸出的也會是垃圾“ 。需求的輸入，是交付過程是源頭，也是最關(guān)鍵的部分。如果輸入的有問題，交付的中間過程也不可能順暢。那我們應(yīng)該怎么做呢？

“輸入垃圾，輸出垃圾”的反面是以終為始，——也就是在需求輸入的時候，團(tuán)隊要知道最終要做成什么樣子，并在業(yè)務(wù)、產(chǎn)品和技術(shù)之間達(dá)成一致。

那么，怎樣才叫以終為始呢？以終為始分為3個方面：

第一，對于業(yè)務(wù)需求，要有明確的業(yè)務(wù)目標(biāo)，并基于目標(biāo)定義清晰的業(yè)務(wù)流程，確保業(yè)務(wù)流程可以支持業(yè)務(wù)目標(biāo)的實現(xiàn)，這是業(yè)務(wù)分析要完成的工作。

第二，對于產(chǎn)品需求，它要能支持業(yè)務(wù)流程的實現(xiàn)，為此我們要基于業(yè)務(wù)流程，明確定義產(chǎn)品的功能，對于每一個產(chǎn)品功能，首先要明確用戶使用的交互流程，并在交互流程的基礎(chǔ)上，明確驗收標(biāo)準(zhǔn)。

第三，明確業(yè)務(wù)需求、產(chǎn)品需求之間的結(jié)構(gòu)，也就是業(yè)務(wù)需求和產(chǎn)品需求之間的層級關(guān)系。這對后面的團(tuán)隊協(xié)作都很重要，我們協(xié)作交付的目標(biāo)不是產(chǎn)品需求而是業(yè)務(wù)需求，只有結(jié)構(gòu)清晰，協(xié)作的時才知道這些產(chǎn)品需求如何協(xié)同向業(yè)務(wù)對齊，完成快速交付業(yè)務(wù)需求。

總結(jié)一下，業(yè)務(wù)分析和產(chǎn)品設(shè)計分是一個金字塔的結(jié)構(gòu)：

需求永遠(yuǎn)源自業(yè)務(wù)目標(biāo)，基于業(yè)務(wù)目標(biāo)分析業(yè)務(wù)流程，基于業(yè)務(wù)流程分解產(chǎn)品需求，并對產(chǎn)品需求進(jìn)行設(shè)計。

金字塔的上面兩層：是業(yè)務(wù)分析關(guān)注的。我們引入了“事件驅(qū)動的分析”方法，——基于目標(biāo)和業(yè)務(wù)事件分析業(yè)務(wù)流程，并基于業(yè)務(wù)流程拆分定義產(chǎn)品需求，并劃分最小可行產(chǎn)品（MVP）。

金字塔的下面兩層：是產(chǎn)品設(shè)計所關(guān)注的。在業(yè)務(wù)流程設(shè)計的基礎(chǔ)上，分解出產(chǎn)品需求，并對產(chǎn)品需求進(jì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ù)的交付對齊。 ? ?

我們的目標(biāo)不是讓某一個產(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ì)量標(biāo)準(zhǔn)并執(zhí)行到位，例如需求輸入的質(zhì)量要做到以終為始，需求測試的質(zhì)量、測試轉(zhuǎn)發(fā)布等都應(yīng)該有明確的標(biāo)準(zhǔn)。質(zhì)量應(yīng)該建立在每個需求的每個階段之上，而不是成批的依賴于最后的檢測階段。

我們要做到前后職能拉通，左右模塊對齊，內(nèi)建過程質(zhì)量。最終形成這樣下圖所示的協(xié)作模式。

圖中每個節(jié)點都是一個具體活動，這些活動有它的節(jié)奏、負(fù)責(zé)人、輸入輸出，以及實踐方法的支持，如前面提到的事件驅(qū)動的業(yè)務(wù)分析和實例化需求等，這樣才能讓業(yè)務(wù)、產(chǎn)品、技術(shù)真正形成一個整體，做到這樣順暢和高質(zhì)量的交付業(yè)務(wù)需求。

技術(shù)和工程實踐

技術(shù)和工程部分，我們究竟要解決什么問題呢？我們先看一幅圖。

上圖橫軸是時間，縱軸是生產(chǎn)效率。我們希望效率是沿著綠色線一路向上的，但是現(xiàn)實中可能隨著時間的推移、產(chǎn)品變得復(fù)雜、團(tuán)隊規(guī)模變大，而效率反而降低。

區(qū)分這兩條線的核心就是在工程和技術(shù)實踐上，它決定我們積累的到底是資產(chǎn)還是債務(wù)，也最終決定了長期的效率。

領(lǐng)域驅(qū)動的架構(gòu)和實現(xiàn)

在技術(shù)方面，我們要持續(xù)積累并維護(hù)好領(lǐng)域資產(chǎn)，讓它易于理解、擴(kuò)展、維護(hù)和復(fù)用，今天業(yè)界普遍都認(rèn)識到領(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)品需求，通過實例化需求定義驗收測試，澄清和細(xì)化產(chǎn)品需求。更重要的是，在整個的需求分析的階段中，我們要不斷地提取和精化領(lǐng)域模型。因為對領(lǐng)域的認(rèn)識和抽象來自于每個具體的業(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)驗收標(biāo)準(zhǔn)。

同時，測試先行的方式，讓我們有更靠譜的自動化測試，而自動化測試會讓我們的重構(gòu)更有保障。持續(xù)的重構(gòu)又保證代碼資產(chǎn)不會快速腐化，維持系統(tǒng)健康。

今天分享的更多還停留在概念層面，但是我希望能在思考規(guī)劃上給大家?guī)韱l(fā)。除非你認(rèn)為你可以犧牲長期的質(zhì)量，你不需要積累一個長期可重復(fù)的資產(chǎn)，那么上述這些都是不可或缺的。

標(biāo)準(zhǔn)化的工程基礎(chǔ)設(shè)施

接下來我們看工程部分。今天比較幸運的是，我們看到工程部分的技術(shù)趨勢正在收斂。

我們看到基于容器管理和分發(fā)制品，基于k8s編排環(huán)境資源,這一部分已成為了一個事實，大家都不再考慮要不要做，而是什么時間做，或者怎么做的問題。這個方向大概率不會改變。但問題是，我們講容器，更多還是站在資源的視角去看，即站在運維的視角，但是在開發(fā)視角，看到的是代碼，代碼對應(yīng)的是應(yīng)用。如果僅做到這一點，開發(fā)和運維之間還是有隔閡，他們所面對的對象就不同。

今天我們看到另外一個趨勢，是基于OAM的標(biāo)準(zhǔn)去做應(yīng)用管理。OAM的標(biāo)準(zhǔn)是阿里和微軟共同提出的叫做開放應(yīng)用模型，基于OAM可以管理應(yīng)用的開發(fā)、編排和運維。OAM是一個標(biāo)準(zhǔn)，基于這個標(biāo)準(zhǔn)，開發(fā)可以聲明式地編排應(yīng)用，運維也可以基于已有的聲明進(jìn)行自動化的運維。

OAM 面向應(yīng)用的部署和運維的終態(tài)，統(tǒng)一了應(yīng)用開發(fā)和運維的基本模型。它首先提出了應(yīng)用描述的基本模型，包括應(yīng)用的拓?fù)洹①Y源依賴、部署方式、運維方式等，然后定義聲明式的應(yīng)用編排、部署和運維方式。OAM基于應(yīng)用，統(tǒng)一了開發(fā)和運維的基本語言，讓應(yīng)用成為開發(fā)和運維共同的關(guān)注和操作的基本對象，解決了技術(shù)基礎(chǔ)實施的問題，讓真正的DevOps 成為可能。

但是這個離真正的DevOps還差一點，我們剛才講的只是我們有了DevOps的基礎(chǔ)，我們從部署這個階段基于這樣的標(biāo)準(zhǔn)，但是我們還沒有定義我們的應(yīng)用是怎么交付的。如果把應(yīng)用和交付這一部分也包含進(jìn)去，就會實現(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ā)布。

我們認(rèn)為持續(xù)交付的最佳形態(tài)是以單應(yīng)用為單位變更部署，以單需求為單位，需要的時候就去發(fā)布，在此基礎(chǔ)上，我們就有機(jī)會建立起最快速的業(yè)務(wù)閉環(huán)。

以上是我們看到云原生持續(xù)交付的形態(tài)，也就是以應(yīng)用為單位的持續(xù)部署，業(yè)務(wù)為需求單元的持續(xù)發(fā)布，前提是，我們以應(yīng)用統(tǒng)一了開發(fā)和運維的基本單元。

總結(jié)一下，我們認(rèn)為云原生下的BizDevOps的形態(tài)是什么？有三點：

• 面向終態(tài)，基于開放應(yīng)用模型OAM，形成運維和開發(fā)底層模型的一致化和標(biāo)準(zhǔn)化。
  ?
• 以應(yīng)用為核心，連通應(yīng)用的開發(fā)、集成過程和部署運維過程，實現(xiàn)云原生時代的DevOps。
  ?
• 連接并對齊業(yè)務(wù)需求與應(yīng)用變更，并完善反饋閉環(huán)，實現(xiàn)真正意義上的BizDevOps 。

?總結(jié)

效能提升，必須從清晰定義問題開始。

我將提升研發(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è)云原生的標(biāo)準(zhǔn)化基礎(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ù)目標(biāo)開始，分析業(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)新。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。