作者： Q.H. Wang

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

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

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

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

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

门禁已触发迭代产出未就绪、评审已通过门禁材料被退回，这类等待返工需要先分清是同步点设置、交付边界还是评审输入输出问题。本文给出三类原因假设的判别特征、取证顺序与分根因处置动作。

硬件门禁已通过而软件迭代未就绪，混合项目的关键是把两条进度线拆开处理：硬件门禁转为基线冻结，软件侧设就绪判定点并滚动排期，交付边界按交付物拆分为先行冻结与合并发布，用缓冲和并行窗口替代整体等待。

评审过多、迭代空转、阶段等待可能来自方法不适配，也可能来自执行条件缺失。本文把模糊抱怨拆成可计数症状，给出假设与证据对照、先查执行再评估方法的排查顺序，以及两类判断对应的处置路径、停止点与验证指标。

选了瀑布、敏捷或混合方法后仍出现阶段等待和形式化迭代，先别急着换方法。本文给出诊断顺序：把模糊抱怨转成可观察症状并界定范围，用证据验证方法不适配与执行走样两类假设，按判断结果分场景处置，再用指标确认恢复并防止复发。

硬件门禁已过、软件迭代未就绪，关键路径上会出现一段无人推进的等待。本文给出三步调整方法：先定位等待发生在门禁条件、迭代出口还是交付边界，再把门禁改为带条件放行，接着重切软件迭代范围与出口标准，最后书面重设交付边界与角色分工，并附完成检查清单与复查指标。