今天分享一个用户故事拆分的案例。引起我的注意的是团队认为这个用户故事无法继续拆分，而他们在一次Sprint中只能完成这一个User Story，所以我尝试理解了实际的需求，并自己尝试拆分了一下。欢迎小伙伴们一起讨论。
背景： 一个共创孵化场地的设施管理系统
用户故事描述： 作为一个培训讲师，我希望能够订阅到合适的培训场地。(搜索场地的User Story是另外一个，这里主要说的是订阅这个场景)
客户需求描述：
- 看到场地的布局图，位置，楼层，容量，内部设施等信息。
- 订阅时长是要明确否包含午餐时间，并设定午餐时间段。
- 选择订阅的起始时间的时候，只允许比当前时间提前半小时，否则超时不允许订阅。
- 如果场地在选择时间段内被占用，允许按照占用时间段和选择时间段自动切分后订阅。同时显示占用人和占用目的描述等信息，以方便内部协商。
- 订阅时间段支持点击时间和滑动方式选择。
上面是在和客户沟通后得到的上下文。可以理解客户需求部分是这个用户故事的业务规则。这让我想起了Mike Cohn的5种简单用户故事拆分法“SPIDR”中一个方法R(Rules)(感兴趣的小伙伴可以阅读我之前的一片文章<五种简单高效的拆分用户故事的方法>)。我们可以尝试将每一个规则(Rules)拆分成一个用户故事来进行迭代开发。例如：
- 作为一个讲师，我希望能够在订阅页面，看到场地布局，位置，楼层，容量和内部设施等信息。这样我就可以为我的课程订阅合适的培训场地和使用时间段。
- 作为讲师，希望在订阅场地的时候可以选择订阅时间区间的时候，选择是否包含午餐时间，这样可以更合理标记和计算的场地占用时间。
- 作为讲师，希望在订阅场地的时候，选择的开始时间已经超过30分钟的时候能够给予提示，告诉我无法使用。这样就能避免讲师错误的订阅场地时间。
- 作为讲师，在订阅场地的时候如果所选时间段有其他人已经占用，希望能够给予提示，这样就可以明白该场地被占用的时间、目的、以及人员，方便调整和协商等后续操作。
- 作为讲师，在订阅场地选择一个较长时间段时，如果中间有被占用的时间段，希望系统能够将可用时间段自动分割，这样我就可以最大限度地利用场地时间。
可以看到每一个客户的需求可以在这里考虑为一个业务规则，而每一个规则可以作为一个独立的用户故事进行开发。当然，你可能会说这是一个操作页面内的逻辑，这样分割用户故事最后还是会导致UI界面的反复修改。是的，有些时候确实很难做到完美的完全独立，但是本例中主要描述的是后台业务规则的拆分，所以主要的后台工作量可以从这种拆分中获益。当有一些突发情况导致用户故事无法全部做完的时候，我们有机会在合理的情况下去掉某些业务规则，同时能够最大限度地保证用户最在意的业务规则被优先交付。
上面的业务描述最后一个是“订阅时间段支持点击时间和滑动方式选择”。这部分不属于业务规则，但依然可以拆分，在“SPIDR”中I(Interfaces)中讲到，GUI的方法可以分成普通和改进版本，所以这个需求可以生成两个用户故事：
- 作为讲师，在选择订阅场地的时间段的时候，我希望能够支持选择时间段，这样就可以方便的订阅场地和时长。
- 作为讲师，在选择场地的时间段的时候，我希望能够通过滑动块的方式选择，这样更炫酷。
Bruce有话说
当一次迭代只能做一个User Story的时候，请大家要引起注意，这会有一定的潜在风险。因为一个迭代只做一个Story，团队很可能做成小瀑布的模式，将团队的人员按照功能和技术能力横向切分。最后组合起来后集中测试。而这种一下子铺开的开发模式很有可能无法保证团队容错能力。例如一旦有突发情况，导致某一个环节出现延误，对最后的交付会产生直接的影响。所以我更倾向于进一步拆分，当然仍然是按照可交付的业务价值来拆分。因为只有这样，我们才可以和客户还有PO敲定用户故事的优先级，并对一些未知事件留有缓冲区，例如：延迟交付一些相对低优先级的Story。今天介绍的拆分实践只是一些个人的想法，希望可以带给小伙伴们一些启发和思考。
