看板中的在制品限制（WIP限制，Work in Progress Limit）是对某一流程阶段或状态中同时存在的任务数量设定的上限，用来暴露流程拥堵、推动团队先完成再开始。它约束的是“正在处理但尚未完成”的工作数量，与任务总量、人员编制和工时上限属于不同层面的管理对象。理解它的定义、边界与作用机制，有助于判断自己的看板是否需要引入这一规则。
要点总览（TL;DR）
- 在制品限制（WIP限制）是对看板上某一流程阶段或状态中同时存在、尚未完成的工作项数量设定的上限，达到上限后不再从上游拉入新工作。
- 它约束的是同时处理的工作件数，不约束总需求、工时、人力编制，也不替代优先级排序和迭代计划。
- 限制通过拉动式流转起作用：下游有空余名额才拉入新工作，超限成为流程拥堵的显性信号，瓶颈随限制位置显现。
- WIP限制与任务上限、容量规划、迭代承诺量、阻塞标记、吞吐量指标在约束对象和统计时点上各不相同，不能混用。
- 限制值没有统一最优解，应结合环节处理能力分别设定；超限是改进线索，不宜当作处罚依据。
在制品限制的准确定义
在制品限制可以概括为一句话：为看板上某个流程阶段或状态设定一个同时容纳工作项的数量上限，达到上限后不再从上游拉入新工作。这个定义包含三个限定条件，缺一不可。
第一，限制施加在流程阶段或状态上，而非整个项目或整个团队。看板的每一列通常对应一个流程状态，例如“待开发”“开发中”“测试中”“待发布”。WIP限制挂在某一列或某几列上，约束的是停留在该列的工作项数量。第二，计数口径是“处于该状态且尚未完成”的工作项。一个工作项进入该状态即计入，离开该状态即释放名额，部分完成不释放名额。第三，限制的对象是数量，不是时长、不是人力、不是工作量。它回答的问题是“这一列最多同时放几个”，而不是“这一列最多花多少小时”或“这一列最多安排几个人”。
需要区分WIP限制与任务总量上限。任务总量上限约束的是一个周期内计划完成的工作项总数，例如一个迭代承诺二十项；WIP限制约束的是任意时刻同时处于处理中的工作项数量，两者统计的时间点和对象都不同。WIP限制也与人员数量无关，它不规定谁来做、做多久，只规定同时在做的事情有几件。
它约束什么、不约束什么
把边界划清楚，才能避免把WIP限制当成万能规则。它约束的是在制数量，以下内容不在其范围内。
- 不约束总需求。需求池里可以积累大量待办事项，WIP限制只作用于已经进入流程、处于处理中的工作项。上游待办再多，只要没有拉入受限状态，就不触发限制。
- 不约束工时与人力编制。它不规定每人每天工作几小时，也不决定团队配几个人。人力不足或工时安排属于容量管理的问题，WIP限制只反映同时处理的工作件数。
- 不替代优先级排序。达到上限后该拉入哪一项，仍需要依据优先级判断。WIP限制制造了“必须选择”的时机，选择本身依赖排序规则。
- 不涉及迭代计划与需求池维护。迭代范围怎么定、需求池如何整理和细化，属于计划与需求管理活动，WIP限制不介入这些决策。
容易混淆的一项是把WIP限制理解为“禁止多做”。它的实际含义是“超过上限时先停下来处理已有工作”，是一种节奏约束，而非对工作意愿的限制。另一项常见混淆是把限制值当成绩效指标，实际上限制值只是流程设计参数，需要随流程变化调整。
WIP限制如何起作用
WIP限制的作用通过三个相互关联的机制实现：达到上限后停止拉入、超限作为问题信号、瓶颈随限制位置显现。
先看拉动式流转。传统推动方式下，上游完成一项就推给下游，下游积压与否不受控制。设置WIP限制后，流转变成拉动式：下游状态有空余名额时，才从上游拉入新工作；名额已满，上游完成的工作停留在原地等待。这一规则把“先完成再开始”从口号变成可执行的约束，团队在同一时刻专注的工作项数量被限制在设定值以内。
再看超限信号。当某一状态的工作项数量达到或超过上限，说明该环节的处理速度跟不上流入速度，流程在此处出现拥堵。这个信号是显性的、可观察的，团队在看板上就能看到某一列堆满。此时正确的反应是分析拥堵原因——是任务拆解过粗、是等待外部输入、还是该环节人手不足——而不是简单提高上限把问题掩盖过去。
最后看瓶颈暴露。瓶颈是限制整体流速的那个环节。把WIP限制设在瓶颈环节之前，可以防止上游继续向瓶颈灌入工作；设在瓶颈环节本身，可以让瓶颈的排队情况一目了然。限制位置的选择决定了团队能观察到哪一段流程的压力，通常建议先在疑似瓶颈处设置，再根据观察结果调整。
在实际的迭代推进中，团队通过看板管理任务状态，每日站会借助看板对齐进度与风险。当看板上的状态列与工作项流转被系统承载时，状态停留情况可以被记录和统计。ONES 的敏捷研发管理方案支持通过敏捷看板管理任务状态，并自动记录工作项滞留时间等过程数据，团队可以据此观察哪些状态容易堆积，为设置和调整数量约束提供依据。需要说明的是，是否为某一状态配置数量上限并在超限时提示，属于具体工具配置层面的问题，选型时应向官方确认。
与相邻概念的区别
WIP限制常与几个相邻概念混用，下表按同一口径对照说明。
| 概念 | 约束对象 | 作用时点 | 主要用途 |
|---|---|---|---|
| WIP限制 | 某一状态同时存在的工作项数量 | 任意时刻 | 控制并行度，暴露流程拥堵 |
| 任务上限 | 一个周期内计划完成的工作项总数 | 周期开始前设定 | 控制范围，避免过度承诺 |
| 容量规划 | 可投入的人力与工时 | 计划阶段 | 判断能承接多少工作 |
| 迭代承诺量 | 一个迭代内团队承诺交付的范围 | 迭代计划时确定 | 形成交付预期 |
| 阻塞标记 | 单个工作项的受阻状态 | 发生时标注 | 提示单项工作无法推进 |
| 吞吐量指标 | 单位时间完成的工作项数量 | 事后统计 | 度量流程产出能力 |
WIP限制与任务上限的区别在于统计口径：前者看同时处理的数量，后者看周期内计划的总量。与容量规划的区别在于对象：容量规划管人和工时，WIP限制管工作件数。与迭代承诺量的区别在于性质：承诺量是交付预期，WIP限制是流程约束。与阻塞标记的区别在于粒度：阻塞标记针对单个工作项，WIP限制针对整个状态。与吞吐量指标的区别在于方向：吞吐量是事后度量的结果，WIP限制是事前设定的规则，二者可以配合使用——限制并行度往往有助于稳定吞吐量，但吞吐量本身不由限制值直接决定。
一个具体例子与常见误解
以下为演示性示例，用于说明限制生效的过程，不指向任何真实团队。
假设某团队的看板设有“开发中”和“测试中”两列，“测试中”的WIP限制设为三项。当前测试中已有三项工作，名额已满。此时开发人员完成了一项新功能，按规则不能直接推入测试中，该项停留在“开发中”列等待。团队在站会上看到测试列已满，转而协助测试环节排查积压原因，发现其中一项在等待环境准备。问题解决后，一项工作完成并离开测试列，名额释放，开发中等待的那项才被拉入测试。整个过程没有增加任何人手，但团队在同一时刻集中处理的工作件数受到控制，积压原因也被及时暴露。
围绕这个机制，有三种常见误解需要纠正。
- 误解一：限制越少越好。限制值过低会让流程频繁停摆，工作项大量堆在上游等待，整体流速反而下降。限制值应结合该环节的实际处理能力和工作项粒度确定，并随观察结果调整，不存在统一的最优值。
- 误解二：超限即违规处罚。超限是流程信号，不是个人过失。它的价值在于提示团队检查拥堵原因，把超限当作处罚依据会促使成员隐瞒积压或绕过规则，信号随之失效。
- 误解三：所有阶段必须设同一数值。各环节的处理能力不同，瓶颈环节与辅助环节的合理上限也不同。统一数值看似整齐，实际可能让瓶颈处限制过松、让快速环节限制过紧。限制值应分别设定，并优先覆盖瓶颈及其上游。
判断自己的看板是否适用WIP限制，可以先观察是否存在明显的状态堆积和频繁的上下文切换。如果团队已经在为“同时做太多事”付出代价，引入数量约束并把超限当作改进线索，是一个值得尝试的起点。
常见问题
WIP限制设了以后，上游完成的工作一直拉不进来怎么办？
这是限制生效时的正常状态，处理方向是疏通下游而非取消限制。先看受限状态里堆积的工作卡在哪个环节：是任务拆解过粗、在等外部输入，还是该环节处理能力确实不足。找到原因并解决后，工作项离开受限状态、名额释放，上游等待的工作自然被拉入。如果长期频繁出现上游大量等待，说明限制值可能低于该环节的实际处理能力，可以结合观察结果适度上调，再继续观察。
团队刚开始用看板，需要马上给每一列都设WIP限制吗？
不必一次铺满。更稳妥的做法是先观察一段时间，找出经常堆积、排队明显的状态，从疑似瓶颈及其上游开始设置。限制值可以先按当前实际并行数量略作收紧，运行一两周后根据等待和拥堵情况调整。各列处理能力不同，限制值也应分别设定，统一数值容易让瓶颈处过松、快速环节过紧。
WIP限制和迭代承诺量会冲突吗？
两者作用层面不同，通常可以并存。迭代承诺量确定一个迭代内团队计划交付的范围，回答“这个迭代做多少”；WIP限制约束任意时刻同时处理的工作件数，回答“同时最多做几件”。承诺量偏大时，WIP限制会让工作分批进入处理状态，交付节奏更平稳。如果承诺量长期明显超出团队处理能力，问题出在计划环节，需要回到迭代范围本身调整，单靠收紧WIP限制解决不了。
超限时应该先提高限制值，还是先查原因？
建议先查原因。超限说明流入速度超过了该环节的处理速度，常见原因包括任务拆得过粗、等待外部评审或环境、该环节人手不足。把原因处理掉，限制值往往不需要动。如果排查后确认是限制值本身设得过紧，再上调也不迟。反复用提高上限的方式消除超限信号，会让看板失去暴露拥堵的作用。
用ONES的看板管理任务状态，能观察到哪些有助于设置限制的过程信息？
ONES 的敏捷研发管理方案支持通过敏捷看板管理任务状态，并自动记录工作项滞留时间等过程数据，团队可以据此观察哪些状态容易堆积，为设置和调整数量约束提供依据。是否为某一状态配置数量上限并在超限时提示，属于具体工具配置层面的问题，选型时建议向官方确认。
