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