name: epic-breakdown-advisor description: 使用Richard Lawrence的Humanizing Work方法论将史诗分解为用户故事——一种流程图驱动的方法，顺序应用9个拆分模式。 type: interactive
目的
指导产品经理使用Richard Lawrence完整的Humanizing Work方法论将史诗分解为用户故事——这是一种系统化的、流程图驱动的方法，顺序应用9个拆分模式。使用此方法来识别适用的模式，在拆分时保留用户价值，并根据拆分揭示的低价值工作（可消除）来评估拆分。这确保垂直切片（端到端价值）而非水平切片（技术层）。
这不是任意切片——这是一个经过验证的、系统化的过程，从验证开始，按顺序遍历模式，并策略性地评估结果。
核心概念
核心原则：垂直切片保留价值
用户故事是“从用户角度描述系统行为的变化”。拆分必须保持垂直切片——触及多个架构层并交付可观察用户价值的工作——而非处理单个组件的水平切片（例如，“前端故事”+“后端故事”）。
三步过程
- 拆分前验证： 检查故事是否满足INVEST标准（除“小”外）
- 应用拆分模式： 顺序遍历9个模式，直到找到适用的
- 评估拆分： 选择能揭示低价值工作或产生大小相等故事的拆分
9个拆分模式（按顺序）
- 工作流步骤——薄端到端切片，非逐步
- 操作（CRUD）——创建、读取、更新、删除作为独立故事
- 业务规则变体——不同规则=不同故事
- 数据变体——不同数据类型/结构
- 数据输入方法——简单UI优先，花哨UI后
- 主要努力——“实现一个+添加剩余”
- 简单/复杂——核心最简单版本优先，变体后
- 延迟性能——“让它工作”在“让它快”之前
- 分离出探索——当不确定性阻碍拆分时，时间箱调查
元模式（适用于所有模式）
- 识别核心复杂性
- 列出所有变体
- 将变体减少为一个完整切片
- 使其他变体成为独立故事
为什么这有效
- 防止任意拆分： 系统化清单防止猜测
- 保留用户价值： 每个故事交付可观察价值
- 揭示浪费： 好拆分暴露低价值工作，可降低优先级
- 可重复： 一致应用于任何史诗
引导源真相
使用workshop-facilitation作为此技能的默认交互协议。
它定义：
- 会话提醒+进入模式（引导式、上下文转储、最佳猜测）
- 单轮提问与自然语言提示
- 进度标签（例如，上下文 Qx/8 和评分 Qx/5）
- 中断处理和暂停/恢复行为
- 决策点编号推荐
- 常规问题快速选择编号响应选项（当有用时包括
其他（指定））
此文件定义领域特定评估内容。如有冲突，遵循此文件的领域逻辑。
应用
步骤0：提供史诗上下文
代理问：
请分享您的史诗：
- 史诗标题/ID
- 描述或假设
- 验收标准（尤其是多个“当/然后”对）
- 目标角色
- 粗略估算
您可以从Jira、Linear粘贴或简要描述。
步骤1：拆分前验证（INVEST检查）
拆分前，验证您的故事满足INVEST标准（除“小”外）：
代理按顺序提问：
1. 独立？ “此故事能否在没有其他故事硬技术依赖的情况下优先考虑和开发？”
选项：
- 是——无阻塞依赖
- 否——需要其他工作先完成（标记此）
2. 可协商？ “此故事是否为团队协作发现实现细节留出空间，而非规定确切解决方案？”
选项：
- 是——它是对话启动器，非规范
- 否——它太规定性（可能需要重构）
3. 有价值？ “此故事是否向用户交付可观察价值？（如果不是，将其与相关工作结合而非拆分。）”
选项：
- 是——用户看到/体验不同内容
- 否——它是技术任务（非用户故事——不要拆分，重构）
⚠️ 关键检查： 如果故事失败“有价值”，停止。不要拆分。相反，与其他工作结合以创建有意义的增量。
4. 可估算？ “您的团队能否相对估算此故事大小（即使粗略）？”
选项：
- 是——团队可估算天数/点数
- 否——太多不确定性（可能需要探索先）
5. 可测试？ “此故事是否有具体验收标准，QA可验证？”
选项：
- 是——清晰通过/失败条件
- 否——需要更清晰验收标准（拆分前细化）
如果故事通过所有检查→进行到步骤2（拆分模式） 如果故事失败任何检查→在拆分前修复问题
步骤2：顺序应用拆分模式
按顺序遍历模式。对于每个模式，问“这适用吗？”
模式1：工作流步骤
关键洞察： 拆分为薄端到端切片，非逐步。从覆盖完整工作流的简单案例开始，然后添加中间步骤作为独立故事。
代理问： “您的史诗是否涉及多步骤工作流，您可以先交付简单案例，然后稍后添加中间步骤？”
示例：
- 原始： “发布内容（需要编辑审核、法律批准、预演）”
- ❌ 错误拆分（逐步）： 故事1=编辑审核，故事2=法律批准，故事3=发布
- ✅ 正确拆分（薄端到端）：
- 故事1：发布内容（简单路径：作者上传，内容立即上线——无审核）
- 故事2：添加编辑审核步骤（现在内容在等待编辑批准后上线）
- 故事3：添加法律批准步骤（内容在等待法律+编辑后上线）
每个故事交付完整工作流，只是随着复杂度增加。
选项：
- 是，多步骤工作流→“描述工作流步骤”
- 否，单一步骤→继续到模式2
如果是： 代理生成薄端到端切片拆分。
模式2：操作（CRUD）
关键洞察： 单词“管理”表示多个操作。拆分为创建、读取、更新、删除。
代理问： “您的史诗是否使用如‘管理’、‘处理’或‘维护’等词？如果是，它可能捆绑多个操作（CRUD）。”
示例：
- 原始： “管理用户账户”
- 拆分：
- 故事1：创建用户账户
- 故事2：查看用户账户详情
- 故事3：编辑用户账户信息
- 故事4：删除用户账户
选项：
- 是，包含多个操作→“列出操作（创建/读取/更新/删除/等）”
- 否，单操作→继续到模式3
如果是： 代理生成每个操作一个故事。
模式3：业务规则变体
关键洞察： 当相同功能在不同规则下操作时，每个规则成为自己的故事。
代理问： “您的史诗是否有不同场景（用户类型、区域、层级、条件）的不同业务规则？”
示例：
- 原始： “具有灵活日期的航班搜索（日期范围、特定周末、日期偏移）”
- 拆分：
- 故事1：按日期范围搜索（+/- N天）
- 故事2：仅按特定周末搜索
- 故事3：按日期偏移搜索（前/后 N天）
选项：
- 是，不同规则→“描述规则变体”
- 否，所有相同规则→继续到模式4
如果是： 代理生成每个规则变体一个故事。
模式4：数据变体
关键洞察： 处理不同数据类型或结构的复杂性。根据需要及时添加变体。
代理问： “您的史诗是否处理不同数据类型、格式或结构（例如，文件类型、地理层级、用户属性）？”
示例：
- 原始： “地理搜索（县、城市/镇/社区、自定义提供商区域）”
- 拆分：
- 故事1：按县搜索
- 故事2：添加城市/镇/社区搜索
- 故事3：添加自定义提供商区域搜索
选项：
- 是，不同数据类型→“列出数据变体”
- 否，单一数据类型→继续到模式5
如果是： 代理生成每个数据变体一个故事（先交付最简单）。
模式5：数据输入方法
关键洞察： UI复杂性独立于核心功能。先构建最简单界面，然后添加复杂UI作为后续。
代理问： “您的史诗是否包括花哨UI元素（日期选择器、自动完成、拖放），这些对核心功能非必需？”
示例：
- 原始： “带日历日期选择器的搜索”
- 拆分：
- 故事1：按日期搜索（基本文本输入：“YYYY-MM-DD”）
- 故事2：添加可视化日历选择器UI
选项：
- 是，花哨UI元素→“描述UI增强”
- 否，仅基本UI→继续到模式6
如果是： 代理生成故事1=基本输入，故事2+=UI增强。
模式6：主要努力
关键洞察： 当初始实现携带大部分复杂性，添加变得琐碎。框架为“实现一个+添加剩余”。
代理问： “您的史诗是否涉及构建基础设施，其中第一个实现困难，但添加更多容易？”
示例：
- 原始： “接受信用卡支付（Visa、Mastercard、Amex、Discover）”
- 拆分：
- 故事1：接受Visa支付（构建完整支付基础设施）
- 故事2：添加Mastercard、Amex、Discover支持（琐碎添加）
⚠️ 注意： 第一个故事做重工作（支付网关、安全、合规）。后续故事是小的添加。
选项：
- 是，主要努力模式→“什么是第一个实现+什么是添加？”
- 否，无基础设施工作→继续到模式7
如果是： 代理生成故事1=构建基础设施，故事2=添加剩余变体。
模式7：简单/复杂
关键洞察： 通过问“什么是最简单版本？”来识别故事核心。提取变体为独立故事。
代理问： “此史诗的最简单版本是什么，仍交付价值？您能否剥离复杂性并稍后添加回来？”
示例：
- 原始： “航班搜索（带最大停留次数、附近机场、灵活日期）”
- 拆分：
- 故事1：基本航班搜索（出发地、目的地、日期）
- 故事2：添加最大停留次数过滤器
- 故事3：添加附近机场选项
- 故事4：添加灵活日期选项
选项：
- 是，可识别最简单核心→“描述最简单版本+要延迟的变体”
- 否，已经简单→继续到模式8
如果是： 代理生成故事1=最简单核心，故事2+=变体。
模式8：延迟性能
关键洞察： 拆分“让它工作”与“让它快”。非功能性需求（性能、安全、可扩展性）可跟随功能交付。
代理问： “您能否先交付功能价值，然后优化性能/安全/可扩展性？”
示例：
- 原始： “实时搜索，响应时间<100ms”
- 拆分：
- 故事1：搜索工作（功能，无性能保证）
- 故事2：优化搜索到<100ms（添加缓存、索引）
选项：
- 是，可延迟优化→“什么是功能版本+什么是优化？”
- 否，性能是必需的→继续到模式9
如果是： 代理生成故事1=功能，故事2=优化。
模式9：分离出探索
关键洞察： 当不确定性阻止拆分时的最后手段。时间箱调查以回答特定问题，然后用更好理解拆分实现故事。
代理说： “模式1-8都不适用，这表明高不确定性。拆分前，运行一个探索以减少不确定性。”
探索是时间箱调查（非故事），回答如：
- 这在技术上可行吗？
- 哪种方法表现最佳？
- API实际返回什么？
代理问： “阻止您拆分此史诗的最大未知是什么？”
选项：
- 技术可行性——“我们能使用我们的技术栈构建这个吗？”
- 方法不确定性——“多种解决方式，不清楚哪个最佳”
- 外部依赖——“不知道第三方API提供什么”
代理推荐： → “运行1-2天探索以回答[问题]。探索后，回来我们将用更好理解拆分史诗。”
⚠️ 探索产生学习，非可交付代码。探索后，从模式1重新开始。
步骤3：评估拆分质量
拆分后，使用这些标准评估：
代理问：
1. 此拆分是否揭示低价值工作，您可以降低优先级或消除？
- 好拆分暴露80/20原则：大部分价值集中在功能的小部分
- 示例：将“航班搜索”拆分为4个故事后，您意识到“灵活日期”很少使用→降低优先级或取消
2. 此拆分是否产生更多大小相等的故事？
- 大小相等的故事给予产品所有者更大优先排序灵活性
- 示例：代替一个10天史诗，五个2天故事允许冲刺中期重新排序
如果拆分不满足任一标准，尝试不同模式。
元模式应用
跨越所有模式，遵循此序列：
- 识别核心复杂性——什么使此史诗困难？
- 列出变体——所有不同方式/案例/规则是什么？
- 减少到一个完整切片——选择仍交付端到端价值的最简单变体
- 使其他变体成为独立故事
Cynefin领域考虑
策略基于复杂性领域变化：
代理问： “此史诗周围有多少不确定性？”
选项：
-
低不确定性（明显/复杂领域）——“我们知道要构建什么；这只是工程工作” → 找到所有故事，按价值/风险优先排序
-
高不确定性（复杂领域）——“我们不确定客户想要什么或什么会工作” → 识别1-2个学习故事；避免穷举枚举（工作本身教什么重要）
-
混乱——“一切都在着火；优先级每日变化” → 延迟拆分直到稳定性出现；先专注于稳定化
输出：生成故事分解计划
# 史诗分解计划
**史诗：** [原始史诗]
**拆分前验证：** ✅ 通过INVEST（除小外）
**应用的拆分模式：** [模式名称]
**理由：** [为什么此模式适合]
---
## 故事分解
### 故事1：[标题]（最简单完整切片）
**摘要：** [用户价值聚焦标题]
**使用案例：**
- **作为** [角色]
- **我想要** [动作]
- **以便** [结果]
**验收标准：**
- **给定：** [前置条件]
- **当：** [动作]
- **然后：** [结果]
**为什么先这个：** [交付核心价值；更简单变体跟随]
**估计努力：** [天数/点数]
---
### 故事2：[标题]（第一个变体）
[重复...]
---
### 故事3：[标题]（第二个变体）
[重复...]
---
## 拆分评估
✅ **此拆分是否揭示低价值工作？**
- [分析：哪些故事可降低优先级/消除？]
✅ **此拆分是否产生大小相等的故事？**
- [分析：故事努力是否大致相等？]
---
## INVEST验证（每个故事）
✅ **独立：** 故事可按任何顺序开发
✅ **可协商：** 实现细节可协作发现
✅ **有价值：** 每个故事交付可观察用户价值
✅ **可估算：** 团队可估算每个故事大小
✅ **小：** 每个故事适合1-5天
✅ **可测试：** 每个故事清晰验收标准
---
## 下一步
1. **与团队评审：** PM、设计、工程是否同意？
2. **检查进一步拆分：** 是否有故事仍>5天？如果是，为该故事**从模式1重新开始**。
3. **优先排序：** 哪个故事先交付最多价值？
4. **考虑消除：** 拆分是否揭示低价值故事？取消或延迟它们。
---
**如果故事仍太大，重新应用模式从模式1开始。**
示例
示例1：模式1应用（工作流步骤-薄端到端）
史诗： “发布博客文章（需要编辑审核、法律批准、预演）”
拆分前验证： ✅ 通过INVEST
模式1： “这有工作流步骤吗？”→是✅
❌ 错误拆分（逐步）：
- 编辑审核故事
- 法律批准故事
- 发布故事 →问题：故事1不交付价值（用户看不到什么）
✅ 正确拆分（薄端到端）：
- 发布帖子（简单路径）——作者上传，帖子立即上线（无审核）
- 添加编辑审核——帖子现在在等待编辑批准后上线
- 添加法律批准——帖子在等待法律+编辑后上线
为什么这有效： 每个故事交付完整工作流，只是随着复杂度增加。
示例2：模式2应用（CRUD操作）
史诗： “管理用户资料”
模式2： “这说‘管理’吗？”→是✅（表示CRUD）
拆分：
- 创建用户资料
- 查看用户资料详情
- 编辑用户资料信息
- 删除用户资料
拆分评估：
- ✅ 揭示低价值工作： 分析后，“删除资料”很少使用→降低优先级
- ✅ 大小相等故事： 每个1-2天
示例3：模式7应用（简单/复杂）
史诗： “航班搜索带最大停留次数、附近机场、灵活日期”
模式7： “什么是最简单版本？”→基本搜索✅
拆分：
- 基本航班搜索（出发地、目的地、日期）——核心价值
- 添加最大停留次数过滤器——增强
- 添加附近机场选项——增强
- 添加灵活日期选项——增强
拆分评估：
- ✅ 揭示低价值工作： 用户研究表明“灵活日期”很少使用→取消或延迟
- ✅ 大小相等故事： 故事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
后果： 拆分不应拆分的故事（例如，无价值=技术任务）
修复： 在步骤2（拆分模式）前始终运行步骤1（INVEST检查）
陷阱2：逐步工作流拆分（模式1做错）
症状： 故事1=“编辑审核”，故事2=“法律批准”
后果： 故事不交付端到端价值
修复： 每个故事应覆盖完整工作流（薄端到端切片），只是随着复杂度增加
陷阱3：水平切片（技术层）
症状： “故事1：构建API。故事2：构建UI。”
后果： 无故事交付用户价值
修复： 垂直切片——每个故事包括前端+后端以交付可观察用户行为
陷阱4：强迫不合适的模式
症状： “我们将按工作流拆分，即使没有序列”
后果： 任意、无意义拆分
修复： 如果模式不适用，说否并继续到下一个模式
陷阱5：不重新拆分大故事
症状： 将史诗拆分为3个故事，但每个仍5+天
后果： 故事太大不适合冲刺
修复： 为每个大故事从模式1重新开始，直到所有1-5天
陷阱6：忽略拆分评估（步骤3）
症状： 拆分但不评估是否揭示低价值工作
后果： 错过消除浪费机会
修复： 拆分后，问：“这是否揭示我们可以取消或延迟的工作？”
实践与技能发展
Humanizing Work推荐： 团队在多个实践会话中2.5-3小时达到流利度。
实践方法：
- 分析最近完成功能（事后诸葛亮使模式明显）
- 将完成工作通过流程图——哪个模式会适用？
- 为每个功能找到多个拆分方法
- 构建共享词汇的领域特定模式示例
不要跳过实践工作。 技能通过分析过去交付成果发展，非仅精炼未来工作。
参考
相关技能
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)——质量标准
来源
技能类型： 交互式
建议文件名： epic-breakdown-advisor.md
建议位置： /skills/interactive/
依赖： 使用user-story-splitting.md, user-story.md, epic-hypothesis.md