将用户故事分解为任务没有什么捷径，许多的开发者在他们的工作当中也一直在做类似的事情-将需求分解为任务。由于放到Sprint当中的用户故事的规模已经比较小了，所以有些人认为已经没有必要在进行分解。那么为何还要对用户故事进行任务的分解呢？
尽管用户故事的确可以小到作为工作的单位，但是将他分解为更小的任务，通常跟符合项目的需要，主要表现在如下三个方面：
第一、 对于很多团队来说，一个用户故事需要多个团队成员协作完成，将故事拆分为更细的任务，便于团队成员协作完成任务。
第二、 用户故事是从用户的角度描述的用户需求，而不是开发团队成员实现用户故事需要完成的任务，将故事分解为任务，有利于发现那些被遗忘的任务点。整体团队协作划分任务，依靠的是集体的智慧，考虑更加全面。
第三、有些人认为敏捷没有像瀑布模式那样的前期设计步骤，这是事实，敏捷没有前期设计的阶段，但是敏捷的特点是做频繁的短期设计。分解任务的过程实际上就是一个即时设计的过程。
分解任务的一些准则：
1. 如果故事中的某个任务很难估算，把它独立出来。
2. 如果某些任务可以分给多个人单独完成，那么把这个任务分割成小的任务
3. 如果有比较让客户了解故事的某一个部分的完成情况，那么将它们分离出来，成为单独的任务。
作者:Eric
