Kanban（看板方法）是一种以可视化工作流、限制在制品数量和管理流动为核心的工作管理方法。它把工作项按流程状态摆到看板上，让团队看清每项工作处在哪一步、哪里堆积、下一步该拉动什么。Kanban不规定固定迭代节奏，也不预设角色和会议，重点在于让价值持续、平稳地流经整个流程。本文围绕定义、边界、运转机制、与Scrum的区别以及常见误解展开，帮助读者判断这套方法是否适合自己团队。
要点总览（TL;DR）
- Kanban（看板方法）是一套以可视化工作流、限制在制品数量和管理流动为核心的工作管理方法，起源于制造业看板信号系统，后演化为知识工作方法。
- Kanban管理的是工作的流动过程，不预设固定迭代、角色和会议；需求优先级来源、组织治理与考核不属于Kanban本身。
- 看板由列、卡片、在制品限制、拉动规则和流动度量配合运转，列对应真实流程步骤，在制品上限用于暴露瓶颈。
- Kanban以持续流动为中心，Scrum以固定Sprint为中心；两者可以组合，例如用Scrum组织迭代、在迭代内用看板管理任务状态。
- 常见误解包括把看板等同于贴任务、认为列越多越专业、认为Kanban等于没有计划；Kanban的计划围绕流动能力展开。
Kanban的直接定义
Kanban的中文通常译为“看板”，在知识工作语境下指一套管理价值流动的方法。一个可以直接引用的定义是：Kanban是一种通过可视化工作流、限制各环节在制品数量、并对流动过程进行度量和改进的工作管理方法。它关注工作从开始到交付的完整路径，通过让流程状态可见、让并行工作量受控，使团队能够识别瓶颈并缩短交付周期。
这个定义包含三个相互配合的核心要素：
- 可视化工作流：把团队实际经历的流程步骤画成列，把每一项工作写成卡片放到对应列中，使工作状态、数量和阻塞情况一目了然。
- 限制在制品数量：为每个流程环节设定同时进行的工作上限，避免任务在某一环节大量堆积，迫使团队先完成再开始。
- 管理流动：持续观察工作在各环节的停留时间和通过速度，找出等待、返工和瓶颈，并通过调整流程规则改善整体流动。
Kanban起源于制造业的看板信号系统，早期用于生产线上以卡片传递“可以补充物料”的信号，实现按需拉动生产。后来这一思路被引入软件开发与知识工作领域，演化为以看板承载工作项、以列表示流程状态、以在制品限制控制节奏的管理方法。在知识工作中，看板不再传递物料补货信号，而是传递“某项工作可以进入下一环节”的拉动信号。
Kanban的边界：它管什么、不管什么
理解Kanban的边界，有助于避免把相关管理活动都算作Kanban本身。Kanban管理的对象是工作的流动过程，它通过可视化、在制品限制和流动度量，帮助团队看清工作如何从进入流程走到完成。它不用于评价个人的忙碌程度或产出高低，卡片在列之间的移动反映的是工作状态，而非人员绩效。
以下清单区分了属于Kanban方法范围的内容与不属于其本身的内容：
| 范围 | 内容 | 说明 |
|---|---|---|
| 属于Kanban | 可视化工作流 | 用列和卡片呈现流程状态与工作项 |
| 属于Kanban | 在制品限制 | 为环节设定并行工作上限 |
| 属于Kanban | 流动度量与改进 | 观察周期时间、吞吐量、阻塞情况并调整流程 |
| 属于Kanban | 拉动式流转规则 | 下游环节有能力时才拉入新工作 |
| 不属于Kanban本身 | 固定迭代节奏 | Kanban不强制按Sprint组织工作，团队可按需引入 |
| 不属于Kanban本身 | 预设角色与固定会议 | 不规定产品负责人、Scrum Master等角色，也不规定站会、评审会等会议形式 |
| 不属于Kanban本身 | 具体工具或软件 | 物理白板与看板软件都是承载方式，工具不等于方法 |
| 不属于Kanban本身 | 需求优先级来源 | 哪些工作进入看板、按什么顺序进入，由需求管理和业务决策决定 |
| 不属于Kanban本身 | 组织治理与考核制度 | 汇报关系、绩效制度、预算与编制属于组织管理范畴 |
需要说明的是，Kanban不强制迭代、角色和会议，团队仍然可以根据自身情况引入固定节奏或明确职责，这些做法与Kanban并不冲突，只是它们来自团队的其他管理选择，而非Kanban方法的强制要求。同样，看板软件提供列、卡片、筛选和报表等功能，这些功能是方法的承载工具，判断一个团队是否在用Kanban，关键看它是否可视化流程、限制在制品并持续管理流动。
Kanban如何运转：看板、列与在制品限制
Kanban的运转依赖几个基本组成部分的配合：看板承载整体视图，列表示流程状态，卡片承载工作项，在制品限制控制各环节的并行量，拉动规则决定工作何时进入下一环节，流动度量则用于判断流程是否健康。
看板与列代表流程状态
列应当对应团队真实经历的流程步骤，例如“待处理—分析—开发—测试—完成”。列的名称和数量来自实际工作方式，而不是照搬模板。工作项只有满足进入条件时才移动到下一列，列与列之间的交接规则越清晰，流动越顺畅。
工作项卡片承载的信息
卡片是工作项在看板上的载体，通常包含标题、类型、负责人、优先级、创建时间、阻塞标记等字段。卡片信息的作用是让团队成员在不打开详细文档的情况下判断这项工作是什么、由谁负责、是否被阻塞。卡片上的字段应服务于流动管理，字段过多会增加维护负担。
在制品限制的作用与设置思路
在制品限制为每个环节设定同时进行的工作数量上限。当某一列达到上限时，团队不再从上游拉入新工作，而是集中处理该列的现有工作。这一规则的作用是暴露瓶颈：如果“测试”列经常达到上限，说明测试环节的通过能力不足，需要补充资源、调整流程或减少上游投入。设置上限时可以从当前实际并行量出发，先设定一个略低于现状的数字，观察阻塞和等待情况后再逐步调整。
拉动式流转与流动度量
拉动式流转指下游环节在有能力处理时才从上游拉入工作，而不是由上游不断推送。配合在制品限制，拉动规则让工作按流程能力进入，减少堆积。流动度量常用的指标包括周期时间（一项工作从开始到完成所经历的时间）和吞吐量（单位时间内完成的工作项数量）。团队通过观察这些指标的变化，判断流程改进是否有效。
一个最小看板结构示例
以下是一个缺陷修复团队的最小看板结构，列名与在制品上限仅为示例，实际设置应结合团队情况调整：
| 列 | 含义 | 在制品上限（示例） |
|---|---|---|
| 待处理 | 已确认但尚未开始修复的缺陷 | 不设上限或设较高上限 |
| 分析中 | 正在定位原因、评估影响 | 3 |
| 修复中 | 正在修改代码 | 4 |
| 验证中 | 等待或正在回归验证 | 3 |
| 已完成 | 验证通过并关闭 | 不设上限 |
在这个结构中，当“验证中”达到上限时，团队应优先完成验证工作，而不是继续从“修复中”拉入新缺陷。这样做的结果是验证环节的等待时间更容易被看见，团队可以据此决定是否增加验证人手或调整修复节奏。
在实际落地时，看板方法需要工具承载列、卡片和状态流转。ONES Project 提供看板视图，支持自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人；团队在迭代过程中通过敏捷看板管理任务状态，在每日站立会议中借助看板对齐进度与风险。ONES 系统还会记录工作项滞留时间等过程数据，为观察流动情况提供依据。需要核验的是，看板列的在制品上限配置以及周期时间、吞吐量等流动指标的现成报表，是否满足团队的具体管理口径，选型时可向厂商确认。
Kanban与Scrum的区别
Kanban和Scrum都是常见的敏捷工作方法，但两者的组织方式不同。Kanban以持续流动为中心，Scrum以固定长度的迭代为中心。下面的表格按同一组维度对比两者的框架特征，帮助读者区分概念，不涉及优劣判断。
| 对比维度 | Kanban | Scrum |
|---|---|---|
| 节奏 | 持续流动，不强制固定迭代 | 以固定长度的Sprint组织工作 |
| 角色 | 不预设角色 | 预设产品负责人、Scrum Master和开发团队等角色 |
| 会议 | 不规定固定会议 | 包含Sprint规划、每日站会、评审和回顾等会议 |
| 变更方式 | 可在流程能力允许时持续引入新工作 | 通常在Sprint内控制范围变更，下个Sprint再调整 |
| 度量重点 | 周期时间、吞吐量、在制品数量、阻塞情况 | 迭代目标达成、增量交付、燃尽情况 |
| 工作项组织 | 按流程状态列组织，工作项持续进入和流出 | 按Sprint待办列表组织，一个Sprint内完成一组工作 |
两者可以组合使用。例如团队采用Scrum的迭代节奏和角色分工，同时在迭代内部用看板管理任务状态并设置环节在制品上限，以改善迭代内的流动。ONES 支持经典的 Scrum 研发场景，也提供看板视图用于任务状态管理和进度对齐，这种组合在工具层面可以同时承载。选择哪种方式，取决于团队面对的工作类型：需求持续到达、优先级频繁变化的支持类或运维类工作，通常更适合以流动为中心的Kanban；需要定期交付增量、强调跨职能协作的产品开发，可能更适合Scrum或两者结合。
具体例子与常见误解
下面用一个缺陷修复团队的场景说明Kanban如何实际运转，并澄清三个常见误解。
场景示例：缺陷修复团队使用看板
某产品团队每周收到若干缺陷报告，过去由测试人员直接分配给开发人员，开发人员手上同时处理多个缺陷，导致修复完成时间难以预测。引入Kanban后，团队做了以下动作：
- 把缺陷流程画成“待处理—分析中—修复中—验证中—已完成”五列，明确每一列的进入条件，例如缺陷必须复现并记录影响范围才能进入“分析中”。
- 为“分析中”“修复中”“验证中”分别设置在制品上限，当某一列满额时，团队成员不再拉入新缺陷，而是协作处理该列现有工作。
- 每天站会围绕看板进行，重点看哪些卡片停留时间过长、哪些卡片被阻塞，并当场决定处理方式。
- 每周记录一次各列的平均停留时间和完成数量，观察调整上限后周期时间是否缩短。
运行一段时间后，团队发现“验证中”经常满额，说明验证能力是瓶颈，于是安排开发人员在提交修复前完成自测，并调整验证排期。这个例子的可迁移之处在于：先让流程可见，再用在制品限制暴露瓶颈，最后用流动数据验证改进效果。
误解一：看板就是把任务贴在墙上
把任务贴到白板或录入看板软件，只是可视化的第一步。Kanban还包括为环节设置在制品限制、建立拉动规则、持续观察流动指标并改进流程。缺少这些规则，任务墙只能显示状态，无法帮助团队控制并行量和识别瓶颈。
误解二：列越多越专业
列的数量应反映团队真实经历的流程步骤。列过多会让卡片频繁移动、增加维护成本，也会模糊真正的瓶颈所在；列过少则可能掩盖等待和返工。合理的做法是从当前实际流程出发设置列，随着流程变化再调整，而不是追求列的数量。
误解三：Kanban等于没有计划
Kanban不强制固定迭代，但并不意味着不做计划。团队仍然需要决定哪些工作进入看板、按什么顺序处理、各环节投入多少能力。区别在于，Kanban的计划围绕流动能力展开：根据在制品上限和吞吐量判断能承接多少工作，根据周期时间预估交付时间，而不是把工作打包进固定周期的承诺中。
常见问题
团队已经在用Scrum，还需要单独引入Kanban吗？
不一定需要单独引入。Kanban的要素可以作为Scrum迭代内部的补充：在Sprint内用看板呈现任务状态，为分析、开发、测试等环节设置在制品上限，观察卡片停留时间，从而改善迭代内的流动。这种做法保留Scrum的迭代节奏和角色分工，同时借助看板暴露瓶颈。是否引入取决于团队当前的问题：如果迭代内任务堆积、状态不透明，补充看板规则通常有帮助；如果流动已经顺畅，则不必额外增加管理动作。
在制品上限设多少合适？设错了怎么办？
没有统一数值。常见做法是从团队当前的实际并行量出发，先设定一个略低于现状的上限，观察一两周内各列的阻塞和等待情况，再逐步调整。上限过低会让环节频繁空闲，上限过高则起不到暴露瓶颈的作用。调整时以周期时间和吞吐量的变化作为参考，而不是追求某个标准数字。上限本身也是流程规则的一部分，团队应共同商定并定期回顾。
需求持续到达、优先级经常变化的工作，用Kanban要注意什么？
这类工作适合以流动为中心的管理方式，但需要额外明确两件事：一是哪些工作可以进入看板，避免看板变成无限制的收件箱；二是进入顺序由谁决定、依据什么决定。Kanban本身不负责需求优先级的来源，这部分需要与需求管理流程衔接。此外，在制品上限在这类场景中尤其重要，它能防止团队同时承接过多工作而导致整体交付变慢。
看板软件里的看板视图，和Kanban方法是一回事吗？
两者不等同。看板软件提供列、卡片、状态流转和报表等功能，是方法的承载工具；Kanban方法的核心在于是否可视化真实流程、是否限制在制品数量、是否持续观察并改进流动。只把任务录入工具而不设上限、不看流动数据，仍然只是任务列表。选型时可以关注工具是否支持自定义状态、能否记录工作项滞留时间等过程数据，具体能力以厂商说明为准。
Kanban没有固定会议，团队靠什么同步进度？
Kanban不规定会议形式，团队可以自行安排同步方式。常见做法是每天围绕看板做一次简短同步，重点看哪些卡片停留过久、哪些被阻塞、在制品上限是否触发，并当场决定处理方式。同步的频率和时长由团队根据工作节奏决定。需要区分的是，这类同步是团队的管理选择，并非Kanban方法的强制要求。
