系統開發描述：：研發效能提升 36 計第三課：束水攻沙，持續加快產品交付速度 摘要：互聯網時代，業務與協作復雜度與日俱增，競爭日趨激烈，提升研發效能已成為軟件行業的共同挑戰。《研發效能提升和敏捷實施 36 計》是阿里云聯合 Teambition 精心打造的系列課程，課程由何勉、張剛、張燎原等國內多位在研發效能領域擁有數十年經驗的精益敏捷資深專家擔任講師；將從敏捷項目協作、敏捷需求管理、持續交付與工程實踐、設計及代碼實踐、業務創新 5 大方面，首次系統分享阿里巴巴研發效能提升方法、解析阿里巴巴及業界優秀實踐案例，并通過工具的直觀演示，幫助企業研發管理者們突破研發效能瓶頸、通往業務成功之路。 沒有度量的改進就是盲人騎瞎馬，夜半臨深池。好的度量，必須直指本質，并指導行為改變。本次課程，是研發效能提升 36 計系列課程第三課，兩位講師將介紹一套行之有效的研發效能的度量指標，幫助團隊設定研發效能改進的愿景和目標；通過有效反饋，持續提升研發效能。 注：以下內容是演講視頻的精要整理，點擊文末鏈接可前往課程信息合集頁面查看往期視頻、PPT 以及最新直播預告。 上一課介紹了可視化交付過程。如下圖所示，我將其總結為：4個步驟和3個檢查項。可視化奠定了研發效能提升的基礎。仍而，必須謹記的是：“可視化是手段，而不是目的”。讓價值順暢高質量地流動才是目的，這也是本次課程分享內容的目的。 本次課程將在可視化價值流的基礎上，介紹：有效管理價值流動，提升持續交付能力。我們將從一個故事——束水攻沙——講起。 一. 束水攻沙 —— 限制在制品數量，加速價值流動 故事的主人公叫潘季馴，他是治理黃河的水利專家，被稱為“千古治黃第一人”。 治理黃河難，難在泥沙不斷淤積，上圖中黃河入海水道的大范圍變遷，就是不斷淤積、潰壩的結果，背后的災難深重則難以言表。 清淤是治理黃河的傳統辦法，問題是清了又會淤，年復一年。大批的河工聚集，又為造反提供條件，元朝的覆滅就與之關系甚大。不治則生靈涂炭，治則勞民傷財，這是擺在歷代統治者面前的兩難決定，明朝也不例外。 嘉靖到萬歷年間潘季馴四次臨危受命治理黃河，取得前所未有的成效，并總結了切實可行的方略，其中最為重要的思想就是：“束水攻沙”。 什么是“束水攻沙”呢？潘季馴在治理黃河時沒有蠻力清淤，也沒有一味地加高、加寬河堤。他反其道而行，收窄河堤——在大堤（稱為遙堤）內再修筑一道更窄的堤（稱為縷堤），“遙堤用以防潰，縷堤用以束水”。河堤收窄了，水流的速度就會加快，并將沉積的泥沙帶走，這就是所謂"束水攻沙"。 “束水攻沙”與產品開發有什么關系呢？“束水”加快了水的流速，并帶走了泥沙。對應的，產品開發中我們限制并行需求的數量，也是為了加快流速——縮短需求從開始到完成的交付周期，并即時發現和處理交付過程中的問題。我們來看具體的例子。 上圖的看板，我們前面介紹過。其中提到了泳道（圖中橫向的需求泳道）的概念。泳道數約束了并行需求的數目，目的是盡快完成已開始需求，加速需求的流動。就像縷堤約束了黃河水，加快了水流。 更重要的是，限制并行能更快暴露問題。由于泳道數有限，需求發生阻塞，很容易被發現。團隊必須盡快解決阻塞的問題，否則會影響需求的開始。這里面的基本原則是：“聚焦完成，暫緩開始”。 并行的需求又被稱為“在制品” （Work In Progress）。看板上，所有已經開始，但還沒有完成的需求（或其他工作）都是在制品。一般而言，在制品數量越少，交付速度越快。源自“精益思想”的“利特爾法則”解釋了背后的原理。 什么是李特爾法則？上圖被稱為累積流圖，其中，橫坐標代表日期，縱坐標表示需求個數。紅色線表示已經開始的需求的數目，綠色線則表示已經交付的需求的數目。 紅色和綠色之間豎線的長度表示在制品的數目——已經開始，但還沒有完成的需求的數目；紅色和綠色之間橫向線的長度表示前置時間——需求從開始到完成要花費的時間；圖中斜線的斜率表示交付速率（吞吐率）——單位時間交付需求數。 這三條線構成的三角形，直觀的表達了利特爾法則： 前置時間 = 在制品/交付速率。 在交付速率相對穩定的情況下，在制品越少，前置時間越短，也就是響應速度越快。例如：團隊每月可以交付 5 個需求，并行開發 10 個需求，那么平均前置時間是：10 除以 5 ,也就是兩個月。如果將在制品數量減半，變為 5 個，前置時間就會變成: 5 除以 5，也就是 1 個月。這就是產品開發中的利特爾法則，約束在制品數目，交付的時間變短，響應變快。這與束水攻沙的思想不謀而合。 控制在制品數目，讓團隊更加敏捷的響應用戶需求。控制的方法則是多元的，如：聚焦于需求的完成而不是任務，讓任務向需求對齊，盡快地完成（而不是開始）需求；及時發現阻礙，集中精力解決它們；即時向測試移交，并盡快開始測試；優先解決缺陷而不是開始更多的需求等。 上圖表示了常見的控制在制品的方法。控制在制品數目，讓團隊聚焦需求的快速流動和交付，提高了團隊的響應能力和敏捷性。不過，團隊效能的本質提升需要更深層次的改進。如何發現并落實這些改進呢？這是我們接下來要分享的內容。 二. 湖水巖石——暴露問題，促進改進 潘季馴在解釋“束水攻沙”時，曾說過：“急則沙隨水流，緩則水漫沙停”。 “束水攻沙”不僅僅是要讓水流地更快，更重要的是把沙給沖走。 這里我們想用沙來隱喻產品交付過程中的問題，也就是說需求流動速度快，則能夠及時發現和解決問題；反之，當需求產生積壓，問題也會隱藏和積累。 下面是阿里某個基礎產品團隊的實例。我們看他們是如何通過“束水攻沙”發現和解決問題，提高效率的。 這個團隊早期使用了物理看板，可視化了交付過程。其中藍色卡片代表需求，黃色卡片代表需求分解出的任務。當時，這個團隊的迭代周期是一個月，每個月發布一次對基礎產品來說并不算太差。問題是迭代過程并不順暢，質量也有很大的問題。 第一幅圖拍的是迭代的前幾天，幾乎所有需求都同時開始了。 第二幅圖是迭代中期，所有的需求都做了一半，看上去還不錯，至少有進展。但沒有一個需求進入了測試，這其實是有問題的。 問題出現在迭代的后期，上圖是迭代結束前兩天的狀況，開發完成了一堆需求，但卻沒有一個需求真正進入了測試。這顯然不是一個號的狀態，要在最后兩天完成所有測試，這對進度和質量都是極大的挑戰，尤其是這種 “code then fix” 的模式對產品的長期質量傷害很大。事實上，這個團隊的進度和質量一直有問題，可視化更好地暴露了問題，問題背后的原因也更清楚了。 回頭看團隊迭代的過程，這是典型的“緩則水漫沙停”，過程中需求沒有向下流動，問題也被積累到了最后，比如需求拆分、測試環境以及需求之間相互依賴等問題，在前期都被有意無意的忽略了。這其實是團隊效率和質量問題的重要和根本的原因。 可視化讓團隊看到了問題和影響，接下來他們開始有意識的控制在制品。以此為基礎，開啟了他們的改進之旅，在協作過程、需求管理、工程能力都做了很大的改進。 上圖的右邊是改進后的狀態。我們看到，需求開發的交付流暢起來，每個階段的需求（在制品）都不多，需求的分布更加均勻，需求持續進入測試及發布狀態，團隊從集中批量交付轉變為了持續交付。在這個過程中，效率、質量、敏捷性都得到了很大的提升。 當然改進的過程是需要付出艱辛的努力的，涉及到技術、管理、需求、環境等多個方面。4 個迭代后，質量、效率都得到了大幅提升。我的同事蔡春華用一篇文章（集體通宵發版怎么破？阿里敏捷教練開出四道“藥方” ）真實記錄了團隊轉變的過程和效果，非常值得參考。 在上面的團隊中，我們用“湖水巖石”來比喻并指導了改進過程。 什么是“湖水巖石”呢？如上圖所示，湖水比較深時，石頭都隱藏在湖面之下；只有水位降下來，石頭才會漸次暴露出來。我們用石頭隱喻的產品開發中的問題，而湖水的水位則隱喻交付周期（或并行需求的數目）。當需求的交付周期長時，問題被隱藏，我們看到的是平整的水面。只有水位降低，問題才會暴露。 上圖中，巖石所處的深度表達了這個團隊問題暴露的先后順序。比如：為了控制在制品數目，最早暴露的是協作模式的問題，因為產品、開發、測試團隊之間習慣了大批量的移交，這是首先要解決的問題。 接下來暴露的是需求拆分和管理的問題，為此我們引入了故事地圖、實例化需求等實踐，比較順利的解決了這個問題。關于這兩個實踐，在敏捷需求的課程中，我們會詳細介紹。 其后，又陸續暴露和解決了測試回歸、測試環境、團隊溝通機制、目標管理等問題。在這個過程中水位不斷降低，深層次的問題不斷顯露和解決。而團隊的效率和質量也在解決問題中不斷提升。過程并不容易，但沒有這些問題的解決就不會有研發效能的根本提升。 三. 建立節奏，管理價值流動 “束水攻沙”是為了限制在制品的數量，讓價值順暢流動； “湖水巖石”是為了持續暴露問題，改進交付能力。這為研發效能的改進提供了可操作的理念支撐，這當然是有巨大意義的。 然而，如果離開有效的落地，再先進的理論和原則都沒有意義。接下來要討論的就是如何落地上面的原則——建立節奏，管理價值流動。 有效地管理價值流動需要從三個方面入手，價值的輸入、流動過程以及輸出。其中，關于輸出，它的最終的目標是持續交付和發布。因此接下來的討論將關注兩個方面： 價值的輸入：它對應需求的規劃和排期； 價值的流動過程：我們將介紹每日站會; 月規劃，周排期——建立管理價值流動的節奏; 應該建立怎樣的計劃節奏，多長時間做一次計劃呢？這是我們首先要回答的問題。傳統瀑布開發模式下，計劃是大批量進行的——一次計劃很多內容，并且要很長時間后才完成交付。這是瀑布開發與敏捷開發本質的區別之一。它帶來一系列問題： 降低決策的質量：一次要準備很多需求，其中包含當前還不清晰的需求。缺乏足夠的信息，卻不得不做出決策，決策的質量很難保證; 導致范圍蔓延：填充間隔過長時，業務方傾向將那些只是可能有用的需求也計劃進來，因為此時不計劃，下一次就要等到很久以后了。這樣就會產生很多猜測的需求，導致需求范圍蔓延; 降低需求澄清的關注度和效果：填充的需求要等很久之后才做，團隊關注度就會大打折扣，難以保證需求澄清的效果; 不能很好地支持有效學習和創新：計劃時做出假設，交付后得到反饋，驗證假設并作出調整，這是互聯網產品試錯和創新的重要模式。一次填充過多需求，反饋速度慢，極大降低學習和創新的機會; 降低團隊靈活響應市場變化的能力（敏捷性）：一次填入很多需求，發生變化或出現新需求時，就只能等很久以后的下一次填充了，這對組織響應變化的能力顯然是不利的，損害了組織的敏捷性。 計劃的頻率越高，批量越小，則敏捷性越好。同時決策時信息越充分，決策質量也越高。但是頻繁計劃也帶來額外的成本。相關的人在一起進行會議，業務人員要提前準備好需求，這都帶來協調成本。 除了成本外，還要考慮頻繁填充的必要性。兩次填充之間產生了足夠多的支持更好決策的新信息，分開進行需求填充才是有意義的。否則，必要性就很低。 基于對以上兩點的考慮和阿里自身的一些實踐經驗，我們形成了“月規劃，周排期”的機制。 如上圖所示，看板中選擇（規劃）這一列，對應需求規劃，規劃好的需求放入選擇列。第四列則是需求排期，排期好的需求放入該列。團隊每個月會進行一次產品規劃，和產品或者業務方確認本月的主題是什么，圍繞這些主題需要做哪些需求。月規劃的基礎上再做周排期，決定本周要做什么。如此形成的機制就是: 月規劃：每月進行一次。由業務方和開發團隊的代表參加，共同計劃和確認接下來的一個月要做的需求，初步的溝通和確認后，放入“選擇”隊列； 周排期：每周進行一次。在開發團隊內部進行，團隊從計劃隊列中選擇接下來要做的需求，詳細澄清后，放入就緒“排期”隊列。團隊決定填充什么需求時，一方面會考慮需求的優先級，也會結合上一周開發實際完成情況做調整。 對于規劃排期這部分更加詳細的內容，可以參見之前的文章（精益看板方法從理論到實戰 （9）—— 計劃會議，就緒隊列填充）。 “非常6+1”——站會的正確姿勢 站會應該聚焦于價值的流動，而非個人工作。它的目的是：檢視價值流動的狀態，促進價值順暢流動。站會的組織形式也要服務于這一目的。 典型的看板站會，發生在每個工作日、同一時間、同一地點（看板前）。站會上，團隊從右至左走讀看板。之所以從右往左，一方面是為了體現價值拉動的方向；另一方面是為了貫徹“暫緩開始，聚焦完成”的原則，比如 Bug 一般在看板墻上偏右的測試列，從右往左更方便安排優先解決 Bug，快速完成需求交付，而不是開始更多的需求開發。 影響和阻礙價值順暢流動的因素有很多，比如瓶頸和隊列、關鍵缺陷、重點需求、阻礙和問題、已經到期或者即將到期的需求、中斷以及未反映在看板上的問題。 站會上不需要檢視每一張卡片。本著“檢視價值流動的狀態，促進價值順暢流動”的目的，我們應該重點關注影響價值流動的問題。如上圖所示，它們中的絕大部分都可以很清晰地體現在看板墻上，典型的包括以下 6 個方面，加上未反映在看板上的問題（+1）。我們稱之為 “ 6+1 ” 站會。這里只是一個簡單的介紹，關于如何組織站會，可以參考之前的文章（精益看板方法從理論到實戰 （8）—— 看板站會）。 以上我們介紹了規劃、排期以及站會的節奏。我們，在實施過程中逐漸形成了：月規劃、周排期、日站會的節奏。如上圖所示，這些節奏幫團隊落地相關的精益和敏捷實踐，并在此基礎上形成改進閉環，在不同的場景中得到了應用，在新零售、大文娛、云基礎設施都得到過驗證，效果不錯，具有較廣泛的適應性。 總結 本次課程我們從“束水攻沙”的故事講起，通過主動的控制在制品，加速價值的流動； “湖水巖石”，則通過不斷降低水位，讓團隊盡早暴露問題，并直面和解決它們。為了讓價值順暢、高質量地流動，團隊還必須建立節奏，落地相關原則和實踐，并形成效能改進和業務反饋閉環，切實提升組織的“研發效能”。 阿里云雙11億元補貼提前領，進入抽取iPhone 11 Pro：https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110 ------------------------------------ 本文作者：Teambition Developer 原文鏈接：https://yq.aliyun.com/articles/719255?utm_content=g_1000083600 本文為云棲社區原創內容，未經允許不得轉載。