用户故事拆分案例摘要

背景与问题

本文分享了一个用户故事拆分的案例，探讨如何拆分一个团队认为无法进一步细化的用户故事。案例涉及一个共创孵化场地的设施管理系统，团队在一次Sprint中只能完成一个用户故事，可能导致潜在的开发风险。

客户需求与业务规则

用户故事描述为“作为一个培训讲师，我希望能够订阅到合适的培训场地”。客户需求主要包括场地信息展示、订阅时间段规则、时间段占用提示和调整功能，以及时间选择交互方式。这些需求被归类为业务规则，并且每个规则可拆分为独立的用户故事进行迭代开发。

用户故事拆分实践

通过Mike Cohn的“SPIDR”方法，将原业务规则拆分为多个用户故事。例如：

• 场地信息展示：订阅页面显示布局、位置、楼层等信息。
• 订阅时间区间设置：是否包含午餐时间的选项。
• 时间段验证：选择时间需提前半小时，否则提示无法订阅。
• 占用时间提示：显示场地占用人和目的，方便内部协商。
• 时间段自动分割：被占用时间段内自动调整剩余可用时间。

此外，交互方式需求也可拆分为普通和改进版本，包括点击选择时间和滑动块选择。

团队开发模式与风险

文章讨论了迭代中仅完成一个用户故事的风险。这种方式可能导致团队按功能和技术横向切分，类似小瀑布模式，集中测试后交付。一旦出现突发情况，整个交付可能受到影响。通过进一步拆分用户故事，可交付更细化的业务价值，优先级较低的部分可作为缓冲区，以提升团队容错能力。

总结与启发

本文通过拆分案例展示了如何将复杂用户故事转化为多个独立的可交付项，同时强调了良好的拆分方式可以降低开发风险并提升交付效率。希望该实践能为读者带来启发和思考。

PDCA循环——快速提升软件质量的必备工具

了解更多

想要了解更多内容？

查看原文：一次基于业务规则的用户故事拆分

文章来源：

Bruce Talk

扫码关注公众号