敏捷开发：用户故事介绍

什么是用户故事

用户故事（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