由于放到Sprint当中的用户故事的规模已经比较小了，所以有些人认为已经没有必要在进行分解。那么为何还要对用户故事进行任务的分解呢？

为什么要对用户故事进行任务拆分

尽管用户故事的确可以小到作为工作的单位，但是将他分解为更小的任务，通常更符合项目的需要，主要表现在如下三个方面：

1. 对于很多团队来说，一个用户故事需要多个团队成员协作完成，将故事拆分为更细的任务，便于团队成员协作完成任务。

2. 用户故事是从用户的角度描述的用户需求，而不是开发团队成员实现用户故事需要完成的任务，将故事分解为任务，有利于发现那些被遗忘的任务点。整体团队协作划分任务，依靠的是集体的智慧，考虑更加全面。

3. 有些人认为敏捷没有像瀑布模式那样的前期设计步骤，这是事实，敏捷没有前期设计的阶段，但是敏捷的特点是做频繁的短期设计。分解任务的过程实际上就是一个即时设计的过程。

任务拆分的准则

1. 如果故事中的某个任务很难估算，把它独立出来。
2. 如果某些任务可以分给多个人单独完成，那么把这个任务分割成小的任务

拆分的核心目标

快速交付用户价值

任务拆分的方法

• 按工作流程步骤切分
  • 是否可以先完成工作流程的头尾部分，再添加中间步骤去完善该故事呢？ 按操作切分 是否可以把不同操作切分成独立的故事呢？（比如是有关“管理”或“配置”某物）
• 按不同业务规则切分
  • 是否可以先完成业务规则的一个子集，后续再添加其他规则呢？（比如故事中有没有范围型词语像是“灵活的日期”来暗示着多种变化呢？）
• 按不同类型数据切分
  • 是否可以先处理一种类型的数据，后续再处理其他类型的数据呢？
• 按实现先后依赖切分
  • 该故事的实现背后是否依赖另一个流程的数据输入？
• 按照体验质量切分
  • 是否可以先完成一个低体验质量的故事，然后再提高体验水平？
• 按不同界面切分
  • 是否能先简化复杂界面，先完成一个简单版本？如果多个界面获取相同类型数据，是否可以先从一个界面处理数据，后续再增添其他界面呢？
• 按简单/复杂切分
  • 如果简单的核心就能提供大部分价值，是否可以先完成简单核心，再通过后续的故事来扩充它呢？
• 延迟性能优化
  • 是否可以先使其工作，后续再满足非功能性需求呢？（当复杂主要来自非功能性需求时）
  • Make it work then make it faster.

如何避免拆分时丢失重要的需求

容易被遗忘的重要需求往往可能是非功能性的需求，如果你不确定是不是还有哪些重要功能被我们忽略了，可以通过问两个问题帮助你开展脑暴：

产品上线后，如果你会收到一些用户投诉，会是哪些问题？ 产品上线后，如果监管部门来做审计并发现了问题，会是哪些问题？