在敏捷开发中，利用SPIDR框架中的五种方法可以很好地完成需求的垂直切片，将大的需求垂直拆分成小而有价值的可以独立交付的用户故事。
本期将继续揭示敏捷开发中需求拆分的全过程。
需求分割的第二种方法：用户故事分割流程图
听起来和《如何把大象放进冰箱》很相似，但它并不是“废话文学”。
《用户故事细分流程图》（以下简称“流程图”）介绍了9种常见的垂直细分模式，并详细讲解了每种模式的具体思维路径和判断规则； 此外，还提供了很多针对实际需求拆分的详细建议：
“用户故事细分流程图”by | 来源：
1.了解要拆分的需求的价值
在正式开始拆分需求之前，敏捷团队应该花一些时间梳理和确定工作目标，并充分了解工作范围，例如涉及的干系人、需求验收标准等。 其中，明确需求的价值是最重要的。
将研发需求分解为用户故事本质上是对交付增量的进一步细分。 如果对于需要拆分的需求没有明确的价值引导，那么研发工作很可能走错方向或者“死胡同”，导致前期的努力付诸东流。
举一个简单的例子：重构公司官网的用户注册页面。
在此描述下，“重构注册页面”是为了让网站管理者更好地管理注册信息，还是为了让访问者有更好的体验？ 如果是后者，那么需要优化的“使用体验”到底指的是什么？ 是更美观、更易用的用户界面，还是更简单的注册过程？
用户故事的“WHO-WHAT-WHY”语言结构要求故事必须解释需求价值，即清楚地传达用户可以获得的好处。 此规格也适用于大型需要分割的情况。 甚至可以说，缺乏价值描述的需求是无效的，因为研发团队必须知道工作目标和需求的价值，才能更快、更正确地推进后续工作。
那么有效的需求应该如何写呢？ 其实，只要对上面的描述稍加改进，添加重要的价值信息，明确“WHO”和“WHY”，就可以成为被拆分的合格要求：
【需求】重构公司官网用户注册页面，以便访问者能够快速获取自己感兴趣的内容。
除了强调价值描述之外，《流程图》还要求待拆分的需求尽可能符合小原则以外的原则，即待拆分的需求应该是独立的、可协商的、有价值的、可估计和可预测。 实验性的。
对于不满足这个条件的需求，可以尝试将其与另一个需求合并游戏项目拆解流程图，或者重新构思另一个需求，然后以这个新的合格需求作为拆分的起点。
2. 9种垂直分割模式
明确了需要拆分的需求的交付价值和工作规模后，研发团队可以采用以下9种细分模式进行规划和拆分。
01 按工作流程步骤划分
根据工作流程中的步骤顺序，将大需求拆分为逻辑上连续且具有独立价值的用户故事，是最常见的拆分模式。 在敏捷实践中游戏项目拆解流程图，通常采用以下两种方法来构建完整、全面的工作流程：
在实际工作中，我们可以用快乐路径（Happy Path）来表示最常见的主流程，这是一条没有任何异常情况的成功路径； 用异常路径（Path）来表示异常情况的处理路径，代表用户没有按照操作中的各种错误场景来期望顺利到达终点。
80/20 规则指出，最有价值的流程往往只占 20%，剩下的 80% 通常是次要的。 因此，遵循“从部分到整体”的原则，首先捕捉最重要的工作流程，然后逐步扩大和丰富所需的故事集是操作的重点。
02 按用户操作拆分
当一个大的需求与“管理”或“配置”等描述符相关时，可以根据不同的用户操作将其划分为更小的故事。 借用CRUD操作概念作为用户操作分类的底层逻辑是一个不错的选择。
CRUD 操作是四个基本操作的缩写，分别代表添加、读取、更新和删除。 在需求拆分领域，可以这样应用：
03 根据不同业务规则进行拆分
该模式对应SPIDR框架中的Rules方法。 在实际工作中，有些业务逻辑会有很多潜规则限制，尤其是与时间、空间、选择等范围词相关的业务。
敏捷团队可以根据业务规则和技术标准拆分需求，并根据时间和价值进行排序，从而逐步适应技术规范或业务规则。
例如，在线票务系统的购票流程通常隐含着数量限制、排他性等规则。 研发团队可以先实现无限制的购票流程，然后进一步实现与约束规则相关的故事。
04 根据不同数据类型进行拆分
根据不同的数据类型或数据源拆分大需求是处理输入/输出操作的常用手段。 敏捷团队可以根据不同数据子集的优先级，在迭代中专注于一种数据类型的实现，以快速交付故事价值。
05 根据不同页面拆分
与SPIDR框架中的接口方法类似，当需要拆分的需求涉及多个交互系统的使用，或者涉及用户界面呈现的升级和变化时，可以根据不同的用户界面拆分多个用户故事集。
06 按主要工作划分
或者可以理解为：按照主要工作目标划分。 如果完整的需求描述包含and/or/etc./then等连词，通常意味着需求可以拆分成多个独立的用户故事，并且故事集必须基于相同的基础设施才能完成。
这时，只有把基础设施建设标记为主要工作并先完成，才能更好地推动用户故事和大规模需求的研发。
07 除以简单/复杂
对于一些复杂的大规模需求，在开发初期就考虑并实施所有情况是非常困难的。 因此，可以先交付最基本的简单版本，然后基于其他拆分模式进一步扩展，将需求拆分为不同的故事集合，以更复杂的故事一一交付，逐步实现大规模需求。
08 非功能需求的延迟交付
延迟交付模型的核心是将大需求拆分为“可用”和“易于使用”两部分。 在故事优先级的驱动下，需求是分步骤完成的。 例如：
这种拆分的优点是，它允许团队专注于交付功能，而不是被非功能性需求分散注意力。 然而，我们也必须小心那些需要完成并积累成“技术债务”的非功能性需求。
以下是一些常见的非功能性需求的列表：
09 调查问卷
当你发现使用上述八种拆分模式无法将一个大的需求拆分成更小的需求时，很可能是因为敏捷团队缺乏支持拆分的重要信息。 例如，团队不熟悉需求中描述的业务，不理解需求。 对涉及到的技术等不了解，这时候就需要用探针模式去探索不确定的领域，明确需求方向。
敏捷团队可以通过技术预研充分理解需求内涵，快速探索可能的技术方案，初步判断支持需求详细拆分的工作量。
3.评估需求拆分的效果
指出在敏捷开发中，需求拆分遵循两个经验法则：
划分后的用户故事可以根据以下判断标准进行评估，以确定是否进入后续开发流程：
联赛总结
在敏捷开发中，无论是史诗级需求还是用户故事，都需要传达清晰的需求价值。
敏捷团队可以多次尝试九种需求垂直切片模式的不同组合，以确定最合适的拆分模型。
评估需求拆分的有效性有两个维度：用户故事大小和优先级。
参考
