关于需求分析:研发需求拆分的全流程详解-敏捷实践

在麻利开发中，采纳 SPIDR 框架中的 5 种办法能够很好地实现需要的垂直切片，将大的需要纵向拆分成小但有价值的、可独立交付的用户故事。

// 回顾「需要垂直切片」和「拆分第一招：SPIDR 框架」，请戳 👉 如果需要拆分像切蛋糕一样简略。

本期内容将持续揭秘麻利开发中的需要拆分全流程，倡议珍藏⭐先码后看。

需要拆分第二招：用户故事切分流程图

听下来仿佛与「如何把大象🐘放进冰箱里」有殊途同归之妙，但它并不是什么「废话文学」。

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

• 待拆分的需要必须是有价值的且尽量合乎 INVEST 准则（除了短小准则）；
• 垂直拆分后的故事大小应该大抵相等，最好是团队研发速率的 1/10 ~ 1/6。

👇关注 LigaAI 公众号，回复关键词【需要拆分】即可获取中文版《流程图》。

《用户故事切分流程图》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. 需要拆分的成果评估有两个维度：用户故事的大小和优先级排序。
4. 公众号回复关键词【需要拆分】，获取中文版《用户故事切分招数图》。

参考资料

1. https://www.humanizingwork.co…
2. http://www.its-all-design.com…
3. https://xp123.com/articles/tw…

理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的 sf 账号 -LigaAI~ 或者点击 LigaAI- 新一代智能研发合作平台，在线申请体验咱们的产品。