從持續交付到業務創新（上）：互聯網時代研發效能的核心

本期的分享嘉賓是阿里巴巴阿拉丁團隊的資深技術專家何勉老師，何老師也是國內最早的精益產品開發實踐者之一，專注于產品開發和產品設計及創新兩方面的探索和實踐，幫助組織提升效能，使其順暢、高質量交付有用價值，

本期課程將圍繞著敏捷產品開發維度，從敏捷開發的目標、定義和提高持續交付能力、敏捷在持續交付的基礎上的創新實踐和全堆疊敏捷四個維度，帶我們探索敏捷研發的冰山一角，

大家好，今天我們分享的主題是：《從持續交付到業務創新》，我將從敏捷產品開發講起，

從本質上講敏捷開發的一個重要目標是建立持續價值交付的能力，這種能力最終必須服務于業務的創新，促進業務的成功，相對應的，今天分享的內容，包含兩個方面，第一：什么是持續交付以及如何建立持續交付能力；第二：以持續交付能力為基礎，落實業務創新的實踐，形成有效的創新倍訓，這是今天分享題目——“從持續交付到業務創新”的由來，具體包含以下4個部分：

第一：敏捷開發的目標；

第二：定義和提高持續交付能力；

第三：在持續交付的基礎上落實創新實踐；

最后是一個總結，我們會提出全堆疊敏捷 Full Stack Agile 的概念，它是技術和管理的綜合，也是交付和創新的綜合，

第一部分：敏捷開發業務目標

我們經常會說敏捷模式，那什么開發模式是不敏捷呢？對，我們通常說“瀑布”是不敏捷的，

瀑布開發模式把開發分成一系列階段，如需求、設計、開發、測驗，就像上圖它畫出來的，看起來很像瀑布，所以叫瀑布開發，問題是需求的交付難道不都是要經歷這些階段嗎？

瀑布開發的本質問題并不是階段，而是批量，需求批量地在一起進行設計，然后是批量地開發，批量地測驗、交付等等，批量有什么問題? 首先，批量讓價值交付延遲，所有需求在最后的階段才能交付，價值交付比較晚，    

價值交付比較晚又怎么樣？看這幅圖，左邊是Intel的創始人摩爾，摩爾定律的提出者，摩爾定律告訴我們，18個月之后，用同樣的錢能買到多一倍的東西，比如計算能力、存盤量、晶元數等等，而右邊這位是Google執行董事長施密特，他提出了反摩爾定律，表述為：“如果18個月之后我們只能賣出跟今天一樣的東西，我們就只能得到一半的收入”，

反摩爾定律是摩爾定律的一個簡單推論，它告訴我們，越遲交付的價值也是越低的價值，對硬體公司這很關鍵，甚至決定它們的的宿命——技術進步必須跟得上摩爾定律，否則利潤就會被摩爾定律吞噬，讓產品或公司走向滅亡，

軟體或互聯網服務又怎樣呢? IBM在上世紀90年代，意識到不能做一家硬體公司，轉而主攻服務和軟體行業，它的確過了一段好日子，然而，很快互聯網時代到來了，軟體和服務行業的創新一下子加速了，這時，相對硬體公司，反摩爾定律在軟體和互聯網服務公司的作用是有過之而無不及的，時間的遲早可能不僅僅決定價值的多少，有時錯過整時間窗，可能會一無所獲，

反摩爾定律告訴我們，越遲交付的價值也是越低的價值，所以對于軟體開發來說，瀑布模式延遲了價值交付，得到的價值也更少，相對瀑布，我們提出了迭代交付，我們把開發分成迭代，每個迭代交付一部分價值，更早交付的價值往往意味著更多的價值，就這一點來說，迭代相對瀑布的本質是，更小批量的快速交付，從而更早獲取更多價值，和獲取市場競爭的先機，

所以敏捷開發有第一個目標就是更快的交付價值，這里的快指的不是絕對速度，而是更早的交付，

第二點，我們再看一個坐標圖，這個坐標是專案的時間歷程，最左是專案開始，最右是專案結束，縱坐標是團隊擁有的這個專案和產品的知識，比如說用戶要什么，采取什么樣的產品方案，應該做什么樣的功能，以怎樣的形式來協作，選擇什么樣的技術方案等等，

我們想問一下團隊（包括產品也包括開發、業務）什么時候對于產品和專案的知識最充分、最多？大家的答案都很一致，專案結束的時候，這顯而易見，我們在專案行程中積累了知識，特別是當向用戶交付產品后，用戶反饋：“我要的不是這個啊，我說的明明是…”，這時候你瞬間狂漲知識，并感嘆道“你怎么不早說呢？”，這中間可能有溝通問題，但更多可能的是，用戶這時才清楚或能夠描述他們要的是啥，更有甚者，我們可能一開始連用戶是誰也未必能準確的定義，產品和業務開發本來就是一個探索的程序，開始時一定是最無知的時刻，

再問一個問題，專案中的大部分決策，是什么時間做出的呢？大家的答案也很明確——專案開始的時刻，這里埋藏了一個重大的悖論，我們在最無知的時刻，做出了最重要而且是絕大部分的決策，并把它作為隨后執行的依據，面對不確定的技術、市場環境，傳統開發模式已無法適應要求，悖論越發突出，

對于這一悖論，敏捷的對策還是迭代，開始時，我們會做出一些初始的決策，比如說總體目標是什么，大概的策略和打法是什么，從哪里開始，怎么檢驗等等，但這些只是初始決策，定義了大致的方向，在整個開發程序，我們迭代交付需求，獲取市場的反饋和最新的資訊，并基于這些反饋和資訊，積累和修正對產品的認知，增量地決策和調整，

產品開發程序中，技識訓境、市場環境、競品策略、團隊認知都會發生變化，面對變化的環境，我們必須承認自己的無知，在開發程序主動有效地學習，不斷地汲取反饋，靈活地調整，這也是敏捷的第二個業務目標，有效學習和靈活回應變化，

綜合上面提到的敏捷開發的兩個業務目標，我們就可以給敏捷開發下一個定義了，敏捷指的是創建一個組織更快（早）的交付價值，和更有效學習和靈活應變的能力，

從能力的角度，敏捷的核心是持續交付價值的能力，以及以持續交付為基礎的快速反饋學習能力，為了具備這樣的能力，產品的開發和交付方式需要做出根本變化，這幅圖從概念上體現了，傳統批量式的開發方式到敏捷的持續交付方式的轉變，

傳統開發方式下，需求成批量的流經各個階段和組織部門，如產品、UED、開發、測驗、運營等直至交付，各個職能各自優化自己的作業，形成效率豎井，由于批量的原因，需求等待整個批量完成，才能集中進入下一階段，從單個需求的角度看，需求大部分時間都處于等待狀態，

上圖的右半部分表達了這一程序，單個需求的實際處理的時間很短（圖中折線中上面綠色的短線），它們大部分時間都處于等待狀態（圖中折線下面紅色的長線），最終表現出的實際交付周期很長，

通過敏捷實施，我們希望整個組織協調一致，更緊密協作，縮短交付周期，圖中左半部分是理想的敏捷開發模式，它體現了敏捷開發的基本目標——持續價值交付和快速反饋、學習，這其中持續價值交付是基礎，

問題是如何才能建立和改進持續價值交付能力呢？

第二部分：定義和提升持續交付能力

管理學之父德魯克說：“如果你不能度量它，你就無法改進它”，對于持續交付能力，這同樣適用，

有效的度量體系應該圍繞核心問題展開，在這里，這個根本問題就是團隊的持續價值交付能力如何？我們將用五組指標來回答這一問題，它們分別是：

第一：發布能力，具體包含兩個細分指標，分別是：1）發布頻率，也就是團隊平均多長時間發布一次需求，它約束了團隊對外回應的最大可能；2）發布前置時間，也就是從代碼提交，到功能上線所需要花費的時間，如果時間開銷很大，團隊就不太可能去加大發版的頻率，

第二：需求回應周期，它包含兩個細分的指標，分別是：1）交付周期時間，也就是從用戶提出需求并被確認，到需求上線所要經歷的時長，它反映團隊（包含業務、開發、運營等職能）對客戶問題或業務機會的整體回應速度；2）開發周期時間：從開發團隊理解并確認需求，到需求可以上線所經歷的時長，它反映研發的回應能力，后面我們還會更詳細解讀兩個周期，

第三：交付的吞吐率，也就是單位時間內交付的需求的個數，

第四：內建質量的能力，也就是整個交付程序的質量，它包含兩個細分的指標，分別是：1)開發程序中缺陷的創建和修復時間的分布，我們希望缺陷能夠及時且持續的發現，并且在發現后盡快修復；2）缺陷庫存，我們希望能在整個開發程序中控制缺陷庫存量，讓產品始終處于接近可發布狀態，奠定持續交付的基礎，關于內建質量的能力的具體度量方法，我們后面還會詳細介紹，

第五：對外交付質量，它包含兩個細分的指標，分別是：1)單位時間（線上）問題數目；2）（線上）問題平均解決時長，

好的度量體系應該回答一個根本問題，并為此講述完整的故事，為回答團隊交付能力如何這一問題， 上面5組指標，分別從回應能力、效率和質量三個方面提供一個完整的故事，其中，持續發布能力和需求回應周期這兩組指標反映的是回應能力，也就是價值的流動效率；交付吞吐率這一指標反映的是團隊效率，也就是資源的產出效率；內建質量的能力和對外交付質量這兩組指標是質量指標，這些指標綜合起來，讓我們可以全面了解當前交付等能力，與目標的差距，以及改進的機會，

以上是度量體系的總體設計，我們把周期時間作為衡量團隊回應能力的核心指標，這幅圖更直觀地展示了兩個周期時間的計算方式，以看板的作業流為基礎，客戶周期時間的起點是從需求被選擇開始，到需求發布結束；開發周期時間則從待開發開始，到待發布結束，

基于上面的度量指標體系，我們選擇和設計了相關的圖表，來呈現這些度量，下面我們介紹其中的一些例子，

第一是累積流圖，累積流圖再現了團隊協作交付價值的程序，它的橫坐標為日期，縱坐標為各階段累積完成的需求數目，從左至右的各條線，反映各個階段累積處理完成的需求數量，例如：圖中最上面這條線是已經就緒的需求的個數，最下面這條線是已經上線的需求的個數，中間這條線分別是已經開發的、開發結束的、已經測驗的、測驗結束的等等，

 累積流圖綜合反映了平均交付周期、在制品數量、到達和交付速率三類指標，

第一：平均交付時間，交付時間指需求交付之前從開始到結束所經歷的時間，圖中，到3月26日這一天累積計劃了40個需求，而到5月15日這一天累積交付了40個需求，假設需求符合先入先出（先計劃的先交付）的規律，那么第40個需求的交付周期時間就是 5月15日 - 3月26日 = 50（天），之所以要在交付時間之前加上“平均”，是因為并非所有的需求都是先進先出，從累積流圖上還可以進一步看出交付時間在各個階段的分布，

第二：在制品的數量，在制品（Work in Process）指正在處理的需求的數目，也就是所有開始但還沒有完成的需求的數目，如：上圖中4月15日這一天，累積開始的需求有61個，累積上線的需求是8個，在制品數量 = 61- 8 = 53（個），它們已經開始，但還沒有交付，從累積流圖上還可以進一步看出在制品在各個階段的分布，如開發中的，待測驗的，測驗中的等，

第三：需求的到達和交付速率，指單位時間內到達和交付需求的數目，圖中，從3月1日到3月30日，4周時間交付需求數目從10個增加到50個，共交付40個需求，到達速率 = 40 / 4 = 10 （個/周），從4月1日到4月30日，4周時間交付需求數目從10個增加到30個，共交付20個需求，到達速率 = 20 / 4 = 5 （個/周），從累積流圖上還可以看出不同階段的產出速率，以及它們的變化趨勢，

累積流圖再現了團隊協作和交付程序，從中我們能夠解讀出團隊的開發模式，演變趨勢和改進機會等，例如：從圖中上邊線階梯可以看到批量計劃模式，而4月開始計劃的批量變得更小，發布頻率加大，相應的并行的在制品的數目也變少了，周期時間隨之變短了，交付的效率（交付線的斜率）也有所提高，

我們再看另一幅圖表——缺陷趨勢圖，它反映了團隊引入、發現及移除缺陷的行為模式，圖形的橫坐標是日期，橫坐標上方紅色豎條代表當天發現缺陷的數量；橫坐標下方綠色豎條代表當天解決的缺陷的數量；橙色曲線代表缺陷存量，通過缺陷趨勢圖希望引導用戶的行為是：持續且盡早發現缺陷并及時移除它們，從而控制缺陷庫存，保證系統隨時處于接近可發布狀態，奠定持續交付的基礎， 上圖的左右兩個部分比較了兩種交付模式下的缺陷趨勢圖，

左半部分：“迭代”前期團隊集中設計、編碼引入缺陷，但由于并未即時的集成和驗證，缺陷未被即時發現，到了專案后期團隊開始集成和測驗，缺陷集中爆發，小瀑布模式程序質量差，帶來大量的返工、延期、趕工和交付質量問題，該模式下，產品的交付時間依賴于何時缺陷被充分移除，無法做到持續交付，降低了團隊對外的回應能力，

右半部分：在整個迭代程序中，團隊以小粒度的需求為單位開發、集成、測驗，即時發現并解決問題，這樣，缺陷庫存得到控制，系統始終處于接近可發布狀態，做到持續發布，提高團隊對外的回應能力，缺陷趨勢圖可以從一個側面反映團隊的開發及交付模式，衡量團隊的持續交付能力，引導團隊向持續交付演進，

好的度量應該為回答一個根本問題，講述完整的故事，我們回答的問題是團隊持續交付能力及其改進機會，并針對這個問題講述了完整的故事，也正是基于以上的體系， 云效專案域對度量體系做了一次重構，上面的圖是一個概念說明，大家可以去使用，我們也會根據大家的反饋，持續優化度量體系的設計，

基于這樣的度量體系，我們應該設定怎樣的目標呢？最近我們在阿里內部做團隊效能改進時，提出了稱之為“2-1-1”的愿景，得到了不少部門的認可，什么是211呢？“2”指的是交付周期2周——85%以上的需求可以在2周內交付；第一個“1”指的是開發周期1周——85%以上的需求可以在1周內開發完成；第二個“1”指的是發布前置時間1小時——提交代碼后可以在1小時內完成發布，

今天，很多團隊離“211”還是有距離的，特別是這個“2”，它涉及到整個組織各職能，和部門的協調一致，緊密協作，一小時的發布前置時間，則需要持續交付流水線，產品架構體系和自動化測驗、部署等有力保障，達成“211”并不容易，但它體現了組織提升持續交付和快速回應能力的目標，樹立了持續改進的方向，因此我們才把它作為愿景，

備注：以上理念也將落地到研發工具云效（阿里內部叫Aone）中，從交付流程、交付結果、交付質量等資料也可在云效的度量功能中查看，

以上我們定義了什么是持續交付能力，并制定了愿景性的目標，問題是我們如何才能達成這一目標呢？讓我們先看一幅漫畫，

這是一個酒吧，路燈下醉漢在找什么東西，很長時間過去了，警察一直看著他，終于忍不住走上前，問道：“你在找啥？”，醉漢說：“找我的鑰匙”，警察看了一下鑰匙好像不在這，就問：“鑰匙是丟在這嗎？”醉漢說：“不是”，警察奇怪的問道：“那你為什么在這找？”，“只有這兒能看到啊” 醉漢回答道，

鑰匙（key）英文的也是關鍵的意思，光照亮的地方卻不是關鍵所在，我講這個故事，是為了說明研發中一個常見的問題——在光照亮的地方，而不是關鍵所在的地方尋找答案，當然不會有結果，那研發程序的關鍵所在究竟在哪里呢？

《The Principles of product development flow》一書的作者Don指出：“在產品開發中，問題的關鍵幾乎從來不是停滯的資源，而是停滯的需求”，這是什么意思呢？產品開發的最終目的是交付價值，那我們就必須讓價值交付的程序順暢起來，也就是讓價值流動順暢起來，計劃、管理、協調活動，以及資源的配置等等，都應該服務于價值的流動，價值流動是目的，資源忙起來不是，

現實中我們更多關注資源是否停滯，人是否閑著，但真正的問題并不在這兒，真正的問題是需求的停滯，需求在各個階段的積壓——如分析階段、測驗階段、發布階段等等，需求不能順暢流動才是真正的問題所在，也就是我們所說的關鍵所在，

為什么我們往往對需求的積壓很少關注？因為它很難看到，不是光照亮的地方，我們很難覺察（至少很難即時的察覺）需求的停滯、積壓和返工，而那才是改進價值交付的關鍵所在，

要改進端到端的流程，我們必須看到價值端到端的流動程序，在哪里出現了積壓和停滯，為此，改進的第一步，就是要讓光照亮關鍵所在——可視化端到端的價值流動程序，基于價值流發現流動程序中的問題，

看一個例子，它是來自某個產品團隊看板，看板中藍色卡片的是需求，讓光照亮關鍵所在，就是要讓需求流動的端到端程序可視化，需求從“選擇”開始，所謂選擇是指從眾多的市場機會中選擇這些需求開始開發，選擇之后是流程中的其他階段，比如需求的設計、開發、測驗、驗收等，直至發布，這是一個端到端的程序，

我們單獨看“開發中”這個階段，在這里需求被分解成為任務——圖中黃色紙條，任務與其所屬于的需求處于同一行中，我們把這樣的行成為泳道，泳道的首列（藍色紙條）是需求，下屬任務（黃色卡片)按模塊組織在一起，如前端、后端或其他依賴的外部模塊，其中任務的最后一列代表完成狀態，所有任務完成后，需求進入下一階段——待測驗，

端到端可視化需求的流動程序，從需求被選擇開始，直到發布結束，這讓我們能即時看到問題，如：需求是否順暢流動，是否發生了停滯和積壓，是否有瓶頸，這就是所謂：光照亮了問題所在，

除此之外，我們還要保障價值流動的程序質量，把交付質量內建到開發程序中，而不是依賴最后環節的測驗，為了做到內建質量，我們需要明確定義需求流動的標準，上圖顯示了需求進入開發環節要滿足的輸入標準，在這個例子中，它被定義為：1）需求的用戶使用流程和驗收規則清晰定義；2）依賴方能夠被識別；3）大的需求拆分成在兩周以內或者一周以內的小需求，等等，我們還可以定義其它階段的規則，如開發輸出（也就是轉測驗）的規則，這也是照亮關鍵所在一部分，

照亮關鍵所在，看到需求端到端流動的程序，以及流動中的問題和瓶頸是第一步，更關鍵是看到問題后要怎樣做？以可視化端到端的價值流動為基礎，我們希望價值能夠順暢流動，從左到右，不要發生停滯和積壓，如何做到呢？讓我們再看一個故事，

圖中這位叫潘季馴，他是明朝治理黃河的水利專家，被稱為“千古治黃第一人”，我們今天要講的就是他治理黃河的故事，治黃河難，難在泥沙不斷淤積，清淤是治理黃河的傳統辦法，問題是清了又會淤，年復一年，大批的河工聚集，又為造反提供條件，元朝的覆滅就與之關系甚大，不治則生靈涂炭，治則勞民傷財，這是擺在歷代統治者面前的兩難決定，明朝也不例外，

嘉靖到萬歷年間潘季馴四次臨危受命治理黃河，取得前所未有的成效，并總結了切實可行的方略，其中最為重要的思想就是“束水攻沙”，什么是“束水攻沙”呢？潘季馴在治理黃河時既沒有蠻力清淤，也不是一味地加高、加寬河堤，他反其道而行，收窄河堤——在大堤（稱為遙堤）內再修筑一道更窄的堤（稱為縷堤），遙堤用以防潰，縷堤用以束水，河堤收窄了，水流的速度就會加快，將沉積的泥沙帶走，這就是所謂"束水攻沙"，

“束水攻沙”與產品開發有什么關系呢？“束水”加快了水的流速，也帶走了泥沙，對應的，產品開發中我們也要限制并行需求的數量，同樣是為了縮短需求從開始到完成的平均交付周期——加快流速，并即時發現和處理交付程序中的問題——帶走泥沙，我們來看具體的例子，

在上圖中，泳道數約束了并行需求的數目，并行需求減少，需求流動的速度隨之加快,從而縮短開發和交付周期，更重要的是，限制并行能更快暴露問題，有限泳道中的需求發生阻塞，很容易被發現，團隊必須盡快解決阻塞的問題，才能開始新的需求，而即時解決問題又促進了價值的順暢流動，

基于端到端的價值流，團隊可以更好的管理價值流動，以站會為例，團隊在站會上，會去審視需求的狀態，這里面有兩個策略，一種是從左向右審視，還有一個從右往左審視，大家認為哪個合適？對，大家都說從右往左，為什么呢？因為我們應該聚焦于完成而不是開始，我們應該聚焦于盡快的交付，比如測驗中的需求是不是有缺陷，并優先解決這些缺陷，好讓需求盡快上線；開發中的需求，有沒有阻礙，并即時解決這些阻礙，完成它們，只有這樣，新的等待開發的需求才能夠開始，

站會的核心是通過審視價值流動，關注需求流動中的缺陷、阻礙、停滯、等待和瓶頸，即時發現和解決這些問題，促進需求更流暢流動，站會只是一個例子，圍繞看板的其他活動，比如說度量資料分析和改進行動的制定，都是為了促進價值流動，而價值的順暢流動是回應能力、質量和效率的保障，

此電子看板截圖來自阿里云云效

上面舉例用的都是物理看板，是為了讓大家更有體感，現在絕大部分團隊，不管是阿里云，技術中臺還是閑魚，用的都是云效電子看板，經過持續的優化，電子看板操作體驗已經與物理看板接近，并且具備物理看板不具備的優勢，比如：前面講到的資料度量都可以自動生成，這對于發現問題和改進很有意義，還有就是與其他系統如檔案和發布工具的無縫集成，這是優酷電子看板的截圖，

看板幫助團隊暴露問題，具體的改進行動還是要落實到不同方面的，我們可以用湖水巖石效應來描述這一程序，這是一個湖，湖里有一些石頭，湖水比較深時，石頭都隱藏在湖面之下，但其影響是在的；當湖面降低，石頭就會漸次暴露出來，

在產品開發中，石頭暗喻的是問題，而湖水的深度暗喻交付周期長短（或并行需求的數目），當需求的交付周期長時，問題被隱藏，我們看到的是平整的水面，只有水位降低，問題才會暴露，

以某個中間件團隊的效能改程序序為例，他們原先采用小瀑布的模式，沒有持續集成和有效自動化，以月度為周期交付產品，需求在月初集中開始，在月底集中轉測驗和發布，對外交付質量和效率一直不讓人滿意，內部的協作也有很多問題，每次發布都例外痛苦，延期的情況時有發生,但大家對問題根源和解決方案卻各執一詞，

在精益和敏捷開發實施程序中，我們首先做的是可視化價值流動，并以此為基礎逐步減小并行需求的數目，力求需求的持續流動——持續小批量的輸入、開發、轉測驗和交付，在減小批量的程序中，問題逐漸暴露，

在這個案例中，為了做到小批量的流動，首先暴露的是需求分析和拆分的問題，也就是如何將需求拆分成可以獨立測驗、驗證和交付的小的單元，通過引入“實體化需求”（一種需求澄清、分析和拆分的方法）等方法，這一問題得到了解決，開發和測驗移交的批量明顯減小了，

很快新的問題又出現了，測驗環境或移交給測驗的版本總是不可用，需求還是不能順暢流動，這時持續交付流水線的建設的重要性就凸顯出來，當然持續交付流水線的建設也并不是一步實作的，一開始我們只是打通了管道，并引入了最基本的自動驗證，保證測驗隨時都有一個可用的環境和版本可用，接下來才是自動化對關鍵功能的覆寫，在其后組織協調溝通，技術架構等問題也漸次暴露，

程序中，我們感受到最大的好處是，盡管解決問題的程序還是比較痛苦，但我們可以集中精力一個時間解決一個被暴露的真實問題，而解決它們也會帶來立即可感知的受益，這大大提升了團隊持續投入解決問題的動力，

這個團隊，多年未能解決的問題，在短短三、四個月內被一一解決，在沒有投入額外資源的情況下，研發效能得到根本改善，質量、回應能力都有了質的提升，我對此也深有感觸——研發效能改進實踐的技術難度，并不比我們平時做的業務系統難，但為什么總是得不到實施呢？這個團隊有做對了什么，

這里面的根本問題不是能力問題，也不是意識和態度問題，更重要的是：要讓團隊看見問題，并且提供合適的路徑，一個時間解決一個問題，并且解決問題后要能看到立即的想過，核心有兩個，第一:“看見”，它的關鍵是看見系統，看見價值的端到端流動，以此為基礎看到問題和改進機會；第二：“路徑”，它的關鍵是小步快走，但每一步都要有可感知的成果，

圖中巖石的高低，從概念上反映了隨著并行的降低，問題逐漸暴露的大致順序，對不同的團隊，問題和次序會不同，但相同的是，通過水位的降低，問題被漸次暴露和解決，產品交付的回應能力、效率和質量也會得到提升，我們的目標并不是要把水位降到最低，而是要發現問題，讓需求能以較小的粒度順暢流動，實作順暢和高質量和持續的交付價值，

總結一下持續交付實踐，它關注從需求到開發、測驗直至部署和運維這些環節，它的目標可以總結為兩個，

第一：讓價值順暢流動,這個我們已經講了很多，之前講的實踐都能促進價值的順暢流動，如：看板、反饋改進這些管理實踐，故事地圖、驗收測驗驅動開發這類技術實踐，

第二：讓流動程序更加高效,這個我們前面沒有強調，補充一下，其核心是讓團隊成員只需要關注帶來真正價值的業務邏輯，而不需要在其他作業上花費過多時間，我們看看除了業務邏輯，團隊還會被那些作業影響？又如何減少這些作業？這里我們列舉了其中的一些：

• 可靠的交付流水線: 讓團隊不用擔心驗證和部署的環境，步驟及流程

• 容器技術（如Docker）：讓團隊不必過多考慮構建分發及運行環境的問題

• Kubernetes：讓團隊不用過多考慮容器應用的部署，運行，擴縮容等作業

• Sevice Mesh：讓團隊不用過多考慮分布式服務的通信

• Severless：讓團隊不用過多考慮服務器的物體資源

• …

到此為止，我們已經分享完今天上半部分的內容，持續交付價值的能力是互聯網時代研發效能的核心，我們還介紹了提升持續交付能力的度量，以及以流動效率為抓手提升持續交付能力的實踐和路徑，

問題是，建立了持續交付能力就可以保證業務的成功嗎？顯然不是，持續交付能力是快速交付價值、獲取反饋并靈活調整的基礎，我們還必須以把持續交付能力轉化為有效的業務創新，帶來真正的業務成功，這也是我們下半部分要分享的內容：《從持續交付到業務創新（下）：有效的業務創新》

擊下方鏈接體驗敏捷理念指導下的工具云效和學習更多企業敏捷實踐案例，

https://www.aliyun.com/product/yunxiao?channel=yy_yccb

【關于云效】

? ?云效，云原生時代一站式BizDevOps平臺??，支持公共云、專有云和混合云多種部署形態，通過云原生新技術和研發新模式，助力創新創業和數字化轉型企業快速實作研發敏捷和組織敏捷，打造“雙敏”組織，實作 10 倍效能提升，

? ?立即體驗??

標籤：其他

上一篇：從持續交付到業務創新（上）：互聯網時代研發效能的核心

下一篇：如何幫助金融客戶“用好云”？