# Epic设计流程
```mermaid
flowchart TD
A[识别价值主题] --> B[定义Epic范围]
B --> C[设计Epic结构]
C --> D[制定验收标准]
D --> E[评估大小与依赖]
E --> F{质量检查}
F -->|通过| G[Epic就绪]
F -->|不通过| H[优化调整]
H --> B
A1[用户价值分析] --> A
A2[商业目标对齐] --> A
A3[技术价值识别] --> A
```
## 价值识别方法
```mermaid
mindmap
root((Epic价值))
用户价值
用户旅程痛点
核心使用场景
体验提升目标
商业价值
收入影响
成本优化
竞争优势
技术价值
架构改进
技术债还清
开发效率
```
### Epic定义建议
- **标题命名**: 使用"动词+对象"格式,如"构建用户工作区"
- **价值先行**: 每个Epic必须先定义用户价值,再描述功能
- **边界明确**: 用包含/不包含列表明确Epic范围
- **分阶段交付**: 大Epic按MVP→增强→完善分阶段
### 大小控制指南
| Epic类型 | 建议大小 | 完成周期 | Feature数量 |
|---------|---------|---------|------------|
| 小型Epic | 20-40 SP | 2-3迭代 | 2-4个 |
| 中型Epic | 40-80 SP | 3-5迭代 | 4-8个 |
| 大型Epic | 80-120 SP | 5-6迭代 | 8-12个 |
### 验收标准设计
- **功能完整性**: 可测试的功能检查点
- **质量标准**: 性能、安全、可用性指标
- **商业指标**: 可量化的业务成功指标
1. **INVEST原则必须遵循**
- Independent: Epic间依赖最小化
- Negotiable: 范围可协商调整
- Valuable: 有明确用户价值
- Estimable: 可进行工作量估算
- Small: 不超过6个迭代
- Testable: 有明确验收标准
2. **强制包含要素**
- 用户价值和商业价值必须明确
- 验收标准必须可测试和量化
- 依赖关系必须识别和记录
- 风险必须评估和应对
3. **范围控制规则**
- 单个Epic不超过120 Story Points
- 超过6迭代的必须拆分
- 不相关功能不得组合在同一Epic
1. **团队能力约束**
- Epic大小受团队速度限制
- 技术复杂度受团队技能约束
- 并行开发Epic数量有限
2. **业务约束**
- 必须与产品路线图对齐
- 受预算和时间窗口限制
- 合规和安全要求约束
3. **技术约束**
- 现有架构和技术债务影响
- 第三方集成依赖限制
- 性能和扩展性要求约束
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 价值清晰度 | 用户价值和商业价值都明确量化 | 价值描述清晰但部分未量化 | 价值模糊或无法说清 |
| 范围合理性 | 边界清晰,大小适中,内聚性强 | 边界基本清晰,大小可控 | 范围模糊或过大过小 |
| 验收标准 | 标准具体可测,覆盖功能质量业务 | 标准基本明确可测试 | 标准模糊或不可测 |
| 依赖管理 | 依赖最小化,风险已识别应对 | 依赖已识别,风险可控 | 依赖复杂或风险未评估 |
| INVEST符合度 | 完全符合INVEST原则 | 基本符合,个别项有改进空间 | 不符合多个INVEST原则 |