迭代规划最佳实践：研发团队需求排期实操方法，常见问题

迭代计划排得满满当当，到了上线前却发现关键接口还没联调、测试时间被压缩、需求临时插队，这通常不是团队“不够努力”，而是排期把工作量当成了计划，把承诺当成了确定性。我的判断是，迭代规划的核心不是把所有需求塞进一个周期，而是在容量、依赖、风险和价值之间做出可解释、可调整的取舍。下面给出一套从需求准入、容量估算到迭代复盘的实操方法，并用明确标注的情景模拟数据说明怎样避免“计划看起来完整、执行起来失真”。

一、先讲核心结论：排期不是分配任务，而是管理不确定性

1. 先排可交付结果，再排具体需求

我做迭代规划时，第一步不会问“这个周期还能塞几个需求”，而会先问：周期结束时，用户或业务能够观察到什么变化？如果回答只是“完成若干开发任务”，计划就容易退化成工时清单；如果能回答“新用户可以独立完成首次配置，并且失败时有明确反馈”，团队就有了可验证的交付目标。

需求、任务和结果不是同一层级。需求描述要解决的问题，任务描述团队要做的工作，结果描述上线后发生了什么变化。只有结果能帮助团队在需求超量时判断哪些工作必须保留、哪些可以拆分或推迟。

核心结论是：先确定迭代目标和容量边界，再决定承诺范围；先确认依赖和验收条件，再细化任务；周期中出现新工作时，用显式取舍替代悄悄加量。

2. 计划要有承诺层和候选层

排期表里所有事项都写成“本迭代必须完成”，通常意味着没有真正的优先级。我的做法是把计划分成两层：承诺层是有明确价值、验收标准和可执行条件的工作；候选层是容量允许时再启动的工作。

候选项不是“顺手做一下”的别名。它必须有明确的进入条件，例如核心需求提前完成、某项外部依赖按期交付，或者线上紧急问题没有消耗预留容量。否则候选层会在执行过程中悄悄变成第二份承诺。

这种分层也能降低讨论成本。团队不必在每次进度变化时重开所有需求，而是先确认承诺层是否仍然可交付，再根据真实剩余容量决定是否启动候选项。

3. 计划准确不等于每项任务估得很准

把每项工作估到小时，不代表迭代计划可靠。需求本身不清楚、环境依赖不稳定、评审排队或线上故障，都会让精细估算失去意义。比起追求看起来精准的数字，我更关心估算依据是否一致、风险是否显式、偏差是否能在周期内暴露。

因此，计划质量至少要看四件事：承诺工作是否有清楚边界，团队容量是否扣除了必要的非项目工作，关键依赖是否有人负责，新增工作是否有明确的挤出规则。

二、真实场景：为什么排得越细，团队有时越容易延期

1. 三类工作同时挤占同一批人

一个常见场景是：产品团队把新功能排进迭代，研发团队同时承担线上故障处理，测试团队还要支持上一版本的回归。排期文档里可能只有新功能的估算工时，但真实日历里每个人都在切换任务。此时延期不是某个人估算错了，而是计划忽略了共享容量。

越是多人协作的团队，这个问题越明显。某需求看起来只需要一名开发完成，但实际上还依赖接口团队、测试资源、数据权限和发布窗口。若这些资源没有一起进入计划，开发任务按时完成也不代表需求能够按时交付。

2. 示例场景：一支跨职能产品小组的两周迭代

下面用一个情景模拟说明排期差异。假设团队有 6 名研发、2 名测试和 1 名产品负责人，周期为两周。成员并非每天都能全职投入项目：例会、代码评审、线上支持、请假和跨项目协作都会占用时间。文中数值是为了展示计算方式而构造的样本推演，不代表行业统计或任何组织的真实经营数据。

计划初稿按人头和工作日直接计算，得到 96 人日可用容量；但团队回看过去几个周期的日历后，发现平均每人约有 2.5 天用于会议、支持与跨团队协作，另有少量时间被评审和发布准备占用。调整后，可用于迭代承诺的容量明显低于名义容量。

真正重要的不是把固定折扣机械套用到所有团队，而是让容量口径能解释真实工作：哪些是计划内会议，哪些是不可预测的线上支持，哪些是周期性发布活动。若不同类型工作都混在“效率不好”里，就无法知道下周期该改计划、改流程还是补资源。

3. 计划失真的信号通常比延期更早出现

延期是结果，不是最早的预警。更早的信号包括：迭代开始后仍在反复确认验收口径；关键依赖没有明确负责人；开发已完成但测试环境尚未准备；多个需求都依赖同一名成员；周中新增事项只加进清单、没有对应移出项。

如果团队只在周期末复盘“为什么没做完”，往往只能得到“沟通不够”“估算不准”这样的宽泛结论。我建议记录首次暴露风险的时间、当时可见的证据、采取的决策，以及该决策是否减少了后续返工。只有把风险暴露过程记录下来，才有机会改变计划机制。

三、常见误区：看似认真，实际上在制造虚假确定性

1. 误区一：把历史速度当作下周期保证

速度或吞吐量可以帮助团队理解自己过去完成过多少工作，但它不是承诺额度，更不是人员绩效指标。工作难度、团队组成、缺陷修复和外部依赖都会变化。直接拿最近一个高产周期作为下个周期目标，容易把一次偶然的顺利变成长期要求。

我更倾向于看多个周期的范围和趋势，而不是盯住单点数字。例如团队过去 6 个周期完成量差异很大，就应该讨论波动来源，而不是只取最高值或简单求平均。若新团队刚组建、工作类型变化明显，历史数据的参考价值还要进一步打折。

2. 误区二：每个人都排到百分之百，才叫资源利用充分

迭代中出现等待和突发工作是正常的。若每个人的日历都被任务排满，接口阻塞、代码评审、紧急缺陷和需求澄清就只能靠加班消化。看上去没有空闲，实际缓冲被压到了零，计划自然对小幅波动非常敏感。

预留容量并不是鼓励低效，而是承认工作系统存在不确定性。预留多少要由团队自身数据决定：若过去多个周期都被线上支持打断，就应根据记录单独预留；如果工作高度稳定，也可以减少缓冲，但不能把缓冲误认为可以随时填满的闲置容量。

3. 误区三：拆得越细，估算越准确

把一个未澄清的需求拆成几十条开发任务，只会让不确定性显得更具体。任务细化适用于团队已经理解实现路径、需要协调顺序和责任人的场景；对于核心假设仍未知的工作，先做短时调查、原型验证或技术试验，通常比写一长串猜测性任务更有效。

拆分的价值应看是否帮助发现阻塞、形成可验证的交付切片，而不是看任务数量。假如拆分后仍然无法判断完成标准、前置条件和负责人，那么这项工作还不适合进入承诺层。

4. 误区四：把开发完成视为需求完成

“代码写完”只是工作链中的一个节点。需求是否完成，还可能取决于代码评审、测试、文档、数据迁移、灰度验证和上线确认。若团队按开发完工状态统计完成量，却把测试和发布积压到迭代末尾，迭代完成率会显得很好，用户却未必能用到结果。

我会要求每个迭代目标定义一个团队共享的完成口径。口径可以因产品类型不同而变化，但至少要说明哪些验证已完成、哪些发布条件仍未满足，以及上线后是否需要观察指标。没有共同口径，团队成员即使都说“完成”，讨论的也可能是不同状态。

5. 误区五：优先级只看业务方声音大小

需求紧急程度不等于价值高低。高层关注、客户催促和业务日期都是重要信号，但还需要检查影响范围、风险成本、合规要求、收入或效率影响，以及不做的后果。如果只按谁催得急来排序，团队可能持续牺牲基础质量和长期可靠性。

我会把优先级讨论从“谁的需求更重要”转成“如果这项工作晚一个周期，具体损失是什么；如果提前做，能验证什么”。能回答这些问题的需求，才更适合与其他工作做真正的取舍。

四、专业判断逻辑：需求怎样从候选变成承诺

1. 先检查需求是否具备进入讨论的最低信息

我不会要求每个需求在进入讨论前就写成完美规格，但至少要有足够信息支持判断。最低信息包括目标用户或业务对象、要解决的问题、预期变化、验收方式、已知依赖和主要风险。若这些信息都没有，排期会议很容易变成现场猜需求。

信息不足不代表需求不重要，而是说明当前最合理的工作可能是澄清或验证。团队可以安排一个有时间边界的探索任务，例如半天梳理数据口径、一天验证接口能力，完成后再决定是否承诺完整实现。

2. 用价值、时效、风险和投入共同排序

优先级不是单一分数的自动结果，而是团队对不同因素的共同判断。我常用四个维度组织讨论：价值看用户或业务受益；时效看错过窗口会损失什么；风险看不做或晚做会带来多大代价；投入看交付需要哪些资源和依赖。

评分表可以帮助暴露分歧，但不能替代决策。如果某项需求价值和风险都很高，但投入估算不稳定，正确做法可能是先安排验证任务，而不是因为分数高就把整个需求塞进迭代。

3. 用就绪检查降低“边做边猜”

需求就绪检查不是繁琐审批，而是一个决定“现在开工是否划算”的快速判断。我建议至少确认四项：团队知道要改变什么；验收标准可以被观察；关键依赖有负责人和时间预期；工作规模能够拆成可验证的交付切片。

如果其中一项缺失，团队可以选择三种处理方式：补充信息、先做探索，或者将需求留在候选池。关键是不要把“先开工再说”当成默认方案，因为未解决的问题通常会在测试阶段以更高成本重新出现。

4. 估算不确定性时，先选合适的单位

不同团队适合不同估算单位。稳定的小团队可能用相对规模比较需求；工作高度可重复的运营团队可能用数量和历史处理周期；跨职能团队也可能直接按容量和交付切片讨论。估算单位本身没有高下，重要的是大家使用同一口径，并能从历史记录中校准。

面对大而不明的需求，我会先估算一个短小的探索步骤，而不是假装能够准确估出完整交付。对外依赖多、未知因素多的事项，可以用范围表达，例如“预计 3 至 6 人日，存在接口联调风险”，而不是只报一个看似确定的点值。

5. 依据角色容量和依赖关系校验总量

团队总容量足够，不等于每个关键角色都有容量。如果本周期有 60 人日可承诺工作，但其中 30 人日都需要同一名资深工程师审核，瓶颈可能在审核队列而非开发总量。测试、数据、设计、发布等共享资源也应纳入校验。

我会把依赖关系画到工作序列中：谁先提供什么，什么时候可验证，失败时由谁决定调整。若需求必须等待一个不确定的外部交付，就不要把完整实现当作无条件承诺；可以先排无依赖部分，并明确后续决策点。

五、迭代规划实操：从会前准备到计划冻结

1. 会前两到三天：整理工作池和已知约束

迭代规划会不应成为第一次讨论需求的场合。会前由产品、研发和测试共同整理候选需求，补齐目标、验收方式、依赖和风险；同时标注已知休假、值班、发布窗口、线上遗留问题和跨团队事项。

如果团队使用协作平台，可以把需求、任务、缺陷、负责人和状态放在同一条可追踪链路里。比如使用适合中大型组织的研发管理平台，重点不是功能清单有多长，而是能否让负责人看清需求状态、依赖关系、测试结果和变更记录。以 PingCode 作为此类平台的示例时，是否适用仍应结合组织规模、流程复杂度、权限和集成要求评估；大型组织尤其要确认团队间口径能否统一，而不是只看单个团队是否会填表。

2. 规划会开始：重申目标和不能违反的约束

会议开始时，先确认迭代目标，再列出不能忽略的边界，例如必须完成的合规事项、已经对外承诺的时间窗口、发布冻结期或必须处理的高风险缺陷。没有这些边界，讨论容易只围绕需求热度展开。

目标应足够聚焦。若一个周期有五个互不相关的目标，遇到容量不足时团队很难决定先保哪个。可以有多个交付项，但它们最好服务于同一个用户结果，或者明确分成不同优先级的承诺组。

3. 逐项检查就绪程度，而不是逐项现场估价

对每个高优先级候选需求，团队快速检查验收条件、拆分方式、依赖和角色容量。只对已经理解的工作进行估算；对不确定性大的工作，先提出探索任务或缩小范围。这样做能减少多人围绕模糊需求反复争论数字。

估算要服务于决策，不是为了制造精确感。若团队无法判断两个方案哪个更容易交付，可以先比较相对规模；若必须确保某个时间窗口，则需要进一步核对依赖、验证和发布步骤，而不只是让开发人员报一个工时。

4. 对照容量按优先级装入承诺层

装入需求时，先放必须完成的工作，再放高价值且已就绪的工作，最后看是否有容量承接候选项。加入每一项后，都要同时检查角色瓶颈和依赖链路，而不是只看总人日是否超标。

如果超出容量，优先缩小交付切片或移出低优先级事项，不要要求所有人“想办法多做一点”。加班可以暂时掩盖容量问题，却不会让依赖更可靠，也不会让验收条件更清楚。

5. 明确变更规则和状态更新时间

计划冻结不是说周期中绝不能改变，而是说变化必须有记录、有影响评估、有明确决策人。发生新增事项时，至少说明为什么现在要做、需要谁投入、预计影响什么，以及是否要移出一项已承诺工作。

状态更新也应有固定节奏。每天或隔日核对阻塞与目标风险即可，不必为了“管理进度”频繁要求个人写长篇汇报。更新的重点是让团队知道下一步需要谁做什么，以及何时需要作出取舍。

1. 会前整理候选需求、验收口径、依赖和人员日历。
2. 会议开始重申迭代目标、外部约束和已知风险。
3. 检查需求就绪度，对未知问题先安排有边界的验证工作。
4. 按优先级装入承诺层，并核对角色瓶颈与交付顺序。
5. 剩余容量只用于有进入条件的候选项，不自动视为可承诺容量。
6. 明确新增工作如何进入、什么工作会被移出，以及谁负责决策。

六、具体案例：需求插队时，如何保住计划可信度

1. 情景：迭代中途出现高优先级客户问题

继续使用前文的样本推演。某团队承诺了 7 项工作，其中包括一个用户首次配置流程优化、两项后台能力、测试自动化改进和一项技术风险验证。迭代第五天，客户反馈某类配置失败会导致数据无法继续同步，业务方要求立即插入修复。

第一反应往往是“这项很紧急，大家加一下班”。我会先核实影响范围、是否存在临时缓解办法、是否涉及数据安全或合规风险，以及当前故障是否持续发生。若风险真实且高，插队有合理性；但插入之前仍要估算最低必要修复、验证范围和发布方式。

2. 先限定紧急工作的边界，再决定挤出什么

如果问题可以通过配置回滚缓解，团队可能先用短时处置恢复服务，再安排完整修复。如果没有缓解方式且影响持续扩大，则需要把修复放到承诺层，并明确被挤出的事项。被移出的工作应由产品和业务负责人确认，而不是由执行人员在计划外默默承担。

这一步特别重要：插入一项工作不只是增加一个任务，还可能改变测试资源、评审排队和发布风险。若修复需要同一名工程师完成，而她同时负责关键接口联调，团队需要重新排顺序并重新评估目标是否仍可达。

3. 用替代方案而不是抽象争论来做选择

我们可以把选择写成三种可比较方案：只做止损修复并保留其余承诺；做完整修复并移出一项候选需求；暂停一个已承诺但时效较低的功能，以保证修复和回归测试。每种方案都要说清用户影响、风险、所需角色和预计验证时间。

决策依据应是业务后果，而不是“谁的需求已经做了一半”。沉没成本会诱使团队继续完成低价值工作，但如果风险更高、延迟损失更大，停止或延后已开始的工作也可能是更合理的选择。

4. 记录一次插队的真实成本

每次临时变更都应记录至少四项：提出时间、实际投入、受影响工作、由谁作出取舍。周期结束后，团队可以判断插队是否来自可预测的需求波动、线上质量问题、依赖失控还是优先级机制不清。

如果团队发现每个周期都有类似插队，问题就不只是“业务总有变化”。可能需要建立线上支持轮值、减少发布风险、设置专门的维护容量，或者让业务方更早参与优先级决策。只记录延期而不记录扰动来源，复盘就会把系统问题归咎于个人执行。

七、数据观察与复盘：别只看完成率

1. 记录少而有用的迭代指标

指标越多，维护负担越大。我的建议是先选少数能支持决策的数据：承诺完成比例、周期中新增工作占比、需求等待时间、关键依赖阻塞时长、缺陷返工量，以及目标是否达到。每个指标都要有明确口径，避免不同团队对“完成”“新增”和“返工”的理解不同。

承诺完成比例可以帮助看计划与实际的匹配程度，但不能单独衡量团队表现。若团队为了提高比例而只承诺极少工作，数字会变好，用户价值却未必增加。相反，周期中新增工作较多时，完成比例下降也不一定说明团队能力退化，而可能反映需求变更或运维负担上升。

2. 同时观察流动过程和交付结果

只看周期末完成量，会错过流程中的排队问题。需求从准备到开发、从开发到测试、从测试到发布的等待时间，可以帮助判断瓶颈在哪。若开发任务很快完成，但测试等待持续增长，就应改善测试并行、环境稳定性或开发与测试协作，而不是要求开发“再快一点”。

交付结果则要回到迭代目标本身。功能上线后，用户是否能完成目标动作，错误率是否下降，支持工单是否减少，都是比“任务已关闭”更有意义的观察。不同需求需要不同结果指标，不必强求所有迭代都能在短期内证明收入变化。

3. 复盘时区分预测误差、执行问题和外部扰动

周期没有按计划完成，原因可能不同。预测误差是估算或容量假设不合适；执行问题可能是责任不清或协作不顺；外部扰动可能是线上事故、依赖延迟或临时优先级变化。若把三者混成“计划不准”，行动项就会变成泛泛的“加强沟通”。

我通常让团队围绕一个具体工作追问：最早什么时候知道可能延期？当时有哪些选择？为何没有及时调整？哪条信息缺失？这种问法可以将复盘从追责转向机制改进，同时也能识别真正需要培训或资源支持的地方。

4. 建立轻量的复盘数据账本

团队不必一开始搭建复杂报表。每个周期保留一张简表即可：计划承诺项、实际完成状态、新增事项、移出事项、阻塞原因、投入偏差和目标结果。关键在于记录要能回到具体事项，而不是只有一张总览数字图。

如果团队通过平台管理需求和迭代，最好能直接从工作项状态、变更日志和缺陷记录中获取数据，并允许负责人补充解释。自动统计可以减少重复抄录，但不能替代对口径的讨论。字段再齐全，如果没有人确认“为什么这次变了”，数据仍无法支持决策。

八、不同团队和情境下的行动建议与取舍

1. 新团队或历史数据不足

新团队不宜先追求复杂的速度预测。先用较短周期、较小承诺范围记录实际工作，重点了解角色瓶颈、支持工作和依赖等待。前几个周期的目标是形成基本事实，而不是证明团队能做到某个数字。

取舍上，可以接受预测范围较宽，但要缩小单项需求的交付切片。若一次承诺太大，团队即使完成了大量中间工作，也难以判断是否真正接近可交付状态。先把反馈周期变短，通常比把估算表做得更精致更有用。

2. 线上支持多、需求波动大的团队

这类团队需要把线上支持和紧急响应从普通需求里显式分开。根据历史事件记录建立容量预留，并指定轮值或明确响应机制；如果某些支持任务难以预测，就不要把所有可用工时都提前承诺给功能开发。

取舍上，留出容量可能让功能需求数量看起来少一些，但能减少频繁打断带来的切换成本。若预留连续几个周期都未被使用，可以调整比例；如果每次都迅速耗尽，则应分析支持量是否持续上升，而不是不断扩大迭代承诺。

3. 跨团队依赖多、发布链条长的组织

当需求依赖多个团队、审批环节或外部系统时，单个小组的估算不足以说明交付可行性。应提前确认接口契约、环境准备、审批时限和发布窗口，并把依赖负责人纳入规划。对不确定的外部交付，设置检查点和替代方案，避免等到迭代末尾才发现阻塞。

取舍上，可以牺牲部分并行开发的表面效率，换取更早的集成和风险暴露。若项目管理平台或研发协作工具用于跨团队跟踪，要重点看依赖状态是否可见、变更是否留痕、不同角色是否能看到需要的信息；工具只能承载规则，不能代替团队对责任边界的约定。

4. 稳定产品线或重复性工作较多的团队

工作类型稳定、历史数据较充分的团队，可以更多使用吞吐量范围和周期时间趋势做规划。对相似工作按类型分组，观察哪些需求常常超时、哪些环节经常排队，再逐步提高预测质量。

取舍上，不应为了维持历史速度而拒绝必要的探索工作。产品变化、架构升级或合规改造可能会改变工作结构，旧数据不再能准确预测新阶段。遇到结构性变化时，重新校准假设比强行维持旧目标更可靠。

5. 管理层关注短期交付，团队担心质量受损

这时需要把质量风险转成业务可理解的后果。例如，减少回归测试可能缩短本次排期，但会增加故障概率、回滚成本和支持负担；压缩技术验证可能让计划看似提前，却将未知问题推到上线后。

取舍上，可以讨论风险等级、可逆性和观察窗口。低风险、容易回滚的功能可以小范围灰度；不可逆的数据迁移或高影响支付路径，则应保留更充分的验证。关键不是所有工作都套同一套质量标准，而是任何风险接受都要明确由谁决定、接受什么后果。

九、常见问题：迭代规划中容易卡住的判断

1. 迭代周期应该固定多长吗

周期长度应服务于反馈速度、交付结构和协作成本，而不是为了与其他团队保持一致。变化快、需求切片小的团队可以用较短周期；依赖重、验证链条长的工作也可能需要不同的交付节奏。固定周期的好处是形成稳定检查点，代价是可能与某些工作的自然验证周期不一致。

如果频繁出现“周期结束了，但工作还差一步”，先检查需求切片和验收节点是否设置合理，而不是马上延长周期。周期更长并不会自动解决依赖、测试或发布排队问题，只会让风险晚一些暴露。

2. 需求没法准确估算时，应该怎么排

先判断未知是什么：业务规则不清、技术方案不明、外部系统不可控，还是测试数据尚未准备。针对不同未知安排短时探索、接口验证或数据核对，并给探索任务设置时间上限和结束条件。

如果探索后仍有较大不确定性，就缩小首个交付范围或使用区间估算，并明确依赖条件。比起把不确定性藏进一个精确数字，公开说明“目前无法确认哪些因素”更有利于业务方决策。

3. 迭代中能不能增加新需求

可以，但应把新增事项视为计划变更，而不是自动叠加的额外任务。先确认紧迫性和影响，再评估所需容量、验证范围和受影响的承诺项。若确实需要加入，明确移出什么、谁批准，以及团队如何调整目标。

对真正的生产事故或重大合规风险，快速响应通常比维护原计划更重要；对普通新想法，则更适合进入下一轮优先级评估。规则的意义不是阻止变化，而是让变化带来的成本可见。

4. 谁应该参加迭代规划会

需要参加决策的人包括负责需求价值和优先级的角色、承担交付的研发与测试代表，以及能解释关键依赖的人。若发布、运维或安全约束会影响方案，应在相关议题上邀请对应人员，而不是要求所有利益相关方参加全程会议。

人员太少，重要约束容易遗漏；人员太多，讨论容易变成长时间的需求评审。会前材料越充分，会议越能聚焦取舍和风险，而不是现场补写背景。

5. 完成率不高，是不是说明团队表现差

不能只凭完成率判断。需要结合新增工作、需求变更、目标达成、质量结果和依赖等待一起分析。团队可能完成率较低，却成功处理了影响重大的线上问题；也可能完成率很高，但承诺目标过小，或者忽略了上线后的用户效果。

完成率适合用来发现计划和实际之间的偏差，不适合脱离上下文做个人排名。若将其直接用于奖惩，团队容易通过降低承诺量或拆分工作方式来优化数字，而不是优化真实交付。

6. 使用工具后，排期就会更准吗

工具可以让需求、负责人、状态、依赖和变更记录更容易追踪，但不会自动让价值判断正确，也不会替团队识别所有隐藏工作。工具的有效性取决于流程是否简单、字段是否有用、数据是否及时更新，以及决策责任是否明确。

选型时，我建议先明确组织真正需要解决的问题：是跨团队依赖不可见、需求状态不一致，还是测试反馈无法回到需求？再用真实流程试运行，检查角色权限、历史数据迁移、集成维护和管理成本。功能数量多，不等于更适合；能否让关键决策更快、更可追溯，才是判断重点。

十、最后的判断：一份好计划，允许改变，但不允许隐形变化

1. 把计划当作可检验的假设

迭代计划不是对未来的保证，而是团队基于当前信息做出的可检验假设：这些工作有价值，当前容量足够，依赖可以按期满足，验收条件能够证明结果。周期中出现新证据时，计划可以调整；但调整要让影响和责任都可见。

这也是我认为排期最容易被忽略的专业能力：不是让计划永远不变，而是让团队知道在什么条件下改变、由谁改变、改变后牺牲什么。规则清楚，团队反而更能灵活响应。

2. 下一步先做三个动作

• 回看最近三个迭代的计划与实际记录，区分常规工作、支持工作和临时变更，不急着用一个平均数概括所有偏差。
• 为下一轮候选需求补齐目标、验收方式、依赖和风险，把信息不足的事项先转成有时间边界的探索任务。
• 规划会中明确承诺层、候选层和新增工作规则，并指定一个人记录变更及受影响事项。

如果只能保留一个原则，我会选这一条：不要用满载的计划证明团队积极，要用可解释的承诺证明团队可靠。真正成熟的迭代规划，不是把每个人的时间占满，而是在有限容量内优先交付最值得做的结果，让风险尽早暴露，让每一次取舍都能被团队和业务方共同理解。