在上周的文章中，我们了解了用户故事的 INVEST 原则，以及研发需求拆分的两个标准：
- 大需求拆分的终点是用户故事，而故事要能在一个迭代中完成；
- 用户故事下的开发子任务应尽量满足 0/1 判断标准，且工作量建议设置为 0.5~1 人/天。
本篇内容，Liga 将进一步介绍需求拆分的两种常见方式和具体拆分流程。
一、 需求拆分的两种方式
01 水平切片 Horizontal Slice
如果将一个史诗级需求视作一个千层蛋糕，那么水平切片意味着将千层蛋糕逐层分解，每个人只能吃到其中某一层的味道。
在传统研发工作中，人们通常会按照职能和组织架构，将整个需求横向地拆分成「每个职能小组的任务」，且每部分工作只被对应层次的成员所理解。例如：
任务 1：创建新的数据库表格
任务 2：创建传输协议
任务 3：创建 DAL 以访问存储过程
任务 4：构建 UI/UX 页面
02 垂直切片 Vertical Slice
需求的垂直切片则像是将大蛋糕纵向切分成一块块小蛋糕，每块小蛋糕都能尝到「千层」的完整口感。
垂直切片要求将完整需求分解成若干个小但有价值的、可独立交付的用户故事。 每个故事只交付需求中的部分价值，但需要每个切片始终包含完整的开发架构，且能被小组的全体成员知晓和理解。
以「重构账户管理功能」为例，它可以被垂直切分成多个用户故事，交付多个价值：
故事 1：用户可以拥有多个账户
故事 2：用户可以更换账户头像
故事 3：用户可以查看头像使用的历史记录
故事 4：用户可以添加邮箱作为联系方式
03 垂直切片更适合敏捷开发
在之前的文章中我们说过，敏捷开发更适用于需求多变的、功能耦合度低的、价值可持续叠加的项目，或迫切需要推进市场反馈和验证的产品。点击回顾：敏捷之道 | 敏捷开发真的过时了么？
水平切片将需求横向地拆分成了各个架构层中的开发任务。对软件团队来说看似清晰，但每个部分的任务并不能独立交付给客户，不同任务间存在很强的依赖性。
如果采用这种不甚符合 INVEST 原则的需求拆分方式，又想要试行敏捷开发，就可能遇上许多问题：
- 难以统一工作目标：每个职能小组仅从自身具体工作出发推进工作，难以就「用户价值」认知达成统一，堆高团队沟通成本；
- 优先级排序难度加大：敏捷方法的核心就是持续滚动的优先级评估和价值排序，但横向切片带来的高耦合度，使得各项工作不仅有时序依赖，还难以量化价值和优先级，进而导致团队的交付速度下降，甚至会严重影响企业的市场竞争力；
- 试错成本提高，项目风险不可控：由于水平切片的任务无法独立交付，管理者和业务相关方很难在项目过程中根据已完成的工作判断推进方向的正确性，或者及时察觉架构中存在的问题。这不仅增加了开发团队的试错成本，更可能因为无法响应市场的快速变化，而承担更大的项目风险。
为了避免上述种种问题，做到目标统一、灵活应变、降低试错成本、提升交付效率，敏捷团队势必要采用全新的方法，打破组织架构间的「隐形墙」，更快地向用户提供价值。
比方说：将完整的功能需求拆分成多个可独立交付价值的用户故事。这正是敏捷开发中的最佳实践——垂直拆分。
二、 需求拆分第一招：SPIDR 框架
敏捷教练兼 Scrum 联盟的联合创始人 Mike Cohn 指出：“几乎所有需求都可以通过五种方法完成拆分”。他用首字母缩略词「SPIDR」总结了这五种方法。
01 Spikes 探针
Spike 探针，或称技术预研，通常指功能的小型原型实现，或是对新技术的调研和可行性评估。
探针法通常适用于需求不明确或太复杂，团队需要更多信息以供决策的情况。通过技术预研充分理解需求内涵，快速探知可能的技术方案，初步判断工作量，以支持需求的细化拆分。
02 Paths 路径
如果完整需求存在多个实现路径或场景（通常由 和/等/或 等描述词体现），那么拆分时不必遍历所有情况，只需要选取部分路径并将它们编写成用户故事即可。
举个例子：线上购物的用户可以使用银行卡或三方支付完成订单支付。
根据「或」的描述，可以将该需求拆分成两个场景「使用银行卡完成支付」、「使用三方渠道完成支付」。进一步细化会发现，三方渠道也有多个实现路径，比如直接对接支付宝、微信，或采用聚合支付手段等等。
路径法指出，当需求存在多个实现路径时，无需遍历所有路径，只需要交付最有价值的部分路径即可。所以，假设我们通过评估认为，率先支持微信支付，开发工作量小且带来的用户价值高，那么整个支付功能就可以作如下拆分：
03 Interfaces 接口
当完整需求横跨多种客户端或者数据交互接口时，可以根据接口的多样性进行需求拆分。
例如，客户端可以分为移动设备和浏览器两大类，移动设备可以分为 iOS 系统、Android 系统等，而浏览器又可以分为 Chrome、Edge、Firefox等等。为了避免工作量过于庞大和繁琐，在实际应用中更常见的做法是，按照「可支持」和「暂时无法支持」两类来规划此类故事。
第二种情况是依据不同的数据操作接口进行拆分，例如在实现数据导入功能时，可能需要支持多种文件类型（Word，Excel，CSV）的导入，那么每一个不同的数据接口的实现都可以是一个独立的用户故事。
第三种情况基于不同的界面交互方式，递增拆分需求。如下图所示，在后台数据类型不变的情况下，根据工作时间、任务紧急程度以及客户接受程度等判断条件，将「精美的操作界面」交付分为两个故事进行：
- 先交付「一个简单的 UI 」，向客户提供「可用」的界面（如左图所示）；
- 补充一个持续优化的故事「使用户界面更加精美」，向客户提供更极致的 UI 与体验（如右图所示）。
图片出自 Bruce Wong 个人博客：https://brucetalk.com/2020/09...
04 Data 数据
依据不同的数据类型或者数据来源，拆分大型需求；通过专注于数据子集的功能实现，实现更简单的用户故事交付，是非常有效的方式。敏捷团队可以在一个迭代周期内只专注于一种数据类型的实现，交付价值。
05 Rules 规则
一些业务逻辑中会带有很多规则限制，敏捷团队可以按照业务规则和技术标准对用户故事进行拆分。
在时间紧、任务重的情况下，逐步实现对技术规范或业务规则的适应，是有意义的。这可以帮助团队快速试错、快速交付、获得用户反馈，之后再基于反馈进行逐步迭代，完善对应的业务规则，并达到相应技术标准。
三、Liga 总结
- 垂直切片更符合敏捷开发的要求。研发团队应该将大的需求纵向切分成多个小的、可独立交付价值的用户故事。
- 敏捷需求拆分框架之一：SPIDR。通过使用探针法、路径法、接口法、数据法和规则法，可以将大的需求拆分成符合 INVEST 原则的用户故事。
在下一篇文章中，Liga 将继续带来研发需求垂直拆分的第二招：用户故事切分流程图。请持续关注 LigaAI 动态。
了解更多敏捷开发、项目管理、行业动态等消息，关注我们的sf账号-LigaAI~ 或者点击LigaAI-新一代智能研发协作平台，在线申请体验我们的产品。