研发看板的在制品上限没有通用数值，确定它需要三步：先统计每个看板列近几周的实际并行数量和停留时间，得到基线；再以略低于现状的值设第一版列级上限，并让上下游列通过空位联动形成拉动；运行两到四周后，用停留时间、阻塞时长和交付节奏判断偏松还是偏紧，逐步调整。上限按列设置、由团队协商确定，并保留变更记录，才能避免它变成墙上的一个数字。
要点总览（TL;DR）
- 先统计每个看板列近2–4周的平均并行工作项数量、平均停留时间和阻塞占比，形成基线表并记录统计口径，作为后续所有判断的参照。
- 第一版上限按列设置，取略低于现状并行数的值，瓶颈列优先收紧；下游列有空位时上游才允许拉动，超限时按约定规则排队、协助或拆分。
- 上限由团队共同协商确定，团队负责人推动规则落地，看板管理员或迭代负责人维护列配置与超限记录，调整需记录原因与生效时间。
- 运行两到四周后用停留时间、阻塞时长和交付节奏判断偏松偏紧，每次只调整一到两列，观察两到四周再评估。
- 上限长期无人触碰、超限无处理动作、数据不再更新即已形式化，回到测量现状重新校准一轮即可恢复作用。
先算清现状：每列实际并行多少、停留多久
设定上限之前，团队需要先知道当前每列同时压着多少工作项、每项停留多久。凭印象设数字，往往会把上限设成理想状态，上线后立刻被现实突破，规则随之失效。测量周期建议取近2–4周，覆盖至少一个完整的交付节奏，减少偶发高峰对基线的干扰。
具体做法是逐列统计四项数据：平均并行工作项数量、工作项进入该列到离开该列的平均停留时间、处于阻塞状态的时长占比，以及阻塞原因的大致分布。统计时以工作项的实际状态流转记录为准，避免用会议上的口头估计替代。需求、缺陷、技术任务三类工作项的并行情况应分开统计，因为它们的处理节奏和阻塞原因差异明显，混在一起会掩盖某一类的积压。
数据来源和统计口径要写下来，包括统计的时间区间、工作项类型的筛选条件、停留时间从哪个状态开始计算。后续调整上限时，只有口径一致，前后数据才可比较。
| 看板列 | 平均并行数 | 平均停留时间 | 阻塞占比 | 主要阻塞原因 |
|---|---|---|---|---|
| 待开发 | 填写 | 填写 | 填写 | 填写 |
| 开发中 | 填写 | 填写 | 填写 | 填写 |
| 代码评审 | 填写 | 填写 | 填写 | 填写 |
| 测试中 | 填写 | 填写 | 填写 | 填写 |
| 待发布 | 填写 | 填写 | 填写 | 填写 |
这张基线表是后续所有判断的参照。完成标志是：每列都有数据，口径已记录，团队对“现状并行多少”形成一致认识。
设定初值：按列给上限，用拉动代替推入
第一版上限从基线推出，原则是略低于现状平均并行数。比如某列近三周平均同时有6项，初值可设在5；平均有3项的列，初值可设在2或3。略低的目的不是制造紧张，而是让积压显性化，迫使团队在超限时处理排队和协助，而不是继续往里塞新工作。
上限按列独立设置，不按人设置。按人分配名额会把看板变成任务分派表，掩盖列与列之间的流动问题；按列设置才能暴露哪一段是瓶颈。瓶颈列优先收紧，因为它的停留时间最长、对整体交付节奏影响最大。非瓶颈列的上限可以相对宽松，但也要有明确数值。
列与列之间通过空位联动：下游列有空位时，上游才允许把完成的工作项拉过去；下游满员，上游即使完成也保持原位，转而协助下游处理。这就是拉动机制，它让上游的产出速度受下游消化能力约束，避免半成品在中间列堆积。
超限时的处理规则要提前约定，常见做法有三种：新工作项进入排队区等待，不占用列内名额；列内成员优先协助完成已有工作项，暂不接新任务；对明显过大的工作项拆分后再进入。规则应写进看板说明，让每个人遇到超限时知道下一步做什么。
| 看板列 | 现状平均并行数 | 第一版上限 | 超限处理动作 |
|---|---|---|---|
| 开发中 | 6 | 5 | 排队等待，优先协助评审 |
| 代码评审 | 4 | 3 | 暂停拉入新项，集中清理 |
| 测试中 | 5 | 4 | 拆分大项，缺陷优先 |
完成标志是：每列都有上限数值、有超限处理动作，团队能说清上下游如何联动。
角色与交付物：谁定上限、谁维护、谁调整
上限由团队共同协商确定，而不是由某个人单方面下发。协商过程让成员理解每个数字背后的基线数据，也更容易在日常工作中遵守。团队负责人对规则落地负责，包括在站会上提醒超限情况、推动阻塞问题解决。
看板管理员或迭代负责人承担日常维护：保持列配置与团队约定一致，记录每次超限的发生时间和处理方式，收集停留时间与阻塞数据供回顾使用。这项工作不需要额外系统，关键是形成固定记录习惯。
阻塞和超限情况应在每日站会或迭代回顾中提出。站会关注当天是否需要调整拉动顺序，回顾则看一段时间的趋势：哪列反复超限、哪列长期空置、阻塞原因是否集中。调整上限属于规则变更，需要记录变更的列、调整前后的数值、原因和生效时间，便于下次评估时对照。
| 角色 | 职责 | 产出 |
|---|---|---|
| 团队负责人 | 组织协商、推动规则落地、跟踪阻塞 | 上限规则说明、站会超限处理结论 |
| 看板管理员/迭代负责人 | 维护列配置、记录超限与流动数据 | 超限记录、基线数据更新 |
| 全体成员 | 遵守拉动规则、及时暴露阻塞 | 阻塞说明、协助完成的动作 |
上限变更记录可以很简单：日期、变更列、原上限、新上限、变更原因、观察期。这份记录既是调整依据，也是团队学习流动规律的材料。
用流动数据校准：偏松、偏紧怎么判断和调整
上限运行两到四周后，用数据判断它是否合适。停留时间持续变长、阻塞项增多，通常说明上限偏松，列内容纳了超出团队处理能力的工作，或者真正的瓶颈在更下游而未被识别。此时应收紧该列上限，或把注意力转向瓶颈列。
反过来，某列长期空置、成员完成任务后等待下游、交付节奏没有提升，说明上限偏紧或列间衔接不畅。偏紧的上限会让团队频繁处于“不能拉入”的状态，反而降低流动。判断时要结合交付节奏和缺陷逃逸情况，不只看单列数字：一列停留时间短但下游缺陷增多，可能是上游压缩了必要的检查。
调整节奏宜小步进行，每次只改一到两列，观察两到四周再评估。一次改动过多列，数据变化无法归因，团队也难以适应新的节奏。每次调整都写入校准记录，包括调整的列、调整前后的关键数据、判断依据和观察结论。
| 观察信号 | 可能判断 | 建议动作 |
|---|---|---|
| 停留时间持续变长、阻塞增多 | 上限偏松或瓶颈在下游 | 收紧该列，排查下游瓶颈 |
| 列长期空置、人员等待 | 上限偏紧或衔接不畅 | 适度放宽，检查拉动规则 |
| 交付节奏稳定、阻塞可控 | 上限基本合适 | 保持，继续观察 |
| 停留时间短但缺陷逃逸上升 | 检查环节被压缩 | 复核该列完成标准 |
在工具层面，ONES 可自动记录和统计工作项滞留时间等研发过程数据，团队在回顾时可以直接取用这些数据对照基线表，减少手工统计的负担；看板与燃尽图也能用于观察迭代进度。具体统计口径和可用范围以团队实际配置为准。
一个研发看板的示例：从基线到上限落地
以下为一个演示情景，用于说明完整过程，数字仅作示例。某研发团队看板分为待开发、开发中、代码评审、测试中、待发布五列，统计近三周数据后发现：开发中平均同时有6项，平均停留3.5天；代码评审平均4项，停留2天，阻塞占比约三成，主要原因是评审人时间冲突；测试中平均5项，停留4天。
第一版上限据此设定：开发中5、代码评审3、测试中4，待开发和待发布暂不设严格上限但标注观察。拉动规则为下游有空位才拉入，代码评审满员时开发中完成项原地等待，开发成员优先协助评审。
运行两周后观察：代码评审停留时间从2天降到1.6天，但开发中等待拉入的时间增加，测试中仍有积压。团队判断代码评审上限有效，测试中偏松，于是把测试中上限从4收紧到3，并约定缺陷修复优先进入测试列。再观察两周，测试中停留时间下降，整体交付节奏趋于稳定。仍需关注的问题是评审人时间冲突尚未根本解决，团队计划在回顾中讨论评审轮换安排。
这个示例说明：上限不是一次设定就完成，而是随流动数据逐步逼近团队真实能力。示例中的数值不可直接套用，每个团队应按自己的基线表推出初值。
完成检查：上限是否真正起作用
判断上限机制是否建立并有效运行，可以逐项核对以下清单。全部满足，说明上限已经成为团队工作方式的一部分；有缺项，则回到对应环节补齐。
- 每列都有明确的上限数值，且团队每个成员都能说出自己所在列的上限和超限时的处理动作。
- 超限有统一处理动作，并在站会或看板记录中留下痕迹，而不是靠个人临时决定。
- 停留时间、阻塞时长等数据可以定期获取，统计口径与基线表一致，便于前后对比。
- 上限调整有数据依据、有变更记录、有回顾讨论，调整后经过观察期再评估。
- 上下游列通过空位联动，拉动规则在实际工作中被执行，而不只是写在看板说明里。
- 上限按列设置，未退化为按人分配任务的名额。
如果上限长期无人触碰、超限没有处理动作、数据也不再更新，说明它已经形式化。此时不必推翻重来，回到第一步重新测量现状，用新的基线校准一轮，往往就能让规则重新发挥作用。
常见问题
团队刚开始用看板，还没有历史数据，第一版上限怎么定？
没有历史数据时，可以用一周左右做一次快速测量：每天记录各列同时进行的工作项数量，取这一周的平均值作为临时基线。初值仍按略低于该平均值设置，并明确这是临时上限，运行两到四周后按正式口径重新统计再校准。另一种做法是先不设数值上限，只约定“下游满员时上游停止拉入”，运行一段时间后从实际流动中读出各列的合理容量，再补上数值。
不同工作项类型（需求、缺陷、技术任务）混在同一列，上限怎么算？
建议分开统计、合并设限或分列设限。若三类工作项共用一列，先分别统计各自的平均并行数，再按团队实际处理能力确定该列总上限；如果缺陷修复经常挤占需求开发，可以把缺陷单独设列或单独设上限，避免一类工作项长期压制另一类。关键是统计口径在调整前后保持一致，否则数据无法比较。
上限设了之后经常被突破，是不是说明设得太紧？
先看突破后的处理动作是否被执行。如果超限时团队仍继续拉入新工作项，说明规则本身没有落地，与数值松紧无关；如果团队按规则排队或协助，但列内工作项长期无法完成，才考虑上限偏紧。另一种常见情况是工作项颗粒度过大，一项就占满整列名额，此时应先拆分工作项，再评估上限是否需要调整。
看板列很多时，每列都要设上限吗？
不必每列都设严格数值。优先给停留时间最长、积压最明显的列设上限，这些列对整体流动影响最大；等待区或缓冲列可以只标注观察，不设硬性数值。随着数据积累，再逐步补齐。列数过多本身也会增加维护成本，可以合并职责相近的列，让上限数量控制在团队能日常关注的范围内。
用工具管理看板时，上限数据怎么持续获取？
关键是让工作项的状态流转在工具中留下记录，停留时间、阻塞时长等数据才能被统计出来。ONES 可自动记录和统计工作项滞留时间等研发过程数据，团队在回顾时可以直接取用对照基线表，减少手工统计负担；看板与燃尽图也能用于观察迭代进度。具体统计口径和可用范围以团队实际配置为准。
