> # 一、可視化什么？——可視化照亮問題所在  能夠看見的地方，卻不是 “關鍵” 所在，當然也找不到需要的答案，研發過程當中，我們是否會范同樣的錯誤？很不幸，不但會，而且還非常普遍  在軟件產品的研發過程中，其實根本問題從來都不是停滯的資源（工程師），而是停滯的產品需求（用戶價值）。 研發過程可視化，就是要可視價值端到端的交付過程，讓我們看到價值流動的過程，以及流動過程中的阻礙、停滯和問題。  “開發中”的需求和其下屬的任務處于同一行，我們稱之為“需求泳道”。某個需求下屬的所有任務都 “完成”后，則需求開發完成,可以繼續往后流動到“待測試”，任務則可以清理或折疊。泳道空出，可以準備讓下一需求進入。 通過這個看板我們可以看到需求流動的整個過程，看到需求被拆分成多個任務以及團隊協作完成任務的過程。它幫助團隊暴露和發現問題，促進團隊更好地協作交付需求。為團隊的高效協作和價值的順暢流動奠定了基礎。 > # 二. 如何可視化——四個步驟實現有效可視化 ## **第一步：用戶價值驅動，識別有效的流動單元** 我們首先需要分析的是：團隊或組織對外交付的是什么，從而識別有效的流動單元，明確可視化的主體。  以上四類需求是團隊需要交付的主體內容，也是看板上的流動單元 ## **第二步：前后職能拉通，定義端到端價值流**  需求從（被）“選擇”開始，經過“分析”、“待評審”階段到達“就緒”階段（注：就緒指的是對開發團隊而言的就緒）；再經過“實現”、“待測試”、“測試待發布”，最后到“已發布”階段。這個端到端的過程就是需求交付的價值流 端到端的價值流動過程,涉及不同的職能，如產品設計、交互視覺、開發和測試等。為了提升流動效率，必須拉通組織中的各個職能，實現整個過程的可視化 一些團隊因為條件約束，無法立即做到全面的端到端拉通。條件允許，還是要盡量向兩端擴展，才能實現真正的端到端的敏捷和精益。這也為團隊的進化提供了方向 ## **第三步：左右模塊對齊，體現環節的任務協作**  上圖中間的“實現”階段中，綠色卡片所代表的需求被拆分成多個任務（黃色卡片）。這些任務，分屬后端、iOS 開發、安卓開發以及外部依賴等。團隊的目的不是完成更多的任務，而盡快交付需求。 這就是我們說的：左右模塊對齊，也就是任務向需求對齊，盡早交付需求。它促進團隊以需求交付為牽引，更有效的協作，并幫助團隊發現影響需求交付的瓶頸。 ## **第四步：明確流轉規則，賦能團隊本地決策、內建質量** 定義需求向下一階段流動所必須滿足的條件。比如:達到什么條件才能從“待評審”進入“就緒”環節。團隊應該定義明確的需求流轉規則，并達成一致理解 明確流轉規則幫助團隊做到內建質量。所謂內建質量，是讓需求在每一個階段的質量，都得到有效地保證，避免問題在最后的階段集中爆發，和避免不必要的返工，這也是持續順暢價值流動的基礎。  下面的例子。就緒隊列準入規則: 1. 開發、測試和業務共同澄清需求，并定義明確交互過程和驗收標準 2. 大需求已拆分為工作量在兩周以內可以完成和交付的需求 3. 已與業務關聯方（如有）確認相關計劃 4. 識別大的技術風險并定義應對方案 5. 涉及三個（含三個）開發人員以上的需求，指定好協調人，負責進度協調 ## **總結 - 可視化價值流的基本步驟**  ## 可視化是手段，而不是目的”。讓價值順暢高質量地流動才是目的