一次用户故事拆分分享

正文

最近连续翻译了几篇用户故事拆分方法的文章。总想找个机会尝试一下，本周在参加一个团队的计划会的时候被一个用户故事的拆分吸引了。今天拿来分享一下当时团队是如何拆分，以及我自己的思考——如果是我将如何拆分。作为一个对比。希望这次分享的实际例子对你在工作中用户故事拆分能有帮助。你如果有更好的拆分方法也欢迎一起交流。

用户故事

“当老师需要发布网课给学生的时候，系统可以结合 Zoom，给老师和学生提供流畅的在线课程体验。这样就不需要受限于地理位置以及其他情况，随时随地提供高质量培训服务。”

团队拆分的版本

1. 第一次迭代中先实现 Zoom App 的配置页面。（系统和 Zoom 集成的配置信息的设置和保存）

2. 第二次迭代实现 Zoom 和系统集成的全部功能。

之所以这么拆分的原因是，第一次迭代还会做其他一些 User Story，而完成 Zoom 集成的功能很多，团队觉得无法在一次迭代做完，所以拆分成两个迭代中完成。先做一个简单的配置页面，但是无法真的和 Zoom 集成，第二次迭代才完成和 Zoom 的全部集成。只有两次迭代之后才能给客户使用 Zoom 集成功能。

我拆的版本

1. 第一次迭代，支持系统中的课程和 Zoom 会议的手动关联。

   
   

   AC：学生收到课程通知 Email 中带有 Zoom 的会议 Link。可以点击直接加入课程。学生在 Portal 的个人日历中找到对应的课程，并能够点击 Zoom 的 Link 参加在线课程。

2. 第二次迭代，支持系统中课程和 Zoom 会议自动关联

   
   

   AC：在课程创建的同时，如果是网课类型，自动创建对应的 Zoom 会议。给学生发送的邮件和学生自己的日历中对应课程自动关联 Zoom 会议链接。

   Note：为了实现这两个 AC，实际上需要实现 Zoom 系统的集成配置信息的设置和保存功能。也就是团队拆分中的第一个任务。

我的拆分思路：

1. 从 INVEST 的原则入手，故事要足够小，同时可测。可测的一个原则就是对用户使用是有价值的。也就是从业务上是垂直切片的(下面有垂直切片的说明文章，感兴趣的可以了解一下)。Zoom 是一个第三方视频会议软件。他可以独立操作，而系统和他集成主要是考虑使用系统的用户能够无缝的使用 Zoom，享受到网课的便利。所以从这个角度出发，如何让用户在使用的时候方便找到课程对应的 Zoom 入口就是一个有价值的业务切片范围。而最简单的实现方式就是在课程通知和日历中加入对应 Zoom 的链接。

2. Zoom 是第三方系统，如果需要让创建课程的老师在系统中就能创建 Zoom 会议，无需在系统和 Zoom 间切换，那就是更方便了。所以要实现这个 Nice to have 的功能，需要使用 Zoom API 来做系统集成。

3. 在系统中可以配置集成 Zoom App 的信息等一系列设置。系统集成 Zoom，通过 API 自动设定课程和 Zoom 会议的关联，并获得对应的课程 Link。 按照这个思路来拆分用户故事，每一个都是相对独立的，可测的，工作量足够小，同时对客户来说是有价值的。对应用户故事拆分全景图中模式 7：简单/复杂模式。先拆分出简单的业务逻辑，之后再补充 Nice to have 的复杂逻辑。

推荐相关文章

用户故事是垂直的切片(译)

用户故事拆分招数全景图(译)

五种就按单搞笑的拆分用户故事的方法

【欢迎关注我的博客】