10 powerful strategies for breaking down Product Backlog Items in Scrum (with cheatsheet)
为什么垂直拆解要优先于横向拆解？
显然，拆解需求有两种方式，一个是横向拆解，按需完成的任务的类型，或需完成的组件的层级这些维度来拆解。因此，UI, 数据库，一些其他组件，前端，测试等工作会在这种拆解中被拆成小模块。但它有以下问题，导致在敏捷中无法正常工作：
- 单个模块不能独立演示。假设有一个网上下单购物需求，如果被按横向拆解的方式，拆解成数据库，前端和测试工作。尽管每个模块都很小，但它们并不能单独提供功能。任何一块都无法独立运转，仅当所有工作都完成了才能产生业务价值。
- 这种拆解方式，增加了瓶颈。横向拆解经常伴随的是“孤立的思考”，每个模块的成员都是一个孤岛。“设计人员”负责设计，“数据库人员”建立 数据库，“开发人员”编写代码，“测试人员”进行测试。这些人一般是无法互换的，那就可能出现瓶颈。比如：如果设计延迟，那设计之后的工作将受影响，而且团队成员无法互相帮助。因此任何延迟都坐影响最终交付时间。
- 横向拆解无法进行优先级划分，因为他们互相依赖，缺一不可。
尽管横向拆解能减少模块的数量，但这严重限制了团队阶段性交付成果的能力。因此它不是一个好办法。在Scrum 中，垂直拆解更有用。它通过把项目待办事项细分为理小的待办事项（而不是技术任务）译注：这个表述明显没能解释清楚与横向拆解的不同..：例：“作为客户，我可以为我的订单会款，那么我可以得到我的产品”，可以细分为：“作为客户，我可以得通过电汇付款，以便我可以得到我的产品”和“作为客户，我可以用信用卡付款，以便我可以得到我的产品”。可以把隐藏的信息明确下来。
策略一：通过业务流程拆解
假设有以下需求：
作为顾客，我可以为我的购物车付款，然后就能在家收到产品
这是个标准的订单过程，我们可以辨别出以下步骤：
- 顾客可以用帐号进行登录，因此不需要每次都输入个人信息
- 顾客可以确认自己的订单，因此他需要能在支付之前修正错误
- 顾客可以通过电汇支持，所以他需要能二次确认。
- 顾客可以通过信用卡支付，所以他能二次确认。
- 顾客可以通过 email 获取支付凭据。
如上所列，需求拆解成这几项后，我们对自己所需要实现的功能以及需要提供的能力都有了很清晰的理解。而且，对产品经理来说，他也很容易制定优先级。
注：这应该是最常见的拆解方式
策略二：通过业务规则拆解
产品需求通常会带着若干显性或隐性的业务规则，依然是这个需求：
作为顾客，我可以为我的购物车付款，然后就能在家收到产品
它有以下业务规则：
- 店主可以拒绝低于10美金的订单，因为这种订单无法赢利
- 店主可以拒绝来自国外的顾客，因为邮费会过高以致无法赢利
- 店主可以保留48小时内被订的产品的库存，因此顾客可以看到实际库存
- 未48小时内付款的订单，店主可以取消，以便将商品卖给其他顾客。
业务规则通常是隐性的，因此挖掘也需要些技巧和分析能力。一旦确认了业务规则，它将再次提高我们对业务的理解及评估能力，而产品也可以决定规则的优先级。
策略三：按 正常/异常(happy/unhappy) 流程拆解
通常功能会涉及一个正常流程和一个或多个异常流程（原文为happy/unhappy）。
策略四：按输入的选项或平台拆解
如 pc，手机 等输入的不同表现。
策略五：按数据类型或参数拆解
策略六：按操作（增删改查）拆解
策略七：按测试场景或测试用例拆解
策略八：按需求中涉及的角色拆解
例：顾客与店主、发表内容者，阅读内容者