用户故事

更新日期: 2016-12-12 阅读次数: 5968 分类: 管理

这到底在解决什么问题

  • 每天猜测用户是否会喜欢

  • 每天开会重复讨论这个产品的意义

  • 不断有人告诉你,你不懂这部分用户的心理,你只需要照做

  • 不断收到无厘头的需求

  • 我们做到什么程度可以发布

  • 排列功能的优先级

相对需求文档、用例(use case) 有什么优势

  • 强调对话交流而不是书面沟通

  • 可以被所有人理解。而不单单是开发人员。没有技术术语。

  • 用户故事的大小适合做计划

  • 适合迭代开发

  • 鼓励推迟考虑细节,直到你非常了解真正的需求

使用纸质卡片还是软件

使用软件的场景

  • 团队远程办公

  • 客户需要查看

卡片可以随身带着,例如钱包里。

客户代理

如果团队成员都不是我们的受众用户,就需要找真实用户;如果条件不允许,可以找一名团队成员作为客户代理。例如,销售负责人。

定义角色雏形

  • 我的媳妇

  • 我的朋友

  • 寻找解决方案的技术人员

  • 无意间打开链接的人

整合与提炼角色

例如,我和我的媳妇有共同点。我们都有写文章的需求。

而我的媳妇和我的朋友也有共同点。即,都有看的需求。

角色建模

为角色添加详细描述。需要描述的点:

  • 使用软件的频率

  • 该领域的专业性

  • 对电脑和常用软件的熟练程度

  • 对当前软件的熟练程度

  • 使用软件的目的。

例如:

:每天都会记录笔记。草稿记录在为知笔记上,写完之后再同步到博客上。对 Markdown 相对熟练,不需要基本的提示。使用博客的目的是,整理知识、经验形成个人 Wiki。同时也做日记使用。

添加虚构人物

添加虚构人物的目的是,如果一个产品要成功,哪些人的需求是最需要满足的。

例如,针对寻找解决方案的技术人员,虚拟一个人物,王大海。他是一个刚毕业的学生,开发经验不足,需要了解代码管理工具 Git 的使用。不但是基本的使用,同时需要有经验的人为其推荐几本入门书籍。他有大量的业余时间进行自学。

一个优秀的用户故事应该具备的特点

  • 独立的。避免故事间的相互依赖。

  • 可讨论的

  • 对用户有价值的

  • 可估计的

  • 小的

  • 可测试的

用户故事卡是怎样的

正面:故事,如果需要,增加一两句的备注,不宜过长。

例如:

为了购买书,用户要输入他的账单地址、送货地址和信用卡信息。

备注: 接受 Visa 信用卡、万事达信用卡和美国运通卡,考虑支持发现卡。

背面:测试案例 test case

  • 输入账单地址,并指明与送货地址是相同的

  • 用有效的 Visa 卡测试

  • 用过期的 Visa 卡测试

  • 用完全无效的 Visa 卡号测试

注意:过多的细节需要转变成测试,而不是写在用户故事中。

关于作者 🌱

我是来自山东烟台的一名开发者,有敢兴趣的话题,或者软件开发需求,欢迎加微信 zhongwei 聊聊, 查看更多联系方式