一句话需求好不好？ 其实挺好的。可以作为 Epic 的准确描述。
史诗（Epic），也称史诗故事，是基于产品长期战略被提出的、颗粒度最大的研发需求，具有跨迭代特性。它通常表示一个可独立使用的产品功能模块或者功能合集，能够被拆分成若干个用户故事并在多个迭代周期中完成。
有了这个史诗故事，就可以进一步拆解下面的具体故事了。
用户故事，也称故事，是任务需求最清晰的、颗粒度最小的需求，一般要求在一个迭代周期内完成。当需求落到故事层级，敏捷团队就可以通过完成它实现价值交付，因此故事有时也被称为需求的最小可交付单位。
重点看一下粗体的那些描述，后面的拆解一定要坚持上面粗体描述的原则。
接下来是子任务，如果说故事是最小可交付单位，那么子任务就是最小可执行单位，它是用户故事的完成路径，是组成故事的具体工作事项；只有将若干个子任务全部完成，才能最终交付完整的用户故事。
以上这三个层级关系把握好，足矣！
故事拆解是一步到位的吗？ 肯定不是，敏捷从来不追求一步到位， 故事的拆解是不断迭代的过程，从一句话需求开始，不断沟通调研，不断丰富完善，不断反馈互动，即使用户最开始只有一个很模糊的需求，我们也可以通过这一过程逐步将需求清晰并且最终可以落地。
有时候会有些非常技术性的需求，似乎不太容易转变成用户故事，其实开动脑筋，也不是不可能的，举例如下：
假设公司的业务系统需要改用一种新的架构模式来重新组织，比如说是要加一个全新的 API 平台，所有原来零散的业务终端都要统一调用这个全新的平台（中台？呵呵……），这看起来完全是个技术性的变更需求，对于业务来说似乎没有什么价值和改变，而且目标也是对原来的业务系统完全没有影响。
那么这样的 Epic 要怎么样拆解和创建用户故事呢？
先列一句话的需求 Epic： 新平台 API 替换旧 API 调用
这个一句话需求，可以是团队一说出来，就知道是哪件事的那一句话，不必非常标准和规范，但需要有独特性和可辨别性，与其他的 Epic 有明确的区别和范围边界。
接下来，开始列具体的 Story 或 Task，比较使用新平台 API 前后的系统区别，仔细分析一下某一个具体的业务的流程变化，看是否能列出具体的实现目标，如：
- 作为销售人员，我希望发布二级页面左侧 8 号广告位的广告时，提交新广告后，能在15分钟内在线上浏览到最新的广告。
- 我们假设使用了新的平台 API 后带来的好处是原来要 1 小时才能上线的广告发布过程，可以减少到 15 分钟，使用原来的技术解决方案，一般的优化并不能达到这样的效果，而新平台的 API 可以带来这样的好处。
因此，从上面这个示例，可以看出，我们可以多去挖掘新旧技术替换后，给业务流程带来的好处和价值来思考。上面这个示例就将 8 号广告位的发布这样一个颗粒度的用户故事拆解了出来，也许在实际实现时，可能有一些架构层面上的通用工作，比如需要整个平台的替换，网关的配置等，而一旦建立了这样的 Story，我们就可以不过于考虑得成熟或者复杂，只需要先针对这个 Story 的需求来实现，可能一些架构层面上的实现并不完美，但只要足够支持当前这个 Story 即可。后面还可以不断通过更多的 Story 上的子任务不断完善这个架构替换的设计。
当然，实在不行，还有最后一招，就是直接创建 Task 任务，如下：
- 替换商品发布模块的 API 调用为新平台 API 调用
- 子任务 01： 替换商品列表 API 为新平台 API 调用
- 子任务 02： 替换商品新增 API 为新平台 API 调用
- ……
总之，思路清晰，颗粒度把握好，拆解故事或任务，是非常有技巧和成就感的一件事，做得专业可以让后续的开发工作变得非常有序和高效。
