【DevCloud · 敏捷智库】如何拆分用户故事

提起用户故事拆分，我们听得最多的就是 INVEST 原则（关于 INVEST 原则可以参考文章“用户故事等于需求说明”——你一定没有写好用户故事），但很多人面临的问题是拿到一个较大的用户故事时，该如何拆分才能使得它满足 Small 的原则呢？接下来，就和大家一起讨论一下如何拆分用户故事。

首先，拆分可以参考以下流程：评估待拆分用户故事-按方法拆分-评估拆分结果。

评估待拆分用户故事

拆分前，我们需要知道手中的用户故事是否需要拆分，就是目前是否已经符合了 Small 的原则。我们推荐一个用户故事在 1-2 天内能完成，最多不超过 3 天，则符合 Small 原则。有些地方给出的说法是 1/5-1/10 团队速率，这个算法和你每个迭代天数以及团队成员数有关系，所以我个人还是喜欢简单的说，1-2 个工作日能完成算 Small。在这种情况下如果你的用户故事已经符合了 INVEST 其他原则的话，那就没必要拆成多个用户故事了，因为再拆就增加了管理成本（这里不包括拆成多个 task，task 可以再多拆分的）。

好，当你已经根据上面评估了用户故事，发现依旧需要拆分的话，那么可以按下面方法进行拆分。

按方法拆分

目前业界比较好的方法是 Richard Lawrence 的方法，原文请参考https://agileforall.com/patterns-for-splitting-user-stories/，下图为已官方翻译的中文版本。

图片来自 Lawrence 官方

原文里有作者的切分方式，这里我只根据我的理解选择更熟悉的例子，同时合并了其中一些方法。

方法一：按流程拆分

作为有爱心的有财力的中国人，我可以从国外进口口罩捐给武汉。

这个用户故事涉及的过程就很多了，需要找到国外可靠的口罩供应商，然后付款，运回国内，再送到武汉捐给指定医院等等。我们可以先分析整个用户故事成一个一个连续的流程，如果每个小流程作为一个用户故事，能对用户有价值，那我们就先这么拆开。结果比如下面

作为有爱心的有财力的中国人，我可以寻找个国外的朋友帮忙寻找可靠的口罩来源。

作为有爱心的有财力的中国人，我可以在这个来源付款购买指定数量的口罩。

作为有爱心的有财力的中国人，我可以将口罩从外国运回国内。

作为有爱心的有财力的中国人，我可以将口罩从国内某地送到武汉捐给医院。

方法二：按操作种类划分

作为有爱心的中国人，我可以在口罩购买平台上操作以完成购买。

如果是一个业务更简单的系统的话，对应的就是增删改查动作。这里的操作会复杂些，把每个操作拆分成一个用户故事即可。

作为有爱心的中国人，我可以在口罩购买平台上购买。

作为有爱心的中国人，我可以在口罩购买平台上退货。

作为有爱心的中国人，我可以在口罩购买平台上查询。

作为有爱心的中国人，我可以在口罩购买平台上卖货。

方法三：拆出主要的工作

作为有爱心的中国人，我可以购买 N95/KN95/医用外科三种口罩进行捐赠。

整个购买捐赠流程就很复杂了，还要买不同种类的口罩，明显这三种口罩可以拆成三个故事，同时考虑一点，就是无差别的完成 购买一个口罩进行捐赠 的故事后，剩下的两种需要的工作量就会很少了，同时这里如果没有区分三种口罩的优先级的话，我们可以先拆出一个作为主要工作，再看剩下的两个是合到一起还是继续拆分。

比如拆成如下

作为有爱心的中国人，我可以购买其中一种（N95/KN95/医用外科）口罩进行捐赠。（3 个故事点）

作为有爱心的中国人，我可以购买另外一种（N95/KN95/医用外科）口罩进行捐赠。（1 个故事点）

作为有爱心的中国人，我可以购买最后一种（N95/KN95/医用外科）口罩进行捐赠。（1 个故事点）

如果后两个都比较小，合道一起也没问题的话，也可以拆成如下

作为有爱心的中国人，我可以购买其中一种（N95/KN95/医用外科）口罩进行捐赠。（3 个故事点）

作为有爱心的中国人，我可以购买另外两种（N95/KN95/医用外科）口罩进行捐赠。（2 个故事点）

方法四：业务规则分类

作为有爱心的中国人，我可以购买三十万个口罩捐赠给武汉。

这里购买的口罩可以选择多种类型，价格不一样，效果不一样，这就是我们要区分的不同的业务规则，拆分后可能如下

作为有爱心的中国人，我可以购买三十万个最贵的口罩捐赠给武汉。

作为有爱心的中国人，我可以购买三十万个口罩捐赠给武汉，不区分口罩种类。

作为有爱心的中国人，我可以购买三十万个口罩捐赠给武汉，只要 N95 和 KN95 级别的。

方法五：简单到复杂

作为有爱心的中国人，我可以购买口罩捐赠给武汉。

简单一句话，涉及的业务可以是购买何种口罩，如何捐赠，给什么机构等，明显不能作为一个故事进行交付，需要拆分。但是业务太复杂，一开始无法全都想清楚，可以先做最基本的，然后再根据方法四的业务规则分类进行扩展。

（简单）作为有爱心的中国人，我可以购买口罩捐赠给武汉。

（复杂）在 XXX 日期购买。

（复杂）通过不同的运输通道送到武汉。

（复杂）捐赠给 XXX 不同的医院。

方法六：推迟性能实现

作为有爱心的中国人，我可以明天购买口罩捐赠给武汉。

明天这个性能太高了，实现起来可能比较困难，我们先实现购买和捐赠，不考虑哪天能完成，再考虑明天这个性能要求。

作为有爱心的中国人，我可以购买口罩捐赠给武汉。

作为有爱心的中国人，我可以明天购买口罩并完成捐赠给武汉。

方法七：探针

作为有爱心的中国人，我可以明天购买口罩捐赠给武汉。

这个可能对我来说太复杂了，完全不知道该买什么类型的口罩，买 30 万个大概多少钱，渠道买比较靠谱，怎么捐赠，给哪个机构，如果现在就强行做计划的话，可能最后发现，我手上的钱是不够的，或者周期太长，到最后才发现的话，会损失很多。所以一般都是先去探探路。

调查市场上口罩类型、价格、渠道。

调查捐赠方式，靠谱的接受机构。

实施捐赠（需要等前面的工作完毕后重新评估）

评估拆分结果

拆分完毕后，再用 INVEST 原则进行评估，如果符合，那就没问题了。但是有的时候会不符合其中某些原则，比如独立性，但是实际业务就只能这样。比如上面提到的方法三的拆分，这个是必然有关系的，不可能先做第二个用户故事后做第一个。这时只能选择不符合独立性原则。

彩蛋

看了上面这么多拆分方法，是否迷糊了？是否每次拆分都要对照上面的方法一个一个的试？其实不需要的，根据经验，拆分用户故事最重要的是，先捋清楚整个业务 (划重点，这个最重要，之前很多例子你感觉切分的不如作者好，都是因为对举例的业务不熟悉)，然后按照最重要的原则-纵着切即可。如下图所示。

图片来自网络

纵着切的意思是，每个切分出来的需求是个单独对用户有价值的，就像上图中切出来的一块蛋糕，是独立的个体，包括这一块蛋糕的所有层次以及上面的小人。对比的横着切的意思是所有的需求放一起将前台、后台、数据库操作这样切分出来，结果就是先用几个迭代将所有的需求前台工作做完了，再开发后台的，这样无法尽早交付有价值的需求，比如先将蛋糕上上所有的小人都切下来了。

如果业务比较复杂，那么就以 MVP 的思想，先交付一个简单的端到端的业务，再慢慢扩展复杂程度。如果过于复杂，就尝试探针方法。

如果捋清楚了需求，尝试纵着切，发现很难下手，这时候再来看上面提到的 Lawrence 的七个方法，寻求帮助。