迭代容量测算表围绕“成员—可用工时—承诺工作量—偏差”这条主线展开：先逐人算出迭代内真正可投入的工时，再折算成团队可承诺的工作量，最后用实际完成情况修正下个迭代的估算。下面给出一份可直接复制填写的空白表，并逐字段说明取数来源与计算公式，附一个两人小组的完整填写示例。
要点总览（TL;DR）
- 迭代容量测算表按“成员级容量明细—团队汇总与承诺—偏差与复盘”三块组织，字段在空白模板、字段说明和填写示例中保持同名同口径。
- 核心计算项有三个：可用容量 = 可用天数 × 每日有效工时 − 占用工时；负载率 = 承诺工作量 ÷ 团队可用容量；偏差值 = 实际完成 − 承诺工作量。
- 成员、可用天数、每日有效工时、占用工时、团队可用容量、承诺工作量、实际完成与偏差值为必填；角色、历史速率、偏差原因、按技能分组等按团队情况选填。
- 估算单位需全表统一，人天与故事点不混填；未完成工作在下个迭代重新评估后再纳入承诺，不默认自动结转。
- 每个迭代开始前更新容量与承诺，结束后填写实际完成与偏差，连续几个迭代偏差同向时修正历史速率。
可复制空白模板：迭代容量测算表
模板分三块：成员级容量明细、团队汇总与承诺工作量、偏差与复盘。三块表使用同一套字段名，填写时按顺序从第一块算到第三块，避免口径在传递中走样。
表一：成员级容量明细
| 成员 | 角色 | 可用天数 | 每日有效工时 | 占用工时 | 可用容量 |
|---|---|---|---|---|---|
| 合计 | — | — | — |
表二：团队汇总与承诺工作量
| 迭代周期 | 团队可用容量 | 历史速率 | 承诺工作量 | 负载率 |
|---|---|---|---|---|
表三：偏差与复盘
| 迭代 | 承诺工作量 | 实际完成 | 偏差值 | 偏差原因 | 下迭代调整 |
|---|---|---|---|---|---|
字段说明：每个字段填什么、怎么算
字段的价值在于口径统一。同一张表里，可用天数按工作日计，每日有效工时按扣除日常沟通后的净投入计，占用工时只记录已确定发生的占用。下面按“含义—取数来源—计算口径”逐项对照。
| 字段 | 含义 | 取数来源 | 计算口径 |
|---|---|---|---|
| 成员 | 参与本迭代交付的人员 | 团队花名册 | 一人一行，不合并 |
| 角色 | 成员在迭代中的主要职责 | 团队分工约定 | 用于按技能分组时筛选 |
| 可用天数 | 迭代周期内该成员可出勤的工作日 | 迭代日历、考勤安排 | 迭代总工作日 − 请假 − 法定假日 |
| 每日有效工时 | 单个工作日可投入交付的净工时 | 团队历史观察值 | 工作时长扣除固定会议、日常沟通后的估计值 |
| 占用工时 | 迭代内已确定被占用的工时 | 请假单、会议安排、支持排班、培训计划 | 请假、会议、支持、培训分项相加 |
| 可用容量 | 该成员本迭代真正可投入的工时 | 由前四项计算 | 可用天数 × 每日有效工时 − 占用工时 |
| 团队可用容量 | 全团队可投入工时之和 | 表一合计行 | 各成员可用容量相加 |
| 历史速率 | 过去若干迭代单位时间完成的工作量 | 历史迭代完成记录 | 取最近3至5个迭代的平均值，剔除异常迭代 |
| 承诺工作量 | 本迭代计划完成的工作量 | 迭代计划会确定 | 按历史速率折算，且不超过团队可用容量对应的上限 |
| 负载率 | 承诺工作量相对可用容量的饱满程度 | 由前两项计算 | 承诺工作量 ÷ 团队可用容量 |
| 实际完成 | 迭代结束时实际交付的工作量 | 迭代验收记录 | 按与承诺相同的单位统计 |
| 偏差值 | 实际与承诺之间的差距 | 由前两项计算 | 实际完成 − 承诺工作量 |
估算单位必须全表统一。选择人天时，承诺工作量直接以人天计，与可用容量同单位，负载率接近1表示排满；选择故事点时，承诺工作量以点计，需要先用历史速率把可用容量折算成可承诺的点数，两种单位不能在同一列混填。占用工时的记录建议分项列明，请假、会议、支持、培训各自一行或一栏，便于复盘时判断哪类占用在增长。
必填与选填：哪些字段不能省
必填字段决定这张表能否算出可信的容量结论，缺一项就会让后续计算失去依据。选填字段服务于特定管理需要，省略不影响主结论，但会损失一部分分析视角。
必填字段
- 成员、可用天数、每日有效工时、占用工时、可用容量：缺成员无法归集容量；缺可用天数或每日有效工时，可用容量无从计算；缺占用工时会把被占用的时间误算成可交付时间，导致承诺偏高。
- 迭代周期、团队可用容量、承诺工作量：缺迭代周期无法横向比较；缺团队可用容量则承诺工作量没有约束基准；缺承诺工作量，负载率与偏差都失去参照。
- 实际完成、偏差值：这两项是下个迭代修正速率的唯一依据，缺失会让表格退化为一次性计划表。
选填字段
- 角色：团队存在明显技能分工、需要按角色核对容量时填写；成员职责高度重叠的小团队可省略。
- 历史速率：首次使用该表、尚无历史数据时可暂缺，用团队经验估计值替代并标注“估计”。
- 偏差原因、下迭代调整：复盘深度要求较高时填写；仅做容量核对时可只保留偏差值。
- 按技能分组、按子系统拆分：适用于多人协作、跨模块交付的团队，把容量拆到技能或模块维度，便于识别瓶颈；单模块小团队填写会显著增加维护成本。
团队规模影响字段取舍。五人以下小组可以只保留必填字段加偏差原因，表格一页即可维护；十人以上团队建议保留角色与分组字段，否则汇总后的团队容量无法定位到具体瓶颈；跨职能团队还应增加按技能分组的容量小计，避免某一角色过载而整体负载率看起来正常。
填写示例：一个两人小组的完整测算
以下为演示情景，用于说明计算过程，数值为便于核算的假设值。背景：某两人小组，迭代周期两周共10个工作日，成员A为开发，成员B为测试与支持。
成员级容量计算
| 成员 | 角色 | 可用天数 | 每日有效工时 | 占用工时 | 可用容量 |
|---|---|---|---|---|---|
| 成员A | 开发 | 10 | 6 | 4 | 56 |
| 成员B | 测试与支持 | 8 | 6 | 10 | 38 |
| 合计 | — | — | — | 14 | 94 |
成员A：10 × 6 − 4 = 56 工时，其中4工时为迭代内两场评审会议。成员B：请假2天，可用天数8天，8 × 6 − 10 = 38 工时，10工时包含请假折算与线上支持排班。团队可用容量为94工时。
团队汇总与承诺
| 迭代周期 | 团队可用容量 | 历史速率 | 承诺工作量 | 负载率 |
|---|---|---|---|---|
| 第12迭代（10个工作日） | 94工时 | 约80工时/迭代 | 80工时 | 0.85 |
历史速率取前三个迭代实际完成的平均值约80工时。承诺工作量按历史速率定为80工时，负载率 80 ÷ 94 ≈ 0.85，为临时插入的缺陷修复留出余量。若直接按94工时排满，负载率为1，任何计划外工作都会挤压测试时间。
偏差记录与下迭代调整
| 迭代 | 承诺工作量 | 实际完成 | 偏差值 | 偏差原因 | 下迭代调整 |
|---|---|---|---|---|---|
| 第12迭代 | 80工时 | 72工时 | −8工时 | 成员B支持工时有3天超出排班估计 | 支持占用按上迭代实际值上调，承诺工作量降至75工时 |
偏差为负说明承诺偏高，原因定位在支持类占用被低估。下个迭代把成员B的占用工时按实际值修正，同时把承诺工作量下调到75工时，负载率维持在0.8左右。未完成的8工时工作不直接顺延，而是在下个迭代计划会上重新评估优先级与工作量后再决定是否纳入承诺。
调整与维护：让测算表随团队变化更新
测算表的价值来自跨迭代可比。维护的核心是固定更新时点、记录变化原因，让每一版数据都能解释清楚。
更新时点
- 迭代开始前：更新可用天数、占用工时与历史速率，完成承诺工作量与负载率计算，作为计划会的输入。
- 迭代结束后：填写实际完成与偏差值，记录偏差原因，形成下个迭代的调整项。
- 迭代中期：人员或占用发生重大变化时做一次临时修订，并在备注中注明修订原因，避免与计划值混淆。
人员与假期变化的处理
人员增减时，新增成员补一行，离职成员保留历史行并标注离开迭代，便于速率统计时剔除。假期集中期（如长假前后）应单独调整可用天数，不通过压低每日有效工时来吸收，否则会掩盖真实的出勤变化。长期借调或兼职支持建议单列一行，与全职成员分开统计。
估算单位切换
从人天切换到故事点时，保留历史人天数据作为对照，用最近几个迭代的实际完成量建立换算关系，切换后的前两个迭代同时记录两种单位，确认折算稳定后再停用旧单位。切换期间的历史速率需要重新计算，不能直接沿用旧单位的数值。
偏差积累与速率修正
连续三个迭代偏差同向且幅度接近时，说明历史速率需要修正，取最近几个迭代的实际完成平均值替换原速率。偏差方向反复变化则说明估算波动来自外部干扰，应优先检查占用工时的记录是否完整。偏差原因建议归入固定几类，如需求变更、支持占用、估算偏差、外部依赖，便于按类统计。
测算表算出的容量与承诺，最终要落到迭代内的具体工作项上。ONES 支持将需求和相关任务规划至迭代并分配负责人，任务工时统计可用于记录实际投入，迭代结束后可通过燃尽图、工时日志等报表复盘进度与成本偏差，让表中的实际完成与偏差值有系统数据可对。具体统计口径与配置以实际产品为准。
常见问题
团队第一次用这张表、还没有历史速率，承诺工作量怎么定？
首次使用时可以把历史速率一栏留空或标注“估计”，由团队根据成员经验和类似工作量的完成情况给出一个估计值，并在偏差原因中注明这是估计基准。前两个迭代结束后，用实际完成值替换估计值，从第三个迭代起按最近3至5个迭代的平均值计算。这样处理不会让表格停摆，也能让速率逐步建立在真实数据上。
迭代中途有人请假或临时支援其他项目，表格要重算吗？
占用发生重大变化时建议做一次临时修订：调整对应成员的可用天数或占用工时，重新计算可用容量与负载率，并在备注中写明修订原因和修订日期。计划值与修订值分开保留，复盘时才能区分“原本就估少了”和“中途被抽走”两种情况。小幅波动不必每次重算，可在迭代结束后统一反映在偏差记录里。
承诺工作量按可用容量排满可以吗？
排满意味着负载率为1，任何计划外的缺陷修复、支持请求或会议增加都会直接挤压交付时间。示例中两人小组把负载率控制在0.85左右，为临时插入的工作留出余量。余量留多少取决于团队历史干扰程度：支持类工作多、需求变更频繁的团队需要更大余量；干扰较少的团队可以适当提高负载率，但建议保留一段可观察的缓冲区间，用几个迭代的偏差数据来校准。
从人天切换到故事点，之前的容量数据还能用吗？
历史人天数据建议保留作为对照，不直接删除。切换后的前两个迭代同时记录两种单位，用实际完成量建立换算关系，确认折算稳定后再停用旧单位。切换期间的历史速率需要按新单位重新计算，不能把旧单位下的速率数值直接套用。若团队同时存在按人天排期的支持和按故事点估算的功能开发，可在表中分列两种单位，各自汇总，避免在同一列混填。
测算表算出的容量，怎么和迭代里的实际工时记录对上？
关键是让表中的“实际完成”有系统数据可依。ONES 支持将需求和相关任务规划至迭代并分配负责人，任务工时统计可用于记录实际投入，迭代结束后可通过燃尽图、工时日志等报表复盘进度与成本偏差（claim F3、F4）。落地时建议统一工时记录的最小单位与是否含非工作日的口径，使系统统计值与表中数值可比；具体统计口径与配置以实际产品为准。
