⚡

用户故事拆分Skill user-story-splitting

用户故事拆分是一种敏捷开发技能，用于将大型用户故事、史诗或特性分解为更小、可独立交付的故事。通过应用8种系统化拆分模式，如工作流步骤、业务规则变化等，使开发工作更易管理、降低风险、加快反馈周期，并保持流程顺畅。适用于产品管理和软件开发中的需求分解场景。关键词：用户故事拆分、敏捷开发、需求分解、产品管理、故事分割、软件开发、用户体验。

产品管理 0 次安装 0 次浏览 更新于 3/18/2026

name: 用户故事拆分 description: 使用系统化的拆分模式，将大型用户故事、史诗或特性分解为更小、可独立交付的故事。这使工作更易管理、降低风险、加快反馈周期，并在敏捷开发中保持流程顺畅。此技能适用于用户故事、史诗和任何无法在单个迭代中完成的太大规模的工作。

这不是随意分割——而是战略性的分解，在减少复杂性的同时保留用户价值。 type: 组件

目的

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

这不是随意分割——而是战略性的分解，在减少复杂性的同时保留用户价值。

核心概念

故事拆分框架

基于 Richard Lawrence 和 Peter Green 的《人性化工作指南：拆分用户故事》，该框架提供了8种系统化的拆分模式：

  1. 工作流步骤： 沿用户旅程中的顺序步骤拆分
  2. 业务规则变化： 按不同规则场景（权限、计算等）拆分
  3. 数据变化： 按不同类型的数据或输入拆分
  4. 验收标准复杂性： 当存在多个“当”或“那么”语句时拆分
  5. 主要工作： 按技术里程碑或实施阶段拆分
  6. 外部依赖： 沿依赖边界（API、第三方等）拆分
  7. DevOps步骤： 按部署或基础设施需求拆分
  8. 微小发现行为（TADs）： 如果以上均不适用，使用小实验来解开未知因素

为什么拆分故事？

  • 更快反馈： 更小的故事更早交付，允许早期验证
  • 降低风险： 构建更少 = 出错可能更少
  • 更好估算： 小故事更容易准确估算
  • 保持流程： 在迭代中保持工作流动，无瓶颈
  • 可测试性： 更小范围 = 更容易编写和运行测试

反模式（这并非什么）

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

何时使用此技能

  • 故事太大，无法在单个迭代中完成
  • 验收标准中有多个“当”或“那么”语句
  • 史诗需要分解为可交付的增量
  • 团队无法就故事规模或范围达成共识
  • 故事捆绑了多个角色或工作流

何时不使用此技能

  • 故事已经很小且范围明确（不要过度拆分）
  • 拆分会产生依赖关系，减慢交付
  • 故事是技术任务（改用工程任务分解）

应用

步骤1：识别原始故事

从需要拆分的故事/史诗/特性开始。确保使用用户故事格式编写（参考 skills/user-story/SKILL.md 或 skills/epic-hypothesis/SKILL.md）。

### 原始故事：
[使用用例和验收标准格式化的故事]

步骤2：应用拆分逻辑

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

按顺序遍历8种拆分模式。找到适用的模式时停止。

模式1：工作流步骤

问： 这个故事是否包含多个顺序步骤？

示例：

  • 原始： “作为一个用户，我想注册、验证我的邮箱并完成引导”
  • 拆分：
    1. “作为一个用户，我想用邮箱/密码注册”
    2. “作为一个用户，我想通过确认链接验证我的邮箱”
    3. “作为一个用户，我想通过回答3个配置文件问题完成引导”

模式2：业务规则变化

问： 这个故事是否有不同场景的不同规则？

示例：

  • 原始： “作为一个用户，我想应用折扣（会员10%、VIP20%、首次买家5%）”
  • 拆分：
    1. “作为一个会员，我想在结账时应用10%折扣”
    2. “作为一个VIP，我想在结账时应用20%折扣”
    3. “作为一个首次买家，我想在结账时应用5%折扣”

模式3：数据变化

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

示例：

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

模式4：验收标准复杂性

问： 这个故事是否有多个“当”或“那么”语句？

示例：

  • 原始： “作为一个用户，我想管理我的购物车”
    • 当我添加一个商品，那么它出现在我的购物车中
    • 当我移除一个商品，那么它从我的购物车中消失
    • 当我更新数量，那么购物车总数更新
  • 拆分：
    1. “作为一个用户，我想将商品添加到我的购物车，以便以后购买”
    2. “作为一个用户，我想从我的购物车中移除商品，以便改变主意”
    3. “作为一个用户，我想更新商品数量，以便购买正确数量”

注意： 这是最常用的指标，表明故事需要拆分。如果看到多个“当/那么”对，沿这些边界拆分。

模式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：微小发现行为（TADs）

问： 如果以上均不适用，是否有未知因素或假设需要解开？

示例：

  • 原始： “作为一个用户，我想要AI驱动的推荐”（太模糊，太多未知）
  • TADs：
    1. 原型化3种推荐算法，并用10个用户测试
    2. 定义成功标准（点击率、用户满意度）
    3. 构建最简单的推荐引擎（协同过滤）
    4. 测量并迭代

注意： TADs不是故事——它们是实验。在编写故事之前，使用它们来降低风险和澄清。

步骤3：编写拆分故事

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

### 使用[模式名称]拆分1：

#### 用户故事[ID]：
- **摘要：** [简短标题]

**使用案例：**
- **作为一个** [角色]
- **我想要** [动作]
- **以便** [结果]

**验收标准：**
- **场景：** [描述]
- **给定：** [前提条件]
- **当：** [动作]
- **那么：** [结果]

步骤4：验证拆分

问这些问题：

  1. 每个拆分是否交付用户价值？（不仅仅是“前端完成”）
  2. 每个拆分是否可以独立开发？（无硬依赖）
  3. 每个拆分是否可以独立测试？（清晰的验收标准）
  4. 每个拆分是否足够小以适应迭代？（1-5天的工作量）
  5. 拆分组合时，是否等于原始故事？（没有丢失任何东西）

如果任何答案为“否”，请修订。

示例

参见 examples/sample.md 获取完整拆分示例。

迷你示例摘录：

### 原始故事：
作为一个团队管理员，我想管理团队成员，以便控制访问。

### 建议拆分（验收标准复杂性）：
1. 邀请新团队成员
2. 移除团队成员
3. 更新团队成员角色

常见陷阱

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

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

后果： 两个故事都不能独立交付用户价值。

修复： 垂直拆分——每个故事应包括前端和后端工作，以交付完整的面向用户的能力。

陷阱2：过度拆分

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

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

修复： 仅在故事太大时拆分。一个2天的故事不需要拆分。

陷阱3：无意义拆分

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

后果： 随意拆分，不映射到用户价值或工作流。

修复： 使用8种拆分模式之一——每个拆分应有明确的理由。

陷阱4：创建硬依赖

症状： “故事2无法开始，直到故事1完成100%、测试和部署。”

后果： 无并行化，减慢交付。

修复： 以允许独立开发的方式拆分。如果依赖不可避免，优先处理故事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’s Work

  • 基于人性化工作框架的用户故事拆分提示模板

来源

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

技能类型： 组件 建议文件名： user-story-splitting.md 建议放置位置： /skills/components/ 依赖： 参考 skills/user-story/SKILL.md, skills/epic-hypothesis/SKILL.md 适用对象： 用户故事、史诗和任何无法在单个迭代中完成的太大规模的工作