我们为什么要拆分用户故事

    拆分用户故事有两个层面，一是史诗级故事拆分成小故事，二是将小故事拆分成任务。

    一个好的用户故事除了要有其明确的三要素外，还要具有“独立、完整地交付一个用户价值”的特点，以及“规模适中”以确保能在一个迭代内完成。

    继续以“手机导航能进行语音播报”这个用户故事举例。

    从其是否“独立、完整地交付一个用户价值”来看。语音播报可播报的内容很多，比如方向指示、超速提醒、红绿灯提醒等等，这些不同的内容提供给用户的价值都不一样。

    从其规模是否“足够小”来看，语音播报首先要有一个从语音识别引擎，这个需要从第三方引进，进度可控性不高；其次，越多的提醒内容需要越多的工作量，开发时间越长，基本上不可能在一个迭代内完成。

    尝试其拆分成如下几个故事（一个技术故事、三个用户故事）：

技术故事：集成语音识别引擎，为手机导航提供文字向语音转换的接口。

用户故事1：作为一个驾驶员，我希望手机导航能用语音播放方向指示，以便在交叉路口更安全地通过手机导航了解下一步行驶方向。

用户故事2：作为一个驾驶员，我希望手机导航能用语音提醒超速，以便通过导航即时、安全地了解是否超速。

用户故事3：作为一个驾驶员，我希望手机导航能用语音进行红绿灯提醒，以便我在通过红绿灯时提前减速。

    如上拆解之后，故事规模明显变小，同时每个故事都提供了不同价值，甚至能更清晰地分辨出不同的语音提醒需要在不同的时机进行提醒。史诗级故事拆解成小故事除了能通过“小规模化故事”防止小瀑布，同时也有助于识别出需求的某些细节信息。

    经典瀑布式开发中有明确的详细设计阶段，通过这个阶段的活动完成框架、算法、流程、数据结构等设计，为软件编码提供一个最优方案。敏捷开发中没有这个阶段，那敏捷开发是不是就不用做详细设计了？任何形式的软件开发都要做详细设计，敏捷开发也不例外，只是不要求如同瀑布式开发一样输出标准的详细设计文档，敏捷开发可以通过任务分解的方式完成详细设计。

    所谓任务分解就是将要开发的用户故事拆分成多个任务，每个任务都能在较短的时间内（不超过一天）完成，完成所有任务后能达到高质量实现用户故事的目的。部分人认为任务很难拆分，甚至觉得没有必要拆分，存在这种思想的人就如同在瀑布式开发中任务不做详细设计一般，设计思路还没有理清就扑入代码的海洋，这种做法写出来的代码质量是可想而知的。

    任务分解除了发挥详细设计的作用，也可用于制定工作计划。分解出来的任务就是在实现故事的过程中要做的事情，每个任务需要的时间就是做这些事情分别需要的时间。从这个角度来看，如果我们无法很好地将故事分解成任务，那我们如何评估故事的规模？大致都是拍脑袋拍出来的，我想这也是我们没法做好迭代计划的原因之一吧。