在敏捷开发中，采用 SPIDR 框架中的 5 种方法可以很好地完成需求的垂直切片，将大的需求纵向拆分成小但有价值的、可独立交付的用户故事。

本期内容将继续揭秘敏捷开发中的需求拆分全流程，建议收藏⭐先码后看。

需求拆分：用户故事切分流程图

Richard Lawrence 在《用户故事切分流程图》（又称《用户故事切分招数图》）中总结了研发需求拆分的三个步骤：准备一个待切分的需求、运用切分模式对它切分、评估切分后的故事效果。

听上去似乎与「如何把大象🐘放进冰箱里」有异曲同工之妙，但它并不是什么「废话文学」。

《用户故事切分流程图》（下文简称《流程图》）介绍了 9 种常见的垂直切分模式，并详细地说明了每一种模式的具体思考路径和判断规则；此外，它还提供了许多需求拆分实战的细节建议，例如：

待拆分的需求必须是有价值的且尽量符合 INVEST 原则（除了短小原则）；

垂直拆分后的故事大小应该大致相等，最好是团队研发速率的 1/10 ~ 1/6 。

《用户故事切分流程图》by Richard Lawrence | 来源：https://www.humanizingwork.com

一、理解待拆分需求的价值

在正式开始拆分需求之前，敏捷团队应该花一些时间梳理和确定工作目标，充分理解工作范围，比如涉及的利益相关者、需求验收标准等等。其中，明确需求价值是最为重要的。

将研发需求拆分到用户故事，本质上是对交付增量做出的进一步细分。如果待拆分的需求没有明确的价值引导，那么研发工作就极有可能进入错误的方向或者「死胡同」，导致前功尽弃。

举个简单的例子：重构企业官网的用户注册页面。

在该描述下，「重构注册页面」究竟是为了让网站管理者更好地管理注册信息，还是为了让访问者拥有更好的使用体验？如果是后者，那么需要优化的「使用体验」具体指什么，是更美观好用的用户界面，还是更简洁的注册流程？

用户故事的「WHO-WHAT-WHY」语言结构要求故事必须说明需求价值，即清晰传递用户能获得的好处。这个规范，同样适用于待拆分的大需求。甚至可以说，缺乏价值描述的需求是无效的，因为研发团队必须知悉工作目标和需求价值，才能更快速、正确地推进后续工作。

那么有效的需求应该怎么写？其实，只要对上述描述稍作改进，补充重要的价值信息，说清楚「WHO」和「WHY」就能使其成为一条合格的待拆分需求：

【需求】重构企业官网的用户注册页面，以便让访问者快速获得感兴趣的内容。

除了强调价值描述外，《流程图》还要求待拆分的需求要尽量符合除 Small 原则外的 INVEST 原则，即待拆分需求应是独立的、可协商的、有价值的、可估算的和可测试的。

对于不满足此条件的需求，可以尝试将其与另一个需求合并，或者重新构思得到另一个需求，再将这个符合条件的新需求作为拆分起点。

二、垂直切分的 9 种模式

明确了待拆分需求的交付价值和工作大小后，研发团队可运用以下 9 种切分模式进行规划和拆分。

01  按工作流程步骤切分

依照工作流程的步骤顺序，将大需求拆分成一个个逻辑连续的、有独立价值的用户故事是最常见的拆分模式。在敏捷实践中，构建完善、 周全的工作流程常用以下两种方式：

先找出完整流程的头尾环节，逐步加入更多的中间流程和特殊案例处理；

先用最简单的办法构建主流程闭环，即 Happy Path，再进一步丰富和完善特殊情况和异常判断。

在实际工作中，我们可以借用快乐路径（Happy Path）表示最常见的主流程，是没有任何异常情况的成功路径；用异常路径（Unhappy Path）表示异常情况的处理路径，它代表了用户没有按照操作预期顺利抵达终点的各种错误情况。

二八定律指出，最有价值的流程往往只占 20%，其余的 80% 通常是次要的。因此，遵循「部分到整体」的原则，先抓取最重要的工作流程，再逐步扩大和丰富需求的故事集是操作重点。

02  按用户操作切分

当大需求与「管理」或「配置」等描述词相关，可以将其按照不同的用户操作切分成更小的故事。这里借用 CRUD 操作概念作为用户操作分类的底层逻辑是个不错的选择。

CRUD 操作是四种基本操作的首字母缩略词缩写，分别代表了增加 Create、读取 Read、更新 Update 和删除 Delete。在需求拆分领域，可以这样应用：

03  按不同的业务规则拆分

该模式可与 SPIDR 框架中的 Rules 方法对应。在实际工作中，一些业务逻辑会带有很多隐形的规则限制，尤其是与时间、空间、选择等范围词相关的业务。

敏捷团队可以按照业务规则和技术标准对需求进行拆分，并根据时间和价值排序，逐步实现对技术规范或业务规则的适应。

例如，在线售票系统的购票流程通常隐含对数量限制、排他性等规则，研发团队可以先实现没有限制条件的购票流程，再进一步实现约束规则相关的故事。

04  按不同的数据类型切分

根据不同的数据类型或数据来源，拆分大型需求，是处理输入/输出操作的常用手段。敏捷团队可以根据不同数据子集的优先顺序，先在一个迭代内专注一种数据类型的实现，以快速交付故事价值。

05  按不同的页面切分

与 SPIDR 框架中的接口法类似，当待拆分需求涉及多个交互系统的使用，或者涉及用户界面展示的升级和变更时，可以按照不同的用户界面拆分多个用户故事集。

06  按主要工作切分

或理解为：按主要工作目标作切分。如果完整需求描述中含有和/或/等/然后这类连接词，通常意味着该需求可以被拆分成多个独立的用户故事，且故事集都必须基于相同的基础设施建设才能完成。

此时，只有将基础设施建设标记为主要工作，率先完成，才能更好地推进用户故事和大型需求的研发。

07  按简单/复杂切分

对于一些复杂的大型需求而言，在研发早期将全部情况都考虑并且实现是很困难的，因此可以先交付最基本的简单版本，再依据其他的拆分模式做进一步扩展，将需求拆分为不同的故事合集，通过一个个更复杂的故事交付，逐步实现大型需求。

08  非功能性需求的延迟交付

延迟交付模式的核心是将大型需求拆分成「能用」和「好用」两个部分，以故事优先级为驱动，将需求分步完成。例如：

这种拆分的好处是能让团队专注于交付功能，而不是被非功能性需求分散注意力，但是也要小心待完成的非功能性需求遗留、堆积成「技术债」。

以下是一些常见的非功能性需求列表：

性能方面：延迟交付「更快的速度」

可扩展性方面：延迟交付「支持大量并发用户或大量数据」

并发性方面：延迟交付「支持多个并发用户」（数据锁定、争用条件等）

可用性方面：延迟交付「高可用性和容错能力」

可用性/可访问性方面：延迟交付「易于使用」

UX 方面：延迟交付「更好用的交互」

跨浏览器/平台方面：推迟交付各种客户端设备

国际化方面：推迟对多种语言/本地约定的支持

09  探针调研

当你发现运用上述八种拆分模式都无法将一个大的需求拆小，那么很有可能是因为敏捷团队缺乏重要的、支撑拆分的信息，比如团队对需求描述的业务不熟悉、对其中涉及到的技术不了解等等。此时，就需要使用探针模式，对不确定的领域进行探索，明确需求方向。

敏捷团队可以通过技术预研充分理解需求内涵，快速探知可能的技术方案，初步判断工作量，以支持需求的细化拆分。

三、评估需求拆分的效果

Richard Lawrence 指出，在敏捷开发中，需求拆分遵守两条经验法则：

需求拆分总能将低价值或无价值的故事剥离。如果一个需求拆分后没有可抛弃或者降级的故事，则说明它还需要进一步拆解。

将需求拆分成大小一致的更小的故事更佳。大小一致的小故事在优先级排序、稳定团队工作节奏等方面都展现出更大的优势。

切分完成的用户故事可以通过以下判断标准评估是否进入后续开发流程：

用户故事的大小大致相等吗？

故事大小大概是团队速率的 1/10 ~ 1/6 吗？

故事符合 INVEST 原则的要求吗？

所有故事的优先级都很高吗？是否可以进行降级或者删除处理？

哪些故事需要尽早交付，才能获得早期价值、认知或降低风险？

# Liga 总结

1. 敏捷开发中，无论是史诗需求还是用户故事，都需要传递清晰的需求价值。

2. 敏捷团队可以多次试验需求垂直切片的 9 种模式的不同组合，以确定最适合的拆分模型。

3. 需求拆分的效果评估有两个维度：用户故事的大小和优先级排序。

参考资料

1. https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/ 

2. http://www.its-all-design.com/how-to-split-user-stories/

3. https://xp123.com/articles/twenty-ways-to-split-stories/