敏捷开发 - 面向过程管理：Kanban 方式
敏捷开发 - 面向过程管理：Kanban 方式
看板（Kanban）源自丰田的精益制造实践，核心是「准时化」（Just In Time, JIT）：让正确的物资在正确的时间流动到正确的地方，数量刚刚好。本文介绍看板的定义与核心实践，说明它在软件研发中的落地方式，并对比它与 Scrum 的差异。
什么是看板
看板一词来自日文，本义是「可视化卡片」。在精益制造中，看板的实质是：后道工序在需要时，通过看板向前道工序发出信号——给我需要数量的输入；前道工序只有收到看板后，才按需生产。信号由下游向上游传递，拉动上游生产，使产品向下游流动，拉动的源头是最下游的客户需求。
丰田生产方式有两大支柱：准时化与自働化。准时化强调「在需要的时间、生产需要数量的必要产品」；自働化则指设备发现异常时能自动停机（日语「働」带人字旁，寓意把人的智慧赋予机器），从源头杜绝不合格品流入下一环节。二者共同指向「内建质量」——质量在每一个环节就被保证，而不是依赖最后的检测。看板正是运营这一系统的核心工具。
拉动系统与准时化
看板形成拉动（Pull）系统，各环节仅在需要的时间生产需要数量的产品，从而降低库存甚至实现零库存。库存即「在制品」（Work In Progress, WIP）——已经开始但尚未完成的工作。降低库存带来的直接收益：
- 降低成本：库存减少提高运营现金使用率，降低管理与仓储开销。
- 缩短交付周期：减少工序间排队等待，缩短从开始到交付的周期。
- 提高灵活性：低库存下更容易调整生产计划。
更重要的一点是：降低库存能暴露问题。可以用「湖水与岩石」来理解——水位代表库存，岩石代表问题；水位高时问题被掩盖，水位降低后，设备不良、停工等待、质量问题、瓶颈过载都会显现出来。暴露问题是解决问题的前提。
从制造到软件研发
软件研发与制造有本质差异，不能照搬精益制造：
| 维度 | 产品制造 | 产品开发 |
|---|---|---|
| 工作对象 | 可见的物理产品 | 抽象、不可见的信息 |
| 单个任务时长 | 固定、可精确预测 | 每个任务都不同，难以预测 |
| 延期成本 | 各任务大致相同 | 差别很大 |
| 对可变性的态度 | 消除可变性以提高质量 | 可变性是价值的一部分，需通过试错验证 |
正因为价值流不可见、任务时长不确定，软件开发更依赖「可视化」与「更灵活的队列管理」。
看板的核心实践
看板方法形式多样，但都遵循以下核心实践。
可视化价值流
把工作流画成「看板墙」：每一张卡片代表一个价值项（需求、缺陷、技术验证等），每一列代表一个阶段。卡片从左到右流动，每经过一个阶段就注入新信息、价值随之增加。用醒目的颜色标记阻塞项，推动阻碍解决。瓶颈通常表现为最长的队列，找到最长的队列就找到了系统瓶颈。
可视化是起点：它把抽象、不可见的信息工作变成具体、可讨论的对象。只有先把价值流动画出来，团队才能看清「价值在哪个环节停住」，进而谈优化与改进。
显式化流程规则
「流转规则」定义一个价值项从一个阶段进入下一阶段必须满足的标准（相当于各阶段的就绪定义与完成定义）。把规则显式化，一方面让质量内建于各阶段，另一方面为「持续改进」提供依据——没有显式规则，改进讨论就容易变得主观随意。
限制在制品数量（WIP Limit）
列标题右侧的数字表示该阶段允许的在制品上限。只有当某阶段的在制品数低于上限时，才允许从上游拉入新工作。这形成与精益制造类似的拉动机制，好处是：
- 加速价值流动：减少阶段间排队等待，缩短交付周期。
- 暴露问题：让被高 WIP 掩盖的协作不良、需求定义错误、资源失衡等问题显现。
需要强调：没有限制在制品数量，就不成其为看板。许多号称使用看板的团队恰恰省略了这一核心机制，自然拿不到上述收益。
从协作角度看，限制 WIP 还能自发地激发协作：当测试环节达到上限、无法从上游拉入新工作时，上游开发环节很快也会到达上限，于是开发不得不关注下游的阻塞并主动协助——瓶颈由此被暴露，也被跨环节的协作所推动解决。
度量与管理流动
快速、顺畅的价值流动是看板的目标：快速流动带来快速产出与反馈；顺畅流动意味着稳定、可预测的交付能力。度量是为改进提供方向与反馈的手段，而非目的。
流动效率与度量指标
常见的流动度量指标如下：
| 指标 | 英文 | 含义 |
|---|---|---|
| 在制品 | WIP | 已开始但尚未完成的工作项数量 |
| 周期时间 | Cycle Time | 一个工作项从「开始」到「完成」所花的时间 |
| 前置时间 | Lead Time | 从一个工作项进入系统到交付的时间 |
| 吞吐量 | Throughput | 单位时间内完成的工作项数量 |
| 流动效率 | Flow Efficiency | 真正产生价值的时间 / 总前置时间 |
累积流量图（Cumulative Flow Diagram, CFD） 是看板最常用的度量工具：用两条斜线分别表示「累积已开始」与「累积已完成」的工作项数量，两条线的垂直距离即在制品总量，水平间距即周期时间，斜率即吞吐量。通过 CFD 可以直观看出 WIP 上升、周期时间变长等趋势，从而验证「限制 WIP 能缩短周期时间」这类假设。
读懂累积流量图的关键，是看三条信息：两条斜线的垂直距离（在制品总量）、水平间距（周期时间）与斜率（吞吐量）。当 WIP 持续上升而斜率不变时，说明团队在「堆任务」而不是「多交付」，周期时间随之变长——这正是需要收紧 WIP 上限的信号。
需要注意的是，周期时间的下降往往略滞后于 WIP 的下降——只有已积累的队列被处理完后，交付周期的改进才会显现出来。
看板与 Scrum 的区别
Kanban 与 Scrum 看起来相似，实则差别明显：
| 维度 | Scrum | Kanban |
|---|---|---|
| 节奏 | 固定长度的 Sprint（2–4 周） | 连续流动，无固定迭代 |
| 角色 | 有 Product Owner、Scrum Master 等定义角色 | 不强制定义角色 |
| 变更 | Sprint 内通常不接受需求变更 | 随时可拉入新工作（受 WIP 限制） |
| 度量 | 速度（Velocity）、燃尽图 | 周期时间、吞吐量、累积流量图 |
| 核心机制 | 时间盒（Time-box） | 限制在制品数量 |
| 改进方式 | 回顾会议 | 持续改进 |
一句话概括：Scrum 以时间盒驱动，Kanban 以流动与 WIP 限制驱动。
Scrumban
有的团队把两者糅合成 Scrumban：既保留 Scrum 的固定 Sprint 与角色概念，又吸收 Kanban 的「关注流动」与「限制 WIP」原则。但对刚接触敏捷的团队，建议先掌握 Scrum 或 Kanban 中的一种，熟练后再按团队特点融合，避免一开始就混用导致两种机制都落不了地。
选择哪一种，取决于团队面临的主要矛盾：需求相对稳定、希望有明确节奏与规划，则 Scrum 更合适；需求零散、以持续响应和支持为主（如运维、客服型团队），则 Kanban 的连续流动更自然。
落地要点与常见坑
- WIP 上限必须真实生效：设置了上限却随意突破，等于没有限制。
- 先可视化，再优化：没有可视化的价值流，讨论改进无从下手。
- 拿最长队列找瓶颈：改善端到端流速，必须从瓶颈入手。
- 流转规则要落到卡片上：就绪与完成的定义写清楚，便于团队对齐。
- 度量服务于改进：不要为度量而度量，指标应由目标与现状决定。
小结
- 看板源于精益制造的拉动系统，核心是准时化与暴露问题。
- 四大核心实践：可视化价值流、显式化规则、限制在制品数量、度量与管理流动。
- 限制 WIP 是看板的标志性机制，没有它就不是看板。
- 与 Scrum 的最大差异在于「时间盒」与「限制 WIP」；两者可按需融合为 Scrumban。
- 流动效率与周期时间、吞吐量等指标，是衡量改进成效的依据。