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

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

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

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

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

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