迭代规划要处理的约束通常有五类：需求与范围、产能与人员、时间与节奏、外部依赖与质量、组织与流程。规划时先把这些约束逐项列出，标注哪些不可协商、哪些可以调整，再折算成团队能承诺的工作量，留出缓冲，并在迭代中设检查点跟踪变化。下面按识别、折算、分工、示例、跟踪和验收的顺序给出可执行步骤，其中约束清单和迭代范围在ONES中可由需求、任务与迭代视图承载。
要点总览（TL;DR）
- 迭代规划要盘点五类约束：需求与范围、产能与人员、时间与节奏、外部依赖与质量、组织与流程，并逐条标注硬约束或软约束。
- 把约束折算成可承诺范围需要三个数：可用产能、固定占用和缓冲；缓冲比例按团队历史波动确定并写明用途。
- 产品负责人、研发负责人、测试负责人、项目负责人和外部依赖对接人各有明确输入与交付物，约束变更要有确认与升级路径。
- 迭代中通过每日站会和每周范围对照跟踪约束变化；未完成工作重新评估必要性、剩余工作量和下一迭代条件后再决定去向。
- 规划会结束前用检查表核对约束显性化、产能依据、依赖责任人、缓冲用途和不做项记录，未通过项在迭代开始前补齐或记为已知风险。
先列约束清单：迭代规划要盘点的五类约束
约束盘点要在排期之前完成，目的是把“到时候再说”的隐性条件提前摆到桌面上。建议用一张表逐项填写，每行写清约束内容、影响对象、责任人和硬软属性。五类约束的盘点口径如下。
| 约束类别 | 盘点内容 | 常见硬约束 | 常见软约束 |
|---|---|---|---|
| 需求与范围 | 需求优先级、验收标准是否明确、需求颗粒度是否可拆分、需求之间的先后依赖 | 合同或合规要求必须交付的需求；验收标准未定导致无法开工 | 优先级排序、需求拆分粒度、可延后的增强项 |
| 产能与人员 | 可用人力、请假与培训安排、并行任务占用、技能缺口 | 关键岗位人员请假或离职；只有个别人掌握的技能 | 并行任务分配、结对与交叉培训安排 |
| 时间与节奏 | 迭代长度、发布窗口、评审与测试所需时间 | 对外承诺的发布窗口；固定日期的评审或上线节点 | 迭代内各环节的时间分配比例 |
| 外部依赖与质量 | 上下游团队交付、第三方接口就绪时间、缺陷修复与技术支持占用 | 第三方接口未就绪；上游团队交付日期已锁定 | 缺陷修复的插入比例、支持工单的响应安排 |
| 组织与流程 | 审批环节、合规检查、固定例会、跨团队协同会议 | 必须走的审批或合规检查 | 会议时长与频次、协同方式 |
硬约束指不因团队意愿改变的条件，例如已对外承诺的发布日期、必须通过的合规检查、关键人员已批准的假期。软约束指在范围内可以协商的条件，例如某个需求的优先级、某次会议能否改期。处理方式不同：硬约束直接作为排期的边界条件，先满足再安排其他工作；软约束在产能不足时按影响大小依次调整，并记录调整理由，便于后续复盘。
盘点时容易漏掉的是“占用型”约束：技术支持、线上问题处理、面试、培训这类工作不体现在需求列表里，却真实消耗人力。把它们单独列一行，估算每周大致占用的人天，后续折算产能时直接扣除。
把约束折算成可承诺的工作量
约束清单本身不构成排期结论，需要折算成本迭代能承诺的范围。折算的核心是三个数：可用产能、固定占用、缓冲。
第一步，确定产能口径。团队有稳定历史数据的，用近几个迭代的平均完成量作为速率参考；数据不足的新团队，用可用人天估算：迭代总工作日乘以投入比例，再减去请假、培训等不在岗时间。两种口径都应在规划会上说明来源，避免各角色对“能干多少”理解不一致。
第二步，扣除固定占用。把约束清单中已识别的会议、技术支持、缺陷修复、审批配合等时间从产能中减去。缺陷修复和支持工作如果波动较大，可以按历史占比估算，例如每迭代预留一定比例的人力处理线上问题，而不是等发生了再挤占计划内工作。
第三步，按依赖排序。需求之间存在先后关系时，先排被依赖项，再排依赖项；跨团队依赖的需求，把对方交付时间作为前置条件写入排期，对方时间未确认的需求不进入本迭代承诺范围，或只承诺到“等待依赖”之前的准备工作。
第四步，设置缓冲。缓冲比例依据团队历史波动确定：交付时间受外部影响大、需求变更频繁的团队，缓冲比例应更高；流程稳定、需求变化少的团队可以低一些。缓冲要写明用途，例如应对第三方延迟或紧急缺陷，而不是留作“机动加需求”的空间。
最后把结论写成两份清单：一份是本迭代承诺完成的范围，逐项列出需求、负责人和验收标准；一份是本迭代明确不做的事项及原因。不做项写清楚，能减少迭代中途的范围争议。
| 折算项 | 计算方式 | 输出 |
|---|---|---|
| 可用产能 | 历史速率或可用人天，扣除请假与培训 | 本迭代总产能 |
| 固定占用 | 会议、支持、缺陷修复、审批配合的估算人天 | 可分配给需求计划的产能 |
| 缓冲 | 按历史波动设定比例，写明用途 | 可承诺范围的上限 |
| 依赖排序 | 先排被依赖项，跨团队依赖标注前置时间 | 承诺范围清单与不做项清单 |
角色分工与各环节交付物
约束收集和范围确认涉及多个角色，职责不清时最容易出现“都以为对方在跟”。下表按动作列出输入、输出和完成标志，团队可据此对照分工。
| 角色 | 关键动作 | 输入 | 输出 | 完成标志 |
|---|---|---|---|---|
| 产品负责人 | 整理需求优先级与验收标准，提出候选范围 | 需求池、业务方诉求 | 带优先级和验收标准的需求清单 | 每个候选需求都有明确验收标准 |
| 研发负责人 | 评估技能缺口、并行任务与技术依赖 | 需求清单、人员排班 | 产能与人员约束条目 | 关键技能缺口有应对安排 |
| 测试负责人 | 评估测试时间、环境与质量风险 | 需求清单、历史缺陷数据 | 测试时间与质量约束条目 | 测试窗口在排期中已预留 |
| 项目负责人 | 汇总约束清单，组织规划会，形成承诺范围 | 各方约束条目 | 约束清单、可承诺范围与不做项 | 范围经各方确认并记录 |
| 外部依赖对接人 | 确认上下游团队与第三方交付时间 | 依赖事项清单 | 依赖时间点与责任人 | 每个外部依赖有明确日期和联系人 |
约束在迭代中发生变化时，需要有明确的确认与升级路径。一般做法是：影响本迭代承诺范围的变更，由提出方书面说明原因和影响，项目负责人评估后组织相关角色确认；涉及对外承诺或硬约束冲突的，升级到产品负责人和团队负责人共同决定。变更结论要回写到约束清单和范围清单，保持两份文档与实际情况一致。
在ONES中，产品负责人可以按优先级把需求规划到对应迭代，并在迭代计划会上与团队评审需求与验收标准；达成一致后，设计、研发、测试人员用子任务拆分需求，便于后续跟踪。任务工时统计和持续时间估算可以为产能折算提供数据基础，具体统计口径按团队配置确认。
示例：一次两周一迭代的约束盘点与排期
以下为演示情景，用于说明从约束清单到排期结论的过程，不代表真实客户案例。
背景：一个由产品、后端、前端、测试共8人组成的团队，采用两周一迭代，本迭代有一个对外发布窗口在迭代结束后的第三个工作日。
约束清单填写结果：需求与范围方面，候选需求12项，其中2项验收标准未定，属于硬约束，暂不纳入；产能与人员方面，1名后端工程师请假3天，1名前端工程师每周有约1天支持线上问题；时间与节奏方面，发布窗口固定，测试需预留3个工作日；外部依赖与质量方面，一个支付接口由第三方提供，对方承诺迭代第7个工作日就绪；组织与流程方面，迭代中有一次合规评审需要产品负责人参加半天。
产能折算：团队两周期内总可用人天约72人天，扣除请假3人天、线上支持约2人天、合规评审0.5人天、固定会议约4人天，剩余约62人天；按历史波动设置约10%缓冲，可承诺范围控制在约56人天以内。
依赖排序与取舍：支付接口相关需求排在第7个工作日之后，前置的页面与流程开发先排；验收标准未定的2项需求移出本迭代，列入待明确清单；发布窗口前的测试时间单独锁定，不安排新需求进入测试阶段。
排期结论：本迭代承诺9项需求，合计约54人天，留出约2人天机动；不做项包括2项验收标准未定的需求和1项依赖外部数据、时间未确认的需求。遗留风险是支付接口若延迟，相关联调与测试会被压缩，需要在迭代第7个工作日设置检查点确认接口状态。
迭代中的检查点与未完成工作的处理
规划落地后，约束是否仍然成立需要持续跟踪。每日站会看三件事：承诺范围内任务的进展、阻塞项及其责任人和解决时间、新出现的约束（例如临时支持请求、依赖方延迟）。每周增加一次范围与产能对照，比较已完成工作量和剩余工作量与缓冲的消耗情况。
约束被打破时的调整动作按影响程度分档：影响单个任务进度的，由任务负责人调整顺序并在站会同步；影响本迭代承诺范围的，由项目负责人组织相关角色评估，决定缩减范围、动用缓冲或升级处理；涉及硬约束冲突的，立即升级到产品负责人和团队负责人，不在团队内部自行消化。
迭代结束时，未完成工作应重新评估，而不是默认结转到下一迭代。判断依据包括：该工作是否仍然必要、剩余工作量是否已重新估算、下一迭代的约束条件是否允许纳入、继续推迟的代价是什么。重新评估后，必要且可安排的工作进入下一迭代规划，不再必要的工作关闭或退回需求池，需要拆分的工作先拆分再评估。这样做的目的是让下一迭代的承诺范围仍然建立在真实约束之上。
在迭代执行中，团队可以通过敏捷看板管理任务状态，在每日站会上对齐进度与风险；燃尽图可用于观察剩余工作量与进度的偏差，为是否动用缓冲提供参考。
完成检查：迭代规划是否可执行
规划会结束前，用下面的检查表逐项核对。全部通过，说明本次规划具备执行条件；有未通过项，应在迭代开始前补齐或明确记录为已知风险。
| 检查项 | 通过标准 |
|---|---|
| 约束是否全部显性化 | 五类约束均有条目，每条标注硬约束或软约束及责任人 |
| 可承诺范围是否有产能依据 | 范围总量不超过扣除固定占用和缓冲后的产能，折算口径已说明 |
| 依赖与外部约束是否有责任人和时间点 | 每个外部依赖有对接人、交付日期和检查点 |
| 缓冲是否明确 | 缓冲比例有依据，用途已写明 |
| 不做项是否记录 | 本迭代不做的需求及原因已列出并同步相关方 |
| 未完成处理规则是否明确 | 团队对重新评估而非默认结转的做法达成一致 |
| 检查点是否安排 | 每日站会和每周范围对照的时间、参与人已确定 |
这张检查表可以随迭代复盘更新：如果某个约束反复被遗漏，就把它固化为清单中的固定条目；如果缓冲经常被提前耗尽，就复核缓冲比例和固定占用的估算是否偏低。规划质量靠每次迭代的核对和修正逐步稳定。
常见问题
迭代规划时硬约束和软约束判断不一致怎么办？
判断分歧通常来自对“能否改变”的理解不同。处理办法是让提出方说明改变该约束需要谁同意、代价是什么：需要外部客户或合规部门同意才能调整的，按硬约束处理；团队内部协商即可调整的，按软约束处理。仍有争议的，由项目负责人记录双方理由，在规划会上一次性确认，避免迭代中途反复讨论。确认结果回写到约束清单，作为后续迭代的参考。
团队没有历史速率数据，第一次迭代规划怎么折算产能？
可以用可用人天作为初始口径：迭代总工作日乘以投入比例，再扣除请假、培训、会议、技术支持和缺陷修复等固定占用，剩余部分作为可安排需求计划的产能。首次规划建议把缓冲比例设得比稳定团队更高，并在迭代结束后记录实际完成量，作为下一次规划的速率参考。连续两三个迭代积累数据后，再逐步过渡到按历史速率折算。
外部依赖方延迟交付，本迭代承诺范围要不要马上调整？
先判断延迟影响的是单个任务还是承诺范围。影响单个任务的，由任务负责人调整顺序并在站会同步；导致关联需求无法在迭代内完成的，由项目负责人组织相关角色评估，选择缩减范围、动用缓冲或把依赖项相关工作调整为准备工作。涉及对外承诺的，升级到产品负责人和团队负责人共同决定。调整结论要回写范围清单，并在迭代复盘中记录依赖方的实际交付表现。
未完成工作重新评估后，什么情况下应该关闭而不是放入下一迭代？
常见判断依据有三条：该工作对应的业务需求已经变化或取消；剩余工作量重新估算后明显超出下一迭代可安排空间；继续推迟的代价低于挤占其他更高优先级工作的代价。满足其中一条时，可以关闭或退回需求池，并记录原因。需要保留的，先拆分再评估，确保进入下一迭代的部分有明确验收标准和工作量估算。
约束清单和迭代范围在ONES中如何对应到具体工作项？
ONES 敏捷研发管理方案支持产品负责人按需求优先级把产品待办列表中的需求规划到对应迭代，并在迭代计划会议上与团队评审需求与验收标准；达成一致后，设计、研发、测试人员用子任务拆分需求，便于后续跟踪。ONES Project 支持把需求和相关任务规划至迭代并分配负责人，并提供任务工时统计与估算任务持续时间的能力，可作为产能折算的数据基础。约束清单本身可按团队习惯以文档或工作项形式承载，具体方式按团队配置确定。
