WIP 上限解决什么问题
WIP 上限是对看板各状态并行工作量的显式约束。它不承诺让团队更快，而是通过限制并行、暴露瓶颈来缩短周期时间——同时推进的事项越多，切换损耗与排队等待越严重。设定方法常见三类：从现状实际在制量逐步下调、按人数与有效并行系数估算容量、以瓶颈环节的吞吐反推上游上限。数值不是一次定死，要结合回顾中的阻塞与等待数据迭代校准。
基本信息
| 经验法 | 从当前实际在制量逐步下调，每次一两项并观察 |
|---|---|
| 容量法 | 人数乘以有效并行系数，把协作损耗计入 |
| 瓶颈法 | 以瓶颈工序的吞吐反推上游各状态上限 |
| 调整周期 | 结合回顾中的阻塞与等待数据校准 |
| 配套规则 | 拉动规则、紧急插单让路方式、超限处理 |
典型使用场景
- 团队同时推进事项过多、频繁切换导致周期时间拉长时引入上限
- 交付延误集中在评审或测试等待，用上游上限约束投放速度
- 缺陷修复与需求开发混流，为缺陷单独设上限避免冲击交付节奏
- 版本发布或业务高峰前临时下调上限，优先保证交付质量
- 新成员加入或跨团队协作增多时先降上限，稳定后再逐步放开
常见设定路径
常见设定路径
# 1 记录当前各状态实际在制量，作为基线
# 2 先把上限设在略低于基线的位置，观察一周
# 3 出现阻塞时优先协作清障，而不是提高上限
# 4 回顾中用周期时间与等待数据判断是否调整
# 5 上限的例外要有记录，事后复核是否长期超限设定方法对比
| 方法 | 适用范围 | 注意点 |
|---|---|---|
| 经验法 | 缺少历史数据的新团队 | 下调幅度要小，避免一次压死 |
| 容量法 | 人员与技能构成明确的团队 | 有效并行系数要按团队实际校准 |
| 瓶颈法 | 存在明显瓶颈工序的流程 | 瓶颈移动后需重新测算 |
| 回顾校准 | 已进入稳定运行的团队 | 每次只调一处，便于归因 |
WIP 上限的目的是暴露问题并推动协作：数值需要迭代校准，直接照搬其他团队的模板往往不适配。
上限形同虚设、超额就口头放行，会让在制量悄悄回到原点，周期时间也随之回到原水平。