迭代计划要处理的约束主要有五类：时间盒与团队可用容量、需求范围与优先级、外部依赖与固定时点、质量与验收门槛，以及迭代周期本身。排期时先锁定周期和真实可用工时，再按优先级把需求裁剪到容量之内，逐条登记依赖并预留缓冲，最后用完成定义和验收标准作为收口条件。下面按这个顺序给出可执行的步骤和配套表格。
要点总览（TL;DR）
- 迭代计划的约束集中在五类：时间盒与团队可用容量、需求范围与优先级、外部依赖与固定时点、质量与验收门槛、迭代周期本身。
- 先按角色核算真实可用容量，从名义工时中扣除休假、会议、支持值班等占用，识别瓶颈角色，再按优先级把承诺范围裁剪到容量之内。
- 依赖逐条登记类型、责任人和期望时间，不确定的依赖后留1到3个工作日缓冲并计入排期；发布窗口、合规节点等固定时点要倒推关键节点。
- 完成定义和验收标准在计划阶段写清，测试与验收工时计入容量；未完成的工作在回顾时重新评估优先级，不默认顺延到下一迭代。
先锁定时间盒与团队可用容量
迭代计划的第一步是确定时间盒，也就是这一轮迭代从哪天开始、到哪天结束、中间有没有节假日或发布冻结期。周期一旦确定，就不再因为需求增加而延长，范围调整只能在周期内做。两周迭代通常以周一为起点、次周五为终点，起止日期要写进计划文档，作为后续所有时间估算的基准。
时间盒确定后，核算团队真实可用容量。名义工时是人数乘以工作日，真实容量要从中扣除以下占用：
- 已批准的休假、调休和法定假日；
- 计划内的会议，包括站会、评审会、跨部门同步会；
- 支持值班、线上问题处理等固定占用；
- 培训、面试、行政事务等非交付工作。
容量要按角色或技能分别核算，而不是只算一个总人天。开发、测试、设计各自的可用工时分开统计，才能看出哪个角色是瓶颈。例如两名后端各可用8天、一名前端可用6天、一名测试可用5天，那么测试就是这一迭代的瓶颈角色，范围裁剪要优先考虑测试能承接多少。
容量结论要写成可引用的数字，例如“本迭代开发可用16人天、测试可用5人天、设计可用3人天”，并注明扣除项。这份按角色拆分的容量表是后续裁剪范围的唯一上限，任何新增需求都要对照它判断是否装得下。
| 角色 | 人数 | 名义工时（人天） | 扣除项 | 可用容量（人天） |
|---|---|---|---|---|
| 后端开发 | 2 | 20 | 休假2、会议1、值班1 | 16 |
| 前端开发 | 1 | 10 | 会议1、培训1、值班1 | 7 |
| 测试 | 1 | 10 | 会议1、支持2 | 7 |
| 设计 | 1 | 10 | 会议1、其他项目2 | 7 |
按优先级把需求裁剪到容量之内
容量确定后，处理范围约束。候选需求来自需求池，进入迭代前要按业务价值、紧急程度和风险排序，排序结果由产品负责人确认。排序之后，把颗粒度大的需求拆成能在一个迭代内完成的小项，拆分依据是需求与验收标准，拆到每个小项都能独立开发、独立测试、独立验收为止。
范围清单要区分承诺范围和延伸范围。承诺范围是团队承诺本迭代必须完成并达到验收标准的需求，其估算总量必须落在可用容量之内，通常留出10%到20%的余量应对估算偏差。延伸范围是容量有余时再做的需求，不进入承诺，完不成不影响迭代目标。这样划分的好处是：迭代目标清晰，团队不会因为范围模糊而同时推进过多事项。
范围超载时的取舍规则要提前约定，常见做法是：
- 先砍延伸范围，承诺范围不动；
- 承诺范围仍超载时，按优先级从低到高移出需求，移出的需求回到需求池重新排序；
- 不通过延长工时或压缩测试时间来消化超载；
- 新增需求必须同时移出等量工作，保持总量不变。
最终产出一份迭代范围清单，每条需求标注承诺或延伸、估算工时、对应角色，清单合计与容量表逐角色比对，确认没有角色超载。
识别外部依赖与固定时点约束
内部范围确定后，处理外部不确定性。依赖主要有三类：上游团队交付的接口或组件、第三方接口的联调与开通、环境与数据准备（测试环境、脱敏数据、账号权限）。这些事项不在本团队控制范围内，但会直接卡住排期，必须在计划阶段逐条登记。
固定时点约束单独列出，包括发布窗口、合规审查节点、客户验收日期。固定时点的特点是不可移动，计划要倒推：从时点往前排出提测时间、联调时间、验收准备时间，确认每个节点前需要什么输入、由谁提供。
依赖登记表建议包含以下字段：依赖事项、类型、提供方与责任人、期望交付时间、对本迭代的影响、当前状态、备用方案。每条依赖都要有本团队内的跟进人，负责在约定时间前确认进度，发现延迟立即上报。
| 依赖事项 | 类型 | 提供方/责任人 | 期望时间 | 影响 | 备用方案 |
|---|---|---|---|---|---|
| 支付接口联调环境 | 第三方接口 | 外部厂商/张三 | 第5个工作日 | 阻塞支付需求提测 | 先用沙箱模拟，联调顺延2天 |
| 用户中心接口变更 | 上游团队交付 | 平台组/李四 | 第3个工作日 | 阻塞登录改造 | 按旧接口开发，变更下迭代适配 |
| 生产发布窗口 | 固定时点 | 运维/王五 | 迭代最后一天 | 决定提测截止日 | 无，需提前完成验收 |
对不确定的依赖要预留缓冲，做法是在依赖期望时间之后留出1到3个工作日的等待余量，并把缓冲计入排期而不是藏在估算里。缓冲被消耗时要记录原因，供回顾时分析。
把质量门槛与验收标准写进计划
质量约束决定“完成”的含义，必须在计划阶段写清楚，避免测试和验收被挤到迭代末尾再压缩。完成定义是团队对“做完”的统一标准，常见检查项包括：代码评审通过、单元测试覆盖关键逻辑、提测版本部署到测试环境、测试用例执行完毕且无阻断级缺陷、验收标准逐条确认、文档更新。
测试、评审、验收所需的时间和人力要计入容量表，而不是默认“开发完自然有时间测”。如果测试角色可用5人天，而承诺范围的提测工作量需要8人天验证，就要在范围裁剪阶段削减需求，而不是指望加班。质量不达标时的处置方式也要提前约定：阻断级缺陷必须修复后才能发布，一般缺陷可评估后带入下一迭代，但要在计划中记录并说明理由。
验收标准与需求条目一一对应，每条承诺需求都要有可核验的验收条件，例如“订单列表支持按状态筛选，筛选结果与数据库查询一致”。验收标准模糊的需求不进入承诺范围，先补充清楚再排期。这份完成定义与验收标准清单是迭代评审时的核对依据。
角色分工与计划交付物
约束要落到人，计划工作才有归属。产品负责人负责需求排序、承诺范围确认和验收标准定义；迭代负责人负责组织计划会议、汇总容量与范围、登记依赖并跟踪缓冲消耗；开发人员负责需求拆分与技术估算，识别技术依赖；测试人员负责测试工作量估算、完成定义中的测试检查项和验收执行。计划评审由上述角色共同参加，范围与容量的最终确认由产品负责人和迭代负责人共同决策，技术可行性争议由开发负责人给出结论。
| 角色 | 计划职责 | 产出 |
|---|---|---|
| 产品负责人 | 需求排序、承诺范围确认、验收标准定义 | 排序后的候选需求、验收标准 |
| 迭代负责人 | 组织计划会议、汇总容量与范围、登记依赖 | 迭代计划文档、依赖登记表 |
| 开发人员 | 需求拆分、技术估算、识别技术依赖 | 子任务拆分与工时估算 |
| 测试人员 | 测试工作量估算、完成定义检查项、验收执行 | 测试计划、验收记录 |
计划文档建议包含以下字段：迭代名称与起止日期、按角色拆分的容量表、范围清单（含承诺/延伸标注与估算）、依赖登记表、固定时点清单、完成定义与验收标准、缓冲设置、变更记录。计划变更走申请与确认路径：提出人说明变更原因和影响，迭代负责人评估对容量和依赖的影响，产品负责人确认范围调整，变更记入文档后才生效。
这些计划信息需要在协作工具中承载，让容量、范围、依赖和验收状态在执行中可查。ONES 支持产品负责人按优先级把需求规划到对应迭代，并在迭代计划会议上与团队评审需求与验收标准；达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续跟踪。迭代执行中，团队通过敏捷看板管理任务状态，在站会上对齐进度与风险；测试人员依据验收标准编写并执行用例，未通过的用例可转为缺陷指派给对应工程师修复。迭代结束后的回顾会可结合燃尽图、工时日志等报表复盘进度与质量偏差，为下一轮容量核算和缓冲设置提供依据。
一个迭代计划的填写示例
以下为演示情景，数据需按团队实际情况替换。某团队进行两周迭代，共10个工作日，按角色核算后开发可用16人天、前端7人天、测试7人天、设计7人天。候选需求经排序后，承诺范围包含订单筛选改造（后端5人天、前端3人天、测试3人天）、登录流程优化（后端4人天、前端2人天、测试2人天）、报表导出（后端4人天、测试2人天），合计后端13人天、前端5人天、测试7人天，均在容量之内，测试恰好用满，因此不再纳入延伸范围中的“消息通知改版”。
依赖方面，登录流程优化依赖平台组的用户中心接口变更，期望第3个工作日交付，登记责任人为平台组李四，本团队跟进人为后端张三，并在其后预留2个工作日缓冲；报表导出依赖第三方数据接口开通，期望第5个工作日完成，备用方案是先用静态数据验证导出逻辑。固定时点为迭代最后一天的生产发布窗口，倒推提测截止日为倒数第4个工作日。
质量门槛写入计划：承诺需求全部通过代码评审，测试用例执行完毕且无阻断级缺陷，验收标准逐条确认后方可发布。计划中明确，若用户中心接口延迟超过缓冲，登录流程优化移出承诺范围，回到需求池重新排序，不通过压缩测试时间弥补。这个取舍的理由是测试容量已用满，压缩测试会直接推高发布风险。
计划完成前的检查项
计划进入执行前，用下面的清单逐项核对，全部有明确结论才算完成：
| 检查项 | 通过标准 |
|---|---|
| 时间盒 | 起止日期、节假日与冻结期已写入计划 |
| 容量 | 按角色拆分，扣除项列明，瓶颈角色已识别 |
| 范围 | 承诺项逐角色合计不超过容量，延伸项单独标注 |
| 依赖 | 每条依赖有类型、责任人、期望时间和备用方案 |
| 固定时点 | 发布窗口、合规节点、验收日期已倒排出关键节点 |
| 缓冲 | 不确定依赖后留有缓冲，缓冲计入排期 |
| 质量 | 完成定义检查项完整，测试与验收工时已计入容量 |
| 验收标准 | 每条承诺需求有可核验的验收条件 |
| 变更规则 | 新增需求的等量移出规则、变更确认路径已约定 |
| 未完成工作 | 明确在回顾时重新评估优先级，不默认顺延到下一迭代 |
核对中任何一项没有结论，计划就停在草稿状态，补齐后再进入执行。执行过程中范围或依赖发生变化，按变更路径处理并更新计划文档，保持计划与实际一致。
常见问题
迭代周期中途插入紧急需求，计划应该怎么调整？
按计划中约定的变更路径处理：提出人说明原因和影响，迭代负责人评估对容量和依赖的冲击，产品负责人确认范围调整。常见做法是新增需求的同时移出等量工作，保持承诺范围总量不变；如果移不出等量工作，就把新需求放入延伸范围或下一迭代。不建议通过延长工时或压缩测试时间来消化新增需求，这会直接推高发布风险。
团队第一次按角色核算容量，没有历史数据怎么办？
先用名义工时减去已确定的扣除项（休假、固定会议、值班），得到一个初始容量，再在迭代执行中记录实际投入，用一两轮的数据校正。回顾时可以结合工时日志对照计划容量与实际消耗，逐步把会议、支持等占用的比例估准。初期宁可把容量估低一些，留出余量，也不要按满负荷排承诺范围。
依赖方延迟交付，缓冲用完了还没到位，怎么处理？
缓冲消耗完仍未交付时，按计划中预设的取舍规则执行：受影响的需求移出承诺范围，回到需求池重新排序，同时更新依赖登记表的状态和影响说明。如果该需求有固定时点约束（如客户验收日期），需要评估备用方案是否可行，例如按旧接口先开发、变更下迭代适配。处理结果记入计划文档，在回顾时分析延迟原因，作为下一轮缓冲设置的依据。
承诺范围里的需求做到一半发现估算偏差很大，能直接顺延到下一迭代吗？
不默认顺延。先在当前迭代内判断：能否通过缩小需求范围（保留核心验收条件、拆出次要部分）在剩余容量内完成；如果确实完不成，在回顾时重新评估该需求的优先级，由产品负责人决定是回到需求池、拆小后重新排入，还是下迭代继续。顺延本身不是默认动作，需要经过优先级判断并记录理由。
计划中的容量、范围、依赖和验收状态，用什么方式承载比较合适？
这些信息需要在执行中持续可查，适合放在协作工具里而不是只留在文档中。以 ONES 为例，产品负责人可以按优先级把需求规划到对应迭代，在迭代计划会议上与团队评审需求和验收标准；达成一致后，设计、研发、测试人员用子任务拆分需求，执行中通过敏捷看板管理任务状态，测试人员依据验收标准编写并执行用例，未通过的用例可转为缺陷指派给对应工程师修复。迭代结束后的回顾会可结合燃尽图、工时日志等报表复盘进度与质量偏差。
