> ## Documentation Index > Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt > Use this file to discover all available pages before exploring further. # 看板方法 > 看板是一種可視化工作流程管理方法，使用看板和卡片來可視化工作。學習如何實施這種敏捷方法來提高團隊效率。 **Category**: 方法
**Type**: 工作流程管理系統
**起源**: 豐田汽車，1940年代
**Also known as**: 看板、可視化工作流程管理、精益管理系統 **快速回答** — 看板方法是一種可視化工作流程管理系統，幫助團隊可視化正在進行的工作，限制在製品數量（WIP），並最大化效率。看板最初由豐田公司在1940年代為製造業開發，使用一個帶有代表不同工作階段列的看板——通常是「待辦」、「進行中」和「已完成」——用卡片代表單個任務。該方法的核心原則是：可視化工作使瓶頸和低效變得可見，使團隊能夠持續改進流程。 ## 什麼是看板方法？ 看板方法是一種精益管理方法，將工作可視化在看板上，使任務流程透明且可管理。看板的核心在於使不可見的變得可見：通過將每個任務放在團隊成員都能看到的看板上，隱藏的瓶頸、過量的工作量和停滯的工作變得立即可見，而不是潛伏在收件箱或電子表格中。 典型的看板由代表工作流程中各階段的列組成。任務從左到右移動。最簡單的看板有三列——「待辦」、「進行中」和「已完成」——但更複雜的工作流程可能包括額外的階段，如「審核」、「測試」或「部署」。每個任務用一張卡片表示，包含相關資訊：描述、負責人、優先級、截止日期，以及團隊認為有用的任何其他元數據。 > 「瓶頸決定整個系統的吞吐量。看板幫助識別這些約束，使團隊能夠系統地解決它們。」—— 大衛·安德森，《看板：為您的科技業務帶來成功的漸進式變革》一書的作者 看板的真正力量在於強調流程優化而不是嚴格排程。與傳統的專案管理方法計劃特定交付日期不同，看板專注於工作在整個系統中的順暢移動。當一張卡片在一列中停滯時，那是調查的信號。當一列總是有比其他列更多的卡片時，那是需要解決的瓶頸。這種持續反饋循環使團隊能夠迭代改進流程。 ### 看板方法的三層理解 * **入門**：從一個簡單的三列表格開始（待辦、進行中、已完成）。為每項工作創建卡片，並在工作進行時將它們在列之間移動。專注於讓團隊中的每個人都能看到工作。 * **實踐**：為每列添加在製品限制以防止過載。使用泳道分隔不同類型的工作或成員。實施卡片在列之間移動的策略。添加關鍵流程階段的列，如審核或測試。 * **進階**：使用週期時間、吞吐量和累積流程圖等指標來識別趨勢。運行專注於改進流程的定期回顧。嘗試不同的看板結構、WIP限制和策略。將看板與其他敏捷實踐（如Scrum或XP）連接。 ## 起源 看板方法起源於豐田汽車，由工業工程師大野耐一於1940年代末作為豐田生產系統（TPS）的一部分開發。「看板」一詞來自日語，意思是「布告板」或「視覺卡」。最初用於製造業，該系統旨在創建拉動式工作流程，材料和組件僅在需要時生產或交付，減少浪費和過度生產。 2000年代初，軟體顧問大衛·安德森將看板應用於科技企業。他2010年的著作《看板：為您的科技業務帶來成功的漸進式變革》成為將看板應用於軟體開發和IT運維的基礎文本。安德森引入了在製品限制、累積流程圖和服務交付模板等關鍵概念，將看板擴展到其製造業根源之外。 敏捷社區歡迎看板的靈活性。與規定特定角色、儀式和時間盒的Scrum不同，看板只是一種管理工作流程流動的方法——團隊可以根據需要採用或多或少的實踐。這種非規定性的性質使看板對運維、支援和維護角色特別有吸引力，在這些角色中，Scrum的固定衝刺不太適用。 ## 核心要點 建立一個帶有代表工作流程階段列的看板。每項任務成為看板上的一張卡片。這種透明度揭示了整個團隊工作的真實狀態——不再有隱藏在個人收件箱或被遺忘的電子表格中的工作。 為每列設置最大限制。當一列達到其限制時，團隊成員必須在拉取新任務之前完成現有工作。這防止多任務處理，減少上下文切換，並暴露否則會隱藏的瓶頸。 監控工作如何通過系統流動。追蹤週期時間（一項任務從開始到結束需要多長時間）和吞吐量（每個時間段完成多少任務）等指標。使用這些數據來識別延遲和改進流程。 定義工作如何流經看板的明確規則。什麼時候卡片可以移動到「進行中」？移動到「已完成」之前必須滿足什麼標準？明確的策略減少混淆並創建共用理解。 在看板前定期舉行站會討論阻礙和進展。使用回顧來識別改進機會。看板節拍——運維審查、服務交付審查和風險審查——提供結構化的反饋機會。 使用數據和團隊觀察來發展流程。從小實驗開始，而不是大變化。專注於改進流程，而不僅僅是移動更多卡片——目標是可持續的節奏和品質。 ## 應用場景 看板廣泛應用於軟體開發，用於管理功能開發、缺陷修復和技術債務。其可視化特性幫助開發團隊平衡新開發與維護工作，並快速識別何時在製品過多。 管理IT基礎設施、服務台和客戶支援佇列的團隊使用看板來可視化傳入的請求，追蹤正在進行的工作，並確保沒有任何東西遺漏。WIP限制通過限制可以同時處理的事件數量來幫助防止倦怠。 創意團隊使用看板來管理內容製作、活動規劃和設計工作。可視化看板幫助平衡競爭的優先級，並確保所有利益相關者可以看到可交付成果的狀態，而無需頻繁的進度會議。 個人使用個人看板來管理專案、日常任務和目標。該方法的簡單性使其易於個人使用，同時仍提供可視化和流程管理的好處。 ## 經典案例 **背景**：一家SaaS公司的15人客戶支援團隊正在努力應對不斷升級的響應時間和客服倦怠。工單堆積，客戶在社交媒體上抱怨，團隊始終感到不堪重負。傳統方法如增加更多客服或加班並不可持續。 **問題**：團隊如何在不簡單地增加工作時間的情況下獲得工作流程的可見性並減少積壓？ **證據**：支援負責人實施了一個看板，列為分類、進行中、等待客戶和已解決。他們為每個客服引入了WIP限制（最多5個活動工單），並為阻止的工作提供視覺信號。團隊追蹤了8週的指標，並將結果與前8週進行比較。 **結果**：平均首次響應時間從4.2小時降至1.8小時——提高了57%。客戶滿意度評分從3.9上升到5分中的4.5。最重要的是，客服倦怠分數下降了40%——WIP限制迫使團隊專注於完成工作而不是開始更多任務，這 paradoxically 讓他們能夠以更少的壓力處理更多的總工單。 **教訓**：看板揭示了團隊真正的問題不是數量——而是糟糕的流程管理。客服不斷地在數十個開放的工單之間切換上下文，從未完成任何事情。通過限制WIP並使工作可見，團隊發現做得少實際上意味著完成更多。 ## 邊界與失效場景 看板在工作流程相對穩定和可預測時效果最佳。它在某些情況下表現不佳： * **高度變化的優先級**：如果優先級每小時或每天變化，頻繁的重新優先級排序會使看板變得混亂。在採用看板之前，考慮您的工作是否實際上有穩定的階段。 * **非常小的團隊**：兩個人的團隊可能會發現看板的開銷過大。該方法在有足夠的工作填充看板和有足夠的人從共用可見性中受益時效果最佳。 * **不遵守WIP限制的承諾**：簡單地建立看板而不執行WIP限制不會產生結果。限制是強制進行關於容量和瓶頸的困難對話的原因。 * **靜態看板**：看板應該隨著您的流程發展。如果您從不更改列、限制或策略，您就錯過了看板所實現的改進機會。 ## 常見誤區 雖然看板在軟體開發中很受歡迎，但它的起源是製造業，適用於任何知識工作。支援團隊、行銷部門、人力資源、財務和個人都成功地使用看板。核心原則——可視化工作以改進流程——是通用的。 從簡單開始。三列表格（待辦、進行中、已完成）是完全有效的看板。隨著您識別需要關注的特定階段，可以添加額外的列。關鍵不是列的數量，而是限制WIP和使流程可見的紀律。 許多團隊成功地結合看板和Scrum（通常稱為「Scrumban」）。看板提供流程管理，而Scrum提供節拍。這些方法可以相互補充，而不是相互競爭。 ## 相關概念 看板方法與其他幾個生產力和管理方法相關。[敏捷方法論](/zh-hant/models/diffusion-of-innovation)為迭代改進提供了哲學基礎。[艾森豪威爾矩陣](/zh-hant/models/eisenhower-matrix)幫助確定哪些任務值得在您的看板上關注。 帶有衝刺和角色的敏捷框架 基於優先級的任務分類 迭代改進的哲學基礎 ## 一句話總結 使用看板使工作可見並限制在製品——它提供的視覺反饋是實現持續改進和防止倦怠的關鍵。