共计 1300 个字符，预计需要花费 4 分钟才能阅读完成。
根据 INVEST 原则，对用户故事的要求是它必须“足够小”或具有合适的大小。用户故事应该足够小，可以在冲刺中完成 6 -10 个。当然这也取决于开发团队的速度。为了原则上实现这一目标，必须相应地分割大型故事。在下文中，我想向您介绍 Mike Cohn 的简单快速的 SPIDR 方法。他总结了五种技术，几乎每个大型用户故事都可以分为几种。
钉鞋
Spike 是敏捷软件开发中使用的术语。尖峰是功能的小型原型实现，通常用于新技术的评估和可行性。
该方法涉及调查和建立知识。如果其他 SPIDR 方法效果不佳，则应该使用它。借助这些新获得的知识，可以更好地理解一些故事，并可能更容易地分裂。然而，该方法相对抽象，因此比其余方法更难应用。
路径
如果用户故事中有多个可能的备用路径，则一个选项是从这些路径中的某些路径创建单独的用户故事。为每条路径写一个故事并不是绝对必要的，只要它有意义。例如，让我们看一个用户想要在线商店购买的用户故事。现在有两种可能的途径：使用信用卡付款或使用 Paypal 付款。理论上，信用卡付款可以进一步细分，但你需要权衡每种类型的信用卡是否有自己的故事。然而，支付购买的首要任务分为上述两种备选方案。因此，新创建的故事更小，更容易估计。
接口
在该上下文中的接口可以是例如不同的设备或设备类型，例如由 iOS 或 Android 供电的智能电话。用户故事也可以根据这种多样性进行划分。让我们坚持使用不同操作系统的示例：例如，在项目中，可能存在仅与 Android 设备的使用相关的用户故事，或者专注于 Web 浏览器的其他用户故事。为了避免使故事过于庞大和全面，您应该问自己要开发哪些设备或接口。也许第一个开发结果应该只引用 iOS 设备，因为可能更大的目标组。
数据
当初始故事仅涉及相关数据的子范围时，可以使用另一种用于分割用户故事的技术。以一个旨在吸引游客到特定城市的网站为例。例如，如果它是以博物馆而闻名的城市，那么第一个故事可能包括该地区不同博物馆的信息。随后的故事可能包括穿越城市的各种旅游，以及另一项户外活动。
规则
业务规则或技术标准可能是另一个分裂因素。以在线购买电影票为例。通常存在约束，例如基于相应电影的业务要求，例如每个电子邮件地址最多五个票的在线购买限制。
有了这个故事，可以想象开发团队省略了这个限制，允许每个访客购买尽可能多的门票。然后可以在第二次迭代步骤中添加限制。像这样的增量交付意味着初始故事不会立即完全实现，而是以几个较小的步骤提供。有时忽略技术规范或业务规则是有意义的，如果通过这样做，您可以更快地实现满足用户或客户的可呈现结果。可以在以后检索省略的故事。
小用户故事 – 更容易实现
用户故事分裂并不总是那么容易：许多初学者倾向于将他们的故事过于全面而且过于庞大。但是，当涉及到开发团队的改进，并最终实现故事时，很快就会发现必须制作更小的故事。在我之前关于写（好）用户故事的博文中，我坚持认为故事应该是“可估计的”和“小的”。如果您知道如何分割大型故事，则更有可能发生这种情况。正如编写用户故事一样，练习也是完美的。
敏捷软件开发
什么是敏捷软件开发？
什么是用户故事？
什么是用户故事映射？
用户故事与敏捷软件开发的使用案例