iDWong 迭代规划与敏捷管理
Step 0: 主动扫描项目上下文（必须第一步，不要等用户提供）
不要等用户手动描述需求，先主动用工具扫描项目，找到已有文档后再开始工作。
扫描顺序（优先级从高到低）
| 优先级 | 文件类型 | Glob 查找方式 |
|---|---|---|
| 最高 | 需求说明书 | Glob("**/*需求*说明书*.md") / Glob("**/*spec*.md") / Glob("**/*requirement*.md") |
| 高 | 设计方案 | Glob("**/*设计*方案*.md") / Glob("**/*系统设计*.md") / Glob("**/*design*.md") |
| 高 | 功能清单 | Glob("**/*功能*清单*.md") / Glob("**/*功能清单*") / Glob("**/*feature*.md") |
| 高 | CHANGELOG | Glob("**/CHANGELOG*.md") |
| 中 | README | Glob("**/README*.md") |
| 低 | 路由配置 | src/router/modules/ |
| 低 | 项目代码 | src/views/、src/api/、src/mock/ |
扫描完成后
- 汇报找到了哪些文档（文件路径 + 一句话说明内容）
- 直接基于文档内容开始工作，不需要用户再重复描述
- 如果没找到任何文档，再用 AskUserQuestion 向用户询问必要信息
- 如果文档内容不足以完成任务，只询问缺失的部分，不要重复问已有的信息
工作流程
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），团队共同估算