迭代容量统计口径要先把“容量”拆成可复算的分子与分母：分子是迭代内团队可投入的有效工时或故事点，分母是同一时间窗与同一人员范围。确定口径的关键是固定四件事——统计对象、计量单位、时间窗和数据来源。本文围绕这四项给出字段说明、计算公式、完整算例与解读边界，帮助团队用同一份数据算出同一结果。
要点总览（TL;DR）
- 迭代容量口径先固定四件事：统计对象、计量单位、时间窗和数据来源，再谈具体数值。
- 工时口径下个人容量=可用天数×每日有效工时×投入比例，团队容量为各成员之和；故事点口径以历史完成速率为参照，两者并列呈现、不相互换算。
- 分母为零或团队全部不可用时，容量记为“不可计算”并说明原因，不填零、不沿用上期数值。
- 容量是投入上限估计，不等于交付承诺，也不宜直接作为个人绩效指标；口径变更需记录时间与原因，并标注前后数据不可直接比较。
- 未完成工作应在下一迭代重新评估工作量和优先级后再安排，不默认按原估算结转。
评估目标：容量口径要回答什么问题
容量口径的精度取决于它要回答的问题。用途不同，统计对象、时间窗和更新频率都会不同。先明确用途，再决定口径，可以避免“算得很细但没人用”或“算得太粗无法排期”两种情况。
常见用途有两类。第一类是规划承诺：在迭代计划会上判断团队能承接多少需求，此时容量需要覆盖整个迭代时间窗，人员范围以实际参与该迭代的成员为准，精度要求较高，通常按人逐项核算后汇总。第二类是过程观察：在迭代进行中观察剩余可投入量是否被透支，此时容量可以按周或按天滚动更新，允许使用较粗的估算，重点是变化趋势而非绝对数值。
| 用途 | 统计对象 | 时间窗 | 精度要求 | 更新频率 |
|---|---|---|---|---|
| 规划承诺 | 本迭代实际参与成员，按角色区分 | 完整迭代起止日期 | 按人核算，扣减项逐项登记 | 迭代开始时确定，范围变更时更新 |
| 过程观察 | 当前仍在投入的成员 | 按周或按天滚动 | 可使用估算值或区间 | 每日或每周 |
口径确定后需要固定三类输出物：一份字段说明，写明每个字段的定义、单位、取值范围和取数来源；一个算例，用真实或模拟数据完整走一遍计算过程；一条变更记录规则，说明口径调整时如何标注时间点和原因。这三类输出物让口径从“某个人脑子里的算法”变成团队可共享、可复核的约定。
指标与范围：容量由哪些量和边界构成
容量由两个乘数构成：可投入人力与可用时间。工时口径下，个人容量等于可用天数、每日有效工时与投入比例三者相乘；团队容量是各成员容量之和。故事点口径下，容量以团队历史完成速率为参照，表达为“本迭代预计可完成的故事点范围”。两种口径回答的是同一个问题，但计量单位不同，不能混在一个数里相加或换算。
统计对象范围需要事先写清楚。通常计入的是在本迭代内承担需求交付任务的成员，包括开发、测试、设计等直接参与交付的角色。部分投入的成员按投入比例折算，例如某成员本迭代有 50% 时间投入该项目，则其容量按一半计。不计入的典型对象包括：仅参与评审的管理者、本迭代不承担交付任务的外部支持人员、以及处于入职培训期尚不能独立交付的新成员。是否计入没有统一答案，关键是同一口径在多个迭代间保持一致。
计量单位的选择取决于团队已有的数据基础。工时口径适合有较稳定工时记录、任务拆分较细的团队，优点是可直接与排期对应，缺点是依赖填报质量。故事点口径适合已建立估算习惯、有若干迭代历史速率数据的团队，优点是估算成本低、不受个人工时波动干扰，缺点是无法直接回答“某个人这周还有多少余量”。两种口径可以并列使用，但各自独立计算、独立解读。
时间窗边界要覆盖迭代起止日期内的全部工作日，并明确扣减规则：法定节假日不计入可用天数；已批准的请假按天扣减；固定例会、评审会等占用时间可按团队约定折算为每日有效工时的扣减比例；值班、线上支持等支持性工作如果占用交付时间，也应作为扣减项登记。扣减项越具体，容量数越接近实际可投入量，但登记成本也越高，团队需要在精度和操作成本之间取一个可持续的平衡。
数据口径与证据：每个字段从哪里取、怎么记
字段级口径的作用是让容量数据可追溯。每个进入公式的字段都应能回答三个问题：从哪里取、由谁维护、异常时怎么处理。下表给出一套可直接套用的字段口径框架。
| 字段 | 定义 | 单位 | 取数来源 | 维护责任 |
|---|---|---|---|---|
| 成员名单 | 本迭代实际参与交付的成员 | 人 | 迭代排期表或项目成员列表 | 迭代负责人 |
| 角色 | 成员在本迭代承担的主要职责 | — | 排期表 | 迭代负责人 |
| 投入比例 | 成员投入本迭代交付工作的时间占比 | 百分比 | 排期表或资源协调记录 | 迭代负责人与成员确认 |
| 可用工作日 | 迭代起止内扣除节假日后的工作日数 | 天 | 团队日历 | 迭代负责人 |
| 每日有效工时 | 每个工作日可用于交付任务的小时数 | 小时 | 团队约定值，扣除会议等固定占用 | 团队共同约定 |
| 扣减项 | 请假、培训、支持性工作等占用 | 天或小时 | 请假记录、排班表 | 成员申报，负责人确认 |
| 故事点估算 | 需求或任务的工作量估算值 | 点 | 估算记录 | 参与估算的成员 |
| 历史完成速率 | 过去若干迭代实际完成的故事点 | 点/迭代 | 迭代完成记录 | 迭代负责人 |
缺失值和异常值需要预先约定处理方式，否则不同人会用不同办法填补，导致结果不可比。缺勤未登记时，按排期表默认全员可用计算，并在备注中标注“存在未登记缺勤，容量可能高估”；跨迭代投入的成员，按本迭代实际分配比例计入，不把其他迭代的占用重复扣减；临时支援人员如果在本迭代中途加入，按其实际可投入天数折算，并在变更记录中注明加入日期。所有调整都应留下记录，而不是直接修改原始数字。
在工具承载上，ONES Project 支持将需求和相关任务规划至迭代并分配负责人，也支持任务工时统计，可作为成员投入与工时字段的记录载体；迭代回顾阶段可结合工时日志等数据报表复盘进度与成本偏差。团队可以把上述字段对应到迭代排期、任务工时和成员分配记录中，让容量核算的输入数据与日常执行数据来自同一处，减少手工汇总的偏差。具体字段配置以实际产品版本为准。
计算与评估步骤：从原始记录到容量数
工时口径的计算分三步。第一步，逐人计算个人容量：个人容量 = 可用天数 × 每日有效工时 × 投入比例，再减去该成员的扣减项折算工时。第二步，将各成员个人容量相加得到团队容量。第三步，用团队容量对照本迭代计划承接的工作量，判断是否超出可投入上限。
故事点口径的计算以历史速率为基础。取过去若干迭代的实际完成故事点，计算其平均值或中位数作为参照速率，再结合本迭代的人员变化和扣减情况做调整。例如团队人数减少一人，可按该成员历史贡献比例下调参照速率。故事点口径给出的是一个区间或参考值，不宜精确到小数点后多位。
异常情况需要明确处理规则。当分母为零，即团队在本迭代全部不可用或可用天数为零时，容量应记录为“不可计算”并说明原因，不填零，也不沿用上一期数值，因为零容量与无数据是两种不同状态。当数据不可比时，例如部分成员使用工时口径、部分使用故事点，应将两类数据隔离呈现，分别汇总，不合并为一个总数。单位换算只在同一口径内部进行，例如小时与天的换算按团队约定的每日有效工时执行，不跨口径换算。
计算完成后建议保留中间结果：每人的可用天数、扣减项、投入比例和最终容量都应可见。这样当结果与预期不符时，可以逐项回溯是哪一步的输入导致了差异，而不是只看到一个汇总数字。
算例：一个五人迭代的容量核算
以下为演示情景，用于说明口径如何落地，数据为假设值。某团队共 5 人，迭代周期为两周共 10 个工作日，团队约定每日有效工时为 6 小时（已扣除固定例会和沟通占用）。成员构成与扣减情况如下：
| 成员 | 角色 | 投入比例 | 可用天数 | 扣减项 | 个人容量（小时） |
|---|---|---|---|---|---|
| 甲 | 后端开发 | 100% | 10 | 无 | 60 |
| 乙 | 前端开发 | 100% | 10 | 请假 2 天 | 48 |
| 丙 | 测试 | 80% | 10 | 无 | 48 |
| 丁 | 后端开发 | 100% | 10 | 线上支持 1 天 | 54 |
| 戊 | 设计 | 50% | 10 | 无 | 30 |
计算过程：甲为 10 × 6 × 100% = 60 小时；乙为（10 − 2）× 6 × 100% = 48 小时；丙为 10 × 6 × 80% = 48 小时；丁为（10 − 1）× 6 × 100% = 54 小时；戊为 10 × 6 × 50% = 30 小时。团队容量合计 240 小时。
同一组数据用故事点口径呈现：假设该团队过去三个迭代实际完成故事点分别为 32、28、30，取中位数 30 点作为参照速率。本迭代乙请假 2 天、戊仅投入一半，人员有效投入低于历史平均水平，可将参照速率下调至约 26 至 28 点作为本迭代容量参考区间。这个区间与工时口径的 240 小时并列呈现，各自独立解读：工时口径回答“总共能投入多少小时”，故事点口径回答“按历史节奏大致能完成多少工作量”。两者不相互换算，也不合并成一个数。
结果解读时需要注意：240 小时是投入上限估计，不等于可交付 240 小时的工作量。任务切换、等待依赖、返工都会消耗容量而不产生交付。计划承接的工作量应留出余量，具体余量比例由团队根据历史偏差自行确定，没有通用标准。
解读与限制：容量数能说明什么、不能说明什么
容量是投入上限的估计值，回答的是“团队在这个迭代最多能投入多少”，不回答“团队一定会交付多少”。把容量直接当作交付承诺，会在需求变更或估算偏差出现时造成计划失准。容量也不宜直接作为个人绩效指标，因为投入比例、扣减项和任务难度都会影响结果，单看容量数无法反映贡献质量。
估算偏差和需求变更会同时影响容量与实际完成量的对比。估算偏大时，同样的容量会显得完成量不足；需求中途变更时，容量没有变化但实际可用的投入被重新分配。因此容量与实际完成量的对比应放在多个迭代的趋势中观察，而不是只看单个迭代的差值。对比时还要确认两个数使用同一口径、同一人员范围和同一时间窗。
口径变更时需要记录变更时间、变更内容和原因，并标注变更前后的数据不可直接比较。例如团队从工时口径切换到故事点口径，切换前后的容量数不能放在同一条趋势线上。未完成的工作应在下一迭代重新评估工作量和优先级后再安排，不默认按原估算结转，否则会高估下一迭代的实际可用容量。
在迭代回顾中，容量数据适合与燃尽图、工时日志等记录一起使用，帮助团队判断计划与实际投入的偏差来自哪里。ONES 敏捷研发管理解决方案在迭代回顾环节支持通过燃尽图、工时日志等数据报表复盘迭代进度、质量和成本偏差，团队可以据此核对容量口径中的扣减项是否登记完整、投入比例是否与实际一致，再决定下一迭代的口径是否需要调整。
常见问题
迭代中途有成员临时加入或退出，容量口径怎么调整？
按成员在本迭代的实际可投入天数折算，而不是按整迭代计入或整迭代剔除。临时加入的成员从加入日期起算可用天数，并在变更记录中注明加入日期和投入比例；中途退出的成员只计退出前的可用天数。调整后重新汇总团队容量，同时保留调整前后的两个数值和调整原因，便于后续对比时识别差异来源。
团队同时有工时记录和故事点估算，容量应该用哪一个？
两个都可以用，但各自独立计算、独立解读，不合并成一个数。工时口径回答“本迭代总共能投入多少小时”，适合与排期逐项对应；故事点口径回答“按历史节奏大致能完成多少工作量”，适合在计划会上判断承接范围。如果团队两类数据都有，建议以其中一个作为主口径用于承诺，另一个作为参照，并在字段说明中写明主口径的选择理由。
历史速率数据不足三个迭代，故事点口径还能用吗？
可以用，但要降低结论的确定性。数据不足时，参照速率只能作为粗略参考，建议给出较宽的区间，并在计划承接时留出更大余量。也可以先用工时口径完成本迭代排期，同时开始积累完成记录，待积累若干迭代数据后再引入故事点口径作为并列参照。关键是不要把基于一两个迭代的速率当作稳定基准。
容量口径确定后，多久需要复核一次？
建议每个迭代回顾时核对一次输入数据是否登记完整，例如请假、支持性工作、投入比例是否与实际一致；口径本身（统计对象、单位、时间窗、取数来源）则按需调整，不宜频繁变动。口径发生实质变更时，记录变更时间、内容和原因，并在趋势分析中标注变更点，变更前后的容量数不放在同一条趋势线上比较。
容量数低于计划承接的工作量时，应该怎么处理？
先核对输入数据是否有遗漏或错误，例如扣减项是否重复登记、投入比例是否填错。确认数据无误后，处理方式包括：缩减本迭代承接范围、把部分工作拆到后续迭代、或调整成员投入比例。不建议通过调低每日有效工时等参数把数字“凑”到与计划一致，那样会让容量失去度量意义。范围调整的决定和理由应记录在迭代记录中。
