看板方法是一种以可视化工作流、限制在制品数量和管理流动为核心的工作管理方法。它用列表示流程阶段、卡片表示工作项，通过限制各阶段并行工作量暴露瓶颈，再借助周期时间、吞吐量等指标持续调整流程。本文说明看板方法的定义、组成机制、概念边界，以及它与 Scrum、甘特图、任务列表的区别，并给出一个内容发布流程的示例。
要点总览（TL;DR）
- 看板方法是一种以可视化工作流、限制在制品（WIP）数量和管理流动为核心的工作管理方法，用列表示流程阶段、卡片表示工作项。
- 完整运用看板方法需要同时具备可视化流程、WIP 限制、流动管理、显式规则和定期回顾改进，只贴任务卡片不构成完整方法。
- 看板方法依靠拉动式推进和周期时间、吞吐量、累积流图等指标识别瓶颈，不规定固定迭代节奏和固定角色体系。
- 看板方法与 Scrum 的差异在节奏、角色、事件和工件，与甘特图的差异在管理对象，与任务列表的差异在流程阶段和 WIP 限制，这些是机制差异而非优劣判断。
- 看板方法适用于工作持续进入、需要控制并行量的流程，产品研发、内容生产、市场活动执行都可以采用，列设置依实际流程而定。
看板方法的直接定义
看板方法（Kanban Method）是一种面向持续流动的工作管理方法。它要求团队把工作流程显式地画出来，让每个工作项在流程中的位置可见；为流程的各个阶段设定在制品数量上限，控制同一时间并行推进的工作量；再通过观察工作项在流程中的流动情况，识别阻塞与瓶颈，并据此调整流程规则和协作方式。看板方法回答的核心问题是：工作现在处于什么状态、同时推进多少件合适、哪些环节在拖慢整体流动。
理解这个定义，需要先明确几个基本术语：
- 看板：承载工作流程的可视化界面，通常由若干列组成，每一列对应流程中的一个阶段。
- 工作项：被管理的一件具体工作，如一个需求、一个缺陷、一篇待发布的文章，在看板上以卡片形式呈现。
- 在制品（WIP，Work In Progress）：已经进入流程但尚未完成的工作项。在制品数量指某一阶段或整个流程中同时处于进行状态的工作项个数。
- 流动：工作项从进入流程到完成所经过的连续过程。流动顺畅意味着工作项较少长时间停留、等待和返工。
看板方法要解决的核心问题可以归纳为三点：让工作状态可见，避免“做到哪了”只能靠口头询问；让并行工作量可控，避免同时开工太多导致每件事都完不成；让瓶颈可被识别，使改进有具体的观察对象，而非停留在感觉层面。
看板方法的边界：包括什么、不包括什么
看板方法常被简化成“一块贴满任务卡片的墙”，这种理解只覆盖了可视化这一项。要判断一个团队是否在运用看板方法，可以看它是否同时具备以下核心要素：
- 可视化流程：把真实的工作阶段画成列，工作项按实际状态放置，看板结构与团队真实流程一致。
- WIP 限制：为阶段设定并行数量上限，达到上限时不再拉入新工作，先推动已有工作完成。
- 流动管理：持续观察工作项在流程中的停留与等待，识别阻塞并处理。
- 显式规则：把“什么算进入下一阶段”“卡片何时可以移动”“阻塞如何标记”等规则写清楚，让团队按同一口径操作。
- 反馈与协作改进：定期回顾流动数据，调整列设置、限制数值和规则。
相应地，以下内容属于看板方法之外的范畴：具体使用哪款软件工具、是否采用固定迭代节奏、是否设置固定角色体系、采用何种估算方法。这些可以由团队自行选择，与看板方法本身是否成立无关。
| 判断维度 | 属于看板方法 | 不属于看板方法本身 |
|---|---|---|
| 流程呈现 | 列对应真实阶段，卡片位置反映实际状态 | 任意任务清单或待办列表 |
| 工作量控制 | 为阶段设定 WIP 上限并执行 | 只贴卡片、不设任何数量约束 |
| 改进依据 | 依据流动指标与阻塞记录调整流程 | 仅凭印象评价快慢 |
| 节奏与角色 | 由团队按需设定 | 固定迭代周期、固定角色分工 |
| 工具与估算 | 可自由选择 | 特定软件、特定估算方法 |
把任务贴在墙上，如果缺少 WIP 限制和流动管理，只是完成了可视化，尚不构成完整的看板方法。另外需要说明本文的范围：具体的迭代规划、评审与回顾操作属于迭代管理的内容，需求池的维护与优先级排序属于需求池管理的内容，本文不展开。
看板方法如何运转：组成与机制
看板方法从工作项进入看板到完成，依靠一组相互配合的组成部分持续运转。
看板的结构
看板通常由三个层次构成：列表示流程阶段，例如“待处理—分析—制作—审核—发布”；卡片表示工作项，卡片上记录标题、负责人、阻塞原因等关键信息；泳道表示工作类型或优先级，例如把常规任务与紧急修复分在不同泳道，避免紧急工作淹没常规工作。
WIP 限制的作用机制
WIP 限制是看板方法与普通任务墙的分水岭。当某一阶段的卡片数量达到上限，团队不再从上游拉入新工作，而是集中处理该阶段已有的卡片。这一约束会带来两个效果：阻塞和积压会立刻显现出来，因为卡片堆在某一列无法前进；团队被迫优先完成已开始的工作，减少半成品同时堆积。
流动指标
看板方法用指标描述流动状况，常用的有三类：
- 周期时间：一个工作项从开始处理到完成所经历的时间，反映单件工作的交付速度。
- 吞吐量：单位时间内完成的工作项数量，反映流程的整体产出能力。
- 累积流图：横轴为时间、纵轴为各阶段工作项累计数量的图。各条带之间的宽度反映该阶段的在制品数量，条带变宽说明工作在该阶段积压，是定位瓶颈的常用读法。
拉动式推进与规则显式化
看板方法采用拉动式推进：下游阶段出现空位时，上游的工作项才被拉入下一阶段，而不是由上游不断把工作推给下游。配合这一机制，团队需要把流程规则写清楚，例如进入“审核”列的条件、阻塞卡片的标记方式、紧急工作如何插队。规则并非一次定死，团队在定期回顾中依据流动数据和实际阻塞情况调整列设置、限制数值与规则本身，形成“观察—调整—再观察”的循环。
看板方法与 Scrum、甘特图的关键区别
看板方法容易与几种常见的计划和管理方式混淆。它们的差异主要在机制层面，各自适用于不同的管理需要，不构成优劣判断。
| 对比维度 | 看板方法 | Scrum | 甘特图 | 任务列表 |
|---|---|---|---|---|
| 核心机制 | 可视化流程 + WIP 限制 + 流动管理 | 固定长度迭代 + 角色分工 + 事件与工件 | 时间轴上的任务排期与依赖关系 | 记录待办事项及其状态 |
| 节奏 | 连续流动，不规定固定迭代 | 以 Sprint 为固定节奏 | 按计划日期推进 | 无固定节奏 |
| 角色 | 不规定固定角色体系 | 设产品负责人、Scrum Master、开发团队 | 通常对应项目经理与执行人 | 通常只有负责人 |
| 计划方式 | 按流动与容量持续调整 | 迭代计划会确定本迭代目标 | 前期排定时间与依赖 | 逐条罗列，缺少流程阶段 |
| 典型关注点 | 并行量、周期时间、瓶颈 | 迭代目标达成与团队协作 | 关键路径与交付日期 | 事项是否被记住 |
看板方法与 Scrum 可以组合使用：团队在固定迭代内用看板管理任务状态、观察流动，迭代评审时再对照目标检查结果。看板方法与甘特图的差别在于管理对象，前者管理流动与并行量，后者侧重时间计划与依赖排期，项目型工作中两者也常同时出现。与任务列表相比，看板方法多了流程阶段划分和 WIP 限制，因此能回答“卡在哪一步”，而任务列表只能回答“做没做”。
一个具体例子与常见误解
以下为一个演示情景，用于说明机制，不作为真实案例。某团队负责内容发布，把流程设为五列：待处理、选题、撰写、审核、发布。团队为“撰写”列设定 WIP 上限为 3，为“审核”列设定上限为 2。
某周开始后，待处理列积压了 12 个选题，撰写列很快达到 3 篇的上限。此时团队不再从选题列拉入新内容，而是集中完成已有三篇。两天后，三篇中有两篇完成并进入审核列，审核列达到上限 2，第三篇仍停在撰写列等待修改。看板上出现明显信号：审核环节成为瓶颈，撰写完成的内容无法及时通过审核。团队据此调整，安排一名审核人优先处理积压，并在回顾中讨论是否把审核拆成“初审”和“终审”两列，让部分内容先通过初审，减少整列堵塞。整个过程没有改变迭代节奏，也没有新增角色，改变的是流程结构和限制数值。
围绕看板方法，常见的误解有三类：
- 误解一：看板方法就是一块看板工具或任务墙。工具只是承载界面，方法成立的关键在于流程是否真实可见、是否设定了 WIP 限制并据此管理流动。
- 误解二：看板方法不需要任何规则和限制。恰恰相反，WIP 限制、进入下一阶段的条件、阻塞标记方式都需要显式约定，缺少这些约定，看板会退化为任务墙。
- 误解三：看板方法只能用于运维或支持类工作。看板方法适用于工作持续进入、需要控制并行量的各类流程，产品研发、内容生产、市场活动执行都可以采用，具体列设置依流程而定。
回到定义：看板方法的价值来自可视化、WIP 限制与流动管理三者的配合，任何一项缺失，方法的效果都会打折扣。
把看板方法落到团队协作中的管理动作
看板方法落地时，团队首先要解决的是信息分散问题：工作项状态记在个人表格里、阻塞原因靠口头同步，看板列就会与真实流程脱节。把工作项的状态、负责人和阻塞原因记录在同一处，让卡片位置对应真实进展，是维持看板可信度的基础动作。ONES 敏捷研发管理解决方案将需求提出方、产品经理、研发、测试等角色连接在同一流程中，团队成员通过敏捷看板管理任务状态，在每日站立会议中借助看板对齐迭代进度与风险。
在控制并行量方面，团队需要让状态流转和数量约束在流程中实际生效，使积压和阻塞在看板上直接可见，而不是等到交付延期才被发现。回顾环节则需要可追溯的数据支撑：ONES 系统自动记录和统计资源投入、缺陷分布、工作项滞留时间等研发过程数据，团队可以据此讨论哪些阶段停留时间偏长、规则是否需要调整。ONES Project 提供看板、燃尽图等工具用于掌握当前进度，并支持按业务需求灵活定义项目类型与相关组件，便于让看板结构与团队实际流程保持一致。这些能力的具体配置与范围以实际产品资料为准。
常见问题
团队刚开始用看板方法，WIP 限制应该设多少？
WIP 限制没有统一数值，需要从团队当前的实际并行量出发。可以先观察一到两周，记录每个阶段同时进行的工作项数量，取一个略低于现状的数字作为初始上限，让约束产生作用又不至于立刻堵死流程。运行一段时间后，依据周期时间和积压情况调整：如果某列长期满额且下游空闲，说明该列容量偏小；如果各列都很宽松、瓶颈始终不出现，说明限制偏大。调整的依据是流动数据，而非个人感觉。
看板方法和 Scrum 可以同时使用吗？会不会冲突？
可以组合使用，两者并不冲突。常见做法是在固定长度的 Sprint 内用看板管理任务状态和并行量，观察工作项在各阶段的流动，迭代评审时再对照迭代目标检查结果。需要注意的是，组合使用时要把两套规则都写清楚：哪些列对应迭代内的流程、WIP 限制按列还是按人计算、紧急插入的工作如何记录。规则含糊时，看板容易退化为任务墙，Scrum 的迭代目标也难以对照。
工作项经常被紧急任务打断，看板方法怎么处理？
紧急工作在看板方法中同样需要被看见，而不是绕开流程直接插队。常见做法是设置单独的泳道或标记，让紧急工作与常规工作在同一个看板上呈现，并明确紧急工作的判定条件和记录方式。如果紧急工作频繁出现，说明流程中存在需要处理的系统性问题，例如某类缺陷反复发生或某环节审核标准不清，可以在回顾中依据阻塞记录和滞留时间讨论根因，而不是长期靠加急消化。
看板方法一定要用软件工具吗？白板和卡片够不够？
白板和实体卡片可以完整承载看板方法，可视化流程、WIP 限制和流动管理都能在物理看板上实现。选择软件工具主要取决于协作范围：当团队成员分布在不同地点、工作项数量较多、需要留存历史数据用于回顾时，工具在记录和统计上更方便。工具只是承载界面，方法是否成立取决于流程是否真实可见、是否设定了 WIP 限制并据此管理流动。
看板方法适合什么样的团队和流程？
看板方法适合工作持续进入、需要控制并行量的流程，例如产品研发中的缺陷处理、内容生产、市场活动执行和支持类工作。判断是否适用可以看两个条件：工作项是否按阶段逐步推进、团队是否需要同时处理多件工作。如果工作以固定周期整体交付、需要明确的迭代目标和角色分工，Scrum 更贴合；两者也可以组合。列设置和 WIP 数值应依据团队真实流程确定，不宜照搬其他团队的做法。
