什么是用户故事？
用户故事（user story）是一个用来确认用户和用户需求的简短描述，用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
- 角色：谁要使用这个功能。
- 活动：需要完成什么样的功能。
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：As a , I want to , so that .
中文：作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
一、用户故事的3C原则
- 卡片（Card）– 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
- 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
- 确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
用户故事的3C原则由Ron Jeffries在2001年提出，直到今天仍被奉为用户故事的基本原则。
1、卡片： 用户故事描述的传统形式是手工书写的用户故事卡，卡片上应该只有几句话来捕获需求的精髓或目的。
后来产品经理们通过写需求设计文档或者规格说明书，通过一个非常完整的word文档将某一个产品的需求定义出来。由于产品需求文档涉及到的内容从项目到实现效果，非常庞大，以至于后来的项目管理中出现了摒弃繁杂的需求文档的做法，或将需求文档仅作为一个参考标准。如知名项目管理软件 禅道提倡将需求文档中的需求点摘出来，录在禅道的【需求描述】里面，作为一个个独立的功能点。这其实跟卡片作用是一致的，用简洁凝练的语言，完整呈现用户故事的三要素。
2、交谈： 交谈（会话）指的是卡片上所记录的用户故事是可以进行讨论和细化的，它包括利益相关人（客户/用户）、产品负责人及开发团队之间进行更细化地讨论用户故事的可行性。用户故事经过会话确认后，才能正式进入开发阶段（用户故事实现）。敏捷开发的流程完整体现了用户故事（需求）的流转过程。
以敏捷开发中的Scrum为例：
scrum的基本流程如上图所示：
- 产品负责人负责整理user story，形成左侧的product backlog。 ——用户故事整理
- 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。 ——用户故事确认
- 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，终每个任务都有明确的负责人，并完成工时的初估计。——用户故事分解
- 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。 ——用户故事实现
- 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。 ——用户故事的二次整理
敏捷开发中用户故事的细化为开发提供了可执行标准，敏捷开发的特点是快速迭代，一个用户故事的大小和复杂度应该在一个迭代中开发完毕为宜。如果用户故事太大，可能会导致对它的开发横跨几个迭代。此时就应该将这个用户故事分解。每个任务的时间最好不要超过8小时，就是要保证1个工作日内完成，如果做计划时发现有些任务的时间超过了8小时，就说明任务的划分有问题，需要进行子任务的分解。
3、确认：用户故事确认可以理解为对用户故事是否达到验收标准的检测。用户故事需要一系列的验收测试用以保证故事功能的完成及软件按照我们的预期运行。同时要保证这个用户故事最后实现是可以带来商业价值的。
用户故事的确认由测试人员完成。测试人员在测试版本所关联的用例列表里执行用例，完成测试，然后生成测试报告。测试报告是对用户故事实现程度的最直接体现。
如果一个用例执行失败，可以直接由这个测试用例创建一个Bug，由开发人员进行二次开发和修复，直到测试通过。
二、用户故事的六个特性- INVEST
INVEST= Independent, Negotiable, Valuable, Estimable, Small, Testable
写好用户故事除了要以3C原则为基础，同时需要考虑到用户故事需要具备的六个特征（也叫INVEST原则）。
1、独立性（Independent）
要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
2、可协商性（Negotiable）
一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
3、有价值（Valuable）
每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
4、可以估算性（Estimable）
开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
5、短小（Small）
一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
6、可测试性（Testable）
一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
三、确定用户故事优先级的几种方法
1、相对优先级=价值/工作量
估算每个故事的价值和工作量，计算相对优先级。
2、莫斯科（MoSCoW）规则
- 必须有（Must have）：基本功能
- 应该有（Should have）：很重要但是短期内有替代方案的功能，如果没有时间约束，此类功能是强制性的
- 可以有（Could have）：没有时间就可以在发布中不予考虑的功能
- 这次不会有（Won't have this time）
3、卡诺Kano模型：
有时候基础型需求部分实现就可以了，尽可能多的完成期望型需求，确定少量兴奋型需求。
- 基础型需求
- 期望型需求
- 兴奋型需求
4、风险-价值指标：确定优先级时同时考虑风险和价值，箭头显示的是正确的优先级顺序。
高价值高风险的功能可以提供高价值，而且对它们的处理可以消除显著的风险。确定好优先级的用户故事集合组成了产品代办列表（backlog），根据backlog估算故事规模并确定最终的发布计划。