1.什么是User Story？
定义： 一件用户通过系统完成他一个有价值的目标的事，这样的过程叫做“用户案列”或者“用户故事”。
理解：比如：一位市场经理告诉我们，用户往售货机每塞一个硬币，售货机都显示当前改客户已经投放了多少钱，当用户投的钱足够买一瓶饮料的时候，代表这款饮料的按钮的灯会亮起，如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零给用户
2.记录用户故事的格式为
名称：买饮料
事件：2.1、用户投了一些钱
2.2、售货机显示用户已经投了多少钱
2.3、用户如果投了足够的钱买某种饮料，改饮料对应的按钮就会亮起
2.4、用户按了某个按钮
2.5、售货机就会把改货物送到出口
2.6、售货机找零给用户
ps：一个用户故事里的事件描述可以为：
1.用户做了xxxx
2.系统做了xxxx
3.系统做了xxxx
。。。
2.核心元素
角色（Role）、活动（Activit）、商业价值（Business Value）
作为一个<角色>、我想要<活动> 、以便于<商业价值>
理解：作为一个“网站管理员”我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会带给他们什么收益”
ps：需要注意的是用户故事不能使用技术预研，要使用户可以理解业务语言来描述
Ron Jeffries的3个C
关于用户故事，Ron Jeffries用3个c来描述它：
卡片（Card）--用户故事一般记在卡片上，卡片上可能会写上故事的简短描述，工作量等
交谈（Conversation）--用户故事背后的细节来源于和客户或者产品负责人的交流沟通
确认（Confirmation）--通过验收测试确认用户故事被正确完成
3.用户故事的特性
一个好的用户故事应该遵循INVEST原则
独立性（Independent）：尽可能的一个用户的故事独立于其他用户故事，用户故事之间减少依赖，确定优先级，通过组合用户故事和分解用户估计来减少依赖性
可协商性（Negotiable）：一个用户用户故事的内容是可以协商的，用户故事不是合同，一个用户卡片上只对用户故事的一个简短的描述，不包括太多的细节，具体细节在沟通阶段产出，一个用户故事卡有太多的细节，实际上限制了和用户的沟通
有价值（Valuable）：每一个故事必须对客户具有价值（无论用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下他们，一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的，
可以估算性（Estimable）：一个开发团队需要去估计一个用户故事以便确定优先级、工作量、安排计划，但是让开发难以估计故事的问题来自：对于一个领域知识的缺乏（这个时候需要及时的沟通）或者故事太大，需要把故事拆分
短小（Small）：一个好的故事在工作量上尽量的短小，最好不要超过10个理想人／天的工作量，至少要确保的是在一个迭代或者sprint中能完成的，用户故事越大，在安排计划，工作量估算等方面的风险就会越大
可测试性（Testable）：一个用户故事是要可以测试的，以便于确认它是可以完成的，如果一个用户故事不能够被测试，那么你就无法知道它什么时候可以完成，一个不可侧视的永固故事例子：软件应该是易于使用的
