iteration-planner

# 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 范围选定规则 1. 按优先级从高到低排列 Backlog 2. 累加故事点，直到接近但不超过参考 Velocity 3. 如最后一个 Story 加入后超出 Velocity 的 110%，则不纳入 4. 留出 10-15% 的缓冲用于应急和技术债务 --- ## Step 4：任务拆分与估点 ### 4.1 Story 拆分检查 每个 Story 应满足 INVEST 原则： | 原则 | 含义 | 检查点 | |------|------|--------| | **I**ndependent | 独立 | 是否可单独交付？ | | **N**egotiable | 可协商 | 实现方式是否灵活？ | | **V**aluable | 有价值 | 是否对用户有明确价值？ | | **E**stimable | 可估算 | 团队是否能给出估点？ | | **S**mall | 小 | 是否能在一个 Sprint 内完成？ | | **T**estable | 可测试 | 验收标准是否明确？ | ### 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 依赖检查流程 1. **列出所有 Story 的前置条件** 2. **构建依赖关系图**（用列表或矩阵表示） 3. **识别关键路径**：找出最长依赖链 4. **标记风险依赖**： - 外部依赖（不可控）→ 标为高风险 - 跨成员依赖链 > 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 分配原则 1. **技能匹配优先**：按成员技能和 Story 技术要求匹配 2. **依赖顺序**：被依赖的 Story 优先分配，确保不阻塞后续任务 3. **负载均衡**：各成员负载偏差不超过 ±20% 4. **避免单点故障**：关键 Story 不应只由一人负责 ### 6.2 负载均衡计算 ``` 成员负载率 = 分配故事点 / 个人产能(故事点等效) × 100% 团队平均负载率 = 总分配故事点 / 团队总产能(故事点等效) × 100% 负载偏差 = |成员负载率 - 团队平均负载率| ``` ### 6.3 负载均衡检查规则 | 检查项 | 阈值 | 处理方式 | |--------|------|---------| | 成员负载率 > 100% | 超载 | 必须转移任务给其他成员 | | 成员负载率 > 90% | 偏高 | 警告，无缓冲空间 | | 成员负载率 < 50% | 偏低 | 检查是否可承接更多任务 | | 负载偏差 > 20% | 不均衡 | 重新调整分配 | | 单人承担 > 40% 总故事点 | 集中度过高 | 分散风险 | ### 6.4 分配调整策略 当出现负载不均衡时，按以下优先级调整： 1. 将低优先级 Story 从高负载成员转移到低负载成员 2. 将技能要求不严格的 Story 重新分配 3. 拆分大 Story 使其可由多人并行 4. 缩减 Sprint 范围（移除最低优先级 Story） --- ## Step 7：输出 Sprint 计划 完成以上步骤后，按以下模板输出： ``` ## Sprint 计划：Sprint [编号] ([起止日期]) ### Sprint 目标 [用一句话描述本 Sprint 要达成的核心目标] ### 团队产能 | 成员 | 角色 | 可用天数 | 产能(人时) | |------|------|---------|-----------| - 团队总产能：X 人时 - 参考 Velocity：X 故事点 - 本次规划：X 故事点 (占 Velocity 的 X%) ### Story 分配 | # | Story | 优先级 | 故事点 | 负责人 | 依赖 | 状态 | |---|-------|--------|-------|--------|------|------| ### 负载分布 | 成员 | 分配故事点 | 负载率 | 状态 | |------|-----------|--------|------| ### 依赖关系 [依赖矩阵或依赖链描述] ### 关键路径 [列出最长依赖链及预计完成顺序] ### 风险与备注 - [风险项 1] - [风险项 2] - [缓冲和应急方案] ``` --- ## Step 8：风险检查与承诺确认 ### 最终检查清单 在输出计划后，逐项确认： - [ ] 总故事点是否在 Velocity 的 80-100% 范围内？ - [ ] 每位成员负载率是否在 60-90% 之间？ - [ ] 负载偏差是否 ≤ 20%？ - [ ] 是否有循环依赖？（不允许） - [ ] 外部依赖是否已标注风险等级？ - [ ] 关键路径上的 Story 是否有人负责？ - [ ] 是否预留了 10-15% 的缓冲？ - [ ] Story 估点是否有超过 13 点的？（建议拆分） - [ ] 是否有成员承担了 40% 以上的总故事点？ ### 常见问题处理 | 问题 | 建议 | |------|------| | 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) 知识体系