如何在2周內交付85%以上需求？阿里工程師這麼作

摘要： 提高持續交付能力 最近咱們在阿里內部作團隊效能改進時，提出了稱之爲「2-1-1」的願景，獲得了很多部門的承認。什麼是211呢？「2」指的是交付週期2周——85%以上的需求能夠在2周內交付；第一個「1」指的是開發週期1周——85%以上的需求能夠在1周內開發完成；第二個「1」指的是發佈前置時間1小時——提交代碼後能夠在1小時內完成發佈。

提高持續交付能力

最近咱們在阿里內部作團隊效能改進時，提出了稱之爲「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）大的需求拆分紅在兩週之內或者一週之內的小需求，等等。

咱們還能夠定義其它階段的規則，如開發輸出（也就是轉測試）的規則。這也是照亮關鍵所在一部分。

照亮關鍵所在，看到需求端到端流動的過程，以及流動中的問題和瓶頸是第一步。更關鍵是看到問題後要怎樣作？以可視化端到端的價值流動爲基礎，咱們但願價值可以順暢流動，從左到右，不要發生停滯和積壓。如何作到呢？讓咱們再看一個故事。

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

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

「束水攻沙」與產品開發有什麼關係呢？「束水」加快了水的流速，也帶走了泥沙。對應的，產品開發中咱們也要限制並行需求的數量，一樣是爲了縮短需求從開始到完成的平均交付週期——加快流速，並即時發現和處理交付過程當中的問題——帶走泥沙。咱們來看具體的例子。

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

基於端到端的價值流，團隊能夠更好地管理價值流動。以站會爲例，團隊在站會上，會去審視需求的狀態。這裏面有兩個策略，一種是從左向右審視，還有一個從右往左審視，你們認爲哪一個合適？對，你們都說從右往左。爲何呢？由於咱們應該聚焦於完成而不是開始，咱們應該聚焦於盡快地交付，好比測試中的需求是否是有缺陷，並優先解決這些缺陷，好讓需求儘快上線；開發中的需求，有沒有阻礙，並即時解決這些阻礙，完成它們。只有這樣，新的等待開發的需求才可以開始。

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

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

上面舉例用的都是物理看板，是爲了讓你們更有體感。如今絕大部分團隊，不論是阿里雲，技術中臺仍是閒魚，用的都是雲效電子看板。通過持續的優化，電子看板操做體驗已經與物理看板接近。而且具有物理看板不具有的優點，好比：前面講到的數據度量均可以自動生成，這對於發現問題和改進頗有意義，還有就是與其餘系統如文檔和發佈工具的無縫集成。這是優酷電子看板的截圖。

看板幫助團隊暴露問題，具體的改進行動仍是要落實到不一樣方面的。咱們能夠用湖水岩石效應來描述這一過程。這是一個湖，湖裏有一些石頭。湖水比較深時，石頭都隱藏在湖面之下，但其影響是在的；當湖面下降，石頭就會漸次暴露出來。

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

以某個中間件團隊的效能改進過程爲例。他們原先採用小瀑布的模式，沒有持續集成和有效自動化，以月度爲週期交付產品，需求在月初集中開始，在月底集中轉測試和發佈，對外交付質量和效率一直不讓人滿意，內部的協做也有不少問題，每次發佈都異常痛苦，延期的狀況時有發生，但你們對問題根源和解決方案卻各執一詞。

在精益和敏捷開發實施過程當中，咱們首先作的是可視化價值流動，並以此爲基礎逐步減少並行需求的數目，力求需求的持續流動——持續小批量的輸入、開發、轉測試和交付。在減少批量的過程當中，問題逐漸暴露。

在這個案例中，爲了作到小批量的流動，首先暴露的是需求分析和拆分的問題，也就是如何將需求拆分紅能夠獨立測試、驗證和交付的小的單元。經過引入「實例化需求」（一種需求澄清、分析和拆分的方法）等方法，這一問題獲得瞭解決，開發和測試移交的批量明顯減少了。

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

過程當中，咱們感覺到最大的好處是，儘管解決問題的過程仍是比較痛苦，但咱們能夠集中精力一個時間解決一個被暴露的真實問題，而解決它們也會帶來當即可感知的受益，這大大提高了團隊持續投入解決問題的動力。

這個團隊，多年未能解決的問題，在短短3、四個月內被一一解決，在沒有投入額外資源的狀況下，研發效能獲得根本改善，質量、響應能力都有了質的提高。我對此也深有感觸——研發效能改進實踐的技術難度，並不比咱們平時作的業務系統難。但爲何老是得不到實施呢？這個團隊有作對了什麼。

這裏面的根本問題不是能力問題，也不是意識和態度問題。更重要的是：要讓團隊看見問題，而且提供合適的路徑，一個時間解決一個問題，而且解決問題後要能看到當即的想過。

核心有兩個：

 ●  第一：「看見」，它的關鍵是看見系統，看見價值的端到端流動，以此爲基礎看到問題和改進機會；
 ●  第二：「路徑」，它的關鍵是小步快走，但每一步都要有可感知的成果。

圖中岩石的高低，從概念上反映了隨着並行的下降，問題逐漸暴露的大體順序。對不一樣的團隊，問題和次序會不一樣。但相同的是，經過水位的下降，問題被漸次暴露和解決，產品交付的響應能力、效率和質量也會獲得提高。咱們的目標並非要把水位降到最低，而是要發現問題，讓需求能以較小的粒度順暢流動，實現順暢和高質量和持續的交付價值。

總結一下持續交付實踐。它關注從需求到開發、測試直至部署和運維這些環節。它的目標能夠總結爲兩個：

 ●  第一：讓價值順暢流動,這個咱們已經講了不少。以前講的實踐都能促進價值的順暢流動，如：看板、反饋改進這些管理實踐，故事地圖、驗收測試驅動開發這類技術實踐。
 ●  第二：讓流動過程更加高效,這個咱們前面沒有強調。補充一下，其核心是讓團隊成員只須要關注帶來真正價值的業務邏輯，而不須要在其餘工做上花費過多時間。

咱們看看除了業務邏輯，團隊還會被那些工做影響？又如何減小這些工做？這裏咱們列舉了其中的一些：

 ●  可靠的交付流水線：讓團隊不用擔憂驗證和部署的環境，步驟及流程。
 ●  容器技術（如Docker）：讓團隊沒必要過多考慮構建分發及運行環境的問題。
 ●  Kubernetes：讓團隊不用過多考慮容器應用的部署、運行、擴縮容等工做。
 ●  Sevice Mesh：讓團隊不用過多考慮分佈式服務的通訊。
 ●  Severless：讓團隊不用過多考慮服務器的實體資源。
 ●  …

持續交付價值的能力是互聯網時代研發效能的核心。咱們介紹了提高持續交付能力的度量，以及以流動效率爲抓手提高持續交付能力的實踐和路徑。

問題是，創建了持續交付能力就能夠保證業務的成功嗎？顯然不是。持續交付能力是快速交付價值、獲取反饋並靈活調整的基礎。咱們還必須以把持續交付能力轉化爲有效的業務創新，帶來真正的業務成功。

阿里內部分享

 阿里雲雙十一1折拼團活動:已滿6人,都是最低折扣了

【滿6人】1核2G雲服務器99.5元一年298.5元三年 2核4G雲服務器545元一年 1227元三年

【滿6人】1核1G MySQL數據庫 119.5元一年

【滿6人】3000條國內短信包 60元每6月

參團地址：http://click.aliyun.com/m/1000020293/

原文連接