用户故事 用户故事入门

作者简介:

沃因:PMI敏捷实践指南翻译评论，scrum大师；PMI-ACP、Scrum Master、DevOps Professional、NPDP等课程讲师；持有高端商业认证和敏捷证书，如CBAP、PMI-PBA、德沃普斯硕士和CSP。

房地

用户故事是描述需求的一种方式，在各种敏捷方法中都很常见。

它彻底改变了需求的编写方式。过去，需求的编制大多来自于需求方通过各种手段(包括但不限于用户访谈、问卷调查、数据分析等)获取需求后准备的不同形式的文档。).

需求文档是需求者已经分析整理过的需求，具有一定的时效性和局限性。随着市场环境的变化，需求文档能否满足用户的需求就被打上了问号。

用户故事从用户的角度描述了用户的“最终目标”，但没有描述“如何实现目标”，这就为R&D团队预留了一些缓冲，让R&D团队在开发过程中可以根据现状分析现状，满足用户的“最终目标”。

在这个过程中，可以充分发挥团队的智慧，让团队分析“用户的最终目标”，给出不同的方式，用集体的智慧去完成需求。

什么是用户故事

用户故事是对用户有价值的功能的描述。通常，用户故事的格式如下:

作为:，我需要:，这样:

在上面的格式中，有三个因素:谁，什么，为什么。

Who 描述了最终使用该功能并获得价值的角色，它帮助我们明确了功能使用人的边界，从而将当前用户故事集中在一个固定的范围内容；What 描述了需要达到的效果。注意此时是效果，而不是解决方案。换言之，关注点是你最终的目的，而不是解决方案（途径）。最简单的区别就是 “快速找到你需要的商品”是目的，而“使用搜索”是解决方案；Why 描述了What的合理性，着眼点是价值，即What 背后的商业逻辑。或者换一个更加粗暴的说法，就是“给Who 所带来的收益”。

用户故事还有一个叫3C的原则，具体来说就是:

卡片，其中包含故事的文字描述

对话，包括需求细节

确认后，记录上述内容

从以上对用户故事的描述来看，目前我们至少知道用户故事至少具有以下特征:

有价值，对用户故事中Who 来说，这个用户故事必须有价值，用户将会因此有所收益。用户故事所带来的价值，用户必须可感知——这点极度重要，这近似将所有的技术细节从用户故事中剔除，让我们可以更关注需求本身。

史诗般的用户故事是什么

Epic在一些书籍或论坛中被视为用户故事类型。

但是我不同意用户故事里有特定类型的Epic。

Epic不是一个类型，只是一个标签。

用户故事就是用户故事，但是有些用户故事比较大。如果这个用户故事完成了，它会给用户一些容量，所以我们认为这个用户故事的标签是史诗，仅此而已。

而且这种认知直接让我对用户故事的一个INVEST原则有了一些其他的看法(我们下次再说)。

用户故事的细节在哪里

如果用户故事写在广告牌上，内容有限，讨论后肯定写不出各种细节(微雕师说我不服)，那么细节应该在哪里？

我的答案是:它需要存在于其他系统中。一般我们会存储在吉拉或者Trello，存储的内容一般是讨论的最终结果(团队和PO共同约定)。

最终结果由两部分组成:

讨论的细节，包括该用户故事涉及的流程、顺序、以及界面（UI）与交互（UX）等结果；验收标准。肯定会有人告诉你，我们将验收测试写在用户故事卡片背后，但实际上由于用户故事的粒度问题，是不能保证100%都能写下的。而且有些验收标准也比较复杂，用户验收测试包含内容太多，这都不适合写在卡片背后。

什么是验收测试

验收测试是用来验证实现的用户故事是否满足客户需求的测试用例。

在迭代开始的时候，当开发人员开始编码的时候，客户或者PO就准备接受产品了。帮助他们完成这个过程的工具是验收测试。

验收测试应尽快完成。这样做最大的好处是开发团队和客户可以尽早对功能开发做出相同的认知，避免开发人员对客户需求的误解，导致开发偏差，浪费工作量。

以下是为用户登录编写的验收测试:

用户可以使用正确的用户名、密码登录用户可使用手机验证码进行登录登录失败时，给用户错误提示

在这个过程中，如果你仔细一点，你可能会发现在验收测试中，我并没有描述“用户名和密码错误”、“验证码输入错误”、“微信扫码后没有授权”等场景。为什么？

在实际的验证过程中，验证的实施者是客户或PO，他们更关心的是“正确的路径”，即所谓的快乐路径，而他们无法穷尽其他错误信息，所以工作在一定程度上由R&D团队进行补充，使客户和PO能够专注于有价值的部分(非快乐路径一般不产生价值)。

写在最后

用户故事是敏捷开发中常见的形式，如何使用好它将直接影响敏捷实施的成功。所以在接下来的文章中，我们会从INVEST、用户角色建模、故事接受、故事收集、故事拆分等方面详细讲解与用户故事相关的内容，敬请期待。