发布间隔由外部承诺、需求供给节奏和团队交付周期共同决定，版本容量则由可用人力、固定开销和预留缓冲倒推。本文按“定节奏基线—算容量—填需求—排衔接—校准”的顺序，给出可直接套用的测算表、清单和时间轴，适用于版本规划阶段确定后续版本的间隔与每版承载规模。
要点总览（TL;DR）
- 发布间隔取对外承诺、需求流入节奏、团队交付周期三者中最紧的约束作为下限，再在固定周期、按需发布、混合节奏中选一种作为基线。
- 版本容量从总人力往下扣：先扣非版本投入得到可用人力，再扣缺陷与技术债等固定开销和缓冲，剩余才是可分配给新需求的容量。
- 单版本目标设为一个主目标加若干次要项，按价值、依赖、风险、成本排序；超出容量时整项延后，跨版本依赖需求提前占位并计入容量。
- 相邻版本之间固定冻结、开发、验收、发布准备、缓冲五个节点，上一版本遗留项在下一版本容量中先行扣除。
- 用前两到三个版本的计划完成率、溢出量、遗留项数校准假设，一次只调一个变量，出现承诺频繁变更或人员大幅调整时重新评估节奏基线。
先定节奏基线：发布间隔由什么决定
发布间隔是三种约束的交集：对外承诺的兑现时间、需求进入规划池的速度、团队从启动到可交付的周期。三者中任何一项明显长于其他两项，间隔就会被它拉长。确定基线时，先列出已对客户或市场做出的时间承诺，再统计近几个版本需求进入规划池的节奏，最后核对团队从需求冻结到可验收的实际耗时，取三者中较紧的约束作为间隔下限。
节奏类型可按产品特征选择：
| 节奏类型 | 适用条件 | 主要风险 |
|---|---|---|
| 固定周期 | 需求持续流入、对外承诺相对稳定、需要客户形成升级预期 | 需求不足时版本内容偏薄，需求突增时被迫压缩质量环节 |
| 按需发布 | 需求稀疏、由合规窗口或大客户项目驱动、版本之间差异大 | 节奏不可预期，客户难以规划升级，团队容易长期处于赶工状态 |
| 混合节奏 | 核心版本按固定周期发布，补丁与小改进按需发布 | 需要明确哪些内容走固定版本、哪些走按需通道，否则边界混乱 |
间隔过短的典型代价是冻结、验收、发布准备等固定开销占比上升，团队把大量时间花在版本切换上；间隔过长的代价是反馈周期变长，需求在规划池中积压，紧急需求只能靠插队破坏节奏。选定后应形成一份节奏基线说明，写清节奏类型、目标间隔天数、依据的承诺与历史数据，作为后续容量测算的输入。
倒推版本容量：可用人力、固定开销与缓冲
版本容量回答的是“一个版本能装多少”，计算顺序是从总人力往下扣，而不是从需求往上加。先算可用人力：团队总人力扣除计划休假、日常支持、会议与培训等非版本投入，得到真正能投入本版本的人力。再扣除固定开销：缺陷修复、技术债偿还、需求评审、代码评审、测试与发布准备，这些工作每个版本都会发生，必须预先留出。剩余部分再按比例留缓冲，才是可分配给新需求的容量。
| 项目 | 计算口径 | 示例数值 |
|---|---|---|
| 团队总人力 | 参与本版本的全部研发人力 | 40人天 |
| 非版本投入 | 休假、支持、会议、培训 | 6人天 |
| 可用人力 | 总人力−非版本投入 | 34人天 |
| 固定开销 | 缺陷、技术债、评审、发布准备 | 10人天 |
| 缓冲 | 按可用人力的一定比例预留 | 5人天（约15%） |
| 可分配容量 | 可用人力−固定开销−缓冲 | 19人天 |
缓冲比例的设定依据是历史波动：如果过去几个版本频繁出现临时插入的紧急缺陷或需求，缓冲应取高一些；如果交付稳定，可以适当降低。容量表达方式必须在团队内统一，需求点、故事数、人天只能选一种作为规划口径，混用会让容量数字失去可比性。上表为演示情景，数值仅用于说明计算关系，实际取值应来自团队自身数据。
把需求填进容量：目标排序与取舍规则
容量确定后，单版本目标宜设为一个主目标加若干次要项。主目标决定这个版本对外讲什么，次要项在主目标不受影响的前提下填入剩余容量。排序时同时看四个维度：业务价值、与其他需求的依赖关系、交付风险、实现成本。价值高且成本低的需求优先；有前置依赖的需求即使价值一般也要提前占位，否则后续版本会被卡住。
超出容量时的处理规则要事先约定，避免每次临时争论：
- 按价值密度排序，排在容量线之外的需求整体延后到下一版本，不做部分交付的拆分，除非拆分后仍能独立产生价值。
- 存在跨版本依赖的需求，提前在后续版本中占位，占位需求也计入该版本容量。
- 主目标相关的需求优先保留，次要项在容量不足时整项移出，不压缩测试与评审时间。
最终形成单版本需求清单，逐项标注入选项、延后项及排序理由。清单需要能被研发和测试直接读取，作为排期与验收的依据。在工具层面，这类清单通常以版本或迭代为单位承载需求条目及其状态，ONES 支持将需求关联到版本并跟踪其流转状态，便于在规划阶段就把入选与延后项区分清楚，减少口头传递造成的偏差。
版本间衔接：冻结、验收与缓冲怎么排
相邻版本互相挤压，多数源于衔接节点没有固定。需求冻结点应早于开发启动点，给研发留出理解和拆解的时间；冻结之后进入的需求默认排入下一版本，除非触发事先约定的例外流程。验收与发布准备放在周期后段，占用固定时段，不因开发延期而被挤掉。
一个周期内的节点顺序可以这样排：需求冻结—开发—验收—发布准备—版本间缓冲。版本间缓冲用于吸收上一版本的遗留项和突发缺陷，长度根据历史遗留量设定。上一版本的遗留项进入下一版本时，应作为下一版本容量的已占用部分先行扣除，再分配新需求，避免遗留项悄悄吃掉新需求的容量。
把冻结、开发、验收、缓冲各节点日期落到一张时间轴上，并明确每个节点的责任人和完成标志，衔接规则才算真正可执行。ONES 的版本与迭代视图可以承载这类时间节点和需求状态，使冻结后的范围变化在系统中可见，便于在版本切换时核对遗留项。
角色分工与各环节交付物
节奏规划涉及三类角色，职责按环节划分，避免定节奏的人同时负责证明节奏合理。
| 环节 | 主要负责角色 | 输入 | 输出 |
|---|---|---|---|
| 定节奏基线 | 产品负责人 | 对外承诺、需求流入数据、历史交付周期 | 节奏基线说明 |
| 算版本容量 | 研发负责人 | 人力安排、固定开销历史、缓冲比例 | 版本容量测算表 |
| 需求排序与裁剪 | 产品负责人牵头，研发负责人参与 | 需求池、容量上限、依赖关系 | 单版本需求清单 |
| 衔接节点排布 | 项目管理者 | 需求清单、团队可用时间 | 版本节奏时间轴 |
| 评审与确认 | 产品与研发负责人共同确认 | 上述四份产物 | 确认后的版本计划 |
评审时点建议放在需求冻结之前，确认节奏基线、容量数字、需求清单和时间轴四者一致。确认后的版本计划作为本版本的执行依据，变更走例外流程并记录原因。
示例：一个双周节奏的容量与衔接安排
以下为演示情景，假设一个由产品、研发、测试组成的小型团队，采用双周固定节奏，数值仅用于说明方法。
容量测算：团队总人力40人天，扣除休假与支持6人天，可用人力34人天；缺陷修复与技术债等固定开销10人天；按约15%预留缓冲5人天；可分配容量19人天。
需求填入：主目标为“完成订单导出能力”，占用12人天；次要项“列表筛选优化”占用5人天；剩余2人天用于一个跨版本依赖的前置接口占位。另有两项需求因超出容量延后至下一版本，延后理由为价值密度低于已入选项。
| 节点 | 时间安排 | 完成标志 |
|---|---|---|
| 需求冻结 | 第1天 | 需求清单确认，范围锁定 |
| 开发 | 第2–8天 | 功能开发完成并自测通过 |
| 验收 | 第9–10天 | 验收通过，缺陷收敛到约定阈值 |
| 发布准备 | 第11天 | 发布说明与检查项完成 |
| 版本间缓冲 | 第12–14天 | 遗留项登记并转入下一版本容量 |
这个示例的关键在于：缓冲和固定开销先扣再分配，遗留项在下一版本容量中先行占位，冻结之后的范围变化有明确去向。
用实际完成率校准节奏
节奏定下来后，用前两到三个版本的实际数据检验假设。需要记录的指标包括计划完成率（实际完成需求占计划入选需求的比例）、溢出量（版本结束时未完成的需求规模）、遗留项数（转入下一版本的事项数量）。三项指标连续偏离约定阈值时，说明间隔或容量假设需要修正。
| 指标 | 偏差表现 | 调整动作 |
|---|---|---|
| 计划完成率持续偏低 | 容量高估或固定开销低估 | 下调可分配容量，或提高缓冲比例 |
| 溢出量持续偏高 | 需求排序过于乐观 | 收紧入选标准，主目标只保留一项 |
| 遗留项数持续上升 | 版本间缓冲不足或验收标准偏松 | 延长缓冲，明确验收通过条件 |
调整幅度宜小步进行，一次只改一个变量，观察两到三个版本后再决定是否继续调整。当出现对外承诺频繁变更、需求流入速度明显变化、团队人员结构大幅调整等信号时，应重新评估节奏基线本身，而不只是微调容量数字。
完成检查：节奏规划是否可执行
在版本计划确认前，用以下清单逐项核对，每项都应有对应证据或确认人。
| 类别 | 检查项 | 通过标准 | 证据或确认人 |
|---|---|---|---|
| 间隔 | 节奏类型与目标间隔已写明 | 有选择理由，与对外承诺一致 | 节奏基线说明，产品负责人确认 |
| 容量 | 可用人力、固定开销、缓冲、可分配容量四项齐全 | 口径统一，数值可追溯到人力安排 | 容量测算表，研发负责人确认 |
| 目标 | 单版本目标为一个主目标加次要项 | 入选与延后项均有排序理由 | 需求清单，产品负责人确认 |
| 衔接 | 冻结、开发、验收、缓冲节点日期明确 | 冻结早于开发启动，缓冲已预留 | 版本时间轴，项目管理者确认 |
四类检查全部通过，且遗留项处理规则和校准指标已约定，节奏规划即可进入执行。任何一项缺少证据，都应在需求冻结前补齐，而不是留到版本进行中再补。
常见问题
需求流入很不稳定，还能用固定周期发布吗？
可以，但要把固定周期和内容弹性分开处理。周期固定解决的是客户升级预期和团队节奏稳定，版本内容则按容量上限填入，需求不足时版本内容偏薄属于正常结果，不必为了填满而临时加需求。如果需求长期稀疏且差异很大，按需发布或混合节奏更合适：核心版本保持固定间隔，补丁和小改进走按需通道，同时明确哪些内容走哪条通道，避免边界混乱。
缓冲比例设多少比较合适？
缓冲比例没有统一标准，依据是团队自身的历史波动。过去几个版本频繁出现临时插入的紧急缺陷或需求，缓冲应取高一些；交付相对稳定时可以适当降低。更稳妥的做法是先按经验值设定，运行两到三个版本后看计划完成率和溢出量，再小步调整。缓冲被频繁用尽，说明比例偏低或固定开销被低估；缓冲长期用不完，说明可以释放一部分给新需求。
上一版本的遗留项应该怎么处理？
遗留项在下一版本规划时作为已占用容量先行扣除，再分配新需求，这样遗留项不会悄悄吃掉新需求的容量。同时要记录遗留项数量和产生原因：如果遗留项持续上升，通常指向版本间缓冲不足或验收标准偏松，需要延长缓冲或明确验收通过条件，而不是靠下一版本加班消化。
节奏运行一段时间后，什么情况下需要重新定基线而不是微调容量？
微调容量适用于计划完成率、溢出量、遗留项数这类执行层偏差。出现以下信号时应重新评估节奏基线本身：对外承诺频繁变更、需求流入速度明显变化、团队人员结构大幅调整。这些变化影响的是间隔的三个约束条件，只调容量数字无法解决，需要重新核对承诺时间、需求节奏和交付周期，再决定是否更换节奏类型或调整目标间隔天数。
容量用需求点还是人天表达更好？
两种口径都能用，关键是团队内统一选一种作为规划口径，混用会让容量数字失去可比性。人天直观、便于和人力安排对齐，适合固定开销占比高、需要精细核算投入的场景；需求点弱化了个人差异，适合需求规模差异大、需要长期比较吞吐量的团队。无论选哪种，都要保证同一版本内所有需求按同一口径估算，并在校准阶段用同一口径统计完成率。
