story-splitting

故事拆分

拆分工作，让团队能够以小批次交付、测试、学习并调整方向。好的拆分能保留完整的用户可见能力，同时减少差异、不确定性、范围或质量要求。

目标不是“把工单变小”。目标是让系统的 N% 100% 完成且可演示，而不是让系统的 100% 都完成 N%。

归属

此技能基于 Tim Ottinger 的 Splitting Stories - A Resource Listicle，并综合了 Tim Ottinger、Bill Wake、Joshua Kerievsky、Gojko Adzic、Neil Killick、George Dinwiddie、Mike Cohn、Richard Lawrence、Peter Green、J. B. Rainsberger、Rachel Davies 等人撰写的相关故事拆分文章。按需加载 resources/source-notes.md，查看各来源的出处信息。

深入阅读资源位于 resources/ 目录中。按需加载：

资源	适用场景……
pattern-catalog.md	你需要更多拆分提示、SPIDR/Hamburger/Humanizing Work/Bill Wake 模式详情，或需要为棘手的故事查找示例
source-notes.md	你需要了解来源出处、想要讲解这些概念，或需要说明文章／资源列表中的观点如何影响了此技能

与其他技能的配合方式

当输入内容是大型故事、史诗、功能构想、路线图条目或待办事项时，先使用 story-splitting，再使用 planning。此技能用于发现有价值的小型子故事。随后，planning 技能会将选定的子故事编排为包含证据和交付细节的实现切片。

无论仓库的实现方式或拉取请求工作流如何，都要保持故事边界为垂直切分。切勿将数据库、API、UI 和测试拆成待办列表中的独立交付结果。

如果拆分或计划已经完成，但你需要补充缺失状态、验收标准、边缘情况或不可验证的表述，请在之后使用 find-gaps。如果 find-gaps 发现计划仍是水平切分或范围过大，请返回这里继续拆分。

如果已安装 grill-me，请用它处理尚未解决的产品或设计决策，而不是拆分机制。否则，请使用 specification，并在此技能提出切片之前或之后，每次提出一个重点明确的问题。

如果工作涉及多个 UX 界面或模拟状态，请使用 storyboard；故事板可以揭示缺失的界面和流程缺口，从而形成子故事。使用 shape、critique 和 polish 等设计技能来改进模拟稿本身，而不是取代产品切片。

此技能止步于产品拆分。实现工作流、TDD、变异测试时机、功能标记策略、PR 前检查、分支拓扑和交付机制，应遵循项目说明及已安装的相关技能。故事拆分既不要求也不禁止在本地运行变异测试或使用功能标记。只有在选定的故事进入实现阶段时，才使用领域和架构技能；不要按这些技术层拆分故事。

需求细化流程

根据不确定性，使用最早匹配的技能：

如果问题是……	使用……	满足以下条件时停止……
“我们不知道该选哪个决策分支。”	如果已安装，使用 grill-me；否则使用 specification	已确定决策树，或已明确记录尚未解决的决策
“这项需求范围太宽，或已经预设了解决方案。”	story-splitting	拆分出各自有独立价值的子故事
“这个故事／规格／计划／原型存在漏洞。”	find-gaps	已确认更新相关产物，并使用可测试的措辞
“我们选定了一个子故事，需要构建它。”	planning	已确定包含各切片交付形式的实现切片
“选定的子故事需要安排实现顺序。”	项目的规划／交付技能	符合代码仓库规范的实现与交付计划

不要用 story-splitting 从头盘问每个产品决策；如果决策树才是真正的工作，应使用可选的 grill-me 技能或 specification 作为后备方案。不要用 story-splitting 制定实现任务；选定子故事后，应使用 planning。在有产物可供检查之前，不要使用 find-gaps；应使用它来完善拆分结果、计划、AC 集或原型规格。

核心原则

故事是对话，而非需求

将故事视为占位符，代表了解问题的人与能够解决问题的人之间的协作。不要以编写完美的书面需求或从产品团队向工程团队交接为目标。

当故事看起来太大时，应从产品、工程、设计、QA 和运维的视角共同进行拆分。产品团队了解价值和取舍。工程师了解工作量和不确定性藏在哪里。缺少这两方面的视角就进行拆分，通常会产生价值低的碎片或技术依赖。

拆分能力，而非组件

每个子故事都应从真实用户或外部系统的角度描述行为变化。如果故事中的“用户”是内部组件、层、队列、数据库、API 或服务，那么它很可能是一项任务，而非一个故事。

优先选择：

Buyer can pay one invoice by card and receive a confirmation.

避免：

Backend exposes payment endpoint.
Frontend calls payment endpoint.
Database stores payment rows.

故事中可以包含任务。不要为了让计划看起来循序渐进，就把任务重新标记为故事。

先聚焦问题空间

请提出：

What are the simplest options for delivering value to the customer as soon as possible?

不要从以下问题入手：

What is the simplest way to build this already-imagined solution?

第一个问题能揭示客户能力方面的选项。第二个问题往往会直接跳到门户、应用、服务、供应商和架构，而团队还未选定范围最窄且有价值的能力。

从最小的完整闭环开始

优先选择微小的端到端闭环，而非打磨完善的局部功能。实用的首个版本包括功能未完善的垂直切片、结构尚未组合的路径、仅供内部使用的能力，或明确标注为可丢弃的试验性追踪实现。

这个首个切片应在切实可行的范围内，尽可能贯通真实的行为路径。应如实说明其发布限制。使用功能标志、其他发布机制，还是完全不采用隐藏机制，属于项目策略决策。可丢弃的工作必须明确标注为 spike 或 tracer 试验。

寻找高性价比方案

高性价比方案以完整成本的一小部分实现高价值。寻找只需实现设想功能四分之一、就能获得大部分价值或学习成果的切片。将父故事视为初步构想；在对话中发现成本更低或效果更好的方案时，应乐于调整。

子故事质量标准

将 INVEST 用作质量检查，而不是模板：

字母	检查项
I	足够独立，可以构建、测试、发布、调整顺序或舍弃，而不必等待每个同级故事
N	范围和质量水平可以协商；不是固定的解决方案顺序
V	能为真实用户、外部系统、业务相关方、运营人员或学习目标带来价值
E	行为、未知因素和延期事项都清晰可见，因此可以估算
S	足够小，能在目标规划周期内完成
T	可通过可观察的示例进行测试

还要应用反馈三要素：好的切片能正常运行、能交付价值，并且能产生用户反馈。如果它只带来内部进展，那很可能是任务。如果它能运行，但无法产生任何反馈或学习，请考虑是否有更精简或不同的切片能带来更多价值。

工作流

1. 重新表述父故事

拆分前，先用通俗语言写出父故事：

• 参与者： 谁能获得价值
• 需求或能力： 他们能做什么或学到什么
• 结果： 为什么这很重要
• 当前约束： 为什么它过于庞大、风险太高、含糊不清或不确定

如果父故事是类似“构建网上银行门户”的解决方案描述，就将其重新表述为具体能力，例如“客户可以支付账单”“客户可以转账”或“客户可以查看余额”。

如果父故事是类似“添加支付数据库”的技术任务，就找出它所服务的用户行为。如果不存在相关行为，就保留为任务，并将其关联到第一个能证明它有用的故事。

2. 列出示例和变化情况

在创建工单前，先列出具体示例：

• 顺畅路径示例
• 其他路径和错误路径
• 用户角色或客户细分群体
• 数据形态、大小和边界情况
• 业务规则和策略变体
• 接口、渠道、设备或集成
• 质量属性：性能、规模、可靠性、安全性、无障碍性、可审计性
• 可能使计划失效的未知因素或假设

验收示例通常自然形成拆分点。当每组示例都能独立理解和测试时，将相关示例分组为不同的故事。

3. 找到拆分维度

将这些维度作为提示，然后选择最能创造价值和可选性的拆分方式：

维度	有用的问题
能力	哪种更具体的客户能力仍能交付价值？
路径	哪条顺畅路径、其他路径、工作流分支或操作可以独立成立？
接口	哪个渠道、使用方、UI 层级、设备、浏览器或集成能最先验证这一行为？
数据	我们可以先支持哪种数据子集、文件类型、实体类型、字段子集或数量？
规则	哪些业务、验证、权限、合规或策略规则可以安全地限定范围？
质量	最简单的可接受质量水平是什么：手动、批处理、低保真、小规模、较慢、通用 UI？
风险	哪种探索、示踪弹或行走骨架能够解答某个具体的高风险未知因素？

当故事需要更多提示，或需要应用 SPIDR、Hamburger、Humanizing Work 的模式或 Bill Wake 的二十种方法等命名方法时，加载 resources/pattern-catalog.md。

4. 团队陷入僵局时，使用汉堡法

如果团队总是转向技术分解，就使用 resources/pattern-catalog.md 中的汉堡法：列出技术层，列出每层由简到繁的选项，然后在每一层都先“咬一口”，确保最终结果仍是端到端的。重点是避免只做其中一层。

5. 选择第一个切片

选择第一个切片时，可参考以下经验法则：

• 优先选择能让团队将至少一个后续故事降级优先级或删除的拆分方式。
• 如果价值相近，优先选择能拆分出规模更相近的子故事的方式。
• 优先选择价值与成本比最高的切片。
• 优先选择能端到端推进，并及早降低集成或架构风险的切片。
• 在复杂领域中，应选择一两个有用的学习切片，而不是假装一开始就能列出整个待办事项清单。
• 如果第一个切片无法为任何人带来实际用途，就让它对学习、运维、支持或验证有所帮助，并明确说明这一点。

6. 编写子故事

对于每个子故事，请记录：

• 标题： 执行者 + 操作 + 明确的范围
• 价值： 谁会受益，以及如何受益
• 范围： 包含哪些内容
• 有意推迟的内容： 暂不包含哪些内容，以及原因
• 验收示例： 具体的前置条件 → 触发条件 → 可观察结果示例（或等效的可测试示例）
• 发布约束： 根据项目政策，标明可发布、仅供内部使用、仅供演示、一次性使用或其他约束，并说明原因
• 后续工作： 用于增加路径、接口、数据、规则或质量的故事

使用用户所在领域的术语。如果他们说的是“买家”，就写“买家”，不要写“用户”。

验证清单

返回拆分结果前，请检查每个子故事：

• 是否指明了真实的执行者或外部系统？
• 是否有触发条件和可观察结果？
• 是否通过该行为所需的真实生产路径运行？
• 是否可以在不等待所有同级故事完成的情况下进行测试？
• 发布、演示或实际使用后，是否能产生反馈、学习成果或明确决策？
• 如果后续故事都不再推进，它是否仍能带来价值或学习成果？
• 依赖关系是否明确且易于管理？
• 推迟的路径、数据、规则和质量是否清晰可见？
• 是否可以安全发布，或者是否明确说明了发布约束？
• 是否避免规定不必要的实现细节？
• 是否仍能看清最终的完整能力，避免遗漏有用的后续切片？

警示信号：

• 子故事按流程活动拆分：设计、编码、测试、编写文档、部署
• “作为数据库/API/前端/服务……”
• 将“构建后端”和“构建前端”作为两个独立故事
• 没有面向用户或能产生反馈的结果，却提出“收集数据”或“构建集成”
• 每个子故事都必须完成后，才能测试任何一个子故事
• 每个故事都要先做一次探索
• 验收标准只写“能用”或“够快”，没有可观察的细节
• 切片过小，只描述了实现细节
• 未经讨论就把所有业务规则都塞进第一个切片

输出格式

当用户要求拆分故事时，返回一份可直接用于 planning 的精简产物：

## Parent
[Reframed parent capability]

## Recommended First Slice
[One sentence story]

Why this first: [value, risk, learning, or bargain]

## Split Candidates
| Slice | Value | Includes | Defers | Acceptance Examples | Release Constraint |
|---|---|---|---|---|---|
| ... | ... | ... | ... | ... | ... |

## Parking Lot
[Explicit follow-ups, questions, or intentionally unsplit tasks]

## Warnings
[Component splits, unsafe deferrals, unclear ownership, or missing examples]

## Next Step
[Use the project's planning and delivery instructions for the selected first slice, run `find-gaps` on the split when available, or ask one decision question. Do not prescribe TDD, mutation timing, feature flags, or pre-PR gates here.]

如果用户希望进行交互式细化，每次只问一个高价值问题，不要一次性抛出一连串问题。先问最能影响拆分结果的问题：通常是执行者、结果、发布约束、价值最高的客户群体或最大风险。

如需了解来源信息以及逐篇文章的概念映射，请加载 resources/source-notes.md。