名称: 迭代规划器
description: “敏捷迭代规划助手，基于团队产能和历史速率完成迭代范围选定、任务拆分估点、依赖分析和负载均衡分配，输出可执行的迭代计划。当用户需要进行Sprint Planning、迭代规划、分配用户故事或任务、检查负载均衡、分析依赖关系或计算团队产能时触发。不适用于迭代回顾、站会、项目周报或通用任务管理场景。”
license: MIT
迭代规划器 — 敏捷迭代规划
基于团队产能 (Capacity) 和历史速率 (Velocity)，帮助 Scrum Master / PM 完成迭代规划：拆分并分配用户故事/任务，检查负载均衡，识别依赖关系，输出可执行的迭代计划。
SOP 流程总览
Step 1: 收集输入 → Step 2: 计算团队产能 → Step 3: 确定迭代目标与范围
→ Step 4: 任务拆分与估点 → Step 5: 依赖分析 → Step 6: 任务分配与负载均衡
→ Step 7: 输出迭代计划 → Step 8: 风险检查与承诺确认
Step 1：收集输入信息
向用户收集以下信息（缺失项需主动询问）：
| 输入项 |
说明 |
示例 |
| 迭代时长 |
迭代周期天数 |
2 周 (10 工作日) |
| 团队成员列表 |
姓名 + 角色 |
张三(前端)、李四(后端)、王五(测试) |
| 各成员可用天数 |
考虑请假、会议、其他项目占用 |
张三 8 天、李四 10 天、王五 9 天 |
| 历史速率 |
近 3-5 个迭代的完成故事点 |
[32, 28, 35, 30, 33] |
| 产品待办列表 |
待规划的用户故事列表（含优先级和估点） |
见待办列表表 |
| 已知依赖 |
用户故事之间的前后置关系 |
故事-3 依赖于 故事-1 完成 |
信息不足时的默认值
- 迭代时长未指定 → 默认 2 周 (10 工作日)
- 可用天数未指定 → 默认迭代时长 × 0.8（扣除会议和杂务）
- 历史速率未知 → 使用本次估点总和的 70% 作为保守目标
- 角色未指定 → 按通用开发者处理
Step 2：计算团队产能 (Capacity)
2.1 个人产能计算
个人产能 = 可用天数 × 每日有效工时 × 专注系数
| 参数 |
默认值 |
说明 |
| 每日有效工时 |
6 小时 |
8 小时工作日扣除会议、休息等 |
| 专注系数 |
0.8 |
扣除上下文切换、沟通等开销 |
2.2 团队总产能
团队总产能 (人时) = Σ(各成员个人产能)
团队总产能 (故事点) = 参考速率取值
2.3 产能计算示例
| 成员 |
可用天数 |
有效工时/天 |
专注系数 |
个人产能(人时) |
| 张三 |
8 |
6 |
0.8 |
38.4 |
| 李四 |
10 |
6 |
0.8 |
48.0 |
| 王五 |
9 |
6 |
0.8 |
43.2 |
| 合计 |
|
|
|
129.6 |
Step 3：确定迭代目标与范围
3.1 速率参考值计算
参考速率 = 近 N 个迭代速率的平均值
建议取 N = 3~5，剔除明显异常值
| 计算方式 |
适用场景 |
说明 |
| 简单平均 |
团队稳定 |
mean(近 3-5 个迭代) |
| 加权平均 |
团队近期有变化 |
近期权重更高 |
| 取最小值 |
保守承诺 |
min(近 3 个迭代) |
3.2 范围选定规则
- 按优先级从高到低排列待办列表
- 累加故事点，直到接近但不超过参考速率
- 如最后一个用户故事加入后超出速率的 110%，则不纳入
- 留出 10-15% 的缓冲用于应急和技术债务
Step 4：任务拆分与估点
4.1 用户故事拆分检查
每个用户故事应满足 INVEST 原则：
| 原则 |
含义 |
检查点 |
| Independent |
独立 |
是否可单独交付？ |
| Negotiable |
可协商 |
实现方式是否灵活？ |
| Valuable |
有价值 |
是否对用户有明确价值？ |
| Estimable |
可估算 |
团队是否能给出估点？ |
| Small |
小 |
是否能在一个迭代内完成？ |
| Testable |
可测试 |
验收标准是否明确？ |
4.2 估点参考
如用户未提供估点，使用以下对照表辅助估算：
| 故事点 |
复杂度 |
典型工作量 |
| 1 |
极简 |
几小时内完成，无需讨论 |
| 2 |
简单 |
半天到一天，方案明确 |
| 3 |
中等偏简 |
1-2 天，有少量不确定性 |
| 5 |
中等 |
2-3 天，需要设计和讨论 |
| 8 |
复杂 |
3-5 天，涉及多个组件 |
| 13 |
很复杂 |
一周左右，建议拆分 |
| 21+ |
过大 |
必须拆分后再规划 |
Step 5：依赖分析
5.1 依赖类型
| 类型 |
说明 |
示例 |
| 完成-开始 (FS) |
A 完成后 B 才能开始 |
API 开发完成后前端才能联调 |
| 开始-开始 (SS) |
A 开始后 B 才能开始 |
数据库设计开始后，后端可同步开发 |
| 外部依赖 |
依赖团队外部的交付 |
等待第三方 API 文档 |
| 技术依赖 |
依赖技术组件或环境 |
需要先完成基础框架搭建 |
5.2 依赖检查流程
- 列出所有用户故事的前置条件
- 构建依赖关系图（用列表或矩阵表示）
- 识别关键路径：找出最长依赖链
- 标记风险依赖：
- 外部依赖（不可控）→ 标为高风险
- 跨成员依赖链 > 3 → 标为中风险
- 循环依赖 → 必须拆解
5.3 依赖矩阵输出格式
| 故事 | 依赖于 | 被依赖于 | 类型 | 风险 |
|----------|-----------|-----------|------|------|
| 故事-1 | 无 | 故事-3 | - | 低 |
| 故事-2 | 无 | 无 | - | 低 |
| 故事-3 | 故事-1 | 故事-5 | FS | 中 |
| 故事-4 | 外部API | 故事-5 | 外部 | 高 |
| 故事-5 | 故事-3,4 | 无 | FS | 高 |
Step 6：任务分配与负载均衡
6.1 分配原则
- 技能匹配优先：按成员技能和用户故事技术要求匹配
- 依赖顺序：被依赖的用户故事优先分配，确保不阻塞后续任务
- 负载均衡：各成员负载偏差不超过 ±20%
- 避免单点故障：关键用户故事不应只由一人负责
6.2 负载均衡计算
成员负载率 = 分配故事点 / 个人产能(故事点等效) × 100%
团队平均负载率 = 总分配故事点 / 团队总产能(故事点等效) × 100%
负载偏差 = |成员负载率 - 团队平均负载率|
6.3 负载均衡检查规则
| 检查项 |
阈值 |
处理方式 |
| 成员负载率 > 100% |
超载 |
必须转移任务给其他成员 |
| 成员负载率 > 90% |
偏高 |
警告，无缓冲空间 |
| 成员负载率 < 50% |
偏低 |
检查是否可承接更多任务 |
| 负载偏差 > 20% |
不均衡 |
重新调整分配 |
| 单人承担 > 40% 总故事点 |
集中度过高 |
分散风险 |
6.4 分配调整策略
当出现负载不均衡时，按以下优先级调整：
- 将低优先级用户故事从高负载成员转移到低负载成员
- 将技能要求不严格的用户故事重新分配
- 拆分大用户故事使其可由多人并行
- 缩减迭代范围（移除最低优先级用户故事）
Step 7：输出迭代计划
完成以上步骤后，按以下模板输出：
## 迭代计划：迭代 [编号] ([起止日期])
### 迭代目标
[用一句话描述本迭代要达成的核心目标]
### 团队产能
| 成员 | 角色 | 可用天数 | 产能(人时) |
|------|------|---------|-----------|
- 团队总产能：X 人时
- 参考速率：X 故事点
- 本次规划：X 故事点 (占速率的 X%)
### 用户故事分配
| # | 用户故事 | 优先级 | 故事点 | 负责人 | 依赖 | 状态 |
|---|-------|--------|-------|--------|------|------|
### 负载分布
| 成员 | 分配故事点 | 负载率 | 状态 |
|------|-----------|--------|------|
### 依赖关系
[依赖矩阵或依赖链描述]
### 关键路径
[列出最长依赖链及预计完成顺序]
### 风险与备注
- [风险项 1]
- [风险项 2]
- [缓冲和应急方案]
Step 8：风险检查与承诺确认
最终检查清单
在输出计划后，逐项确认：
- [ ] 总故事点是否在速率的 80-100% 范围内？
- [ ] 每位成员负载率是否在 60-90% 之间？
- [ ] 负载偏差是否 ≤ 20%？
- [ ] 是否有循环依赖？（不允许）
- [ ] 外部依赖是否已标注风险等级？
- [ ] 关键路径上的用户故事是否有人负责？
- [ ] 是否预留了 10-15% 的缓冲？
- [ ] 用户故事估点是否有超过 13 点的？（建议拆分）
- [ ] 是否有成员承担了 40% 以上的总故事点？
常见问题处理
| 问题 |
建议 |
| 速率数据不足 |
取保守估计（已知数据最小值的 80%） |
| 团队成员变动 |
新成员首个迭代按 50% 产能计算 |
| 需求不清晰 |
对不清晰用户故事加 Spike（技术调研），不计入速率 |
| 技术债务积压 |
每个迭代预留 15-20% 产能处理技术债 |
| 跨团队依赖 |
标为外部依赖，提前与相关团队对齐 |
常见误区（规划时必须检查并纠正）
| 误区 |
后果 |
正确做法 |
| 把速率当承诺上限，100% 填满 |
无缓冲，任何意外导致迭代失败 |
保留 10-15% 缓冲，承诺 85-90% |
| 用满额工作日算产能，忽略会议和请假 |
产能虚高，实际交付不达预期 |
必须用 可用天数 × 6h × 0.8 |
| 跳过依赖分析直接分配任务 |
开发中才发现阻塞，被迫返工 |
先画依赖矩阵再做分配 |
| 大用户故事（>13 SP）不拆就排进迭代 |
估点不准、进度不可追踪 |
超过 13 点必须拆分后再规划 |
| 关键路径全部压在一个人身上 |
单点故障，一人请假整条链断 |
关键路径任务分散到 2+ 人 |
| 新成员按满产能分配 |
新人上手慢，实际完成远低于预期 |
新成员首个迭代按 50% 产能 |
参考资料
- Mike Cohn《Agile Estimating and Planning》
- Scrum Guide 2020 (scrumguides.org)
- SAFe (Scaled Agile Framework) — PI Planning 和 Sprint Planning 方法论
- PMI-ACP (Agile Certified Practitioner) 知识体系