本周在参加一个团队的回顾会的时候，注意到团队的一个小抱怨，感觉挺有启发，在这里和大家分享一下。这个团队迭代中实现了一个用户故事，由于实现功能过于复杂，尽管Team已经按理解尽全力来实现，不过最后在Review meeting中PO仍然觉得并没有很好的实现需求。这是什么原因呢？今天就来和大家分享一下。
在回顾会上，Team提到的一点是这个用户故事比以往迭代中做的故事都复杂，而团队在迭代的Time Box中无法很好的应对如此复杂的任务。所以导致了最后并没有很好的完成。面对这个原因，一个问题在我头脑中浮现：为什么这么复杂的用户故事会被放入当前迭代呢？大家是被误判了吗？于是在回顾会快结束的时候，我问了Team两个问题：
- 这个用户故事对用户来说他的核心诉求是什么?
- 如果只做核心诉求，相当于目前工作量的多少？
Team当时给我第一个问题的回答并不清晰。这可能也是评估不准确的原因。于是找PO和了解需求的人员重新说明了一次需求：客户希望一些核心数据的存储在他们自己的存储介质中，而不是SaaS服务商提供的存储介质，这样符合他们的安全合规要求。根据这个需求，如果我们希望拆分它，如何来做呢？结合我之前一篇文章五种简单高效的拆分用户故事的方法中描述的拆分方法。
我们尝试一下。用户希望BYOS(Bring your owned storage),那么会有两类用户面临这个场景：
- 全新的注册用户，之前并没有使用过我们的产品。
- 已经使用产品，有一定数据，希望使用BYOS功能的用户。
按照和两个场景进行拆分当前用户故事，每一个都符合INVEST原则，同时也符合MVP原则。可以将功能投入市场并满足一部分用户需求。当我询问Team如果按照第一种方式只有新注册用户支持BYOS的话，工作量是多少？Team回答只需要当前的20%。我相信如果只实现这个拆分后的用户故事，Team应该可以有更多的时间来完善功能，提高将质量。而恰恰是因为同时为了实现两个场景，导致任务质量完成的差强人意。
按照SPIDR拆分五步法，这个案例的拆分应该属于Paths或者Rules这两种都可以。主要思想是按照业务线纵向来拆分用户故事，保证需求的完整，同时对客户有价值。
Bruce有话说
很多时候我们更在意的是功能的实现，却忽视了用户有价值的需求。合理的拆分用户故事，让其实现能体现出用户期望的价值，这才迭代应有的效果。针对功能的横向拆分和针对业务需求的纵向拆分是我们打破惯性的一个突破口。Mike Cohn的SPIDR拆分法是个不错的开始，让我们多多练习吧。
