# Lesson 15: 需求拆解：从 PRD 到 Epics 和 Stories

## 本课目标

- 理解 BMM 创建 Epics 和 Stories 工作流（CE）的完整流程
- 掌握 Epic 和 Story 的区别、关系及拆解最佳实践
- 学会使用实现就绪检查（IR）确保开发准备就绪
- 理解从 PRD 到 Architecture 到 Epics 到 Stories 的完整链路

## 核心内容

### Epic 和 Story：先搞清楚概念

在开始之前，先搞明白这两个敏捷开发中最核心的概念。

**用一个比喻来理解**：

```
如果你在盖一栋房子——

PRD      = 这栋房子的设计图纸（整体需求）
Epic     = "搭框架"、"做装修"、"搞水电"（大的工作模块）
Story    = "铺客厅地板"、"装厨房水槽"（具体可执行的任务）
```

**更精确的定义**：

| 概念 | 定义 | 粒度 | 例子 |
|------|------|------|------|
| Epic | 一组相关 Story 的集合，代表一个完整的功能模块 | 大，通常需要 1-4 周完成 | "用户认证系统" |
| Story | 一个独立的、可交付的功能单元 | 小，通常 1-3 天完成 | "用户可以通过邮箱注册账户" |

**关键区别**：

- Epic 回答"要做什么大模块"
- Story 回答"具体做什么事情，让什么用户得到什么价值"

> **延伸阅读**：Stories 拆解完成后，每个 Story 附带的 BDD 验收标准会在 **Lesson 22（阶段 4）**中变成 `/tdd` 的测试用例和 `/e2e` 的端到端测试场景。Epics 的依赖关系则会在 **Lesson 21（阶段 4）**的 `/plan` 规划中转化为任务优先级。这条链路是：PRD → Epics → Stories → BDD → 自动化测试。

### CE 工作流：4 步拆解法

John 的 CE 工作流（Create Epics and Stories）将 PRD 系统地拆解为可执行的 Epics 和 Stories。

```
Step 1: 验证先决条件
       ↓ 检查 PRD 是否存在且完整
       ↓ 检查架构文档是否存在（可选但推荐）
       ↓ 检查 UX 设计是否存在（可选）

Step 2: 设计 Epics
       ↓ 从 PRD 的功能需求出发，规划 Epic 结构
       ↓ 确定 Epic 顺序和依赖关系
       ↓ 每个 Epic 定义目标、范围、成功标准

Step 3: 创建 Stories
       ↓ 为每个 Epic 拆解出具体的 Stories
       ↓ 每个 Story 包含用户故事、验收标准、技术要求
       ↓ Story 使用 BDD 格式的验收标准

Step 4: 最终验证
       ↓ 检查所有 PRD 需求是否被覆盖
       ↓ 检查 Story 之间的依赖是否合理
       ↓ 检查每个 Story 是否足够具体可执行
```

**启动 CE 工作流**：

```bash
# 方法 1：通过 PM 代理菜单
/bmad-pm
# 然后选择 [CE]

# 方法 2：直接调用
/bmad-create-epics-and-stories
```

### Epic 设计的最佳实践

#### Epic 的命名和编号

```markdown
## Epic 1: 用户认证与账户管理
目标：让用户能够安全地注册、登录和管理账户
范围：注册、登录、密码找回、个人信息管理
前置条件：无
成功标准：用户可以完成完整的注册到登录流程

## Epic 2: 核心记账功能
目标：让用户能够记录和管理日常收支
范围：手动记账、发票扫描、分类管理
前置条件：Epic 1（需要用户身份）
成功标准：用户可以完成一笔完整的记账操作

## Epic 3: AI 智能分析
目标：提供 AI 驱动的财务洞察
范围：现金流预测、异常检测、行业对标
前置条件：Epic 2（需要记账数据）
成功标准：AI 能基于用户数据生成有价值的分析报告
```

#### Epic 排序原则

```
1. 先做基础设施（认证、数据库、基本框架）
2. 再做核心功能（产品的核心价值）
3. 然后做增值功能（差异化、锦上添花）
4. 最后做优化（性能、体验、安全加固）
```

**反模式**（不要这样做）：

- 把所有功能放在一个 Epic 里
- Epic 之间有循环依赖
- Epic 没有明确的完成标准
- Epic 粒度差异太大（一个 3 天，另一个 3 个月）

### Story 编写的最佳实践

#### 用户故事格式

每个 Story 遵循标准的用户故事格式：

```
作为 [用户角色]，
我想要 [做什么事情]，
以便 [得到什么价值]。
```

**好的示例**：

```
Story 1.1: 用户邮箱注册

作为一个新用户，
我想要通过邮箱和密码注册账户，
以便我能保存我的记账数据并在多设备访问。

验收标准（BDD 格式）：
Given 用户在注册页面
When 用户输入有效的邮箱和密码（8位以上，含大小写字母和数字）
Then 系统创建新账户并发送验证邮件

Given 用户输入已注册的邮箱
When 用户提交注册表单
Then 系统提示"该邮箱已注册，请直接登录"

Given 用户输入不符合要求的密码
When 用户提交注册表单
Then 系统实时提示密码不符合要求的具体原因
```

**坏的示例**：

```
Story: 注册功能
- 做一个注册页面
- 要好看
- 要安全
```

#### 验收标准的 BDD 格式

BDD（行为驱动开发）格式是 Given-When-Then：

```
Given [前提条件]
When  [用户操作]
Then  [预期结果]
```

**为什么用 BDD？**

- 每条验收标准直接可以变成自动化测试
- 无歧义，开发和测试理解完全一致
- 强迫你思考边界情况（"如果用户输入错误的邮箱呢？"）

### 实现就绪检查（IR）

CE 完成后，在开始开发之前还有一个关键步骤——实现就绪检查（Implementation Readiness）。

**IR 是做什么的**：验证 PRD、UX 设计、系统架构和 Epics/Stories 是否全部对齐，没有矛盾或遗漏。

**IR 的 6 步检查**：

```
Step 1: 文档发现
       ↓ 找到所有相关文档（PRD、架构、UX、Epics）

Step 2: PRD 分析
       ↓ 检查 PRD 中的每个需求是否都有对应的 Epic/Story

Step 3: Epic 覆盖度验证
       ↓ 检查 Epics 是否完整覆盖了 PRD 的所有需求

Step 4: UX 对齐检查
       ↓ 检查 Epics/Stories 是否与 UX 设计一致

Step 5: Epic 质量审查
       ↓ 检查每个 Epic 和 Story 的质量

Step 6: 最终评估
       ↓ 输出实现就绪报告：通过 / 有条件通过 / 不通过
```

**启动 IR**：

```bash
# 通过 PM 代理菜单
/bmad-pm
# 选择 [IR]

# 或直接调用
/bmad-check-implementation-readiness
```

**IR 报告示例**：

```
实现就绪检查报告
========================

整体评估：有条件通过

✅ PRD 覆盖度：100%（所有需求都有对应 Story）
✅ Epic 结构：合理（6 个 Epic，清晰的依赖链）
⚠️ UX 对齐：92%（Story 2.3 缺少对应的 UX 设计）
✅ Story 质量：95%（验收标准完整）
⚠️ 依赖风险：Epic 3 依赖外部 API，需确认可用性

需要解决的问题（阻塞项）：
1. Story 2.3 "发票扫描结果展示" 缺少 UX 设计
   → 建议：在开始 Epic 2 前完成此 UX 设计

建议改进项（非阻塞）：
1. Story 1.2 验收标准可以更具体
2. Epic 4 的范围可以再收窄
```

### 从 PRD 到开发的完整链路

到了这里，让我们回顾一下整个链路：

```
┌──────────────────────────────────────────────────────┐
│                    发散阶段（CIS）                     │
│                                                      │
│  头脑风暴 → 创新策略 → 选定方向                       │
│  (Lesson 11) (Lesson 12)                             │
└────────────────────┬─────────────────────────────────┘
                     │
                     ▼
┌──────────────────────────────────────────────────────┐
│                    规划阶段（BMM）                     │
│                                                      │
│  市场研究 → 产品简报 → PRD → 架构 → UX              │
│  (Lesson 13)            (Lesson 14)                  │
└────────────────────┬─────────────────────────────────┘
                     │
                     ▼
┌──────────────────────────────────────────────────────┐
│                    拆解阶段（BMM）                     │
│                                                      │
│  Epics → Stories → 实现就绪检查                      │
│  (Lesson 15 - 你在这里)                              │
└────────────────────┬─────────────────────────────────┘
                     │
                     ▼
┌──────────────────────────────────────────────────────┐
│                    执行阶段（BMM）                     │
│                                                      │
│  冲刺规划 → 创建故事 → 开发 → 审查 → 下一个         │
│  (Lesson 16)                                         │
└──────────────────────────────────────────────────────┘
```

每一步都有对应的代理和工作流，每一步的输出都是下一步的输入。这就是 cc4pm 的核心价值——不是替你做决定，而是确保整个过程不掉链子。

### Story 模板详解

John 创建的每个 Story 文件遵循一个详细的模板：

```markdown
# Story [Epic编号]-[Story编号]: [Story标题]

## 状态
- Status: backlog | ready-for-dev | in-progress | review | done

## 用户故事
作为 [角色]，
我想要 [功能]，
以便 [价值]。

## 验收标准（BDD）
Given [前提条件]
When [用户操作]
Then [预期结果]

## 技术要求
- 相关的架构约束
- API 接口设计参考
- 数据模型说明

## 开发上下文
- 前置 Story 的关键产出
- 需要注意的技术决策
- 可复用的代码模式

## 测试要求
- 单元测试覆盖范围
- 集成测试场景
- 边界情况清单

## 参考资料
- PRD 对应章节
- 架构文档对应章节
- UX 设计稿链接
```

这个模板的设计目标是：开发人员拿到这个 Story 文件后，不需要再问任何人就能开始干活。

## 🛠️ 实操练习

> **⚠️ 实操须知**：命令需在新 Claude Code session 中执行。详见 [practice-notice.md](../shared/practice-notice.md)

完成以下练习，掌握需求拆解工具。

### 练习 1：创建 Epics 和 Stories

```bash
# 运行以下命令启动 PM 代理
/bmad-pm
# 选择 [CE] 创建 Epics 和 Stories
```

**任务**：
1. 确保已有 PRD 文档（上一课的产出）
2. 选择 `[CE]` 开始需求拆解
3. 完成 5 步拆解流程
4. 获得 Epics 清单和 Stories 文件

**预期产出**：
- Epics 清单（3-6 个 Epic）
- 每个 Epic 下的 Stories（每个 Epic 3-8 个 Story）
- BDD 格式的验收标准
- 保存在 `planning-artifacts/epics/` 的文档

### 练习 2：创建单个 Story 文件

使用专门的 Story 创建命令：

```bash
# 直接创建单个 Story
/bmad-create-story

# 或通过 PM 代理
/bmad-pm
# 选择 [CS] 创建故事
```

**任务**：
- 选择一个 Epic 中的 Story
- 创建完整的 Story 文件（包含技术要求、测试要求等）

### 练习 3：运行实现就绪检查

```bash
# 检查是否准备好开始开发
/bmad-check-implementation-readiness
```

**任务**：
- 运行 IR 检查
- 查看报告，识别阻塞项
- 解决阻塞项后重新检查

**检查清单**：
- [ ] 成功启动 `/bmad-pm` 并选择 [CE]
- [ ] 完成 Epics 和 Stories 拆解
- [ ] 每个 Story 都有 BDD 格式的验收标准
- [ ] 运行了实现就绪检查（IR）
- [ ] 所有阻塞项已解决

---

## 常见问题

**Q: Epic 应该拆多细？**

A: 一个 Epic 通常包含 3-8 个 Stories，完成周期 1-4 周。如果一个 Epic 只有 1-2 个 Story，说明太细了，可以合并到其他 Epic。如果超过 10 个 Story，说明太粗了，需要进一步拆分。

**Q: Story 之间有依赖怎么办？**

A: 依赖是正常的。关键是在 CE 阶段就把依赖关系标记清楚。John 会在 Step 4 验证时检查依赖是否合理。一般原则：同一个 Epic 内的 Story 按顺序执行，不同 Epic 的 Story 尽量减少依赖。

**Q: IR 检查不通过怎么办？**

A: IR 报告会明确告诉你哪些是"阻塞项"（必须解决才能开始开发），哪些是"建议项"（可以在开发过程中改进）。先解决阻塞项，比如补充缺失的 UX 设计或修正 Story 的验收标准，然后重新运行 IR。

**Q: PRD 改了，Epics 和 Stories 需要重新做吗？**

A: 取决于改动范围。小改动（比如调整一个指标数字）可以用 EP 修改 PRD 后，手动更新相关 Story 的验收标准。大改动（比如砍掉一个功能模块）建议重新运行 CE 工作流。John 在创建 PRD 时会把步骤进度保存下来，不需要从头开始。

**Q: 我的团队不用敏捷开发，Epics 和 Stories 还有用吗？**

A: 有用。即使你的团队不用 Scrum 或 Kanban，把需求拆解成 Epic 和 Story 的粒度也是一个很好的实践。它帮你把"模糊的大需求"变成"清晰的小任务"。你完全可以只用 CE 的拆解结果，不用后续的冲刺规划流程。

## 下一步

请调用 `AskUserQuestion` 展示以下选项，让学习者点击选择；从每条中提炼 1-5 个词作为 label，其余写入 description，不要要求输入数字：

- 进入下一课：Lesson 16 - 冲刺规划与进度追踪
- 返回主菜单
- 退出学习

---
*阶段 2 | Lesson 15/26 (阶段内 5/6) | 上一课: Lesson 14 - PRD 创建 | 下一课: Lesson 16 - 冲刺规划*