迭代进行到一半，临时需求插进来，排期表往往需要重排。重排的关键是保护前后置依赖链：先评估插入需求落在哪条依赖链上，再按“保依赖、调顺序、挪范围、留缓冲”的顺序调整，并把变更原因和影响范围记录到工作项上。本文聚焦工作项层面的排期调整，说明重排顺序、依赖保护方法和效果验证口径。
要点总览（TL;DR）
- 重排前先固定排期基线：任务清单、前后置依赖、关键路径、优先级依据和剩余缓冲量，重排后用同一口径对照。
- 重排按固定顺序推进：先定位插入需求落在哪条依赖链上，再调整无后置依赖的任务，然后处理关键路径，最后决定动用缓冲还是缩小范围。
- 保护依赖链的关键动作是检查每个后置任务的开始时间仍晚于前置任务完成时间，关键路径上的任务优先考虑并行拆分或提前启动，而非简单顺延。
- 滚动重排适合依赖已显式记录、团队愿意承担沟通评审成本的场景；依赖未梳理或容量已排满时，应先补依赖或调整范围。
- 验证重排效果看四项：依赖链是否闭合、关键路径是否被保护、插入需求是否按新排期完成、缓冲消耗是否在设定上限内。
先看清现状：插入需求前的排期基线
重排之前，需要先有一份可对照的排期基线。没有基线，调整后只能凭感觉判断“好像顺了”，无法回答哪些任务被挪动、哪条依赖链被拉长、缓冲还剩多少。基线的作用是给重排提供一个明确的对照物，让后续每一步调整都有据可查。
基线至少应固定三类信息。第一类是任务清单与依赖关系：当前迭代有哪些任务、每个任务的负责人、前后置关系是什么、哪条链路构成关键路径。第二类是优先级依据：插入需求与既有任务各自对应什么目标、由谁提出、按什么口径比较轻重缓急。第三类是量化数据：任务总数、依赖关系数量、剩余缓冲量、各任务预计完成时间。
| 基线项 | 记录内容 | 用途 |
|---|---|---|
| 任务清单 | 任务名称、负责人、状态、预计工时 | 确定哪些任务可被调整 |
| 依赖关系 | 前后置任务、依赖类型、关键路径标记 | 判断插入需求会牵动哪些任务 |
| 优先级依据 | 需求来源、目标关联、比较口径 | 为插入需求定级提供统一标准 |
| 缓冲与容量 | 剩余缓冲量、已排满程度 | 判断能否吸收波动 |
基线不需要很复杂，一张任务表加一份依赖清单即可。关键是重排前把它固定下来，重排后再用同一份口径对照。若依赖关系此前没有显式记录，应先把依赖补出来，再进入重排，否则后续调整缺少判断依据。
插入需求为什么会打乱排期：常见瓶颈与误区
临时需求打乱排期，通常不是因为它本身工作量多大，而是因为它触动了排期中原本平衡的几处结构。识别这些机制，才能避免用“把日期往后挪”这种表面动作掩盖真实问题。
直接插队导致依赖断裂
最常见的做法是把插入需求塞进某个负责人的当前任务列表，挤掉原有任务的时间。问题在于，被挤掉的任务可能是另一条链路的前置任务，它的延后会沿着依赖关系向后传导，导致后置任务空等或被迫压缩测试时间。依赖断裂往往在迭代后期才暴露，届时补救成本更高。
缓冲被一次性吃掉
迭代排期通常会留出一定缓冲吸收波动。临时需求插入时，如果直接把缓冲全部用于新任务，后续再出现任何偏差都没有腾挪空间。缓冲被吃光后，排期表看起来仍然完整，实际已经失去弹性。
优先级判断缺少统一口径
插入需求常由不同角色提出，若没有统一的比较口径，容易出现“谁声音大谁先做”。优先级口径不一，会导致重排时反复调整，任务在列表中来回移动，团队对排期的信任度下降。
把重排当成单纯挪日期
重排的本质是重新安排任务顺序、范围和依赖关系，日期只是结果。只改日期而不调整顺序和范围，等于把冲突推迟到执行阶段。判断重排是否到位，要看依赖链是否仍然闭合、关键路径是否被识别并保护，而不是看排期表是否整齐。
优先改进动作：按依赖顺序滚动重排
重排可以按固定顺序推进：先定位插入需求影响的依赖链，再从无后置依赖的任务开始调整，最后处理关键路径并决定是否动用缓冲或缩小范围。这个顺序的作用是让每次调整都建立在依赖已经确认的基础上，避免边改边乱。
第一步：定位插入需求落在哪条依赖链上
拿到插入需求后，先判断它依赖哪些既有任务、又被哪些任务依赖。如果它落在关键路径上，影响会被放大；如果它只挂在一条支线上，调整空间相对大。把受影响的链路标出来，作为后续调整的范围边界。
第二步：先调整无后置依赖的任务
从依赖链的末端开始调整，优先挪动那些没有后置任务、或后置任务可以独立并行的任务。这类任务的调整不会传导到其他环节，改动成本最低。把可以吸收的调整先做完，再处理会牵动多条链路的任务。
第三步：处理关键路径，保护依赖闭合
关键路径上的任务每延后一天，整体交付就延后一天。处理这类任务时，优先考虑并行拆分、调整顺序或提前启动前置任务，而不是简单顺延。调整后要检查依赖链是否仍然闭合：每个后置任务的开始时间是否仍晚于其前置任务的完成时间。
第四步：用缓冲吸收短期波动，必要时缩小范围
短期波动可以动用缓冲吸收，但应设定动用上限，避免一次性吃光。若插入需求较大、缓冲不足以覆盖，应主动缩小本次迭代范围，把部分低优先级任务移出，而不是让所有任务都带着风险继续排。范围缩减需要与需求提出方确认，并记录取舍理由。
第五步：把变更记录到工作项并同步相关角色
每次调整后，在对应工作项上记录变更原因、影响范围和新的完成时间，并同步给受影响的负责人和需求提出方。记录的作用是让后续复盘有据可查，也让团队对排期变化有共同认知。ONES Project 支持建立需求池、规划迭代，可将需求和相关任务规划至迭代并分配负责人，适合承载插入需求的登记与重排后的任务归属；任务工时统计可用于估算调整后的任务持续时间，看板和燃尽图可用于观察重排后的实际进度。
| 调整动作 | 操作对象 | 完成标志 |
|---|---|---|
| 定位依赖链 | 插入需求及其前后置任务 | 标出受影响任务范围 |
| 调整末端任务 | 无后置依赖或可并行的任务 | 调整不传导到其他链路 |
| 处理关键路径 | 关键路径上的任务 | 依赖链仍闭合，交付时间明确 |
| 动用缓冲或缩范围 | 缓冲量、迭代范围 | 缓冲有上限，取舍有记录 |
| 记录与同步 | 工作项、相关角色 | 变更原因和影响范围可追溯 |
适用前提与代价：什么情况下适合滚动重排
滚动重排适合依赖关系已经显式记录、团队愿意为变更付出沟通成本的场景。它并非无条件适用，套用前需要确认几个前提，并接受相应的代价。
前提：依赖关系已被显式记录
重排的依据是依赖关系。如果任务之间的前后置关系只存在于个别成员的经验里，重排时就无法判断调整会传导到哪里。依赖未梳理时，应先补依赖清单，再谈重排。依赖记录得越完整，重排的判断越可靠。
代价：沟通与评审成本
每次重排都涉及与需求提出方、任务负责人和相关角色的确认。插入需求越靠近迭代后期，需要同步的人越多，沟通成本越高。团队需要为变更评审预留时间，否则重排会变成单方面的通知，执行时容易出现偏差。
取舍：范围缩减或延期交付
当缓冲不足以吸收插入需求时，需要在缩小范围和延期交付之间做选择。缩小范围意味着部分既有任务移出本次迭代，延期交付意味着整体完成时间后移。两种取舍都需要明确记录，并与相关方达成一致，避免在执行阶段反复变更。
不适用情形
依赖关系尚未梳理、团队容量已经排满且没有缓冲时，滚动重排的效果有限。这种情况下，更合适的做法是先处理依赖梳理或调整迭代范围，再进入重排。把重排当作解决容量不足的手段，往往会让排期表反复变动而问题依旧。
效果验证：怎么判断重排是否有效
验证重排效果，应回到重排前固定的基线，用同一口径对照重排前后的变化。判断标准包括依赖链是否完整、关键路径是否被保护、插入需求是否按新排期完成，以及缓冲消耗是否在可控范围内。
依赖链完整性与关键路径保护
检查每个后置任务的开始时间是否仍晚于其前置任务的完成时间，关键路径上的任务是否被明确标记并优先保障。依赖链闭合、关键路径有保护，说明重排的结构是成立的；若出现后置任务等待前置任务的情况，说明调整没有到位。
插入需求的实际完成情况
对照插入需求的新排期，观察它是否按计划完成、是否出现返工或阻塞。完成情况反映的是重排后的排期是否可执行，而不只是纸面上是否合理。若插入需求多次延期，需要回看它所在链路的依赖是否被正确识别。
缓冲消耗与后续迭代稳定性
记录本次迭代缓冲的消耗量，与基线中的缓冲量对照。缓冲消耗在设定上限内，说明重排吸收了波动；若缓冲被一次性吃光，后续迭代的排期稳定性会受影响。观察后续一两个迭代是否出现类似的插入需求冲击，可以判断重排方法是否在持续发挥作用。
用基线数据对照重排前后
把重排前的任务数、依赖数、缓冲量与重排后的对应数据并列比较，看调整幅度是否与插入需求的影响相匹配。调整幅度过大而插入需求影响有限，说明重排可能过度；调整幅度过小而依赖链已出现断裂，说明重排不足。对照的目的不是追求数字好看，而是确认每次调整都有对应的影响来源。
若团队使用 ONES Wiki 记录迭代排期与变更说明，可将文档与相关任务关联，并在文档中插入 ONES Project 的工作项列表，让排期基线和重排记录保持在同一处可查。ONES Assistant 能基于项目、工作项和迭代等上下文回答问题，在复盘重排效果时可用于快速定位相关任务和变更记录。
常见问题
插入需求落在关键路径上，和落在支线上，重排方式有什么不同？
落在关键路径上时，任务每延后一天，整体交付就延后一天，重排空间最小。此时优先考虑并行拆分、调整任务顺序或提前启动前置任务，把影响压到最小，再决定是否动用缓冲。落在支线上时，影响局限在局部链路，可以先调整支线末端任务，观察是否传导到其他环节。两类情况的共同前提是先标出受影响的任务范围，再动手改日期。
依赖关系此前没有记录，还能直接开始重排吗？
建议先补依赖清单再重排。重排的判断依据是任务之间的前后置关系，如果这些关系只存在于个别成员的经验里，调整时就无法判断影响会传导到哪里，容易出现改完一处、另一处断裂的情况。补依赖不必一次做全，至少把本次迭代内涉及插入需求的相关链路梳理清楚，再进入调整。
缓冲应该留多少，临时需求插入时能动用多少？
缓冲量没有统一标准，取决于迭代长度、任务不确定性和团队历史波动情况。可操作的做法是在排期时设定一个动用上限，例如缓冲只用于吸收短期波动，超出上限就转为缩小范围或调整交付节奏。插入需求时先看缓冲余量，再决定是吸收还是缩范围，避免一次性吃光缓冲导致后续迭代失去弹性。
重排后如何让需求提出方和任务负责人对新的排期达成一致？
把变更原因、影响范围和新的完成时间记录到对应工作项上，并同步给受影响的负责人和需求提出方。涉及范围缩减或延期交付时，需要明确记录取舍理由并与相关方确认。记录的作用是让后续复盘有据可查，也减少执行阶段因理解不一致产生的反复变更。团队可以为变更评审预留固定时间，避免重排变成单方面通知。
用 ONES 管理排期重排时，哪些环节可以落到具体功能上？
插入需求的登记与归属可以用 ONES Project 的需求池和迭代规划承载，把需求和相关任务规划至迭代并分配负责人；任务工时统计可用于估算调整后的任务持续时间，看板和燃尽图可用于观察重排后的实际进度。排期基线与变更说明可以放在 ONES Wiki 中，并与相关任务关联。复盘时，ONES Assistant 能基于项目、工作项和迭代等上下文回答问题，帮助定位相关任务和变更记录。具体功能范围以实际版本为准。
