用户故事
用户故事描述对用户，系统，软件购买者有价值的功能：
1 书面的故事描述，用来做计划与提示
2 故事的对话，具体细化故事细节
3 测试，用于表达和编档
例子：用户可以在网站行发布简历（史诗故事：故事很大）
细化:1.用户可以搜索职位 2.用户可以发布新职位 3.用户可以浏览 4.用户可以搜索
二级细化：
4.1 用户可以那些值？（省市县，职位，关键字？）
4.2 搜索参数可以保存？
4.3 搜索要显示的内容？
自我总结：用户故事是属于MVP模块，最小可闭环的功能。用户故事不等同用户画像，用户故事侧重表达要完成某一个最小完整功能。用户画像以虚拟，抽象化人物的集合
为什么要编写用户故事：每个故事需商业用于来写，而不是技术用语。用于优先级排列，放入迭代与发布
规划发布:故事需求池，根据故事点数（工期）规划
编写用户故事
编写用户故事特点：独立的，可讨论，有价值，可估计，小（最小MVP），可测试
小（最下MVP）：
史诗故事：复合故事和复杂故事。
史诗故事例子：用户可以发布他的简历：
1.简历包含教育信息，工作信息，出版物，个人情况，求职目标等 2.简历的标识状态:激活关闭...3.用户有多份简历 4.用户可以删除简历 5.用户可以修改简历
可测试：1 用户必须觉得软件好用，2 用户绝不需要花很长时间等待窗口出现；以上两点不可量化，需要具体的量化指标量化
用户角色建模
以求职发布简历为例，尽可能罗列角色：
求职者，初次找工作者，裁员受害者，工作地点搜索者，监视者，工作发布者，简历阅读者
a)然后合并整合重叠的角色，b)虚构人物（其实看了介绍就是用户画像 c)极端人物：边界值，安全等因素的考虑
用户故事不是用例：用例是对系统之间以及一个或者多个用户之间交互的一般性描述，用例可以编写为非结构化的文本，或者符合结构化的模板。故事与用例之间区别：他们的范围。两者之间都可以交付商业价值为目标，但故事的范围更小。（用例可以理解为测试用例）
用户故事不是场景：用户故事和场景区别主要在范围和细节：场景包含更多细节，涵盖多个故事.交互式设计场景比用户故事要具体，场景很具体的描述虚拟人物和系统使用的背景，而且，一个场景通常描述的范围比一个用户故事大
用户故事优势：易于沟通，易理解，mvp适合做计划和迭代
Scrum与用户故事
Scrum是迭代递增的软件过程：一轮迭代的过程是一种持续改进的过程，团队清楚一轮迭代不完善，二轮迭代支持更多功能，三轮迭代支持错误处理功能
实施Scrum过程30天为周期，成为Sprint。
每日Scrum简会：昨天/今天做什么。困难点？
其他非功能性需求
性能，准确性，移植性，重用性，维护性，安全，容量，易用
完整实例:
从零到一开发航海用品商城：
1 定义角色雏形，罗列所有的角色，整合和提炼所有角色，添加虚构人物（用户画像）。
2 枚举用户故事：
a)用户可以搜索商品名称
b)用户查看商品信息
c）用户可以加入购物车
d）增设送货地址，账单地址
e）对商品评价，评星评分
f）用户可以编辑的账号信息
g）用户可以查询历史订单
h）用户可以看到各种主题推荐（比如商品套餐活动）
i）管理员删除权限
j）管理员编辑信息
k）用户可以检查订单状态，对不同状态的操作，如增，删改等
l）系统必须支持并发用户
......
总结：什么是用户故事，如何编写用户故事
附录
（完）
网友评论