一文读懂如何拆分用户故事

好的用户故事遵循Bill Wake的​​INVEST模型​​。他们是Independent，Negotiable，Valuable，Estimable，Small 和 Eestable。该小的要求促使我们分账大片的故事。但分裂后的故事仍然必须遵循INVEST模型。

许多新的​​敏捷​​​团队试图通过架构层来分割故事：UI的一个故事，数据库的另一个故事等。虽然​​PBI​​​的横向分解将导致较小的项目，但它严重限制了团队交付工作软件，解决瓶颈和确定工作优先级的能力。因此，它增加了​​冲刺​​失败的风险。

为什么垂直分解优于水平分解?

从广义上讲，有两种方法可以分解大型PBI。第一种方法称为 “横向分解”，涉及根据需要完成的工作或涉及的层或组件来分解故事。因此，必须为UI，数据库，某些组件，前端和测试完成的工作分为Backlog中的技术项目。这在​​Scrum​​中不能很好地工作，原因如下：

单个项目不会产生可用的，可证明的软件：假设一个团队在sprint中处理网上商店的订单流程。如果他们将水平分割PBI，他们最终将完成设计，数据库，前端和测试的工作。虽然这些项目肯定较小，但它们并不能自行提供工作软件。毕竟，只有UI完成时，或者只修改了数据库时，新功能才能生效。如果没有足够的测试，上线也是一个坏主意。因此，单个项目不会导致工作不能产生可用的软件和 - 通过扩展 - 产生商业价值。只有所有工作的组合完成及集成后才能产生商业价值。但只有完成所有任务。这通常是一个问题，正如本段下一点的解释那样; 增加瓶颈，而不是减少瓶颈：水平分解通常伴随着“筒仓思维” (Silo Thinking)。每个成员都取自软件开发所需的一个孤岛 (Silo)。设计人员将负责设计，数据库人’将设置数据库，开发人员’编写代码，测试人员’进行测试。如果​​团队​​​成员所擔當的角色不可互换（使用这种方法通常就是这种情况），很有可能出现瓶颈。如果设计人员无法按时完成工作，这将影响设计后面的任务。由于团队成员无法互相帮助，每次延迟，问题或中断都会影响整个冲刺;
水平切片无法区分优先级：如果产品所有者包含水平切片，那么​​​产品负责人​​​如何确定优先顺序？由于这些项目都不能自行提供商业价值或工作软件，因此产品负责人将无法确定工作的优先顺序。切片很可能是技术性的，这会在产品负责人和团队之间产生距离和误解;
 

在敏捷的这些年里，我发现了九种将用户故事分成好的小故事的模式。 

使用哪种拆分模式

您经常会发现可以使用多种模式拆分故事。你应该选择哪种分组？我使用两条经验法则：

1. 选择允许您优先处理或丢弃故事的拆分。80/20原则表明用户故事的大部分价值来自功能的一小部分。当一个分裂显示低价值功能而另一个分离不显示时，它表明后者分裂隐藏了每个小故事中的浪费。去分裂，让你扔掉低价值的东西。
2. 选择能够为您提供更加同等规模的小故事的分割。将8点故事变为4个2点故事的分割比产生5和3的故事更有用。它使产品负责人可以更自由地分别对部分功能进行优先排序。

模式＃1：工作流程步骤

以下是我的一位客户创建的内容管理系统的故事：

作为内容管理员，我可以将新闻故事发布到公司网站。

听起来不是太大 - 直到我们挖掘工作流程来发布故事。事实证明，只是为了在公司网站上获得一些句子新闻故事，需要在临时站点上进行编辑和法律批准以及最终审查。这样的6-10个故事不可能适合迭代。

在这样的工作流程中，最大的价值通常来自开始和结束。中间步骤增加了增量值，但不要孤立。因此，首先构建简单的端到端案例然后添加中间步骤和特殊情况可以很好地工作。

新故事包括：

......我可以直接向公司网站发布新闻报道。
......我可以通过编辑评论发布新闻报道。
......我可以通过法律审查发布新闻报道。
...我可以在临时站点上查看新闻报道。
...我可以从暂存网站发布新闻报道到制作。

但有时候，整个工作流程都很重要，所以你不能只从开始和结束开始。在这些情况下，请在整个工作流程中查找薄片。也许它支持最常见的情况。也许您会硬编码或以其他方式简化工作流程中最易理解的部分，以便您可以探索更复杂的部分。

无论哪种方式，从开始到结束，一次最明显的分裂步骤是错误的方式。查看​​我的80/20产品所有权课程的摘录​​，了解明显分裂错误的原因以及如何使用其他两种方法。

模式＃2：业务规则变体

这个故事中隐藏着一些同样复杂的故事，它们使用不同的业务规则完成同样的事情：

作为用户，我可以搜索具有灵活日期的航班。

深入研究“灵活日期”会发现几个不同的业务规则，每个规则都可以成为一个好故事：

......作为“x和y之间的n天。” 
......作为“12月的一个周末” 
......作为“x和y的±n天”。

模式＃3：主要工序

有时，故事可以分成几个部分，其中大部分工作将用于实施第一部分。例如，这个信用卡处理故事，

作为用户，我可以使用VISA，MasterCard，Diners Club或American Express支付我的航班费用。

可分为四个故事，每种卡类型一个。但信用卡处理基础设施将建成支持第一个故事; 添加更多卡类型将相对微不足道。我们可以估计第一个故事大于其他三个故事，但是如果产品负责人以后改变优先级，我们必须记住改变我们的估计。相反，我们应该推迟决定首先实现哪种卡类型，如下所示：

...我可以用一种信用卡类型（VISA，MC，DC，AMEX）付款。
...我可以使用所有四种信用卡类型（VISA，MC，DC，AMEX）付款（已经实施了一种卡类型）。

这两个新故事仍然不是独立的，但依赖性比每种卡片类型的故事要清晰得多。

模式＃4：简单 / 复杂

当你在一个讨论故事的计划会议上，故事似乎越来越大（“x怎么样？”;“你考虑过吗？”），停下来问：“这是什么最简单的版本？ ？“将这个简单的版本捕获为自己的故事。您可能必须在现场定义一些验收标准以保持简单。然后，将所有变化和复杂性分解为他们自己的故事。所以，例如，这个故事，

作为用户，我可以搜索两个目的地之间的航班。

通过拆分变体来保持简单，

...指定最大停靠数。
......包括附近的机场。
......使用灵活的日期。
…等等。

模式＃5：数据的变化

故事中的复杂性可以来自处理数据的变化。例如，我目前正在研究的系统需要对运输提供商服务的地理区域进行建模。我们本可以把整个项目预算烧掉，只需交付地理位置; 它可能很复杂。当我讲述这个故事时，

作为用户，我可以按行程起点和目的地搜索交通服务提供商。

与我们的产品负责人一起，我发现虽然我们不需要成熟的GIS，但建模地理位置仍然非常复杂。我们停下来问道：“有什么'足够'的方式来模拟地理，所以我们现在可以建立其他高价值的功能？”我们决定，

作为用户，我可以根据旅行来源和目的地搜索运输提供商作为县。

这工作了一段时间，直到我们收集到更多数据，发现一些提供商只服务于某些城市甚至社区。所以出现了一个新故事：

作为用户，我可以按照旅行起点和目的地搜索运输提供商作为县，城市，城镇或社区。

查看新的提供商数据，我们还发现一些提供商将支持来自单个城市但在任何数量的周边城市结束的旅行。这导致了这个故事：

提供商可以为不同的地理区域提供旅行出发地和目的地。

所有这三个故事都与原始地理故事分开。这里的不同之处在于我们在构建最简单的版本后及时添加了故事。但有时你会预先知道数据的变化。典型的例子是本地化：

作为内容管理员，我可以创建新闻报道。
…用英语讲。
......用日语。
......用阿拉伯语。
…等等。

模式＃6：数据输入方法

复杂性有时在用户界面而不是在功能本身。在这种情况下，拆分故事以使用最简单的UI构建它，然后构建更有用或更有趣的UI。当然，这些并不是独立的 - 第二个故事实际上是原始故事，如果你先做 - 但它仍然可以是一个有用的分裂。

作为用户，我可以搜索两个目的地之间的航班。
...使用简单的日期输入。
...带有花哨的日历UI。

模式＃7：延迟性能

有时候，很大一部分工作就是快速制作一个功能 - 最初的实现并不是那么难。但是你可以从缓慢的实现中学到很多东西，它对那些无法在故事中做出动作的用户有一定的价值。在这种情况下，将故事分解为“使其工作”和“快速”：

作为用户，我可以搜索两个目的地之间的航班。
...（慢 - 完成它，显示“搜索”动画）。
......（在5秒内）。

模式＃8：操作（例如CRUD）

用户故事中的“管理”一词是一个赠品，故事涵盖多个操作。这提供了一种分裂故事的自然方式。例如：

作为用户，我可以管理我的帐户。
...我可以注册一个帐户。
...我可以编辑我的帐户设置。
...我可以取消我的帐户。

模式＃9：突破一个尖峰

一个故事可能很大，不是因为它必然很复杂，而是因为实施知之甚少。在这种情况下，没有任何关于故事的业务部分的讨论会让你分手。先做一个时间限制的峰值，以解决实施过程中的不确定性。然后，您可以执行或更好地了解如何分解它。不知道如何实现以下故事？

作为用户，我可以用信用卡付款。

然后，将其分解为：

调查信用卡处理。
实施信用卡处理。

在“调查”故事中，验收标准应该是您需要回答的问题。做足够的调查来回答问题并停止; 做研究很容易被带走。

尖峰拆分是最后的，因为它应该是你的最后手段。你可能已经足够了解建立一些东西。那样做，你就会知道更多。因此，在采用​​尖峰​​模式之前，尽一切努力使用前八种模式中的一种。

结论

抵制通过建筑层分割过大的用户故事的诱惑。相反，尝试这些模式将您的故事分成仍然满足INVEST模型的小故事。让我知道它是如何为你工作的，或者你是否遇到了不可思议的​​故事​​（我喜欢挑战！）。