Kanban（看板）是一种以可视化工作项、限制在制品数量、管理流动效率为核心的敏捷工作方法。它把工作拆成可观察的卡片，按流程阶段排列在看板上，通过列上限和拉动规则控制同时进行的工作量，让瓶颈、等待和交付节奏变得可见。本文围绕定义、边界、运转机制与相邻概念的区别展开，帮助读者判断自己的场景是否适合采用看板方法。
要点总览（TL;DR）
- Kanban（看板）是一种把工作项做成卡片、按流程阶段排列、用列上限约束并行数量、依靠拉动推进的敏捷工作方法，核心是可视化、在制品限制和流动管理三条规则。
- 属于 Kanban 方法本身的是列、卡片、在制品上限、拉动和流动观察；固定迭代周期、角色体系、估算仪式属于相邻框架，泳道、标签、自动化等属于工具功能。
- Kanban 与 Scrum 的差异在节奏来源：Scrum 用固定迭代和角色分工建立节奏，Kanban 用流动和上限建立节奏；两者可以在迭代内叠加看板管理任务状态。
- 与普通任务列表相比，Kanban 的关键分界是 WIP 上限和拉动规则是否真正被执行，缺少这两条时便签墙仍只是任务列表的可视化。
- 常见误解包括把看板等同于便签墙、认为必须配固定迭代、认为列越多越细越好、把工具里的看板视图当成方法本身。
Kanban 的直接定义
Kanban 的中文名称是“看板”，词源来自日语“看板”（かんばん），原意是“可见的板”或“招牌”。在精益生产中，它指用于传递生产信号、触发上游补货的卡片；在软件与知识工作领域，这个词被借用并扩展为一种管理方法与可视化载体。可以这样复述：Kanban 是一种把工作项做成卡片、按流程阶段排列在板上、用列上限约束并行数量、依靠拉动推进工作的敏捷方法。
这个定义包含三个不可拆分的核心要素。第一是可视化：每一张卡片代表一个可识别的工作项，卡片所在的列代表它当前所处的流程阶段，任何人站在板前都能读出“现在有什么、卡在哪里”。第二是在制品限制（Work In Progress Limit，简称 WIP 上限）：每一列或每个流程环节设定同时允许存在的卡片数量上限，达到上限就不再从上游拉入新工作。第三是流动管理：团队关注工作项从进入到完成的整体流动，通过观察等待时间、堆积位置和交付节奏来发现并消除阻塞。
需要强调的是，Kanban 是一种工作方法，而非某一款软件。纸板加便签可以实践 Kanban，电子工具也可以实践 Kanban；反过来，一个工具里存在“看板视图”，并不自动意味着团队在按 Kanban 方法工作。方法的核心在于规则是否被执行，尤其是 WIP 上限和拉动规则是否真正约束了团队的行为。
Kanban 包括什么、不包括什么
把 Kanban 的边界划清楚，能避免两种常见混淆：一是把任何任务列表都叫作看板，二是把 Scrum 的仪式和角色也算进 Kanban。下面按“属于方法本身”和“属于相邻实践或工具功能”两类对照说明。
| 类别 | 内容 | 说明 |
|---|---|---|
| 属于 Kanban 方法 | 列（流程阶段） | 列反映工作真实流经的步骤，是可视化的骨架 |
| 属于 Kanban 方法 | 卡片（工作项） | 承载任务信息，随流程从一列移动到下一列 |
| 属于 Kanban 方法 | 在制品上限 | 约束每列并行数量，是方法与普通列表的关键分界 |
| 属于 Kanban 方法 | 拉动式推进 | 下游有空位才从上游拉入新工作，而非上游持续推入 |
| 属于 Kanban 方法 | 流动观察 | 关注前置时间、周期时间、累积流等流动指标 |
| 不属于方法本身 | 固定迭代周期 | 属于 Scrum 等迭代式框架的组织方式 |
| 不属于方法本身 | 角色体系 | 如产品负责人、Scrum Master 等角色分工 |
| 不属于方法本身 | 估算与计划仪式 | 故事点估算、迭代计划会等属于相邻实践 |
| 不属于方法本身 | 工具功能 | 泳道、标签、自动化规则、报表样式等是工具能力 |
这张对照表的关键在于最后两行。看板工具通常提供泳道、标签、筛选、自动流转、统计图表等功能，这些功能让 Kanban 更容易落地，但它们本身不构成方法规则。判断一个团队是否在实践 Kanban，看的是列是否对应真实流程、WIP 上限是否被遵守、工作是否按拉动方式推进，而不是看工具里开了几个视图。
同样，固定迭代周期、角色体系和估算仪式可以出现在使用看板的团队中，但它们来自 Scrum 或其他框架，属于组合使用的结果。把 Kanban 理解为“必须没有迭代”或“必须取消估算”，是把边界推得过窄；准确的说法是，这些做法不属于 Kanban 方法的定义性规则，是否采用取决于团队的组织需要。
Kanban 如何运转：从卡片到交付的流动机制
理解 Kanban 的运转，可以沿着一个工作项的完整路径来看：进入看板、逐列流动、受上限约束、被观察和度量、最终交付。下面按这条路径拆解机制。
列的划分与卡片承载的信息
列的依据是工作真实流经的步骤，常见划分包括“待办、分析、开发、测试、完成”，也可以按团队实际流程调整为“需求池、就绪、进行中、评审、发布”。列的作用是让流程阶段可见，因此列应当对应工作状态的真实变化，而不是为了好看而增设。卡片承载的信息通常包括工作项标题、负责人、优先级、类型、阻塞标记和进入当前列的时间；信息量以“站在板前能判断下一步动作”为准。
在制品上限的设置逻辑与拉动式推进
WIP 上限的设置逻辑是：先观察每列当前的平均并行数量，再设定一个略低于该数量的上限，迫使团队暴露过载。上限可以按列设置，也可以按人设置，前者更常见。拉动式推进的含义是，当下游列出现空位时，才把上游的卡片拉入；如果下游已满，上游即使完成也不能继续推入。这样做的效果是把“多做一点”的冲动转化为“先清空下游”的动作，减少半成品堆积。
流动观察：前置时间、周期时间与累积流图
Kanban 用流动指标替代单纯的完成数量来观察健康度。前置时间指工作项从被提出到交付的总时长，周期时间指从开始处理到完成的时长，两者共同反映客户等待与团队处理效率。累积流图把各列的在制品数量按时间画成堆叠面积，带状区域变宽说明该环节堆积增加，是瓶颈的直观信号。这些指标的价值在于把“感觉忙”变成“看得见的等待和堆积”。
阻塞与瓶颈的呈现方式
阻塞通常以卡片上的标记、单独一列“阻塞”或红色标签呈现，让问题停留在板上而不是被口头带过。瓶颈则通过某列长期顶到 WIP 上限、累积流图对应带状区域持续变宽来暴露。团队在站会上优先讨论顶到上限的列和被标记阻塞的卡片，把改进动作落在流程环节上，而不是停留在个人催促上。
当团队把看板从纸面搬到协作工具中，工作项状态流转、卡片归属和滞留时间统计需要被连续记录。ONES 提供看板视图用于管理任务状态，并自动记录工作项滞留时间等过程数据，团队可以在同一处完成卡片流转与流动观察；ONES Project 支持自定义需求状态与属性，便于把列与真实流程阶段对应起来。这些能力承载的是管理动作，方法规则仍由团队自己设定和遵守。
Kanban 与 Scrum、任务列表的区别
Kanban 最容易被拿来与 Scrum 和普通任务列表比较。三者的差异集中在工作如何被组织、节奏如何确定、约束如何生效三个维度上。
| 对比维度 | Kanban | Scrum | 普通任务列表 |
|---|---|---|---|
| 工作组织方式 | 按流程阶段排列，持续流动 | 按固定周期组织，每周期交付增量 | 按条目罗列，状态简单 |
| 节奏来源 | 由流动和交付需求决定 | 由固定长度的迭代决定 | 无固定节奏 |
| 角色体系 | 方法本身不规定角色 | 规定产品负责人、Scrum Master 等角色 | 无角色规定 |
| 计划方式 | 按需补充，持续排优先级 | 迭代计划会确定本周期目标 | 通常按清单顺序处理 |
| 并行约束 | 以 WIP 上限约束在制品 | 以迭代容量约束承诺量 | 通常无并行约束 |
| 度量重点 | 前置时间、周期时间、累积流 | 迭代完成度、燃尽、速率 | 完成条目数量 |
与 Scrum 的差异可以概括为：Scrum 用固定周期和角色分工建立节奏，Kanban 用流动和上限建立节奏。Scrum 的起止规则明确，每个迭代有承诺和评审；Kanban 没有固定的迭代边界，工作项按拉动持续进入和交付。两者并非互斥，常见组合是在 Scrum 的迭代内使用看板管理任务状态和 WIP 上限，既保留迭代目标，又让日常流动可见。这种组合成立的条件是团队清楚哪些规则来自 Scrum、哪些来自 Kanban，避免把两套约束混成模糊的惯例。
与普通任务列表的差异更根本：任务列表通常只记录“要做什么”和“做没做”，没有列上限，也不关注工作在哪一步等待了多久。Kanban 要求列对应流程、上限约束并行、流动指标反映问题。一个贴满便签但没有上限的墙，本质上仍是任务列表的可视化版本；只有当上限和拉动规则被执行，它才成为 Kanban。
一个具体例子与常见误解
下面用一个内容团队的场景演示 Kanban 的完整运转。该团队负责文章从选题到发布，流程分为“选题、撰写、编辑、发布”四列，每列设置 WIP 上限：选题 5、撰写 3、编辑 2、发布 1。
某天看板状态如下：选题列有 4 张卡片，撰写列有 3 张（已达上限），编辑列有 2 张（已达上限），发布列有 1 张（已达上限）。此时一名作者完成了手头文章的初稿，准备把卡片从撰写移到编辑。由于编辑列已满，卡片不能进入，作者转而协助编辑列中的一篇稿件做事实核对，或等待编辑完成一篇后再拉动。与此同时，发布列已满，说明发布环节是当前瓶颈，团队在站会上决定当天优先处理发布前的最后检查，而不是继续从选题列补充新题目。
这个例子体现了三个机制：上限阻止了上游继续推入，拉动让下游空位决定上游动作，瓶颈通过“发布列长期满员”被识别。若没有上限，作者会把初稿直接推入编辑列，编辑列堆积到五六篇，每篇的等待时间拉长，团队却感觉一直在忙。
围绕 Kanban 有几个高频误解，值得逐条澄清。
- 误解一：看板就是贴满便签的墙。便签墙只是可视化载体。缺少列与流程的对应、缺少 WIP 上限和拉动规则时，它仍是任务列表。正确理解是：可视化是起点，上限和流动管理才是方法的核心。
- 误解二：看板必须配固定迭代。固定迭代属于 Scrum 等框架的组织方式，Kanban 本身按持续流动运转。团队可以在看板上叠加迭代周期，但这是组合选择，不是 Kanban 的定义要求。
- 误解三：列越多越细越好。列应当对应真实的状态变化。列过多会让卡片频繁移动却缺少实质进展，也会让 WIP 上限分散、难以约束。正确做法是先按主要阶段设列，等流程稳定后再按需要细分。
- 误解四：有了看板视图就是在用 Kanban。工具视图只是承载方式。方法是否成立，取决于团队是否遵守上限、是否按拉动推进、是否用流动指标改进流程。
这些误解的共同来源，是把 Kanban 的可视化外观当成了方法全部，忽略了上限与流动这两条约束。回到定义：Kanban 通过可视化让工作可见，通过 WIP 上限控制并行，通过流动管理发现并消除阻塞。把握住这三条，就能判断一个团队是在实践看板方法，还是仅仅把任务搬上了一块板。
常见问题
团队刚开始用 Kanban，WIP 上限应该怎么定？
建议先观察一到两周每列实际的平均并行数量，再设定一个略低于该值的上限，让过载先暴露出来。上限可以按列设置，也可以按人设置，按列更常见。初期不必追求精确，重点是把上限写进团队约定并真正执行：下游满员时上游停止拉入，团队转而处理下游堆积。运行一段时间后，再根据瓶颈位置和交付节奏调整数值。
Kanban 一定要取消估算和计划会吗？
不必。估算和计划会不属于 Kanban 方法的定义性规则，但也不被方法禁止。团队可以保留故事点估算或按需排优先级，只要这些做法不破坏列上限和拉动规则即可。是否保留取决于团队对可预测性和沟通成本的需要；如果估算带来的收益低于投入，可以简化，但这是团队选择，不是 Kanban 的硬性要求。
看板上的列应该按流程阶段划分，还是按人员划分？
优先按工作真实流经的流程阶段划分，例如“待办、分析、开发、测试、完成”，这样卡片移动对应的是工作状态的真实变化，瓶颈也更容易定位。按人员划分的列容易变成任务分配表，卡片移动反映的是“换人做”而非“工作推进”，WIP 上限也难以约束流程环节。如果团队需要同时看人员负载，可以用泳道或负责人字段表达，不必把人员做成列。
Kanban 和 Scrum 可以同时用吗？具体怎么组合？
可以。常见组合是在 Scrum 的固定迭代内使用看板管理任务状态和 WIP 上限：迭代计划会确定本周期目标，日常用看板观察卡片流动和阻塞，迭代评审时回看交付结果。组合成立的条件是团队清楚哪些规则来自 Scrum（迭代边界、角色、评审）、哪些来自 Kanban（列上限、拉动、流动指标），避免两套约束混成模糊惯例。如果团队交付节奏本身连续、需求随时进入，单独使用 Kanban 也可以。
用协作工具里的看板视图，就算在实践 Kanban 了吗？
工具视图只是承载方式。判断是否在实践 Kanban，看的是列是否对应真实流程、WIP 上限是否被遵守、工作是否按拉动方式推进、团队是否用流动指标改进流程。ONES 提供看板视图用于管理任务状态，并自动记录工作项滞留时间等过程数据，团队可以在同一处完成卡片流转与流动观察；ONES Project 支持自定义需求状态与属性，便于把列与真实流程阶段对应起来。这些能力承载管理动作，方法规则仍由团队自己设定和遵守。
