任务看板卡片堆积，通常先看四类原因：卡片进入某一列后缺少明确的完成定义与退出条件；同一角色同时承接的在办事项超出可处理量；卡片更新滞后，实际已完成或已阻塞的状态没有反映到看板上；卡片粒度过粗，一张卡包含多个环节，长期停在中间列。排查前先确认堆积集中在哪一列、持续多久、涉及哪些角色，再逐项验证原因，处置后以卡片停留时长和列内数量变化判断是否恢复。
要点总览（TL;DR）
- 卡片堆积通常集中在“进行中”“待评审”“待验证”等中间列，排查前先记录堆积的列位置、持续时间和涉及角色，把笼统感受拆成可观察事实。
- 常见原因有五类：完成定义缺失或模糊、在办事项超出角色可处理量、状态更新滞后、卡片粒度过粗、下游评审验收容量不足，每类都需要对应证据才能成立。
- 排查顺序建议先核对更新记录与实际进展，再检查各列完成定义，然后统计在办数量与完成节奏，最后检查下游承接能力；调整列上限或批量移动卡片前先备份并约定停止点。
- 处置动作对应已确认的原因：补齐退出条件、设置列内上限、固定更新时点、拆分大卡片，并用堆积列数量、平均停留时长和堆积周期变化验证恢复。
- 看板上的卡片数量不等于实际在办工作量，先区分更新滞后造成的表面堆积与真实积压，再决定处置方向。
卡片堆积出现在哪些列、持续了多久
“堆积”是一个笼统感受，排查的第一步是把它拆成可观察的事实：哪一列卡片数量异常、从什么时候开始、涉及哪些角色和哪类卡片。只有把症状范围界定清楚，后面的原因验证才有具体对象，否则容易在不同列的卡片之间来回猜测。
先定位堆积所在的列
逐列清点卡片数量，重点看“进行中”“待评审”“待验证”这类中间列。待处理列卡片多，往往说明入口没有约束或优先级不清；中间列卡片多，更可能与完成定义、在办数量或下游承接能力有关；待评审、待验证列堆积，则要关注评审人和验收人的可用时间。把各列数量与团队正常节奏下的水平对比，找出偏离最明显的一列或两列。
记录时间跨度与出现规律
查看卡片进入该列的时间，判断堆积是持续存在还是周期性出现。持续堆积通常指向流程结构问题，例如某列没有退出标准；周期性堆积常与迭代末集中提测、集中评审等节奏有关。记录起止时间，也能为后续验证处置效果提供基线。
识别涉及的角色与卡片类型
同一列里不同角色的卡片堆积程度可能差别很大。按负责人角色、卡片类型（需求、缺陷、技术任务等）分组统计，能看出是全员普遍积压，还是集中在某一角色或某一类工作上。这一步也为判断“在办数量是否超出可处理量”提供依据。
区分真实积压与表面堆积
看板上的卡片数量不等于实际在办工作量。抽几张停留时间较长的卡片，核对最近更新记录与实际进展：如果工作已经完成或已阻塞，卡片却仍停在原列，这属于更新滞后造成的表面堆积；如果卡片确实仍在处理中且长期无法移出，才是真实积压。两类问题的处置方向不同，需要分开统计。
完成这一步后，应当形成一份症状范围描述：堆积集中在哪些列、时间跨度多长、涉及哪些角色和卡片类型、其中多少属于更新滞后。这份描述是后续逐项验证原因的基础。
常见原因假设与对应的排除证据
卡片堆积的原因往往不止一个，但也不能把所有可能都当成结论。下面列出五类常见假设，每类都给出验证方式和可观察证据，排查时逐项核对，有证据的保留，无证据的排除。
| 原因假设 | 验证方式 | 支持该假设的证据 | 可排除的情形 |
|---|---|---|---|
| 完成定义缺失或模糊 | 请列内成员分别说明“这张卡什么时候可以移到下一列”，对比回答是否一致 | 成员对退出条件理解不一，卡片完成后仍在列内等待确认 | 团队对退出条件表述一致，且卡片移出时无明显争议 |
| 在办事项超出角色可处理量 | 统计各角色当前在办卡片数与近期每周完成数 | 在办数明显高于完成节奏，卡片排队等待同一人处理 | 在办数与完成节奏匹配，卡片停留主要发生在等待他人环节 |
| 状态更新滞后 | 抽取长停留卡片，核对更新记录与实际进展 | 实际已完成或已阻塞的卡片仍显示在原列，更新记录长期空白 | 卡片更新记录与实际进展基本一致 |
| 卡片粒度过粗 | 查看长停留卡片的内容，判断是否包含多个环节或多人交接 | 一张卡跨设计、开发、测试等多个环节，长期停在中间列 | 卡片对应单一可交付动作，停留原因在外部依赖 |
| 下游评审或验收容量不足 | 统计待评审、待验证列的进入速度与评审完成速度 | 上游列卡片持续增加，评审、验收环节排队时间拉长 | 下游环节周转正常，堆积主要发生在其上游 |
使用这张表时要注意两点。一是同一列堆积可能由多个原因叠加，例如完成定义模糊与更新滞后同时存在，排除其中一个不等于问题解决。二是证据要来自看板记录和成员的实际判断，避免仅凭印象下结论。对于完成定义类假设，成员回答不一致本身就是证据；对于容量类假设，在办数量与完成节奏的对比比单看卡片总数更有说服力。
按顺序排查：从入口到出口的检查路径
排查顺序影响效率。更新滞后和完成定义模糊这两类原因验证成本低、影响面广，应优先检查；容量和流程结构类原因需要统计数据，放在其后；调整列上限或批量移动卡片属于有破坏风险的操作，放在最后并设定停止点。
第一步：核对更新记录与实际进展
从堆积列中抽取停留时间最长的若干卡片，逐张核对最近更新记录、评论和实际进展。判断依据是卡片状态是否与事实一致。若相当比例的卡片属于“已完成未移动”或“已阻塞未标注”，先解决更新问题，再重新统计各列数量，避免在失真的数据上继续分析。
第二步：检查各列完成定义
组织列内成员分别说明卡片移出该列的条件，对比回答是否一致。判断依据是团队是否对退出条件有共同理解。若回答分歧明显，说明完成定义缺失或只存在于个别人头脑中，这本身就是卡片滞留的原因之一。此步只做确认，不急于当场修改规则。
第三步：统计各角色在办数量与完成节奏
按角色统计当前在办卡片数和近几周的完成数量，观察在办数是否长期高于完成节奏。判断依据是在办数量与处理能力是否匹配。若某角色的在办数持续偏高，且堆积卡片多集中在其负责的列，容量假设成立的可能性较大。此步需要历史数据，统计口径应保持一致。
第四步：检查下游评审与验收的承接能力
统计待评审、待验证列的卡片进入速度和评审完成速度，观察下游是否形成排队。判断依据是上游列的堆积是否随下游周转放慢而加重。若下游评审人时间有限，上游列即使完成定义清晰也会被动堆积，此时处置重点在下游容量而非上游规则。
操作风险与停止点
排查阶段以观察和统计为主，尽量不改动看板。确需调整列上限、批量移动卡片或清理长期滞留卡片时，先备份当前看板状态（导出卡片清单或保留截图），并约定停止点：例如批量移动后若发现状态与实际不符的比例超过预期，立即停止并回退。调整规则前与列内成员确认，避免单方面改动造成新的混乱。
处置动作与恢复验证
处置动作应对应已确认的原因，而不是对所有假设同时下手。下面按原因列出常用动作，并说明如何验证恢复和防止复发。
补齐完成定义与退出条件
为堆积明显的列写明卡片移出的具体条件，例如“待评审”列的退出条件是评审意见已记录且修改项已闭环。完成定义由列内成员共同确认，并放在看板列标题或团队可见的文档中。验证方式是观察该列卡片移出时是否仍有争议，以及停留时长是否缩短。
设置在办上限与超限处理规则
为关键中间列设置卡片数量上限，并明确超限时的处理规则：先完成列内已有卡片再拉入新卡，或由团队负责人协调分流。上限数值参考团队历史完成节奏确定，不照搬其他团队的数字。验证方式是观察列内数量是否稳定在上限附近，以及新卡进入是否被合理延后。
固定更新时点与责任人
约定每日或每次站会前更新卡片状态，明确每张卡的更新责任人是其负责人。对已阻塞的卡片要求标注阻塞原因和等待对象。验证方式是抽查长停留卡片的更新记录是否及时，以及“已完成未移动”的卡片比例是否下降。
拆分跨环节的大卡片
对包含多个环节、多人交接的卡片进行拆分，使每张卡对应一个可独立完成和验证的动作。拆分后重新观察中间列的停留情况，判断堆积是否随粒度细化而缓解。拆分时保留原卡片的关联关系，便于追溯。
恢复验证指标
处置后以三项指标判断恢复情况：堆积列的卡片数量是否回落到正常水平；卡片在堆积列的平均停留时长是否缩短；堆积是否仍按原周期反复出现。指标对比应使用处置前后的同一口径数据，观察周期覆盖至少一个完整迭代，避免把短期波动当成恢复。
复发预防
把堆积列和更新及时性纳入定期回看，例如每次迭代回顾时检查各列数量与长停留卡片。发现某列连续多个周期偏高时，重新核对完成定义和在办上限是否仍然适用。团队节奏变化（如人员调整、需求集中上线）后，及时复核列上限和评审安排。
在工具层面，ONES 的工作项状态与看板视图可以把卡片状态、负责人和更新记录集中呈现，便于按列统计数量和停留情况；处置阶段调整列规则、拆分工作项和核对更新记录时，这些信息可以作为排查与验证的依据。具体配置方式以团队实际使用的版本和设置为准。
常见问题
卡片堆积集中在“待评审”列，但上游“进行中”列数量正常，应该先查什么？
这种情况优先检查下游承接能力，而不是上游规则。统计待评审列的卡片进入速度和评审完成速度，观察排队时间是否在拉长；同时确认评审人是否同时承担其他工作、评审时段是否固定。若评审环节周转明显放慢，上游即使完成定义清晰也会被动堆积，处置重点应放在评审容量和评审安排上，例如约定固定评审时段或明确评审责任人。
团队规模较小，设置列内上限会不会反而影响协作？
列内上限的作用是让超载可见，数值应参考团队自己的历史完成节奏确定，不照搬其他团队的数字。小团队可以从只对一两个关键中间列设限开始，并明确超限时的处理规则，例如先完成列内已有卡片再拉入新卡。运行几个周期后回看列内数量和停留时长，再决定是否调整上限或扩大适用范围。
卡片更新滞后很普遍，固定更新时点后如何避免流于形式？
更新要求需要落到具体动作：每张卡的更新责任人是其负责人，站会前核对卡片状态与实际进展是否一致，已阻塞的卡片标注阻塞原因和等待对象。验证方式是抽查长停留卡片的更新记录，观察“已完成未移动”的卡片比例是否下降。若更新仍不及时，检查更新动作是否过于繁琐，必要时简化状态选项或减少必填字段。
处置后观察多久才能判断堆积已经缓解？
建议观察周期覆盖至少一个完整迭代，使用处置前后同一口径的数据对比三项指标：堆积列的卡片数量、卡片在该列的平均停留时长、堆积是否仍按原周期反复出现。短期波动不足以说明恢复，若指标在多个周期内稳定回落，再考虑把临时措施固化为团队规则。
多个原因同时存在时，处置动作应该怎么排优先级？
先处理验证成本低、影响面广的原因，例如更新滞后和完成定义模糊，这两类问题解决后重新统计各列数量，避免在失真的数据上继续分析。容量和流程结构类原因需要历史数据支撑，放在其后。若下游评审容量不足与上游完成定义模糊同时存在，可先补齐退出条件，再协调评审安排，分步观察每项动作的效果。
