迭代容量是团队在一个迭代时间窗内可稳定投入并完成的工作量上限，通常以故事点或人时计量。它由可用人力、有效工时、非交付占用和历史完成率共同决定，算出的结果用于制定承诺，而非考核个人。本文按“定范围—取数据—套公式—看算例—做解读”的顺序，给出可复算的计算口径与步骤。
要点总览（TL;DR）
- 迭代容量是团队在一个迭代时间窗内可稳定投入并完成的工作量上限，由可用人力、有效工时、非交付占用和历史完成率共同决定，用于制定承诺而非考核个人。
- 计算分三步：先汇总可用人力与有效工时，再扣除非交付占用得到可投入容量，最后乘以历史完成率折算承诺容量；单位在团队内保持稳定。
- 取数要有明确来源：人力来自迭代参与名单，工时来自工作日历与休假记录，占用来自会议与支持安排，完成率取最近3至6个迭代的完成量与承诺量。
- 容量是承诺参考值，团队之间因单位与估算基准不同不宜直接横向比较；未完成工作应在下一迭代重新评估，不默认结转。
- 算例中6人两周迭代可投入容量约268小时、承诺容量约114点，实际完成量偏差需结合阻塞与需求变更记录解释，连续观察多个迭代后再校准完成率。
评估目标：迭代容量要回答什么问题
容量评估服务于迭代承诺与计划平衡：在迭代开始前，判断团队能接下多少工作；在迭代结束后，判断承诺是否合理、偏差来自哪里。它回答的是“这个迭代团队能稳定完成多少”，而不是“谁做得最多”。
实际使用中需要区分三类量。可投入容量是扣除非交付占用后，团队真正能用于交付的时间或工作量；承诺容量是在可投入容量基础上，结合历史完成率折算出的、可以对外承诺的上限；实际完成量是迭代结束后真正交付并验收的工作量。三者关系是：可投入容量是物理上限，承诺容量是计划参考，实际完成量是结果验证。
评估结果的使用边界需要提前说清。容量适合用于排期、识别过载、校准估算；不适合作为绩效排名依据，也不宜直接推导“容量高就是效率高”。容量是承诺参考值，不保证产出与容量等量，迭代中出现的阻塞、需求变更和协作等待都会让实际完成量偏离承诺。
指标与范围：容量用哪些量、覆盖哪些人和时间
计算前先固定单位、人员和时窗，三项口径一旦确定，应在多个迭代内保持一致，否则前后数据不可比。
| 口径项 | 可选方式 | 适用条件 |
|---|---|---|
| 计量单位 | 故事点 | 团队已建立相对估算基准，需求粒度较稳定，适合以工作量而非时间衡量 |
| 计量单位 | 人时或理想人天 | 任务可拆分到小时级，团队希望直接对接工时记录与排期 |
| 统计人员 | 参与交付的角色 | 研发、测试等直接产出工作项的角色；产品、设计是否计入需团队约定并保持稳定 |
| 统计人员 | 是否含跨团队支持 | 若成员固定抽出部分时间支持其他团队，应作为占用项扣除，而非简单不计入 |
| 时间窗 | 单个迭代周期 | 通常为一周至四周，本文以两周迭代为例 |
| 时间窗 | 节假日与休假 | 按实际工作日扣除，法定假日和已批准休假不计入有效工时 |
单位选择的关键是稳定。故事点适合估算相对规模，但不同团队的“1点”含义不同；人时直观，但容易把等待、会议等非交付时间混入。无论选哪种，都应在团队内写明换算约定，并在回顾中检查是否需要调整基准。
数据口径与证据：工时、占用与完成率怎么取数
容量计算的可复算性取决于每个输入项都有明确来源。建议按下表建立取数清单，并在迭代计划会上确认数据截止时间。
| 输入项 | 取数来源 | 口径规则 |
|---|---|---|
| 可用人力 | 团队名册、迭代参与人员名单 | 按迭代周期内实际参与交付的人数统计，中途加入或退出按在迭代内的实际天数折算 |
| 有效工时 | 工作日历、考勤或排班记录 | 迭代工作日 × 每人每日有效工时，扣除法定假日与已批准休假 |
| 非交付占用 | 会议日历、支持工单、值班安排 | 按迭代内已排定的会议、跨团队支持、运维值班等逐项记录，以小时或人天扣除 |
| 历史完成率 | 最近若干迭代的承诺量与实际完成量 | 分子为迭代内实际完成并验收的工作量，分母为该迭代承诺的工作量；统计窗口建议取最近3至6个迭代并保持口径一致 |
缺失值和异常数据需要预设规则。某成员休假未记录时，按日历补录；某迭代完成率明显偏离（如因需求整体取消导致分母虚高），应在统计时标注并说明是否剔除；完成率样本少于3个迭代时，结果只作参考，不直接用于对外承诺。所有调整都应留下记录，保证下一轮可以复算。
计算步骤：从可用工时到可承诺容量
计算按三步推进，每一步都保留中间结果，便于核对和复盘。
步骤一：汇总可用人力与有效工时。有效工时 = 参与人数 × 迭代工作日 × 每人每日有效工时 − 休假与假日折算工时。若以故事点计量，则先用人时结果作为参照，再按团队历史换算关系折算为点数。
步骤二：扣除非交付占用，得到可投入容量。可投入容量 = 有效工时 − 会议工时 − 跨团队支持工时 − 值班及其他固定占用。占用项按迭代内实际排定内容逐项累加，不用经验比例替代。
步骤三：结合历史完成率折算承诺容量。承诺容量 = 可投入容量 × 历史完成率。历史完成率 = 最近若干迭代实际完成量之和 ÷ 同期承诺量之和。使用加权汇总而非简单平均，可以避免小迭代对结果影响过大。
边界情况需要单独处理。分母为零时，例如团队首次运行或历史数据缺失，完成率无法计算，此时承诺容量暂按可投入容量的一定折扣估算，并在迭代后补齐数据再校准；可投入容量为零或为负时，说明占用已超过可用时间，应先调整排期或人员投入，而不是继续套公式。单位需在公式中统一标注，人时与故事点不可混算。
算例：一个两周迭代的容量计算
以下为演示情景，团队规模、占用比例与完成率均为假设值，实际使用时替换为本团队数据。
假设一个6人团队，迭代周期两周，共10个工作日，每人每日有效工时6小时。迭代内有1人休假2天，另安排1天团队活动。已排定会议合计每人每周3小时，一名成员每周投入4小时支持其他团队。
步骤一：有效工时 = 6人 × 10天 × 6小时 − 1人 × 2天 × 6小时 − 6人 × 1天 × 6小时 = 360 − 12 − 36 = 312小时。
步骤二：会议占用 = 6人 × 2周 × 3小时 = 36小时；跨团队支持 = 1人 × 2周 × 4小时 = 8小时。可投入容量 = 312 − 36 − 8 = 268小时。
步骤三：假设最近4个迭代承诺量合计400点、实际完成量合计340点，历史完成率 = 340 ÷ 400 = 85%。若团队按每点约2小时折算，可投入容量约134点，承诺容量 = 134 × 85% ≈ 114点。
迭代结束后，若实际完成量为105点，与承诺量相差约8%，属于正常波动范围，可结合阻塞时长和需求变更记录解释；若实际完成量仅为80点，则需检查估算基准是否漂移、占用项是否漏记，再决定下一轮是否下调承诺。
解读与限制：容量数字能说明什么、不能说明什么
容量反映的是团队在给定条件下的计划承载能力，与产出质量、绩效高低是不同层面的问题。一个团队容量数字较高，可能只是单位换算或人员配置不同，不能据此判断其效率更高；同样，实际完成量低于承诺量，也应先排查需求变更、依赖等待和占用漏记，避免直接归因于个人。
团队之间的容量数字不宜直接横向比较。故事点基准、任务拆分粒度、统计人员范围和占用扣除方式不同，都会让数字失去可比性。跨团队协调时，应比较承诺兑现率和偏差原因，而不是比较容量绝对值。
迭代内出现容量偏差时，处理原则是重新评估而非默认结转。未完成工作应在下一迭代重新确认优先级和估算，避免把上一轮的承诺直接累加进新迭代，造成容量虚高。每个迭代回顾时，可将承诺量、实际完成量和主要偏差原因并列记录，连续观察3至6个迭代后再调整完成率参数，让容量逐步贴近团队的真实节奏。
当团队在ONES中管理迭代时，需求规划、任务状态和工时日志会随迭代过程自然沉淀：产品负责人按优先级把需求规划进迭代，成员在看板上更新任务状态，迭代回顾时可结合燃尽图与工时日志核对承诺量与实际完成量，为下一轮容量计算提供同口径的数据来源。
常见问题
团队第一次做迭代容量计算，历史完成率还没有数据怎么办？
完成率样本不足时，可以先用可投入容量乘以一个保守折扣作为临时承诺容量，例如按80%估算，并在迭代结束后记录实际完成量。连续积累3个以上迭代的数据后，再改用实际完成率折算。这个阶段的结果只作内部排期参考，不宜直接对外承诺，同时要在回顾中说明数据仍在积累。
迭代中途有成员临时加入或离开，容量要不要重算？
建议在迭代内按实际参与天数折算人力，而不是整轮重算。例如某成员迭代中途加入，只计入其加入后的工作日工时；离开的成员同理扣除剩余天数。重算后的容量用于调整后续排期，已承诺的工作是否缩减，应结合剩余工作量和优先级在迭代内重新确认，避免简单按比例砍任务。
用故事点还是人时计算容量更合适？
两种单位各有适用条件。故事点适合已建立相对估算基准、需求粒度较稳定的团队，便于横向讨论工作量；人时直观，能直接对接工时记录与排期，但容易把等待和会议时间混入。关键是选定后在多个迭代内保持一致，并写明换算约定。团队混用两种单位时，需明确以哪一种作为承诺依据，避免同一迭代出现两套口径。
算出的承诺容量和实际完成量差距较大，下一轮应该调哪个参数？
先定位偏差来源再决定调整项。若占用项频繁漏记，应完善会议与支持工时的记录；若估算基准漂移，需在回顾中重新校准故事点参照；若完成率样本波动大，可延长统计窗口或改用加权汇总。调整应一次只动一个参数，并连续观察几个迭代，避免同时改动多个口径导致结果无法解释。
ONES 里的数据能直接支撑容量计算吗？
ONES 敏捷研发管理解决方案覆盖需求池管理、迭代规划、迭代开发、迭代进度跟进与迭代回顾等场景，需求规划、任务状态和工时日志会随迭代过程沉淀。迭代回顾时可结合燃尽图与工时日志核对承诺量与实际完成量，为下一轮容量计算提供同口径的数据来源。容量或速率的专门计算功能，现有资料未明确说明，实际使用时可按本文口径从报表数据中取数汇总。
