这到底在解决什么问题
-
每天猜测用户是否会喜欢
-
每天开会重复讨论这个产品的意义
-
不断有人告诉你，你不懂这部分用户的心理，你只需要照做
-
不断收到无厘头的需求
-
我们做到什么程度可以发布
-
排列功能的优先级
相对需求文档、用例(use case) 有什么优势
-
强调对话交流而不是书面沟通
-
可以被所有人理解。而不单单是开发人员。没有技术术语。
-
用户故事的大小适合做计划
-
适合迭代开发
-
鼓励推迟考虑细节，直到你非常了解真正的需求
使用纸质卡片还是软件
使用软件的场景
-
团队远程办公
-
客户需要查看
卡片可以随身带着，例如钱包里。
客户代理
如果团队成员都不是我们的受众用户，就需要找真实用户；如果条件不允许，可以找一名团队成员作为客户代理。例如，销售负责人。
定义角色雏形
-
我
-
我的媳妇
-
我的朋友
-
寻找解决方案的技术人员
-
无意间打开链接的人
整合与提炼角色
例如，我和我的媳妇有共同点。我们都有写文章的需求。
而我的媳妇和我的朋友也有共同点。即，都有看的需求。
角色建模
为角色添加详细描述。需要描述的点：
-
使用软件的频率
-
该领域的专业性
-
对电脑和常用软件的熟练程度
-
对当前软件的熟练程度
-
使用软件的目的。
例如：
我：每天都会记录笔记。草稿记录在为知笔记上，写完之后再同步到博客上。对 Markdown 相对熟练，不需要基本的提示。使用博客的目的是，整理知识、经验形成个人 Wiki。同时也做日记使用。
添加虚构人物
添加虚构人物的目的是，如果一个产品要成功，哪些人的需求是最需要满足的。
例如，针对寻找解决方案的技术人员，虚拟一个人物，王大海。他是一个刚毕业的学生，开发经验不足，需要了解代码管理工具 Git 的使用。不但是基本的使用，同时需要有经验的人为其推荐几本入门书籍。他有大量的业余时间进行自学。
一个优秀的用户故事应该具备的特点
-
独立的。避免故事间的相互依赖。
-
可讨论的
-
对用户有价值的
-
可估计的
-
小的
-
可测试的
用户故事卡是怎样的
正面：故事，如果需要，增加一两句的备注，不宜过长。
例如：
为了购买书，用户要输入他的账单地址、送货地址和信用卡信息。
备注： 接受 Visa 信用卡、万事达信用卡和美国运通卡，考虑支持发现卡。
背面：测试案例 test case
-
输入账单地址，并指明与送货地址是相同的
-
用有效的 Visa 卡测试
-
用过期的 Visa 卡测试
-
用完全无效的 Visa 卡号测试
注意：过多的细节需要转变成测试，而不是写在用户故事中。
微信关注我哦 👍
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊， 查看更多联系方式