怎么做用户故事拆分
怎么像切蛋糕一样拆分需求
上一篇我们讲了什么是用户故事，好的用户故事有哪些特征，但是面对一个史诗级的需求（或feature）需要拆分时，我们仍然有可能会茫然不知该怎么下手：
- 明知太大，可就是没办法拆开怎么办？
- 哪些重要先做的要先拆出来？
- 怎么样防止重要需求被拆丢了？
- 会不会拆出一些多余没用的故事？
本文就是要探讨上面这些问题的应对方法。
故事拆分常用方法
对话是拆分故事的最好的工具之一
负责故事拆分的同学一定不要忘了这个最好的工具，但同时我们也需要掌握一些基本的可操作的方法。故事拆分的方法有很多不同的观点，这里主要介绍Richard Lawrence描述的故事拆分招数。
先分三个阶段：
- 准备阶段
- 运用切分模式
- 切分评估
准备阶段
不管待拆分的是feature还是史诗故事（epic），我们首先希望它是满足INVEST原则的（INVEST原则可以参见前一篇博客），当然“small”这条除外；否则先解决这个问题。
然后基于一个7人开发团队一个迭代我们推荐完成5-10个story，所以如果该待拆对象如果已经是团队速率的1/5到1/10的话，那就不用拆了，直接做吧，否则就可以开始拆分了。
切分模式
切分有很多不同的模式：
-
按工作流程步骤切分
- 是否可以先完成工作流程的头尾部分，再添加中间步骤去完善该故事呢？
-
按操作切分
- 是否可以把不同操作切分成独立的故事呢？（比如是有关“管理”或“配置”某物）
-
按不同业务规则切分
- 是否可以先完成业务规则的一个子集，后续再添加其他规则呢？（比如故事中有没有范围型词语像是“灵活的日期”来暗示着多种变化呢？）
-
按不同类型数据切分
- 是否可以先处理一种类型的数据，后续再处理其他类型的数据呢？
-
按实现先后依赖切分
- 该故事的实现背后是否依赖另一个流程的数据输入？
-
按照体验质量切分
- 是否可以先完成一个低体验质量的故事，然后再提高体验水平？
-
按不同界面切分
- 是否能先简化复杂界面，先完成一个简单版本？
- 如果多个界面获取相同类型数据，是否可以先从一个界面处理数据，后续再增添其他界面呢？
-
按简单/复杂切分
- 如果简单的核心就能提供大部分价值，是否可以先完成简单核心，再通过后续的故事来扩充它呢？
-
延迟性能优化
- 是否可以先使其工作，后续再满足非功能性需求呢？（当复杂主要来自非功能性需求时）
- Make it work then make it faster.
切分评估
对于切分完的故事，我们再次检查故事大小是否是团队1/5到1/10的速率？是否满足INVEST原则？是否有故事可以降低优先级或可以删除？是否有故事先交付的话可以收获明显的价值、认知或降低整个项目风险的？
如果答案不是的话可以选择其他的切分模式再拆分试试看。
参考来源："How to Split a User Story" by Richard Lawrence
其他一些技巧
怎么找到需求中最重要的故事
最重要的故事往往是实现最大价值的故事，怎么才能在繁多的story中找到真正最有价值的点呢，我推荐使用impact mapping的方式来梳理。
在impact mapping里我们通过理清“目标”、“角色”、“影响”、“功能”之间的关系，从而找到实现业务目标的最短路径，明确哪些是最重要的故事。
更重要的是我们可以基于开发→测量→认知的循环，不断验证我们的“影响假设”和“功能假设”，完善影响地图，调整产品里程碑计划，完善产品和服务，动态地实现业务目标。
example of impact mapping
怎样防止重要的需求被拆掉了
容易被遗忘的重要需求往往可能是非功能性的需求，如果你不确定是不是还有哪些重要功能被我们忽略了，可以通过问两个问题帮助你开展脑暴：
- 产品上线后，如果你会收到一些用户投诉，会是哪些问题？
-
产品上线后，如果监管部门来做审计并发现了问题，会是哪些问题？
如果你确性能够应付所有的投诉和审计，那你已经没有什么重要故事遗漏了。
基于数据流向的拆分
需求的复杂度往往都是由在系统中流转的信息和数据造成的，所以还有一种需求拆分方法就是从数据入手，通过理清数据的流向把所有功能都串起来。
怎么串呢，请把握下面两个原则：
每个数据必须有来源。
每个数据必须要有消费者。
