怎样在Scrum中分解产品待办项目: 10种强大策略

已经掌握了Scrum的团队知道，成功的关键在于产品Backlog的及时，日益完善和工作细分。他们更喜欢带有许多小（功能）项目的Sprint Backlogs，而不仅仅是几个大项目。较小的项目可以改善流量，并降低冲刺失败的风险。

在本文中，我将解释为什么分解工作很重要，以及为什么应该跨职能而不是僅由尖端技术来完成。我将提供10个有用的策略，让Scrum团队用来分解工作

为什么以及何时分解产品待办项目

软件开发本质上是不可预测的。积压的一些产品待办事项（PBI）需要比预期更多的挑战，而其他项目风险较細。因此，如果冲刺的工作只包含一些大项目，那么低估工作甚至只是单个项目将可能对冲刺产生深远的影响。而且，由于较大的项目往往难以估计和理解，因此短跑失败的可能性会进一步增加。

经验丰富的Scrum团队花费时间和精力将大型PBI分解为较小的故事。虽然他们有时会在规划新冲刺期间这样做，但他们已经了解到这种“精炼”过程应该是连续的，以便使冲刺 - 特别是冲刺计划 - 运行得更顺畅。因此，当冲刺正在进行时，该团队还会花时间分解PBI用于下一个冲刺，甚至可能是后面的1-2冲刺。但这是以“适時” （Just-in-time） 的方式完成的，因此团队花费的时间越来越少，冲刺的步伐亦会越来越快了。

这种分解工作的过程提高了共享理解，提高了估算的准确性，并促进了产品负责人的工作优先次序。但要做得好并不容易，并且需要练习“适时” （Just-in-time） 进行。值得庆幸的是，敏捷社区已经设计了许多有用的策略来将工作分解成更小的部分。

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

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

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

虽然PBI的横向分解将导致较小的项目，但它严重限制了团队交付工作软件，解决瓶颈和确定工作优先级的能力。因此，它增加了冲刺失败的风险。