什么是用户故事

# 一、 什么是用户故事？

## 一、用户故事的概念

概念这种东西我喜欢说文解字的方式去理解和阐述；用户故事=用户+故事=人+故+事，那就是一个人因为什么原因要做什么事，提炼出来三要素就是who、why、what。从需求角度描述就是一个用来确认用户和用户需求的简短描述。

## 二、用户故事的三要素

用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。

一个完整的用户故事包含三个要素：

1. 角色（who）：谁要使用这个
2. 活动（what）：要完成什么活动
3. 价值（value）：为什么要这么做，这么做能带来什么价值

## 三、3C原则

用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。

（1）卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。


卡片的正面书写故事的描述，格式为：作为一个<角色>, 我想要<完成活动>, 以便于<实现价值>描述需求；卡片背面书写完成用户故事的规则和完成标准，格式为：Given…When…Then。

（2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通；确保各方对故事的理解正确。


（3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。

## 四、INVEST原则

好的用户故事除了格式规范，要素完整外，还应该遵循INVEST原则：Idependent（独立的）；Negotiable（可协商的）；Valuable（有价值的）；Estimatable（可评估）；Small（小的）；Testable（可测试的）。


### 1. Idependent（独立的）

要尽可能的让一个用户故事独立于其他的用户故事。用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大小估算所涉及的范围更清晰，从而估算偏差更小。

### 2. Negotiable（可协商的）

一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事只是对用户故事的一个简短的描述，不包括太多的细节；具体的细节在沟通阶段产出。一个用户故事带有了太多的细节，实际上限制了用户、团队的想法和沟通。

### 3. Valuable（有价值的）

每个故事必须对客户具有价值（无论是用户、购买方还是公司内部角色）。用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。

这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作价值。

### 4. Estimatable（可评估）

计划会议里面一个很重要的环节，那就是故事点的估计。实际上就是对要开发的User Story进行一个粗量级的估算，以便于团队能够知道这个user story的复杂度（工作量）。

重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD(完