前言
最近在ScrumMaster的工作中收到团队成员的提问，如何拆分(User Story)用户故事，如何让迭代中的用户故事更适合在迭代中开发交付？我们知道好的用户故事要符合INVEST原则，而往往在实际操作过程中最难做到的是最后两点Size Appropriately和Testable。有时候一次迭代只能做一个用户故事;有时候可能有多个小的用户故事，但是彼此依赖要到最后时刻才能测试，可见如此的场景又回到了小瀑布的形式里面了。 那么用户故事的拆分是否有什么方法可寻吗？答案是肯定的。今天介绍的就是大师Mike Cohn总结的5种方法，也是我到目前为止觉得最高效最实用的一种，所以今天整理分享给大家，有感兴趣的同学，推荐看原文的3个免费视频。原文链接
“SPIDR”方法
用户故事一般分两类：
- 从一开始就非常大且不能分割的用户场景，但这种情况也极少发生。
- 复合用户故事，它包含许多较小的故事，因此可以拆分。
下面介绍的”SPIDR”就是这五种方式的缩写，针对的也是第二种复合用户故事拆分的方法，那么让我们拿好小板凳一起来学习吧。
Spikes
探针(Spikes)，它代表的是一类用于构建知识的研究工作和活动。可以在迭代中安排一些研究型的用户故事来解决不确定的因素。一般来说导致Team无法拆分用户故事的原因是觉得用户故事工作量太大了，Team感觉无从下手。这个主要是从如下几个方面来的原因：
- Team不熟悉业务，不知道如何实现它。
- 涉及的技术不熟练，不知道如何使用。
- 可能的实现方式有很多，Team背景知识不够，不知道用哪个比较好。
Tips: 探针类用户故事一般用在其他4类拆分方式之前,一旦不确定的领域明确了，就可以使用后续方式对用户故事进行拆分了。
Paths
路径(Paths)，考虑用户故事可能的执行路径来拆分，每一个路径都可以拆分为一个新的用户故事。最简单的方式就是按照业务逻辑的执行路径来拆分，举一个销售应用都会有的支付功能的例子，支持信用卡还是Paypal可以分为两个Story，如下图：
当然你可以将信用卡再进一步拆分，根据信用卡的种类来拆分：
不过这并不是一个固定拆分的规则，如果有时候做完一种信用卡支付功能后其他类型很容易实现，那么你就没有必要继续拆分多个信用卡类型的用户故事了。
Interface
接口(Interface)，当用户故事涉及到横跨多种用户交互接口或者数据交互接口的时候可以使用该方法来进行拆分。例如一般交互系统可以分为移动设备和浏览器两大类。而浏览器也可以根据不同类型的浏览器分为：Chrome，Edge，Firefox等。不过很多时候根据开发团队技术的熟悉程度也可以分为可以支持和暂时无法支持两类来拆分用户故事，如下图：
另一种是通过交互方式的递增来拆分用户故事，例如下面的两个交互方式的页面，在后台数据类型不变的情况下，根据工作时间和任务紧急程度以及客户接受程度可以分两阶段来进行用户故事的实现，请注意下面两图的页面和搜索条件样式的调整：
除了上面说的两个交互接口，我们还可能遇到一类接口是数据操作接口，例如你在做一个数据导入功能的时候支持多种文件类型(Excel,XML,CSV)，这个时候你可以使用这类拆分方式来拆分用户故事：
Data
数据(Data)，按照数据类型来进行用户故事拆分。可以将一个用户故事按照所关联数据类型的子集进行拆分，例如下面的一个例子，电影公司希望对电影进行上映排期。这个故事可以根据影片类型对用户故事进行拆分，例如言情类的在圣诞节档期，科幻类的可以在暑期等等。
Rules
规则(Rules)，按照业务规则和技术标准对用户故事进行拆分。一些业务逻辑会带有很多规则，在一开始的时候，可以尝试将用户故事拆分成没有规则和有规则两类，之后还可以按照规则进行拆分。举一个例子：在线售票系统，一些热门场次会需要限制单用户购票数量，那么在一开始的时候可以考虑先实现购票流程但无限制，之后再添加限制规则。
总结
用户故事的设计和拆分从来都不容易。很多团队会面临故事过大无法拆分；或者故事拆分方式不对，无法在每次迭代结束的时候交付一定的价值。毕竟好的用户故事能够让Team在完成的时候获得激励，同时每次都能够感到成就感。本文介绍的五种方式只是众多拆分方式中的一个方向，作为抛砖引玉。希望大家在工作中不断尝试，找到适合自己的，并将他们带给团队，激发团队的无限潜能。
