user-story-splitting

目的

使用系统化的拆分模式，将大型用户故事、史诗或功能拆解为更小且可独立交付的故事。这样可以让工作更易于管理、降低风险、加快反馈周期，并在敏捷开发中保持工作流畅。此技能适用于用户故事、史诗，以及任何无法在单个冲刺中完成的大型工作。

这不是随意切分，而是有策略地拆解，在降低复杂度的同时保留用户价值。

输入

最适合提供： 过于庞大的故事或史诗——按原文粘贴即可。 也很有用： 它过于庞大的原因（无法估算、无法在一个冲刺中完成、无法独立发布），以及团队的规模上限。

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

手头没有内容？也没关系。 此技能会先询问故事文本，然后逐一应用拆分模式进行分析。

调用示例： Split this: 'As an admin, I can bulk-import users from CSV, Excel, or our HR system with field mapping and error handling.'

核心概念

故事拆分框架

此框架基于 Richard Lawrence 和 Peter Green 的《Humanizing Work Guide to Splitting User Stories》，提供了 8 种系统化的工作拆分模式：

1. 工作流步骤： 按用户旅程中的连续步骤拆分
2. 业务规则变体： 按不同规则场景拆分（权限、计算等）
3. 数据变体： 按不同数据类型或输入拆分
4. 验收标准复杂度： 存在多个“When”或“Then”语句时进行拆分
5. 主要工作量： 按技术里程碑或实施阶段拆分
6. 外部依赖： 沿依赖边界拆分（API、第三方等）
7. DevOps 步骤： 按部署或基础设施要求拆分
8. 微型探索行动（TAD）： 以上模式均不适用时，通过小型实验揭示未知情况

为什么要拆分故事？

• 更快获得反馈： 较小的故事能更快交付，从而更早验证
• 降低风险： 需要构建的内容越少，出错的可能性就越低
• 更准确地估算： 较小的故事更容易准确估算
• 保持工作流畅： 让工作在冲刺中持续推进，避免瓶颈
• 可测试性： 范围越小，编写和运行测试就越容易

反模式（这不是什么）

• 不是水平切分： 不要拆成“前端故事”和“后端故事”（每个故事都应交付用户价值）
• 不是任务分解： 故事不是任务（如“设置数据库”“编写 API”）
• 不是随意拆分： 不要把“添加用户管理”拆成“添加用户”和“管理”（毫无意义）

何时使用

• 故事太大，无法在一个冲刺中完成
• 验收标准中包含多个“When”或“Then”语句
• 史诗需要拆分为可交付的增量
• 团队无法就故事规模或范围达成共识
• 故事捆绑了多个角色或工作流

何时不使用

• 故事已经足够小且范围明确（不要过度拆分）
• 拆分会造成拖慢交付的依赖关系
• 故事属于技术任务（应改用工程任务分解）

---

应用

第 1 步：确定原始故事

从需要拆分的故事、史诗或功能开始。确保它采用用户故事格式编写（参见 skills/user-story/SKILL.md 或 skills/epic-hypothesis/SKILL.md）。

### Original Story:
[Story formatted with use case and acceptance criteria]

---

第 2 步：应用拆分逻辑

使用 template.md 获取完整的填写结构和输出格式。

按顺序逐一检查 8 种拆分模式。找到适用的模式后即停止。

模式 1：工作流步骤

询问： 这个故事是否包含多个连续步骤？

示例：

• 原始故事：“作为一名用户，我想要注册、验证邮箱并完成引导流程”
• 拆分后：
  1. “作为一名用户，我想要使用邮箱/密码注册”
  2. “作为一名用户，我想要通过确认链接验证邮箱”
  3. “作为一名用户，我想要回答 3 个个人资料问题以完成引导流程”

---

模式 2：业务规则差异

询问： 这个故事是否针对不同情形规定了不同规则？

示例：

• 原始故事：“作为一名用户，我想要享受折扣（会员 10%，VIP 20%，首次购买者 5%）”
• 拆分后：
  1. “作为一名会员，我想要在结账时享受 10% 的折扣”
  2. “作为一名 VIP，我想要在结账时享受 20% 的折扣”
  3. “作为一名首次购买者，我想要在结账时享受 5% 的折扣”

---

模式 3：数据差异

询问： 这个故事是否要处理不同类型的数据或输入？

示例：

• 原始故事：“作为一名用户，我想要上传文件（图片、PDF、视频）”
• 拆分后：
  1. “作为一名用户，我想要上传图片文件（JPG、PNG）”
  2. “作为一名用户，我想要上传 PDF 文档”
  3. “作为一名用户，我想要上传视频文件（MP4、MOV）”

---

模式 4：验收标准复杂度

询问： 这个故事是否包含多条“When”（当……时）或“Then”（那么……）语句？

示例：

• 原始故事：“作为一名用户，我想要管理购物车”
  • 当我添加商品时，商品会出现在购物车中
  • 当我移除商品时，商品会从购物车中消失
  • 当我更新数量时，购物车总金额会更新
• 拆分后：
  1. “作为一名用户，我想要将商品添加到购物车，以便稍后购买”
  2. “作为一名用户，我想要从购物车中移除商品，以便改变主意”
  3. “作为一名用户，我想要更新商品数量，以便购买合适的数量”

注意： 这是最常见的故事需要拆分的信号。如果你看到多组“When/Then”，就沿着这些边界进行拆分。

---

模式 5：重大工作量

询问： 这个故事是否需要大量技术工作，且可以分阶段交付？

示例：

• 原始故事：“作为一名用户，我想要实时协作文档”
• 拆分后：
  1. “作为一名用户，我想要查看还有谁在查看文档（只读在线状态）”
  2. “作为一名用户，我想要查看其他编辑者的实时光标位置”
  3. “作为一名用户，我想要实时查看其他用户的编辑内容”

---

模式 6：外部依赖

询问： 这个故事是否依赖多个外部系统或 API？

示例：

• 原始故事：“作为一名用户，我想要使用 Google、Facebook 或 Twitter 登录”
• 拆分后：
  1. “作为一名用户，我想要使用 Google OAuth 登录”
  2. “作为一名用户，我想要使用 Facebook OAuth 登录”
  3. “作为一名用户，我想要使用 Twitter OAuth 登录”

---

模式 7：DevOps 步骤

询问： 这个故事是否需要复杂的部署、基础设施或运维工作？

示例：

• 原始故事：“作为一名用户，我想要将大型文件上传到云存储”
• 拆分后：
  1. “作为一名用户，我想要将小型文件（<10MB）上传到云存储”
  2. “作为一名用户，我想要上传大型文件（10MB-1GB）并跟踪进度”
  3. “作为一名用户，我想要恢复中断的上传”

---

模式 8：微型探索活动（TAD）

询问： 如果以上情况都不适用，是否存在需要进一步梳理的未知因素或假设？

示例：

• 原始故事：“作为一名用户，我想要 AI 驱动的推荐”（过于含糊，未知因素太多）
• TAD：
  1. 制作 3 种推荐算法的原型，并邀请 10 名用户进行测试
  2. 定义成功标准（点击率、用户满意度）
  3. 构建最简单的推荐引擎（协同过滤）
  4. 衡量效果并迭代

注意： TAD 不是故事，而是实验。在编写故事之前，使用它们来降低风险并明确问题。

---

第 3 步：编写拆分后的故事

对于每项拆分，请使用 skills/user-story/SKILL.md 中的格式编写完整的用户故事：

### Split 1 using [Pattern Name]:

#### User Story [ID]:
- **Summary:** [Brief title]

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

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

---

第 4 步：验证拆分

请思考以下问题：

1. 每个拆分都能为用户创造价值吗？（而不只是“前端已完成”）
2. 每个拆分都能独立开发吗？（没有硬性依赖）
3. 每个拆分都能独立测试吗？（验收标准清晰）
4. 每个拆分的规模都适合一个冲刺吗？（需要 1-5 天）
5. 合并所有拆分后，是否与原需求相符？（没有遗漏）

如果任何一个问题的答案是“否”，请修改拆分。

---

示例

完整的拆分示例请参见 examples/sample.md。

迷你示例摘录：

### Original Story:
As a team admin, I want to manage team members so that I can control access.

### Suggested Splits (Acceptance Criteria Complexity):
1. Invite new team members
2. Remove team members
3. Update team member roles

---

常见陷阱

陷阱 1：水平切分（技术分层）

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

**后果：**任何一个故事都无法独立交付用户价值。

**解决方法：**纵向拆分——每个故事都应包含前端和后端工作，以交付完整的面向用户的功能。

---

陷阱 2：拆分过细

症状：“故事 1：添加按钮。故事 2：将按钮接入 API。故事 3：显示结果。”

**后果：**造成不必要的开销和依赖。

**解决方法：**只有当故事规模过大时才拆分。一个需要 2 天完成的故事不需要拆分。

---

陷阱 3：拆分毫无意义

症状：“故事 1：功能的前半部分。故事 2：功能的后半部分。”

**后果：**拆分随意，既不对应用户价值，也不符合工作流。

**解决方法：**使用 8 种拆分模式之一——每个拆分都应有明确的理由。

---

陷阱 4：造成硬性依赖

症状：“故事 1 完全完成、测试并部署后，故事 2 才能开始。”

**后果：**无法并行开展工作，交付速度变慢。

**解决方法：**以便于独立开发的方式进行拆分。如果无法避免依赖，请优先处理故事 1。

---

陷阱 5：忽略“以便于”

**症状：**拆分后的故事具有相同的“以便于”陈述。

**后果：**你拆分了行动，却没有拆分结果——这可能是任务分解，而不是故事拆分。

**解决方法：**确保每个拆分都能带来不同的用户成果。如果做不到，请重新考虑拆分模式。

---

参考资料

相关技能

• skills/user-story/SKILL.md — 编写拆分后故事的格式
• skills/epic-hypothesis/SKILL.md — 史诗通常需要先拆分，再转化为故事
• skills/jobs-to-be-done/SKILL.md — 帮助根据用户任务识别有意义的拆分方式

外部框架

• Richard Lawrence 和 Peter Green，The Humanizing Work Guide to Splitting User Stories — 8 种拆分模式的来源
• Bill Wake，INVEST in Good Stories（2003）— 结构完善的故事所需具备的标准（独立、可协商、有价值、可估算、小型、可测试）
• Mike Cohn，User Stories Applied（2004）— 故事分解技巧

Dean 的作品

• 用户故事拆分提示词模板（基于 Humanizing Work 框架）

来源

• 改编自 https://github.com/deanpeters/product-manager-prompts 仓库中的 prompts/user-story-splitting-prompt-template.md。

---

**技能类型：**组件 建议文件名：user-story-splitting.md 建议位置：/skills/components/ **依赖项：**引用 skills/user-story/SKILL.md、skills/epic-hypothesis/SKILL.md **适用范围：**用户故事、史诗，以及任何无法在单个冲刺中完成的工作