epic-breakdown-advisor

目的

引导产品经理使用 Richard Lawrence 完整的 Humanizing Work 方法，将 Epic 拆分为用户故事。这是一种系统化、由流程图驱动的方法，依次应用 9 种拆分模式。使用此方法确定适用的模式，在拆分时保留用户价值，并根据拆分揭示了哪些可以消除的低价值工作来评估结果。这能确保采用纵向切片（端到端价值），而非横向切片（技术层）。

这不是随意拆分，而是一套经过验证、循序渐进的方法：从验证开始，按顺序逐一应用模式，并从策略层面评估结果。

输入

最适合提供： 你需要拆分的 Epic 或大型用户故事——按待办列表中的原文粘贴。 也可以提供： 团队背景（Sprint 时长、估算上限）以及阻碍交付的问题（规模太大，难以估算、安排顺序或发布）。

调用时提供的任何内容——技能名称后的文本、粘贴的上下文信息，或附加的 ARGUMENTS: 行——都视为已回答的问题。使用这些内容，并跳过其中已涵盖的问题；不要重复询问。

空手而来也没关系。 顾问会先询问 Epic 文本，然后根据 Humanizing Work 模式流程图逐步分析。

调用示例： Break this down: 'As a finance admin, I can export any report to Excel, PDF, or CSV with custom date ranges and saved templates.'

核心概念

核心原则：纵向切片保留价值

用户故事是“从用户的角度描述系统行为的变化”。拆分必须保留纵向切片——涉及多个架构层并交付可观察到的用户价值的工作，而不是只处理单个组件的横向切片（例如“前端故事” + “后端故事”）。

三步流程

1. 拆分前验证： 检查故事是否符合 INVEST 标准（“小”除外）
2. 应用拆分模式： 按顺序尝试 9 种模式，直到找到适用的一种
3. 评估拆分结果： 选择能揭示低价值工作或产出规模相当的故事的拆分方式

9 种拆分模式（按顺序）

1. 工作流步骤 — 采用精简的端到端切片，而非逐步拆分
2. 操作（CRUD） — 将创建、读取、更新、删除分别拆分为独立故事
3. 业务规则变体 — 不同规则对应不同故事
4. 数据变体 — 不同数据类型或结构
5. 数据录入方式 — 先实现简单 UI，再实现复杂 UI
6. 主要工作量 — “先实现一个，再添加其余部分”
7. 简单 / 复杂 — 先实现最简单的核心版本，再处理变体
8. 延后性能优化 — 先“让它能用”，再“让它更快”
9. 单独拆出 Spike — 当不确定性阻碍拆分时，限时开展调查

元模式（适用于所有模式）

1. 找出核心复杂性
2. 列出所有变体
3. 将变体缩减为一个完整切片
4. 将其他变体拆分为独立故事

此方法的优势

• 避免随意拆分： 系统化清单可避免凭猜测拆分
• 保留用户价值： 每个故事都能交付可观察到的价值
• 揭示浪费： 合理的拆分会暴露可降低优先级的低价值工作
• 可重复使用： 可一致地应用于任何 Epic

---

引导流程的权威来源

默认使用 workshop-facilitation 作为此技能的交互协议。

其中定义了：

• 会话开始提示 + 进入模式（引导式、上下文信息、最佳猜测）
• 每轮只提一个问题，并使用通俗易懂的提示
• 进度标签（例如 Context Qx/8 和 Scoring Qx/5）
• 中断处理以及暂停 / 恢复行为
• 决策节点处的编号建议
• 常规问题使用编号快捷选项（适用时包括 Other (specify)）

此文件定义领域专属的评估内容。若有冲突，请遵循此文件中的领域逻辑。

应用

步骤 0：提供 Epic 背景

Agent 询问：

请分享你的 Epic：

• Epic 标题/ID
• 描述或假设
• 验收标准（尤其是多个“When/Then”对）
• 目标用户画像
• 粗略估算

你可以从 Jira、Linear 粘贴内容，也可以简要描述。

---

步骤 1：拆分前验证（INVEST 检查）

拆分前，请验证你的用户故事是否符合 INVEST 标准（“Small”除外）：

Agent 依次提问：

1. 独立性？ “这个用户故事能否在没有其他用户故事的硬性技术依赖的情况下，进行优先级排序和开发？”

选项：

• 是 — 没有阻塞性依赖
• 否 — 需要先完成其他工作（标记此项）

---

2. 可协商性？ “这个用户故事是否留有空间，让团队协作探索实现细节，而不是规定确切的解决方案？”

选项：

• 是 — 它是开启对话的起点，而不是规格说明
• 否 — 它的规定过于具体（可能需要重新表述）

---

3. 有价值？ “这个用户故事能否为用户带来可观察到的价值？（如果不能，请将它与相关工作合并，而不是拆分。）”

选项：

• 是 — 用户能看到/体验到不同之处
• 否 — 这是一个技术任务（不是用户故事——不要拆分，应重新表述）

**⚠️ 关键检查：**如果用户故事未通过“有价值”检查，请停止。不要拆分。应将它与其他工作合并，创建有意义的增量。

---

4. 可估算？ “你的团队能否对这个用户故事进行相对估算（即使只是粗略估算）？”

选项：

• 是 — 团队可以估算天数/点数
• 否 — 不确定性太高（可能需要先进行技术调研）

---

5. 可测试？ “这个用户故事是否有 QA 可以验证的具体验收标准？”

选项：

• 是 — 通过/失败条件明确
• 否 — 需要更明确的验收标准（拆分前先完善）

---

如果用户故事通过所有检查 → 继续步骤 2（拆分模式） 如果用户故事未通过任何一项检查 → 拆分前先解决问题

---

步骤 2：依次应用拆分模式

按顺序逐一检查各个模式。对每种模式，询问“是否适用？”

---

模式 1：工作流步骤

关键要点：拆分为精简的端到端切片，而不是逐步拆分。先从一个覆盖完整工作流的简单案例开始，再将中间步骤作为独立用户故事添加。

Agent 询问： “你的 Epic 是否涉及多步骤工作流，可以先交付一个简单案例，之后再添加中间步骤？”

示例：

• 原始内容：“发布内容（需要编辑审核、法律审批、暂存）”
• **❌ 错误的拆分方式（逐步拆分）：**用户故事 1 = 编辑审核，用户故事 2 = 法律审批，用户故事 3 = 发布
• ✅ 正确的拆分方式（精简的端到端切片）：
  • 用户故事 1：发布内容（简单路径：作者上传，内容立即上线——无需审核）
  • 用户故事 2：添加编辑审核步骤（内容现在需要等待编辑批准后才能上线）
  • 用户故事 3：添加法律审批步骤（内容需要等待法律和编辑审批后才能上线）

每个用户故事都交付完整工作流，只是复杂程度逐步提高。

选项：

1. 是，多步骤工作流 → “描述工作流步骤”
2. 否，单一步骤 → 继续模式 2

**如果为是：**Agent 生成精简的端到端切片拆分方案。

---

模式 2：操作（CRUD）

关键要点：“管理”一词意味着包含多个操作。拆分为创建、读取、更新、删除。

Agent 询问： “你的 Epic 是否使用了‘管理’‘处理’或‘维护’等词语？如果是，它很可能捆绑了多个操作（CRUD）。”

示例：

• 原始内容：“管理用户账户”
• 拆分后：
  • 用户故事 1：创建用户账户
  • 用户故事 2：查看用户账户详情
  • 用户故事 3：编辑用户账户信息
  • 用户故事 4：删除用户账户

选项：

1. 是，包含多个操作 → “列出这些操作（创建/读取/更新/删除等）”
2. 否，单一操作 → 继续模式 3

**如果为是：**Agent 为每个操作生成一个用户故事。

---

模式 3：业务规则变化

关键洞察： 相同功能在不同规则下运行时，每条规则都应成为一个独立故事。

Agent 会询问： “你的史诗在不同场景（用户类型、地区、等级、条件）下是否有不同的业务规则？”

示例：

• 原始内容：“支持灵活日期的航班搜索（日期范围、特定周末、日期偏移）”
• 拆分：
  • 故事 1：按日期范围搜索（前后 N 天）
  • 故事 2：仅按特定周末搜索
  • 故事 3：按日期偏移搜索（提前或延后 N 天）

选项：

1. 是，规则不同 →“描述规则变化”
2. 否，规则都相同 →继续到模式 4

如果是： Agent 会针对每种规则变化生成一个故事。

---

模式 4：数据变化

关键洞察： 处理不同数据类型或结构会带来复杂性。根据需要适时添加变化。

Agent 会询问： “你的史诗是否需要处理不同的数据类型、格式或结构（例如文件类型、地理级别、用户属性）？”

示例：

• 原始内容：“地理搜索（县、市／镇／街区、自定义服务商区域）”
• 拆分：
  • 故事 1：按县搜索
  • 故事 2：添加市／镇／街区搜索
  • 故事 3：添加自定义服务商区域搜索

选项：

1. 是，数据类型不同 →“列出数据变化”
2. 否，只有一种数据类型 →继续到模式 5

如果是： Agent 会针对每种数据变化生成一个故事（先交付最简单的）。

---

模式 5：数据输入方式

关键洞察： UI 的复杂性独立于核心功能。先构建最简单的界面，再通过后续故事添加更复杂的 UI。

Agent 会询问： “你的史诗是否包含并非核心功能必需的复杂 UI 元素（日期选择器、自动补全、拖放）？”

示例：

• 原始内容：“使用日历日期选择器进行搜索”
• 拆分：
  • 故事 1：按日期搜索（基本文本输入：“YYYY-MM-DD”）
  • 故事 2：添加可视化日历选择器 UI

选项：

1. 是，包含复杂 UI 元素 →“描述 UI 增强内容”
2. 否，仅使用基本 UI →继续到模式 6

如果是： Agent 会生成故事 1 = 基本输入，故事 2 及后续故事 = UI 增强功能。

---

模式 6：主要工作量

关键洞察： 当初始实现承担了大部分复杂性，而后续添加都很简单时，可按“实现一个 + 添加其余项”的方式组织。

Agent 会询问： “你的史诗是否需要构建基础设施，其中首次实现很难，但添加更多内容很容易？”

示例：

• 原始内容：“接受信用卡付款（Visa、Mastercard、Amex、Discover）”
• 拆分：
  • 故事 1：接受 Visa 付款（构建完整的支付基础设施）
  • 故事 2：添加 Mastercard、Amex、Discover 支持（简单的增补）

⚠️ 注意： 第一个故事承担主要工作量（支付网关、安全性、合规性）。后续故事只是小幅增补。

选项：

1. 是，符合主要工作量模式 →“首次实现是什么？要添加哪些内容？”
2. 否，不涉及基础设施工作 →继续到模式 7

如果是： Agent 会生成故事 1 = 构建基础设施，故事 2 = 添加其余变体。

---

模式 7：简单 / 复杂

关键见解： 通过询问“最简单的版本是什么？”来识别故事的核心。将变体拆分为独立故事。

Agent 提问： “这个史诗中仍能交付价值的最简单版本是什么？你能否去掉复杂部分，以后再逐步添加？”

示例：

• 原始版本：“航班搜索（包含最多中转次数、附近机场、灵活日期）”
• 拆分：
  • 故事 1：基本航班搜索（出发地、目的地、日期）
  • 故事 2：添加最多中转次数筛选条件
  • 故事 3：添加附近机场选项
  • 故事 4：添加灵活日期选项

选项：

1. 是，可以识别出最简单的核心 → “描述最简单的版本，以及应该延后的变体”
2. 否，已经足够简单 → 继续执行模式 8

如果回答是： Agent 生成故事 1 = 最简单的核心，故事 2 及之后 = 各种变体。

---

模式 8：延后性能优化

关键见解： 将“让它能用”与“让它更快”拆分开。非功能性需求（性能、安全性、可扩展性）可以在交付功能后再处理。

Agent 提问： “你能否先交付功能价值，再在之后优化性能 / 安全性 / 可扩展性？”

示例：

• 原始版本：“实时搜索，响应时间 <100ms”
• 拆分：
  • 故事 1：搜索功能可用（功能性，无性能保证）
  • 故事 2：将搜索优化至 <100ms（添加缓存、索引）

选项：

1. 是，可以延后优化 → “功能版本是什么？要做哪些优化？”
2. 否，性能至关重要 → 继续执行模式 9

如果回答是： Agent 生成故事 1 = 功能实现，故事 2 = 优化。

---

模式 9：单独开展 Spike

关键见解： 当不确定性阻碍拆分时的最后手段。为调查设定时间限制，回答特定问题，然后在更充分了解情况后拆分实现故事。

Agent 表示： “模式 1–8 均不适用，这表明存在高度不确定性。拆分之前，先开展一次 spike 来降低不确定性。”

Spike 是一项有时间限制的调查（不是故事），用于回答以下问题：

• 技术上可行吗？
• 哪种方案性能最好？
• API 实际会返回什么？

Agent 提问： “阻碍你拆分这个史诗的最大未知因素是什么？”

选项：

1. 技术可行性 — “我们能用现有技术栈构建它吗？”
2. 方案不确定性 — “有多种解决方案，但不清楚哪种最好”
3. 外部依赖 — “不知道第三方 API 提供什么”

Agent 建议： → “开展一次为期 1–2 天的 spike，回答 [问题]。Spike 结束后再回来，我们会在更充分了解情况后拆分这个史诗。”

⚠️ Spike 产出的是经验，而不是可交付的代码。Spike 结束后，从模式 1 重新开始。

---

步骤 3：评估拆分质量

拆分后，使用以下标准进行评估：

Agent 提问：

1. 这次拆分是否揭示了可以降低优先级或删除的低价值工作？

• 优秀的拆分会体现二八原则：大部分价值集中在少部分功能中
• 示例：将“航班搜索”拆分为 4 个故事后，你发现“灵活日期”很少有人使用 → 降低其优先级或将其删除

2. 这次拆分是否产生了规模更均衡的故事？

• 规模相近的故事能让产品负责人拥有更大的优先级安排灵活性
• 示例：与其做一个为期 10 天的史诗，不如做五个为期 2 天的故事，这样便于在冲刺期间调整顺序

如果拆分不符合上述任一标准，请尝试其他模式。

---

元模式的应用

在所有模式中，遵循以下顺序：

1. 识别核心复杂性 — 这个史诗难在哪里？
2. 列出变体 — 有哪些不同的方式 / 情况 / 规则？
3. 缩减为一个完整切片 — 选择仍能端到端交付价值的最简单变体
4. 将其他变体拆分为独立故事

---

Cynefin 领域考量

策略会根据复杂性领域而变化：

Agent 提问： “这个史诗的周围存在多大的不确定性？”

选项：

1. 低不确定性（显而易见／复杂领域）——“我们知道要构建什么；这只是工程工作” → 找出所有用户故事，并按价值／风险排序

2. 高不确定性（复杂领域）——“我们不确定客户想要什么，也不确定什么方案有效” → 找出 1-2 个学习型用户故事；避免穷举（工作本身会让我们了解哪些事情重要）

3. 混乱——“一切都在失控；优先级每天都在变” → 推迟拆分，直到情况稳定；首先专注于稳定局面

---

输出：生成用户故事拆分结果

# Epic Breakdown Plan

**Epic:** [Original epic]
**Pre-Split Validation:** ✅ Passes INVEST (except Small)
**Splitting Pattern Applied:** [Pattern name]
**Rationale:** [Why this pattern fits]

---

## Story Breakdown

### Story 1: [Title] (Simplest Complete Slice)

**Summary:** [User-value-focused title]

**Use Case:**
- **As a** [persona]
- **I want to** [action]
- **so that** [outcome]

**Acceptance Criteria:**
- **Given:** [Preconditions]
- **When:** [Action]
- **Then:** [Outcome]

**Why This First:** [Delivers core value; simpler variations follow]
**Estimated Effort:** [Days/points]

---

### Story 2: [Title] (First Variation)

[Repeat...]

---

### Story 3: [Title] (Second Variation)

[Repeat...]

---

## Split Evaluation

✅ **Does this split reveal low-value work?**
- [Analysis: Which stories could be deprioritized/eliminated?]

✅ **Does this split produce equal-sized stories?**
- [Analysis: Are stories roughly equal in effort?]

---

## INVEST Validation (Each Story)

✅ **Independent:** Stories can be developed in any order
✅ **Negotiable:** Implementation details can be discovered collaboratively
✅ **Valuable:** Each story delivers observable user value
✅ **Estimable:** Team can size each story
✅ **Small:** Each story fits in 1-5 days
✅ **Testable:** Clear acceptance criteria for each

---

## Next Steps

1. **Review with team:** Do PM, design, engineering agree?
2. **Check for further splitting:** Are any stories still >5 days? If yes, **restart at Pattern 1** for that story.
3. **Prioritize:** Which story delivers most value first?
4. **Consider eliminating:** Did split reveal low-value stories? Kill or defer them.

---

**If stories are still too large, re-apply patterns starting at Pattern 1.**

---

示例

示例 1：应用模式 1（工作流步骤——端到端薄切片）

史诗：“发布博客文章（需要编辑审核、法务审批和暂存）”

拆分前验证：✅ 符合 INVEST

模式 1：“是否包含工作流步骤？”→ 是 ✅

❌ 错误拆分（逐步拆分）：

1. 编辑审核用户故事
2. 法务审批用户故事
3. 发布用户故事 → 问题：用户故事 1 无法交付价值（用户什么也看不到）

✅ 正确拆分（端到端薄切片）：

1. 发布文章（简单路径）——作者上传后，文章立即上线（无需审核）
2. 添加编辑审核——文章现在需要等待编辑批准后才能上线
3. 添加法务审批——文章现在需要等待法务和编辑批准后才能上线

为何有效：每个用户故事都能交付完整工作流，只是复杂程度逐步增加。

---

示例 2：应用模式 2（CRUD 操作）

史诗：“管理用户个人资料”

模式 2：“是否包含‘管理’一词？”→ 是 ✅（表示 CRUD）

拆分：

1. 创建用户个人资料
2. 查看用户个人资料详情
3. 编辑用户个人资料信息
4. 删除用户个人资料

拆分评估：

• ✅ **揭示低价值工作：**分析后发现，“删除个人资料”很少使用 → 降低优先级
• ✅ **用户故事规模相当：**每个需要 1-2 天

---

示例 3：应用模式 7（简单／复杂）

史诗：“航班搜索，支持最多中转次数、附近机场和灵活日期”

模式 7：“最简单的版本是什么？”→ 基本搜索 ✅

拆分：

1. 基本航班搜索（出发地、目的地、日期）——核心价值
2. 添加最多中转次数筛选器——增强功能
3. 添加附近机场选项——增强功能
4. 添加灵活日期选项——增强功能

拆分评估：

• ✅ **揭示低价值工作：**用户调研显示，“灵活日期”很少使用 → 取消或推迟
• ✅ **用户故事规模相当：**用户故事 1 = 3 天，其他各为 1 天

---

示例 4：迭代拆分（多种模式）

史诗：“结账流程，支持折扣（会员、VIP、首次购买）和付款方式（Visa、Mastercard、Amex）”

**第一轮——模式 1（工作流）：**是 ✅

• 用户故事 1：将商品添加到购物车
• 用户故事 2：应用折扣
• 用户故事 3：完成付款

**检查用户故事 2（“应用折扣”）：**仍需 4 天 → 过大，需要重新拆分

**对用户故事 2 进行第二轮拆分——模式 3（业务规则）：**是 ✅

• 用户故事 2a：应用会员折扣（10%）
• 用户故事 2b：应用 VIP 折扣（20%）
• 用户故事 2c：应用首次购买折扣（5%）

**检查用户故事 3（“完成付款”）：**仍需 5 天 → 过大，需要重新拆分

**对用户故事 3 进行第三轮拆分——模式 6（主要工作量）：**是 ✅

• 用户故事 3a：接受 Visa 付款（构建支付基础设施）
• 用户故事 3b：添加 Mastercard 和 Amex 支持

**最终拆分结果：**6 个用户故事，每个需要 1-2 天

---

常见陷阱

陷阱 1：跳过拆分前验证

**症状：**不检查 INVEST 就直接开始拆分

**后果：**拆分了不该拆分的用户故事（例如，不具备价值 = 技术任务）

**解决方法：**务必先执行步骤 1（INVEST 检查），再执行步骤 2（拆分模式）

---

陷阱 2：逐步拆分工作流（错误使用模式 1）

**症状：**故事 1 = “编辑审查”，故事 2 = “法律审批”

**后果：**故事无法交付端到端价值

解决方法：每个故事都应覆盖完整工作流（薄切片式端到端流程），只是复杂程度逐步提升

---

陷阱 3：水平拆分（技术层）

症状：“故事 1：构建 API。故事 2：构建 UI。”

**后果：**两个故事都无法交付用户价值

**解决方法：**垂直拆分——每个故事都包含前端和后端，以交付可观察到的用户行为

---

陷阱 4：强行套用不适用的模式

症状：“即使没有先后顺序，我们也要按工作流拆分。”

**后果：**拆分随意且毫无意义

**解决方法：**如果模式不适用，就回答“不适用”，然后继续尝试下一个模式

---

陷阱 5：没有重新拆分大型故事

**症状：**将史诗拆分成 3 个故事，但每个故事仍需 5 天以上

**后果：**故事对于一个冲刺周期来说太大

解决方法：对每个大型故事从模式 1 重新开始，直到所有故事都只需 1–5 天

---

陷阱 6：忽略拆分评估（步骤 3）

**症状：**完成拆分后，却没有评估这是否揭示了低价值工作

**后果：**错失消除浪费的机会

**解决方法：**拆分后，问：“这是否揭示了可以取消或推迟的工作？”

---

练习与技能培养

**Humanizing Work 建议：**团队通过多次练习，总共花费 2.5–3 小时即可熟练掌握。

练习方法：

1. 分析最近完成的功能（事后回顾更容易发现模式）
2. 按照流程图梳理已完成的工作——适用哪种模式？
3. 为每项功能找出多种拆分方式
4. 建立领域特定模式示例的通用词汇

**不要跳过练习。**技能是在分析过去的交付成果中培养出来的，而不只是通过完善未来的工作。

---

参考资料

相关技能

• user-story-splitting.md — 详细介绍 9 种模式
• user-story.md — 编写故事的格式
• epic-hypothesis.md — 原始史诗格式

外部框架

• Richard Lawrence 与 Peter Green，《The Humanizing Work Guide to Splitting User Stories》——完整方法论
• Bill Wake，《INVEST in Good Stories》（2003 年）——质量标准

来源

• https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/

---

**技能类型：**交互式 建议文件名：epic-breakdown-advisor.md 建议存放位置：/skills/interactive/ **依赖项：**使用 user-story-splitting.md、user-story.md、epic-hypothesis.md