1、分析價值流動過程

分析價值流動過程是看板設計的基礎。為了分析價值流，需要識別團隊交付的價值類型，一般團隊交付的價值類型包括業務需求、關聯需求、改進類需求和其他任務，而往往業務需求占團隊工作的比重比較大，這里圍繞業務需求來設計工作流。

如下圖所示，首先要確定的是價值流動所經歷的主要工作步驟，如分析、開發、測試等，在圖中用綠色方框表示；在這些步驟之間可能會發現明顯的交接或等待，如計劃后等待開始實現，開發完成后向測試移交等，在圖中用紅色方框表示。等待環節雖然沒有具體的工作，卻也占用了價值流動的時間，并可能產生積壓，也需要識別出來。

2、選取可視化設計元素

看板設計使用可視化元素建模和反映價值流動過程。

隊列

用戶需求在某個狀態停留會形成隊列。停留的原因有兩種，第一是工作正在被處理，如開發中和測試中等；第二是等待進入下一個環節，如開發完成和等待驗收等。對應的，看板上的列也分為工作列和等待列。

如下圖，典型情況下，看板上的工作列和等待列交替出現，需求從左至右流經各個列。

列的劃分可細可粗，細的譬如可以把開發階段分成設計、編碼、自測和評審等，粗的譬如合并開發和測試階段，統稱為實現階段。

具體細化到哪一個級別，依賴于兩點：其一，工作是否會在該階段顯著停留，其二，使用者是否需要特別關注這些階段。

另一個問題是從哪個階段開始，到哪個階段結束。理論上，端到端的看板應該從用戶的問題開始，到用戶的問題被解決結束，形成業務閉環。而實際應用中，團隊可以從自己能影響到的局部流程開始，并隨著時間的推移，再尋求向上游和下游延伸，以促進整個組織的協作和需求端到端的順暢流動。

以阿里內部某全功能研發團隊的實踐為例，看板的起始階段是”已選擇”，正常終止狀態是”已發布“

確定了看板的起止階段后，就可以根據團隊的情況設置中間的各階段了。

工作項

在看板上流動的基本單元包括業務需求、關聯需求、改進類需求和其他任務，這里的其他任務一般包含開發任務和測試過程中發現的缺陷，所有業務需求、開發任務和缺陷都會在看板上進行流動。

3、用看板建模價值流動

在前面兩步的基礎上，我們可以設計團隊的看板了，看板的設計過程是綜合選取價值流動過程和可視化元素，即可建立可視化的看板。

如下圖所示，是在云效上建立的看板，需求的階段包括待處理（需求池）、已選擇、分析中、就緒（待開發）、開發中、待測試、測試中、待發布和已發布

這里有兩個階段需要特別說明一下：

已選擇：由業務方和開發團隊代表共同完成，清晰要解決的問題和要達成的目標后，并通過可行性分析，按優先級放入已選擇隊列。

就緒（待開發）：就緒隊列在研發團隊正式開始開發之前，是研發團隊的輸入隊列，其意思是需求已準備好了，處于可以開始開發的狀態，比如：用戶的需求已清晰，團隊理解了用戶的需求，相關的依賴和關聯關系已經確認等。就緒隊列也是研發團隊與其上游產品團隊的交接點，是看板系統設計的必選項。

4、如何在云效上配置工作流和看板

我們以在云效上建立以”Scrum敏捷交付空間“為模板的項目為例：

4.1 創建Scrum敏捷交付空間

在云效頂部導航右上角點擊「新建項目」創建項目，選擇 「Scrum敏捷交付空間」，填寫項目名稱、公開性、項目編號等信息。

項目空間默認配置了需求管理、任務管理 、迭代管理 、度量服務 、工時統計、缺陷等模塊。

4.2 搭建需求工作流

需要設置需求、缺陷和任務的工作流，這里重點講需求工作流的配置，缺陷和任務使用默認的工作流即可。如下圖所示，我們先在云效上搭建需求流轉的整個工作流，展現需求從收集到發布的全流程。

我們推薦的需求工作流是：

待處理->已選擇->分析中->就緒（待開發）->開發中->待測試->測試中->待發布->已發布

• 待處理：一般指需求池；

• 已選擇：從待處理中選擇出確定要做的需求，但還未做具體的分析和設計；

• 分析中：對需求的使用場景、技術可行性、業務價值和效果進行澄清，撰寫產品PRD;

• 就緒（待開發）：需求已澄清，只要有開發資源，就可以進入開發中；

• 開發中：開發資源已就位，依據需求進行代碼特性開發；

• 待測試：需求已開發完成，只要有測試資源，就可以進入測試中；

• 測試中：測試資源已就位，依據測試用例進行測試；

• 待發布：需求已經過驗收和測試，滿足可發布的條件，等待發布；

• 已發布：需求已發布上生產環境，用戶可見。

加餐 ：需求工作流這樣設置有什么好處？歡迎學習「阿里巴巴研發效能提升36計：照亮問題，效能提升從可視化交付過程開始」。

• 設置需求工作流的入口：如下圖所示，進入項目中，點擊左下角的進入設置頁面。點擊工作項-需求，選擇某一類需求進行工作流的設置。

• 在工作流設置頁面，添加或刪除工作項狀態，調整工作項狀態流轉順序。按照上述所推薦的需求工作流，在頁面上設置如下圖所示：

• 通過設置工作項狀態流轉規則，規范需求管理流程。如下圖所示，當需求的使用場景、技術可行性、業務價值和效果已被澄清清楚，進入排期后，需求狀態需要從「分析中」流轉到「待開發」，此時產品經理需要和研發確定計劃完成時間，并由產品經理進行狀態流轉操作。

還會存在，一個產品需求被拆分成若干個子產品需求或者任務的情況，通過設置關系對象流轉規則，規定當產品需求的子工作項均為待開發狀態時，該產品需求才可以從「分析中」流轉到「待開發」，避免出現由于子產品需求或者任務拆分過多，造成遺漏導致需求分析不完善的情況。

4.3 配置看板視圖

如下圖所示，將需求頁面切換為「看板」視圖，配置成所需要的看板視圖。

總結

可視化價值流動是整個團隊協作交付價值的基礎，團隊根據各自上下文，提供不同的服務，交付不同類型的價值，價值流動過程也不同，看板系統設計必須從分析團隊具體的價值流開始，選擇和應用最合理的視覺元素，設計出適合團隊自身的云效看板。