作者： Q.H. Wang

在制品限制适合工作项可拆分、状态稳定、有可视化看板且团队能自主调整节奏的情况。需求波动或成员兼职时仍可适用，需把上限设在瓶颈环节、按可用人力折算并约定例外回补规则；条件不足时应先补齐前提再引入。

Scrum事件开完却没有形成可用决定，恢复衔接的关键是逐事件重设目标、输入输出与参与角色，让每项产出都有明确的消费者和承接动作，再用一轮事件验证产出是否真正驱动了决策。

需求波动和人员兼职改变的是在制品上限怎么定、多久调一次，并不取消限制本身的价值。本文区分直接适用、调整后适用与暂缓三类情形，说明波动场景按瓶颈设限、兼职场景按可投入时段折算容量的具体做法，并列出采用前的前置条件与试点判断依据。

WIP限制只是起点。本文按记录基线、定位瓶颈、同步调整列划分与拆分标准与拉动规则、评估前提代价、用流动数据验证的顺序，说明看板设置WIP限制后如何实质提升流动效率。

瀑布项目的阶段衔接、里程碑评审和变更控制，常见问题出在节点把关方式。本文按单项目层面给出改进路径：先建立可对照的基线，再识别等待、返工和交接损耗的来源，然后依次统一交付物标准、优化评审证据、调整变更分级，最后用指标验证效果，并说明落地的前提条件与代价。

WIP限制只是流动管理的起点。本文给出三条配套改进路径：按实际交接点重划列并重新分配限制值，把工作项拆到能在一列内完成的粒度，用下游有空位才拉入的规则约束推进节奏，并给出效果验证指标与观察周期。

瀑布项目返工往往多因叠加，单看延期无法归因。本文给出四类根因假设的证据对照与排查顺序，按主因分流处置，并说明基线调整的风险边界与恢复验证指标。

瀑布项目的等待、返工和交接损耗多发生在阶段边界。本文给出量现状、找瓶颈、改边界、看代价、做复测的完整路径：用三类指标建立基线，把交付物清单和准入评审落到阶段交界处，变更在阶段内登记，并用同一口径验证改进效果。

瀑布项目的阶段延期和阶段间返工成因不同。本文给出症状定位表、四类原因假设与支持/反向证据对照、按证据强度排序的排查步骤，以及处置后的恢复验证指标，帮助项目经理把笼统的延期拆成可诊断、可处置的具体问题。

瀑布门禁与迭代评审脱节，通常由同步点只按日历、交付边界不清、评审输入输出口径不一致三处错位叠加造成。本文给出三类根因假设与对应验证证据，按同步点、交付边界、评审输入输出的顺序处置，并用等待时长、返工次数和评审一次通过率验证恢复。