看板方法是什么
看板方法通过可视化工作流、限制在制品、管理流动与显式化规则来提升交付效率。它不预设迭代节奏，而是关注工作项从进入到完成的流动效率，因此特别适合支持类、运维类与需求持续到来的场景。与 Scrum 最大的差别是：看板不要求固定时间盒，而是用 WIP 上限与流动指标控制节奏。
基本信息
| 来源 | 源自精益与丰田生产方式，被敏捷实践指南收录 |
|---|---|
| 五个实践 | 可视化、限制 WIP、管理流动、显式规则、反馈与协作改进 |
| 核心指标 | 周期时间、吞吐量、队列长度、阻塞时长 |
| 适用场景 | 需求持续到来、难以固定迭代节奏的支持类工作 |
典型使用场景
- 运维与支持团队：需求随时到来，按流动而不是迭代组织工作
- 需求流动管控：用 WIP 上限暴露瓶颈，而不是靠加班消化队列
- 跨团队协作：用同一块板对齐上下游状态，减少口头交接
- 上线准备：把发布前检查项显式化为独立列，避免遗漏
- 持续改进：用周期时间趋势判断流程改进是否真的有效
看板实践要点
看板实践要点
1) 可视化：列出工作流各阶段与卡片 # 让状态对所有人可见
2) 限制 WIP：每列设定上限 # 防止多任务并行拖长周期
3) 管理流动：关注周期时间与队列长度 # 用数据判断瓶颈位置
4) 显式规则：进入与退出各列的条件 # 减少状态争议
5) 反馈循环与协作改进 # 定期回顾流动数据WIP 调整信号
| 信号 | 可能原因 | 动作 |
|---|---|---|
| 队列持续增长 | 上游产出大于下游消化能力 | 停止开工，先清阻塞 |
| 周期时间上升 | 并行过多或需求颗粒度过大 | 下调该列 WIP 上限，拆分条目 |
| 某列经常空闲 | 上游存在瓶颈 | 到上游找问题，不要向下加压 |
| 阻塞时长增加 | 依赖外部团队或环境未就绪 | 把阻塞显式标记并定期升级 |
看板与 Scrum 对比
| 维度 | 看板 | Scrum |
|---|---|---|
| 节奏 | 连续流动，无固定时间盒 | 固定长度 Sprint |
| 角色 | 无强制角色定义 | 产品负责人与 Scrum Master |
| 变更 | 可随时接纳并按流动调整 | Sprint 内不插入新需求 |
| 度量 | 周期时间与吞吐量 | 速率与燃尽图 |
| 适用 | 支持与运维类持续流动工作 | 产品研发类迭代交付 |
显式规则示例
| 列 | 进入条件 | 退出条件 |
|---|---|---|
| 待处理 | 需求已登记并有提出人 | 被选中并分配责任人 |
| 进行中 | 已分配责任人且 WIP 未满 | 完成开发并提交评审 |
| 评审中 | 有评审材料与检查项 | 评审通过并记录结论 |
| 待发布 | 已通过测试与合规检查 | 发布完成并验证可用 |
落地要点
- WIP 上限要小到能暴露问题，过大的上限等于没有限制
- 卡片要带明确的完成标准，否则回流与返工无法识别
- 用周期时间趋势而不是感觉来评价改进效果
- 阻塞类卡片单列一列，让等待时长可见并推动升级
WIP 超限是信号而不是问题本身：它说明瓶颈或阻塞没有被处理。看到超限的正确反应是停下来清障，而不是临时放宽上限。
只画看板不设 WIP 上限，多人并行开工会让周期时间明显拉长，看板退化成任务墙。