我们如何确定团队成员对需求已经理解一致？每个人看到Design之后想法就能一致吗？我们一定需要等到Team把产品做完才能确定是否是客户想要的吗？基于用户故事卡片的讨论能够做到对齐理解吗？是否还有更具象化的办法帮助团队对齐呢？今天介绍一下我最近的一次团队实践——Cosplay原型游戏。
最近在我教练团队过程中，发现一个有趣的现象，当PO把需求和团队分享之后，开发会马上思考如何写code，QA会思考如何测试。大家认为看的是同一套设计图，听的是PO同一套需求描述，应该理解的都一样了。而事实却不太一样。我打印出设计的交互图(包括手绘图)，和团队一起玩了一把角色扮演的原型游戏。团队成员一起根据自己的理解，按照不同的Role使用产品的场景不同，将Design图摆放一遍，看是否能走通。这个过程中引发一系列的讨论。大家会发现一些需求不完整的地方，理解不一致的地方，甚至是新的idea。
gothrough_story.jpg
Bruce有话说
- 单个Design图是静态的，角色扮演并将图按照使用场景拼接起来会更立体，让大家有代入感，快速达成一致的理解。
- 用Design进行角色扮演是成本最低的快速原型验证方案。
- 团队一起玩角色扮演，会有很多惊喜的发现。
游戏过程如下：
- 打印当次讨论涉及的Design图或者手绘图，总之所有讨论需要的可视化素材。
- 配合backlog或者用户故事地图拿出一个待讨论的story。
- 指定一个Role思考他如何使用软件的过程，并将操作时候的界面流程用图片按照从左到右的顺序拼接起来。
(Note：可替换的操作可以上下平行摆放。) - 对于存在疑问的地方用便签写上问题并粘贴到对应素材上。如果发现缺少步骤用便签占位，并写上缺少部分名称。
- Team对当前场景的所有便签进行讨论，并用手绘图替换掉占位的便签。
- 拍照保留最后的讨论结论，并附带到对应backlog或用户故事条目内，方便后续回顾上下文。
- 回到第二部，重复下一个story的讨论。
有没有摩拳擦掌，想尝试一下:) ？
【欢迎关注我的个人博客】
