什么是用户故事
用户故事（User Story）是用来对软件或用户有价值功能的简短描述，是对需求的一种描述。它清晰简洁的传达了用户想要的功能。
它从用户角度出发，用来描述用户的需求，用来表达用户需求的方式之一。
它从用户角度出发，解释了用户所期望得到的结果。用户故事清楚的解释了新功能给用户提供的价值，而不仅仅专注于功能。
它也是程序开发人员、产品经理、利益相关者关于需求交流的一种媒介。
用户故事三要素
用户故事是用来描述用户需求的一种方式，一份用户故事的组成要素有哪些？
它一般由 3 个要素组成：
- 角色（who）：谁使用。
- 活动（what）：要完成什么活动。系统提供了什么功能？
- 价值（value）：为什么这么做？提供了什么价值。给用户带来什么价值？产生什么商业价值？实现什么业务目标？
作为一个<角色>，我想要<完成活动>，以便<达到目的/实现价值>
用户故事包含哪些内容
上面是对用户故事包含要素的简短概述。在《敏捷软件开发：用户故事实战》一书中描述了一份用户故事需要包含 3 方面内容：
- 一份故事的书面描述。
- 有关故事的交谈，用于充实故事的细节。为了获取用户故事的细节，需要与相关人员沟通交谈来获取故事详细细节。
- 记录故事细节的测试，用来验证故事是否完成。
用卡片描述用户故事内容
用什么工具能快速、便捷，准确的描述和记录用户故事呢？答：卡片记录。
对于用户故事的描述，另外一个人荣恩 (Ron Jeffries) 用 3 个单词简明概括了上节里用户故事 3 方面内容，3 个英文单词如下：
- 卡片(Card)
- 交谈(Conversation)
- 确认(Confirmation)
卡片（Card）包含了用户故事的文字概括说明，需求的详细细节需要在交谈（Conversation）中获得，在确认（Confirmation）环节记录并加以验证。
卡片 Card
在卡片上写着用户故事的简短描述、规则和完成验收标准。
- 卡片正面写用户故事三要素描述，格式为：
作为一个<角色>，我想要<完成活动>，以便于<实现价值>。
例子：
作为操作后台的销售人员，我希望合并来自不同来源的销售数据，以便我可以方便的地分析销售数据并创建销售报告。
- 卡片下写用户故事的规则和完成验收标准，格式为：
Given...When...Then，给用户一个 xxx 功能，在 xxx 时候的 xxx 情况下使用，然后 xxx（成功/失败/错误）
举一个简单例子：
场景：用户凭手机号和验证码登录软件系统。
- Given：用户用手机号登录系统。
- When：当我在界面上输入手机号，然后点击获取验证码，输入验证码登录系统。
- Then：输入了正确的验证码，成功登录进系统。
（故事卡片）
故事卡片写着用户故事的简短描述、一些规则和完成验收标准。用户故事的详情、一些细节还需要与相关人员交谈获得。
用物理卡片展示，而不是假设的想法，有助于团队成员共同讨论需求。
交谈 Conversation
用户故事的细节来源是与用户/客户、产品利益相关者的沟通交流，与所有利益相关者对话交谈，并在对话基础上的理解，整理出需求。然后需要确保各方对用户故事的理解相一致。
这其实是怎么挖掘用户需求详情和细节的方法，与用户/客户交流对谈就是其中一种。
用户故事的第二个阶段，如何实现卡片上的要求以及了解需求的细节，需要与用户/客户、产品相关人员讨论、提问来获得。
确认 Confirmation
通过验收测试，来确认每个用户故事被正确的完成了。
验收测试格式举例：
一般是对操作业务规则的验证。比如验证用户登录系统功能：
1、在输入错误手机号的条件下，会出现 xxx 错误提示，结果登录失败。
2、在验证码输入超时情况下，会出现 xxx 提示，结果登录失败。
3、测试输入过期手机号码，会出现 xxx 提示，结果登录失败。
一些测试的方法：1、功能测试（单元测试）2、交互测试（集成测试）3、自动化测试（持续交付测试）4、性能测试（压力测试）
好故事的六个特征 INVEST
好故事的六个特征 INVEST，它由六个英文首字母组成：
-
独立的（Independent）：每个用户故事之间应该相互独立，尽量避免故事之间相互依赖。故事之间相互依赖会导致优先级排序和计划出现问题，也会使估算变得困难。
-
可协商的（Negotiable）：故事是可协商的，它不是软件必须实现的需求，只是对需求的简短描述，故事细节（需求细节）是在交谈沟通阶段产出的。
-
对用户或客户有价值的（Valuable to users or customers）：确保故事对用户或客户是有价值的，必须站在用户或客户角度来编写故事。这通常不容易做到但尽量去做到。
-
可估算的（Estimatable）：对于需要进行开发的 User Story（用户故事）大小进行估算，或将一个用户故事给到开发人员，用户故事的代码实现需要的工作量，多长时间开发完成进行评估。
-
小的（Small）：一个好的用户故事不能太大也不能太小。太大的故事叫史诗（Epic），史诗应该拆分为较小的故事。那怎么判断好故事大小呢？一个标准就是至少在一个迭代或 Sprint 中能够完成。故事太大，在工作量估算方面存在很大风险。
-
可测试的（Testable）：用户故事是小的具体的，且可以测试。故事太模糊的话，无法进行测试，那怎么验证？
怎么编写用户故事
怎么编写有效的用户故事，从哪里开始？
目标用户
为了编写有效用户故事，需要识别和定义产品的目标用户？谁会使用软件产品，他们怎么与软件进行交互？
明确用户需求
确定了使用产品的用户后，就要挖掘用户使用产品想要达成的目标。
也就是说用户使用产品想要得到什么、对产品的期望是什么，用户想要什么？
这一步是要挖掘用户的真正需求。
产品功能
明确了用户需求，就要思考产品可以提供什么样的功能？能满足用户需求。
这一步还有一个重要的步骤，竞品分析。
或者思考一个重要的问题：用户为什么选择我们，而不是竞争对手？
验收标准
团队开发完成交付产品，需要验收用户故事是否正在完成、适合标准。
每个用户故事可以列出几个验证标准。
参考
- 《用户故事与敏捷方法》https://book.douban.com/subject/4743056/ 作者: Mike Cohn