写点什么

玩一场用户故事的 Cosplay

用户头像
Bruce Talk
关注
发布于: 2020 年 10 月 24 日

我们如何确定团队成员对需求已经理解一致?每个人看到Design之后想法就能一致吗?我们一定需要等到Team把产品做完才能确定是否是客户想要的吗?基于用户故事卡片的讨论能够做到对齐理解吗?是否还有更具象化的办法帮助团队对齐呢?今天介绍一下我最近的一次团队实践——Cosplay原型游戏。

最近在我教练团队过程中,发现一个有趣的现象,当PO把需求和团队分享之后,开发会马上思考如何写code,QA会思考如何测试。大家认为看的是同一套设计图,听的是PO同一套需求描述,应该理解的都一样了。而事实却不太一样。我打印出设计的交互图(包括手绘图),和团队一起玩了一把角色扮演的原型游戏。团队成员一起根据自己的理解,按照不同的Role使用产品的场景不同,将Design图摆放一遍,看是否能走通。这个过程中引发一系列的讨论。大家会发现一些需求不完整的地方,理解不一致的地方,甚至是新的idea。





Bruce有话说

  • 单个Design图是静态的,角色扮演并将图按照使用场景拼接起来会更立体,让大家有代入感,快速达成一致的理解。

  • 用Design进行角色扮演是成本最低的快速原型验证方案。

  • 团队一起玩角色扮演,会有很多惊喜的发现。



游戏过程如下:

  1. 打印当次讨论涉及的Design图或者手绘图,总之所有讨论需要的可视化素材。

  2. 配合backlog或者用户故事地图拿出一个待讨论的story。

  3. 指定一个Role思考他如何使用软件的过程,并将操作时候的界面流程用图片按照从左到右的顺序拼接起来。 (Note:可替换的操作可以上下平行摆放。)

  4. 对于存在疑问的地方用便签写上问题并粘贴到对应素材上。如果发现缺少步骤用便签占位,并写上缺少部分名称。

  5. Team对当前场景的所有便签进行讨论,并用手绘图替换掉占位的便签。

  6. 拍照保留最后的讨论结论,并附带到对应backlog或用户故事条目内,方便后续回顾上下文。

  7. 回到第二部,重复下一个story的讨论。



有没有摩拳擦掌,想尝试一下:) ?

欢迎关注我的博客



发布于: 2020 年 10 月 24 日阅读数: 30
用户头像

Bruce Talk

关注

动机至善,私心了无。 2008.09.26 加入

一只程序猿,热爱新技术,痴迷于精益敏捷,现在北国春城工作。践行软件工艺,让工作因我而不同。个人博客:https://brucetalk.com

评论

发布
暂无评论
玩一场用户故事的Cosplay