用户故事

这到底在解决什么问题

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

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

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

• 不断收到无厘头的需求

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

• 排列功能的优先级

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

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

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

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

• 适合迭代开发

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

使用纸质卡片还是软件

使用软件的场景

• 团队远程办公

• 客户需要查看

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

客户代理

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

定义角色雏形

• 我

• 我的媳妇

• 我的朋友

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

• 无意间打开链接的人

整合与提炼角色

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

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

角色建模

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

• 使用软件的频率

• 该领域的专业性

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

• 对当前软件的熟练程度

• 使用软件的目的。

例如：

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

添加虚构人物

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

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

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

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

• 可讨论的

• 对用户有价值的

• 可估计的

• 小的

• 可测试的

用户故事卡是怎样的

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

例如：

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

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

背面：测试案例 test case

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

• 用有效的 Visa 卡测试

• 用过期的 Visa 卡测试

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

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

关于作者 🌱

我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊，或者关注我的个人公众号“大象工具”， 查看更多联系方式