## 一、束水攻沙  故事的主人公叫潘季馴，他是治理黃河的水利專家，被稱為“千古治黃第一人”。 潘季馴在治理黃河時沒有蠻力清淤，也沒有一味地加高、加寬河堤。他反其道而行，收窄河堤——在大堤（稱為遙堤）內再修筑一道更窄的堤（稱為縷堤），“遙堤用以防潰，縷堤用以束水”。河堤收窄了，水流的速度就會加快，并將沉積的泥沙帶走，這就是所謂"束水攻沙"。 產品開發中我們限制并行需求的數量，也是為了加快流速——縮短需求從開始到完成的交付周期，并即時發現和處理交付過程中的問題。 約束了并行需求的數目，目的是盡快完成已開始需求，加速需求的流動。限制并行能更快暴露問題。由于泳道數有限，需求發生阻塞，很容易被發現。團隊必須盡快解決阻塞的問題，否則會影響需求的開始。這里面的基本原則是：“聚焦完成，暫緩開始”。  迭代的前幾天，幾乎所有需求都同時開始了 迭代中期，所有的需求都做了一半，看上去還不錯，至少有進展。但沒有一個需求進入了測試，這其實是有問題的。 迭代結束前兩天的狀況，開發完成了一堆需求，但卻沒有一個需求真正進入了測試 需求開發的交付流暢起來，每個階段的需求（在制品）都不多，需求的分布更加均勻，需求持續進入測試及發布狀態，團隊從集中批量交付轉變為了持續交付。在這個過程中，效率、質量、敏捷性都得到了很大的提升。 ## 二、建立節奏，管理價值流動 如果離開有效的落地，再先進的理論和原則都沒有意義，在實施過程中我們逐漸形成了：月規劃、周排期、日站會的節奏  1. 月規劃：每月進行一次。由業務方和開發團隊的代表參加，共同計劃和確認接下來的一個月要做的需求，初步的溝通和確認后，放入“選擇”隊列； 2. 周排期：每周進行一次。在開發團隊內部進行，團隊從計劃隊列中選擇接下來要做的需求，詳細澄清后，放入就緒“排期”隊列。團隊決定填充什么需求時，一方面會考慮需求的優先級，也會結合上一周開發實際完成情況做調整。 3. 日站會：站會應該聚焦于價值的流動，而非個人工作。它的目的是：檢視價值流動的狀態，促進價值順暢流動。站會的組織形式也要服務于這一目的  典型的看板站會，發生在每個工作日、同一時間、同一地點（看板前）。站會上，團隊從右至左走讀看板。之所以從右往左，一方面是為了體現價值拉動的方向；另一方面是為了貫徹“暫緩開始，聚焦完成”的原則，比如 Bug 一般在看板墻上偏右的測試列，從右往左更方便安排優先解決 Bug，快速完成需求交付，而不是開始更多的需求開發。