正文
最近连续翻译了几篇用户故事拆分方法的文章。总想找个机会尝试一下，本周在参加一个团队的计划会的时候被一个用户故事的拆分吸引了。今天拿来分享一下当时团队是如何拆分，以及我自己的思考——如果是我将如何拆分。作为一个对比。希望这次分享的实际例子对你在工作中用户故事拆分能有帮助。你如果有更好的拆分方法也欢迎一起交流。
用户故事
"当老师需要发布网课给学生的时候，系统可以结合Zoom，给老师和学生提供流畅的在线课程体验。这样就不需要受限于地理位置以及其他情况，随时随地提供高质量培训服务。"
团队拆分的版本
- 第一次迭代中先实现Zoom App的配置页面。（系统和Zoom集成的配置信息的设置和保存）
- 第二次迭代实现Zoom和系统集成的全部功能。
之所以这么拆分的原因是，第一次迭代还会做其他一些User Story，而完成Zoom集成的功能很多，团队觉得无法在一次迭代做完，所以拆分成两个迭代中完成。先做一个简单的配置页面，但是无法真的和Zoom集成，第二次迭代才完成和Zoom的全部集成。只有两次迭代之后才能给客户使用Zoom集成功能。
我拆的版本
-
第一次迭代，支持系统中的课程和Zoom会议的手动关联。
AC：- 学生收到课程通知Email中带有Zoom的会议Link。可以点击直接加入课程。
- 学生在Portal的个人日历中找到对应的课程，并能够点击Zoom的Link参加在线课程。
-
第二次迭代，支持系统中课程和Zoom会议自动关联
AC：- 在课程创建的同时，如果是网课类型，自动创建对应的Zoom会议。
- 给学生发送的邮件和学生自己的日历中对应课程自动关联Zoom会议链接。
Note：为了实现这两个AC，实际上需要实现Zoom系统的集成配置信息的设置和保存功能。也就是团队拆分中的第一个任务。
我的拆分思路：
- 从INVEST的原则入手，故事要足够小，同时可测。可测的一个原则就是对用户使用是有价值的。也就是从业务上是垂直切片的(下面有垂直切片的说明文章，感兴趣的可以了解一下)。Zoom是一个第三方视频会议软件。他可以独立操作，而系统和他集成主要是考虑使用系统的用户能够无缝的使用Zoom，享受到网课的便利。所以从这个角度出发，如何让用户在使用的时候方便找到课程对应的Zoom入口就是一个有价值的业务切片范围。而最简单的实现方式就是在课程通知和日历中加入对应Zoom的链接。
- Zoom是第三方系统，如果需要让创建课程的老师在系统中就能创建Zoom会议，无需在系统和Zoom间切换，那就是更方便了。所以要实现这个Nice to have的功能，需要使用Zoom API来做系统集成。
- 在系统中可以配置集成Zoom App的信息等一系列设置。系统集成Zoom，通过API自动设定课程和Zoom会议的关联，并获得对应的课程Link。
按照这个思路来拆分用户故事，每一个都是相对独立的，可测的，工作量足够小，同时对客户来说是有价值的。对应用户故事拆分全景图中模式7：简单/复杂模式。先拆分出简单的业务逻辑，之后再补充Nice to have的复杂逻辑。
