提升持續傳遞能力
最近我們在阿裡内部做團隊效能改進時，提出了稱之為“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：讓團隊不用過多考慮伺服器的實體資源。
● …
持續傳遞價值的能力是網際網路時代研發效能的核心。我們介紹了提升持續傳遞能力的度量，以及以流動效率為抓手提升持續傳遞能力的實踐和路徑。
問題是，建立了持續傳遞能力就可以保證業務的成功嗎？顯然不是。持續傳遞能力是快速傳遞價值、擷取回報并靈活調整的基礎。我們還必須以把持續傳遞能力轉化為有效的業務創新，帶來真正的業務成功。
阿裡内部分享
原文釋出時間為：2018-11-2
本文作者：何勉
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。