研發效能提高 36 計第三課：束水攻沙，持續加快產品交付速度

摘要： 互聯網時代，業務與協做複雜度與日俱增，競爭日趨激烈，提高研發效能已成爲軟件行業的共同挑戰。《研發效能提高和敏捷實施 36 計》是阿里雲聯合 Teambition 精心打造的系列課程，課程由何勉、張剛、張燎原等國內多位在研發效能領域擁有數十年經驗的精益敏捷資深專家擔任講師；將從敏捷項目協做、敏捷需求管理、持續交付與工程實踐、設計及代碼實踐、業務創新 5 大方面，首次系統分享阿里巴巴研發效能提高方法、解析阿里巴巴及業界優秀實踐案例，並經過工具的直觀演示，幫助企業研發管理者們突破研發效能瓶頸、通往業務成功之路。

沒有度量的改進就是盲人騎瞎馬，夜半臨深池。好的度量，必須直指本質，並指導行爲改變。本次課程，是研發效能提高 36 計系列課程第三課，兩位講師將介紹一套行之有效的研發效能的度量指標，幫助團隊設定研發效能改進的願景和目標；經過有效反饋，持續提高研發效能。

注：如下內容是演講視頻的精要整理，點擊文末連接可前往課程信息合集頁面查看往期視頻、PPT 以及最新直播預告。

上一課介紹了可視化交付過程。以下圖所示，我將其總結爲：4個步驟和3個檢查項。可視化奠基了研發效能提高的基礎。仍而，必須謹記的是：「可視化是手段，而不是目的」。讓價值順暢高質量地流動纔是目的，這也是本次課程分享內容的目的。

本次課程將在可視化價值流的基礎上，介紹：有效管理價值流動，提高持續交付能力。咱們將從一個故事——束水攻沙——講起。

一. 束水攻沙 —— 限制在製品數量，加速價值流動

故事的主人公叫潘季馴，他是治理黃河的水利專家，被稱爲「千古治黃第一人」。

治理黃河難，難在泥沙不斷淤積，上圖中黃河入海水道的大範圍變遷，就是不斷淤積、潰壩的結果，背後的災難深重則難以言表。

清淤是治理黃河的傳統辦法，問題是清了又會淤，年復一年。大批的河工彙集，又爲造反提供條件，元朝的覆滅就與之關係甚大。不治則生靈塗炭，治則勞民傷財，這是擺在歷代統治者面前的兩難決定，明朝也不例外。

嘉靖到萬曆年間潘季馴四次臨危受命治理黃河，取得史無前例的成效，並總結了切實可行的方略，其中最爲重要的思想就是：「束水攻沙」。

什麼是「束水攻沙」呢？潘季馴在治理黃河時沒有蠻力清淤，也沒有一味地加高、加寬河堤。他反其道而行，收窄河堤——在大堤（稱爲遙堤）內再修築一道更窄的堤（稱爲縷堤），「遙堤用以防潰，縷堤用以束水」。河堤收窄了，水流的速度就會加快，並將沉積的泥沙帶走，這就是所謂"束水攻沙"。

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

上圖的看板，咱們前面介紹過。其中提到了泳道（圖中橫向的需求泳道）的概念。泳道數約束了並行需求的數目，目的是儘快完成已開始需求，加速需求的流動。就像縷堤約束了黃河水，加快了水流。

更重要的是，限制並行能更快暴露問題。因爲泳道數有限，需求發生阻塞，很容易被發現。團隊必須儘快解決阻塞的問題，不然會影響需求的開始。這裏面的基本原則是：「聚焦完成，暫緩開始」。

並行的需求又被稱爲「在製品」 （Work In Progress）。看板上，全部已經開始，但尚未完成的需求（或其餘工做）都是在製品。通常而言，在製品數量越少，交付速度越快。源自「精益思想」的「利特爾法則」解釋了背後的原理。

什麼是李特爾法則？上圖被稱爲累積流圖，其中，橫座標表明日期，縱座標表示需求個數。紅色線表示已經開始的需求的數目，綠色線則表示已經交付的需求的數目。

紅色和綠色之間豎線的長度表示在製品的數目——已經開始，但尚未完成的需求的數目；紅色和綠色之間橫向線的長度表示前置時間——需求從開始到完成要花費的時間；圖中斜線的斜率表示交付速率（吞吐率）——單位時間交付需求數。

這三條線構成的三角形，直觀的表達了利特爾法則：

前置時間 = 在製品/交付速率。

在交付速率相對穩定的狀況下，在製品越少，前置時間越短，也就是響應速度越快。例如：團隊每個月能夠交付 5 個需求，並行開發 10 個需求，那麼平均前置時間是：10 除以 5 ,也就是兩個月。若是將在製品數量減半，變爲 5 個，前置時間就會變成: 5 除以 5，也就是 1 個月。這就是產品開發中的利特爾法則，約束在製品數目，交付的時間變短，響應變快。這與束水攻沙的思想不謀而合。

控制在製品數目，讓團隊更加敏捷的響應用戶需求。控制的方法則是多元的，如：聚焦於需求的完成而不是任務，讓任務向需求對齊，儘快地完成（而不是開始）需求；及時發現阻礙，集中精力解決它們；即時向測試移交，並儘快開始測試；優先解決缺陷而不是開始更多的需求等。

上圖表示了常見的控制在製品的方法。控制在製品數目，讓團隊聚焦需求的快速流動和交付，提升了團隊的響應能力和敏捷性。不過，團隊效能的本質提高須要更深層次的改進。如何發現並落實這些改進呢？這是咱們接下來要分享的內容。

二. 湖水岩石——暴露問題，促進改進

潘季馴在解釋「束水攻沙」時，曾說過：「急則沙隨水流，緩則水漫沙停」。 「束水攻沙」不只僅是要讓水流地更快，更重要的是把沙給沖走。

這裏咱們想用沙來隱喻產品交付過程當中的問題，也就是說需求流動速度快，則可以及時發現和解決問題；反之，當需求產生積壓，問題也會隱藏和積累。

下面是阿里某個基礎產品團隊的實例。咱們看他們是如何經過「束水攻沙」發現和解決問題，提升效率的。

這個團隊早期使用了物理看板，可視化了交付過程。其中藍色卡片表明需求，黃色卡片表明需求分解出的任務。當時，這個團隊的迭代週期是一個月，每月發佈一次對基礎產品來講並不算太差。問題是迭代過程並不暢，質量也有很大的問題。

第一幅圖拍的是迭代的前幾天，幾乎全部需求都同時開始了。

第二幅圖是迭代中期，全部的需求都作了一半，看上去還不錯，至少有進展。但沒有一個需求進入了測試，這實際上是有問題的。

問題出如今迭代的後期，上圖是迭代結束前兩天的情況，開發完成了一堆需求，但卻沒有一個需求真正進入了測試。這顯然不是一個號的狀態，要在最後兩天完成全部測試，這對進度和質量都是極大的挑戰，尤爲是這種 「code then fix」 的模式對產品的長期質量傷害很大。事實上，這個團隊的進度和質量一直有問題，可視化更好地暴露了問題，問題背後的緣由也更清楚了。

回頭看團隊迭代的過程，這是典型的「緩則水漫沙停」，過程當中需求沒有向下流動，問題也被積累到了最後，好比需求拆分、測試環境以及需求之間相互依賴等問題，在前期都被有意無心的忽略了。這實際上是團隊效率和質量問題的重要和根本的緣由。

可視化讓團隊看到了問題和影響，接下來他們開始有意識的控制在製品。以此爲基礎，開啓了他們的改進之旅，在協做過程、需求管理、工程能力都作了很大的改進。

上圖的右邊是改進後的狀態。咱們看到，需求開發的交付流暢起來，每一個階段的需求（在製品）都很少，需求的分佈更加均勻，需求持續進入測試及發佈狀態，團隊從集中批量交付轉變爲了持續交付。在這個過程當中，效率、質量、敏捷性都獲得了很大的提高。

固然改進的過程是須要付出艱辛的努力的，涉及到技術、管理、需求、環境等多個方面。4 個迭代後，質量、效率都獲得了大幅提高。個人同事蔡春華用一篇文章（ 集體通宵發版怎麼破？阿里敏捷教練開出四道「藥方」 ）真實記錄了團隊轉變的過程和效果，很是值得參考。

在上面的團隊中，咱們用「湖水岩石」來比喻並指導了改進過程。

什麼是「湖水岩石」呢？如上圖所示，湖水比較深時，石頭都隱藏在湖面之下；只有水位降下來，石頭纔會漸次暴露出來。咱們用石頭隱喻的產品開發中的問題，而湖水的水位則隱喻交付週期（或並行需求的數目）。當需求的交付週期長時，問題被隱藏，咱們看到的是平整的水面。只有水位下降，問題纔會暴露。

上圖中，岩石所處的深度表達了這個團隊問題暴露的前後順序。好比：爲了控制在製品數目，最先暴露的是協做模式的問題，由於產品、開發、測試團隊之間習慣了大批量的移交，這是首先要解決的問題。

接下來暴露的是需求拆分和管理的問題，爲此咱們引入了故事地圖、實例化需求等實踐，比較順利的解決了這個問題。關於這兩個實踐，在敏捷需求的課程中，咱們會詳細介紹。

其後，又陸續暴露和解決了測試迴歸、測試環境、團隊溝通機制、目標管理等問題。在這個過程當中水位不斷下降，深層次的問題不斷顯露和解決。而團隊的效率和質量也在解決問題中不斷提高。過程並不容易，但沒有這些問題的解決就不會有研發效能的根本提高。

三. 創建節奏，管理價值流動

「束水攻沙」是爲了限制在製品的數量，讓價值順暢流動； 「湖水岩石」是爲了持續暴露問題，改進交付能力。這爲研發效能的改進提供了可操做的理念支撐，這固然是有巨大意義的。

然而，若是離開有效的落地，再先進的理論和原則都沒有意義。接下來要討論的就是如何落地上面的原則——創建節奏，管理價值流動。

有效地管理價值流動須要從三個方面入手，價值的輸入、流動過程以及輸出。其中，關於輸出，它的最終的目標是持續交付和發佈。所以接下來的討論將關注兩個方面：

1. 價值的輸入：它對應需求的規劃和排期；
2. 價值的流動過程：咱們將介紹每日站會;

月規劃，周排期——創建管理價值流動的節奏;

應該創建怎樣的計劃節奏，多長時間作一次計劃呢？這是咱們首先要回答的問題。傳統瀑布開發模式下，計劃是大批量進行的——一次計劃不少內容，而且要很長時間後才完成交付。這是瀑布開發與敏捷開發本質的區別之一。它帶來一系列問題：

1. 下降決策的質量：一次要準備不少需求，其中包含當前還不清晰的需求。缺少足夠的信息，卻不得不作出決策，決策的質量很難保證;
2. 致使範圍蔓延：填充間隔過長時，業務方傾向將那些只是可能有用的需求也計劃進來，由於此時不計劃，下一次就要等到好久之後了。這樣就會產生不少猜想的需求，致使需求範圍蔓延;
3. 下降需求澄清的關注度和效果：填充的需求要等好久以後才作，團隊關注度就會大打折扣，難以保證需求澄清的效果;
4. 不能很好地支持有效學習和創新：計劃時作出假設，交付後獲得反饋，驗證假設並做出調整，這是互聯網產品試錯和創新的重要模式。一次填充過多需求，反饋速度慢，極大下降學習和創新的機會;
5. 下降團隊靈活響應市場變化的能力（敏捷性）：一次填入不少需求，發生變化或出現新需求時，就只能等好久之後的下一次填充了，這對組織響應變化的能力顯然是不利的，損害了組織的敏捷性。

計劃的頻率越高，批量越小，則敏捷性越好。同時決策時信息越充分，決策質量也越高。可是頻繁計劃也帶來額外的成本。相關的人在一塊兒進行會議，業務人員要提早準備好需求，這都帶來協調成本。

除了成本外，還要考慮頻繁填充的必要性。兩次填充之間產生了足夠多的支持更好決策的新信息，分開進行需求填充纔是有意義的。不然，必要性就很低。

基於對以上兩點的考慮和阿里自身的一些實踐經驗，咱們造成了「月規劃，周排期」的機制。

如上圖所示，看板中選擇（規劃）這一列，對應需求規劃，規劃好的需求放入選擇列。第四列則是需求排期，排期好的需求放入該列。團隊每月會進行一次產品規劃，和產品或者業務方確認本月的主題是什麼，圍繞這些主題須要作哪些需求。月規劃的基礎上再作周排期，決定本週要作什麼。如此造成的機制就是:

1. 月規劃：每個月進行一次。由業務方和開發團隊的表明參加，共同計劃和確認接下來的一個月要作的需求，初步的溝通和確認後，放入「選擇」隊列；
2. 周排期：每週進行一次。在開發團隊內部進行，團隊從計劃隊列中選擇接下來要作的需求，詳細澄清後，放入就緒「排期」隊列。團隊決定填充什麼需求時，一方面會考慮需求的優先級，也會結合上一週開發實際完成狀況作調整。

對於規劃排期這部分更加詳細的內容，能夠參見以前的文章（ 精益看板方法從理論到實戰 （9）—— 計劃會議，就緒隊列填充）。

「很是6+1」——站會的正確姿式

站會應該聚焦於價值的流動，而非我的工做。它的目的是：檢視價值流動的狀態，促進價值順暢流動。站會的組織形式也要服務於這一目的。

典型的看板站會，發生在每一個工做日、同一時間、同一地點（看板前）。站會上，團隊從右至左走讀看板。之因此從右往左，一方面是爲了體現價值拉動的方向；另外一方面是爲了貫徹「暫緩開始，聚焦完成」的原則，好比 Bug 通常在看板牆上偏右的測試列，從右往左更方便安排優先解決 Bug，快速完成需求交付，而不是開始更多的需求開發。

影響和阻礙價值順暢流動的因素有不少，好比瓶頸和隊列、關鍵缺陷、重點需求、阻礙和問題、已經到期或者即將到期的需求、中斷以及未反映在看板上的問題。

站會上不須要檢視每一張卡片。本着「檢視價值流動的狀態，促進價值順暢流動」的目的，咱們應該重點關注影響價值流動的問題。如上圖所示，它們中的絕大部分均可以很清晰地體如今看板牆上，典型的包括如下 6 個方面，加上未反映在看板上的問題（+1）。咱們稱之爲 「 6+1 」 站會。這裏只是一個簡單的介紹，關於如何組織站會，能夠參考以前的文章（ 精益看板方法從理論到實戰 （8）—— 看板站會）。

以上咱們介紹了規劃、排期以及站會的節奏。咱們，在實施過程當中逐漸造成了：月規劃、周排期、日站會的節奏。如上圖所示，這些節奏幫團隊落地相關的精益和敏捷實踐，並在此基礎上造成改進閉環，在不一樣的場景中獲得了應用，在新零售、大文娛、雲基礎設施都獲得過驗證，效果不錯，具備較普遍的適應性。

總結

本次課程咱們從「束水攻沙」的故事講起，經過主動的控制在製品，加速價值的流動； 「湖水岩石」，則經過不斷下降水位，讓團隊儘早暴露問題，並直面和解決它們。爲了讓價值順暢、高質量地流動，團隊還必須創建節奏，落地相關原則和實踐，並造成效能改進和業務反饋閉環，切實提高組織的「研發效能」。

下一次課程將分享研發效能的度量和改進閉環。咱們將瞭解到如何經過度量，來了解研發效能的現狀和問題，發現系統和深層次爲題，和指導持續改進。

最新課程直播預告

直播時間：10 月 8 日 20:00 - 21:30

直播主題：第 6 課：【敏捷需求篇】爲何「僱傭」奶昔，從用戶問題出發設計需求

直播內容： 用戶爲何要 「僱傭」 你的產品？這個問題爲產品設計打開了一個全新的視角。本次課程將介紹如何分析產品的價值主張，設計真正可以解決用戶問題，而且被用戶接受的產品方案。

講師陣容： 阿里雲研發效能部資深技術專家、Teambition 客戶成功首席顧問 何勉 阿里雲研發效能部高級技術專家、Teambition 客戶成功資深專家 張燎原

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。