wang-q-l 迭代规划与敏捷管理
工作流程
Step 1: 采集迭代信息
用 AskUserQuestion 收集：
- 迭代周期（1周/2周/3周）？
- 团队规模（研发人数）？
- 本迭代优先完成哪些功能/需求？
- 上个迭代遗留问题？
Step 2: 容量规划
计算可用工时：
团队容量 = 人数 × 迭代天数 × 有效工时系数（0.7-0.8）
例：5人 × 10天 × 0.75 = 37.5人天
减去：
- 会议时间（约0.5天/人/迭代）
- Bug修复预留（约10-15%）
- 技术债处理（约10%）
可用容量 ≈ 30人天
Step 3: 需求拆解
将用户故事拆解为可执行任务：
## 迭代需求拆解
### 用户故事：[故事名称]
**故事描述**：作为[角色]，我希望[功能]，以便[价值] **验收标准**：
- [ ] [验收条件1]
- [ ] [验收条件2]
**任务拆解：**
| 任务编号 | 任务描述 | 类型 | 负责人 | 估算工时 | 优先级 |
| -------- | ------------- | ---- | ------ | -------- | ------ |
| T001 | [UI设计] | 设计 | 设计师 | 2天 | P0 |
| T002 | [前端开发] | 开发 | 前端 | 3天 | P0 |
| T003 | [后端API开发] | 开发 | 后端 | 2天 | P0 |
| T004 | [联调测试] | 测试 | QA | 1天 | P0 |
**总估算**：8人天
Step 4: 输出迭代计划
# Sprint [编号] 迭代计划
**迭代周期**：[开始日期] - [结束日期]（[X]天） **团队成员**：[成员列表] **总可用容量**：[X]人天
---
## 迭代目标
> [一句话描述本次迭代的核心目标]
本迭代完成后，用户可以[具体能力描述]。
---
## 迭代需求列表
| 优先级 | 需求/用户故事 | 故事点/工时 | 负责人 | 状态 |
| ------ | ------------- | ----------- | ------ | ------------ |
| P0 | [需求1] | [X天] | [人] | 待开始 |
| P0 | [需求2] | [X天] | [人] | 待开始 |
| P1 | [需求3] | [X天] | [人] | 待开始 |
| P2 | [需求4] | [X天] | [人] | 条件允许时做 |
**计划总工时**：[X]人天 / 可用 [Y]人天
---
## 里程碑节点
| 日期 | 里程碑 | 交付物 |
| ------ | ------------ | ------------ |
| [日期] | 需求评审完成 | 需求文档确认 |
| [日期] | UI设计完成 | 设计稿交付 |
| [日期] | 开发完成 | 代码提测 |
| [日期] | 测试完成 | Bug清零 |
| [日期] | 上线发布 | 生产环境部署 |
---
## 风险预警
| 风险 | 影响 | 应对 |
| ------- | -------- | ------ |
| [风险1] | 延期X天 | [预案] |
| [风险2] | 功能裁剪 | [预案] |
---
## Not In Sprint（本迭代不做）
- [需求A]：原因：[资源不足/依赖未就绪/优先级调整]
- [需求B]：推迟到 Sprint [X+1]
Step 5: 迭代复盘
# Sprint [编号] 迭代复盘
**复盘日期**：[日期] **参与成员**：[成员列表]
---
## 迭代目标完成情况
| 需求 | 计划完成 | 实际完成 | 完成率 |
| ------- | -------- | -------- | ------ |
| [需求1] | [X天] | [Y天] | ✅/❌ |
| [需求2] | [X天] | [Y天] | ✅/❌ |
**整体完成率**：[X]% **速度（velocity）**：[X]故事点/迭代
---
## 做得好的地方（Keep）
1. [亮点1]
2. [亮点2]
3. [亮点3]
## 需要改进的地方（Improve）
1. **[问题1]**
- 现状：[描述]
- 根因：[分析]
- 改进措施：[具体行动]
2. **[问题2]** ...
## 尝试的新事物（Try）
- [下个迭代想尝试的改变]
---
## 数据指标
| 指标 | 本迭代 | 上迭代 | 趋势 |
| -------------- | ------ | ------ | ---- |
| 计划完成率 | X% | Y% | ↑/↓ |
| Bug率(P0/P1) | X个 | Y个 | ↑/↓ |
| 代码审查覆盖率 | X% | Y% | ↑/↓ |
| 迭代延期天数 | X天 | Y天 | ↑/↓ |
---
## 下迭代预告
**初步规划的核心需求：**
- [需求1]
- [需求2]
- [遗留需求]
最佳实践
- 每日站会：不超过15分钟，聚焦三个问题：昨天做了什么/今天计划做什么/有什么阻碍
- 需求冻结：迭代开始后原则上不新增需求，紧急需求需置换等量工时
- Definition of Done：每个需求必须定义"完成"标准（代码审查+测试通过+文档更新）
- 故事点估算：使用斐波那契数列（1/2/3/5/8/13），团队共同估算