外部依赖多时，迭代承诺容量怎么调

外部依赖多时，迭代承诺容量要按“可信产出减依赖损耗”来定：先算团队理论可用容量，再用历史速率折算成可信产出，然后按外部依赖的到位概率和等待时长折减，最后用缓冲和承诺分级锁定范围。这样既避免把成员可用工时直接当成承诺量，也能减少依赖落空造成的过载或闲置。

要点总览（TL;DR）

• 承诺容量按“历史可信产出 × 依赖可用系数 − 预留缓冲”计算，成员可用工时只作为理论容量参考，不直接当作承诺量。
• 外部依赖先分阻塞型与可并行型：阻塞型相关事项按未到位概率折减或移出承诺，可并行事项保留但标注检查点。
• 承诺分三档——承诺、尽力、观察，缓冲单独划出10%–15%，承诺档总量不超过承诺容量上限。
• 规划会上完成取数、折减、分级和确认四步，每项调整记录理由与责任人；迭代中按约定频率跟踪依赖，未完成工作重新评估后再决定去向。

先算清三笔账：可用容量、历史速率与依赖损耗

承诺容量的计算要建立在三项输入上：成员真实可投入的时间、团队过去能稳定交付的产出、外部依赖带来的等待损耗。三项分开取数，再合成一个可承诺的数字，比在规划会上凭感觉分配任务更可靠。

第一笔账是可用容量。按成员逐个折算本迭代可投入的工时或人天，扣除休假、法定假日、固定会议、生产支持、面试、培训等非交付时间，对同时支持多个项目的成员按实际投入比例折算。折算结果是一个区间，不必精确到小时，但要能说明“这个迭代团队大约有多少有效投入”。

第二笔账是历史速率。取近三到六个迭代的实际完成量，用中位数或区间作为参考，避免用某次冲刺的峰值作为承诺依据。如果团队刚经历人员变动、技术栈切换或需求类型明显变化，历史速率的参考权重应下调，并在记录中注明原因。

第三笔账是依赖损耗。对每项外部依赖估算到位概率和可能等待时长，把受影响事项的工作量乘以“未到位概率”或按等待天数折算，得到需要从可信产出中扣除的部分。依赖损耗不是拍脑袋的百分比，而应来自依赖清单上的逐项判断。

三项合成后可用一个简化计算式：承诺容量 = 历史可信产出 × 依赖可用系数 − 预留缓冲。其中依赖可用系数由阻塞型依赖的到位概率决定，可并行依赖只标注风险、不整体折减。下表可作为规划会上的取数模板。

项目	取数方法	示例数值	说明
理论可用工时	成员人数 × 迭代工作日 × 每日有效工时，逐人扣减	6人 × 10天 × 6小时 = 360小时	扣除休假、会议、支持等
历史可信产出	近几个迭代完成量的中位数或区间	中位数 42 故事点，区间 38–46	不用单次峰值
依赖折减	阻塞型依赖相关事项工作量 × 未到位概率	12 点 × 40% ≈ 5 点	逐项估算，记录依据
预留缓冲	可信产出的 10%–15%，用于吸收未知风险	约 4–6 点	单独列出，不混入承诺
承诺容量	可信产出 − 依赖折减 − 缓冲	约 31–33 点	作为承诺上限

把外部依赖分类并量化等待风险

依赖折减的前提是有一份可核对的依赖清单。规划前由迭代负责人牵头，把本迭代候选事项涉及的外部依赖逐条列出，按来源分为上游交付、第三方接口、跨团队评审、外部审批四类，再按对事项的影响分为阻塞型和可并行型。

阻塞型依赖指未到位时相关工作无法开始或无法完成，例如上游服务未提供接口、合规审批未通过；可并行型依赖指等待期间团队仍可推进设计、联调准备、测试用例编写等工作。两类依赖对承诺容量的影响不同：阻塞型需要折减或移出承诺，可并行型保留在承诺内但标注风险与检查点。

每项依赖至少记录五个字段：最晚需要时间、当前状态、到位概率、影响的工作项、备选路径。到位概率用高、中、低三档加简短依据即可，例如“对方已排期、接口文档已确认”记为高，“对方尚未排期”记为低。备选路径要具体，例如改用模拟数据先行开发、调整事项顺序、缩小范围先交付核心部分。

依赖编号	依赖类型	影响工作项	最晚需要时间	到位概率	阻塞/可并行	备选路径	对接人
D1	第三方接口	支付对接（8点）	第4个工作日	中	阻塞	先用沙箱环境联调	后端负责人
D2	跨团队评审	权限方案（5点）	第2个工作日	高	可并行	先按草案开发，评审后修正	架构师
D3	外部审批	上线合规材料（3点）	第7个工作日	低	阻塞	拆出材料准备，审批结果下迭代跟进	产品负责人

依赖清单要有明确的跟踪方式：指定每项依赖的对接人，约定检查频率（如每日站会过一遍高风险依赖），并设定预警触发条件，例如“最晚需要时间前两个工作日仍未到位”即升级处理。清单在规划会上确认，会后由迭代负责人维护更新。

按依赖风险调整承诺容量的操作步骤

从基准容量到最终承诺容量，按四步推进，每步都有明确输入、动作、输出和完成标志，便于在规划会上当场完成并留痕。

步骤一：用历史速率确定可信产出区间

输入是近几个迭代的完成量数据和本迭代的可用容量折算结果。动作是取中位数或区间，结合人员变化做修正。输出是可信产出区间，例如 38–46 点。完成标志是团队对区间下限达成一致，并记录取数口径。

步骤二：对阻塞型依赖相关事项做移出或折减

输入是依赖清单和候选事项的工作量估算。动作是逐项判断：到位概率低且无有效备选路径的事项移出本迭代承诺；到位概率中等但有备选路径的事项按未到位概率折减工作量；可并行依赖事项保留，但标注检查点。输出是调整后的事项清单和折减明细。完成标志是每个被移出或折减的事项都有书面理由和责任人。

步骤三：设置缓冲并采用承诺分级

输入是折减后的容量和剩余风险。动作是从可信产出中单独划出 10%–15% 的缓冲，不分配给具体事项；同时把事项分为三档：承诺（必须完成，已扣除依赖风险）、尽力（依赖到位即可完成，未到位可顺延）、观察（依赖不确定性高，仅做前期准备）。输出是承诺分级清单。完成标志是承诺档事项总量不超过承诺容量上限。

步骤四：与相关方确认并记录调整理由

输入是承诺分级清单和依赖清单。动作是与产品负责人确认范围取舍，与外部依赖对接人确认到位时间，向相关方说明承诺口径和风险。输出是经确认的迭代承诺记录，包含容量计算过程、折减依据和分级结果。完成标志是产品负责人和迭代负责人共同签字或书面确认。

角色分工与各环节交付物

容量调整涉及取数、依赖确认和范围拍板三类动作，需要明确谁在什么时点交付什么，避免规划会上临时找人、会后无人跟踪。

角色	主要职责	交付物	时点
产品负责人	确定事项优先级，做范围取舍，确认承诺分级	优先级排序后的候选事项清单、范围取舍决定	规划会前完成排序，会上拍板
迭代负责人/Scrum Master	组织容量测算，维护依赖清单，跟踪依赖状态	容量估算表、外部依赖清单、承诺分级清单	规划会前取数，会上主持，迭代中跟踪
团队成员	反馈可用性与工作量估算，拆分任务	个人可用工时、事项估算、子任务拆分	规划会前提交，会上确认
外部依赖对接人	反馈依赖到位时间与风险，更新依赖状态	依赖状态更新、风险预警	规划会前确认，迭代中按约定频率更新

产品负责人依据需求优先级把候选事项带入迭代规划，在计划会议上与团队共同评审需求和验收标准；团队就范围达成一致后，设计、研发、测试人员用子任务拆分需求，便于后续跟踪。这一分工在 ONES 的迭代规划场景中有对应承载：需求可规划至迭代，子任务拆分和状态跟踪在看板中完成，依赖清单和容量记录也可以工作项或文档形式随迭代留存。

一个示例：依赖多时的容量调整全过程

以下为演示情景，数字仅用于说明计算过程，不代表任何真实团队数据。

假设一个 6 人团队，迭代周期 10 个工作日，每人每日有效工时按 6 小时计，理论可用工时为 360 小时。近四个迭代完成量分别为 40、44、38、46 故事点，中位数 42 点，可信产出区间取 38–46 点。本迭代候选事项共 48 点，其中涉及三项外部依赖。

依赖 D1 为第三方支付接口，影响 8 点事项，到位概率中，无完全替代方案，按 50% 折减 4 点；依赖 D3 为外部审批，影响 3 点事项，到位概率低，整项移出承诺，转入观察档；依赖 D2 为跨团队评审，影响 5 点事项，到位概率高且有并行方案，保留不折减。依赖折减合计 7 点，另预留缓冲 5 点。

承诺容量 = 42 − 7 − 5 = 30 点。据此把事项分为：承诺档 28 点（含 D2 相关事项，标注评审检查点）；尽力档 6 点（含 D1 相关事项，接口到位即推进，未到位顺延）；观察档 3 点（D3 相关事项，本迭代只做材料准备）。剩余 11 点事项移出本迭代，回到待办列表等待下轮规划。决策记录中写明每项折减和移出的理由、依赖对接人和检查时点。

迭代中的跟踪与完成检查

承诺确定后，跟踪的重点是依赖状态和容量消耗是否偏离计划。每日站会过一遍高风险依赖，按约定频率向对接人确认到位时间；当依赖在最晚需要时间前两个工作日仍未到位，或已完成工作量明显低于承诺档进度时，触发预警，由迭代负责人组织评估是否调整范围或启用备选路径。

迭代结束时，对比承诺容量与实际完成量，分析偏差来源：是依赖未到位、估算偏差，还是范围变更。偏差复盘放在迭代回顾中进行，结合燃尽图、工时日志等数据讨论改进建议。未完成的工作不默认结转到下一迭代，而是重新评估优先级、依赖状态和估算后再决定去向，避免把失效承诺带入下一轮。

规划完成时可对照以下清单自检：

• 可用容量是否逐人折算并扣除休假、会议和支持时间；
• 历史速率是否取中位数或区间，并注明人员或需求变化的修正；
• 外部依赖是否逐项登记类型、最晚需要时间、到位概率和备选路径；
• 阻塞型依赖相关事项是否已移出或折减，理由是否记录；
• 缓冲是否单独列出，承诺档总量是否不超过承诺容量上限；
• 承诺、尽力、观察三档是否划分清楚，产品负责人是否确认；
• 每项依赖是否有对接人和检查频率，预警条件是否明确；
• 未完成工作的处理规则是否在规划时说明，而非默认结转。

常见问题

团队历史速率波动很大，还能用来估算承诺容量吗？

可以用，但要调整取数方式。速率波动大时，取近几个迭代的中位数或区间下限作为参考，比取平均值更稳妥；同时把波动原因写进记录，例如人员变动、需求类型切换、外部依赖集中。若波动来自可识别的结构性变化，历史数据的参考权重应下调，改用最近两三个迭代的数据，并在规划会上说明修正依据。区间下限适合作为承诺档的上限参考，区间上限可用于判断尽力档的空间。

外部依赖在迭代中途才确认延期，承诺容量还能调整吗？

可以调整，但要按约定规则处理，避免临时压缩范围引发混乱。先判断该依赖属于阻塞型还是可并行型：阻塞型且无备选路径时，由迭代负责人组织评估，把受影响事项移出承诺档或启用备选路径，并同步产品负责人确认范围取舍；可并行型则保留事项，调整检查点。调整结果记录在迭代承诺记录中，说明变更原因和影响，不在站会上口头改动了事。

预留缓冲应该按什么比例设置，依赖特别多时要不要加大？

缓冲用于吸收估算偏差和未知风险，常见做法是取可信产出的10%–15%，单独列出、不分配给具体事项。依赖特别多且到位概率普遍偏低时，可以适当加大缓冲，但更有效的做法是把不确定性高的依赖事项移入尽力档或观察档，而不是用缓冲覆盖所有风险。缓冲过大同样会造成容量浪费，建议在迭代回顾中对比缓冲实际消耗情况，逐步校准比例。

承诺、尽力、观察三档在迭代结束时怎么评价完成情况？

三档的评价口径不同：承诺档按是否全部完成衡量，未完成需要分析原因；尽力档以依赖是否到位为前提，依赖到位而未完成才计入偏差；观察档只评价前期准备是否按计划推进，不要求交付完整成果。回顾时分别统计三档的完成情况，重点看承诺档偏差和尽力档依赖到位率，据此调整下一轮的折减系数和缓冲比例。

规划会上由谁最终拍板承诺容量，出现分歧怎么处理？

承诺容量由产品负责人和迭代负责人共同确认：产品负责人对范围和优先级做取舍，迭代负责人对容量测算和依赖风险负责。出现分歧时，回到数据上讨论——用容量估算表、依赖清单和承诺分级清单逐项核对，优先保证承诺档不超上限。无法当场达成一致的事项放入尽力档或观察档，并约定复核时点，避免把争议带入迭代执行。