SPIDR用户故事拆分法

Mike Cohn的个人实战总结，发表于领英。

经常有人向Mike Cohn询问该如何拆分用户故事的问题。Mike Cohn对其中最常用的5种拆分方式进行了提炼，并用一个近英文单词的语汇来总结，方便记忆。

对故事进行合理的拆解，可以确保故事规模在一个迭代内，提高故事的完成率，并实现价值的持续交付，而非一次大批量交付。

用户故事规模较大（在个人实践里，通常从工作量超过一周的故事拆起），需要分拆，又没有更好的分拆思路时可以使用。

通常，这种分拆会发生在Scrum及其延伸框架的需求梳理会、迭代计划会，以及发布计划会（如果有）和/或PI Planning（如果有）上。实践熟练的团队不必等到会议上才使用这种方法。当产品负责人跟研发人员探讨故事，发现故事过大的时候，即可开展拆解。

注意：本方法仅为提供给入门时的方法，不代表仅有这些方法。

当拆分用户故事时，我们可以按照如下维度对故事进行拆解。

• 按探针（Spikes）拆解：探针是为了获得完成复杂故事所需知识的研究活动。最耳熟能详的探针例子，如自制/外购决策（即自研/外采决策）。

• 按路径（Paths）拆解：用户在采取某种行动时可能通过不同的路径达成自己的目的。例如，在支付时，客户可能通过信用卡支付，也可能通过支付宝支付。那么一个自然而然的想法就是先出一个信用卡支付的故事，再出一个支付宝支付的故事。（个人实践里，这里开发同事非常容易掉进“这几个故事很相近，我就一起做了完了”的坑里）

• 按交互（Interfaces）拆解：按照在不同的浏览器、硬件平台等进行分拆，对于复杂的交互场景还可以通过多个迭代交付。例如，在前一个迭代先做一个只适配Chrome浏览器的版本，把Safari适配放在下一个迭代。

• 按数据（Data）拆解：我们可以通过化简支持的数据集，或为支持的数据集添加限制，以便能够持续交付价值。例如，在第一个迭代中不支持银行账户余额为负数的场景。在随后的迭代中，通过后续用户故事来扩展新的数据支持。（个人实践中，这类分拆需要工程实践中支持暗启动，即上线和发布解耦；同时也需要用户验收测试中，用户愿意为部分数据集的正确性提供验收）

• 按规则（Rules）拆解：当一条故事中需要大量的规则约束时，将这些规则分批实现可以把大故事有效拆小。例如，当我们对录入表单的数据有关联检查、一致性检查、余额检查、录入模糊匹配等多个规则时，可以优先实现对业务合规性最重要的余额兼差和一致性检查，其他规则后续迭代再完善。（按规则拆解会遇到与按数据拆解类似的问题，需要教练跟业务部门保持一致）

https://www.linkedin.com/pulse/5-ways-split-user-stories-spidr-method-mike-cohn