|1. 用户故事的故事

编辑导语：用户故事在软件开发过程中被作为描述需求的一种表达形式；为了规范用户故事的表达，便于沟通，包含角色、活动、价值三个要素；本文作者分享了关于用户故事的故事，解答一些用户故事最常见的问题，我们一起来看一下。

本文插图
一、开篇
我将给你讲述用户故事的故事，并回答一些用户故事最常见的问题；我们将谈论用户故事，从来源到实践，并学习一些技巧来帮助我们。
敏捷开发指南对用户故事只字未提，有一段时间我还在想去哪里找关于用户故事的可靠信息。
待办事项列表是否应该只由用户故事组成？如果不用 “作为用户，我想… ，以便…” 的模板，是不是就不是用户故事了？那么那些写着 “作为开发者…” 或者 “作为产品经理…” 等等的故事呢？
我的目的是对用户故事进行全新演绎，澄清一些围绕用户故事的误解，并为你指出那些对用户故事进行最好阐释的人。
二、基础篇
1. 用户故事的故事
我将解释用户故事的来源，因为这对我来说是理解用户故事和澄清误解的最好方法。
用户故事来自于90年代， Kent Beck在他的《Extreme Programming Applied》一书中开始讨论用户故事。
这个想法来自一个用户告诉他的一个关于新产品的故事：“我输入邮编，它就会自动填入城市和州，不需要我触碰按钮！”
如果你能讲述软件可以做什么的故事，并在听众心中产生动力、兴趣和愿景，那么为什么不在制作软件之前讲故事呢？Kent问自己，为什么不能在构建产品之前就产生这种对产品的愿景呢？关于谁会使用这个产品，它将做什么，以及为什么？我们应该通过对话来帮助我们思考问题。
《User Story Mapping》一书的作者Jeff Patton坚持认为：“故事的名字来自我们如何使用它们，而不是如何写它们。 ”
2. 模板
后来Connextra公司的Rachel Davis发明了我们今天使用的模板，它是这样的：“作为一个用户，我想… 以便…”
她试图帮助同事有条不紊地在小卡片上写故事，模板提醒我们最重要的三件事：谁要、要什么、为什么。
【|1. 用户故事的故事】站在用户的立场上，从他们的角度思考他们的需求，比如说：
作为一个手机用户，我想查看所在位置的天气预报，以便我不用每次去一个新地方都要查天气预报。
同样，你写在卡片上的内容应该只是一个起点，用以推动新想法的第一次对话。卡片的概念来自Ron Jeffries的3Cs：卡片，对话，确认。
你把你的想法写在一张卡片上，其实目前是写在一个软件跟踪工具中，或者是一张便利贴上，然后你和将建立它的人（开发团队）就它进行对话，然后你有一个确认；你把结果写在一个文档或者是跟踪工具中，这样你就可以很容易地回忆起对话，并且知道如何验证这个故事是否已经完成。
你可以在Mike Cohn的《User Stories Applied》一书中读到这一切， Mike Cohn是 “用户故事” 领域的伟大实践者和专家。
所以这就是我们如何从Kent Beck的故事中走来，并得出我们今天使用的用户故事。
在故事中加入 “用户” 这个词，有助于让我们的注意力集中到用户身上，这可以说明为什么 “作为开发者，我想要” 的模板只有在我们的最终用户是开发者的情况下才是准确的。
这就是用户故事的故事。
它是把讲故事引入到你的产品创作中，故事可以使用模板写下来，以确保我们不会错过任何重要的信息，但当然，这是可选的；最重要的是，产品负责人和将建立产品的开发团队，对他们想要实现的目标有一个共同的理解。分页标题
三、实践篇
1. Ron Jeffries的3Cs
Ron的3Cs：卡片、对话、确认；我们现在就通过这三件事来看看实践中创建用户故事的过程。
1）卡片
卡片的概念来自我们在前互联网时代用来寻找书籍的图书馆卡片，它们包含了作者、书名和简短的摘要。
Ron认为类似的卡片可以用来写一个软件系统新功能的简短摘要，卡片引发了对话，它可以包含 “作为用户，我想，以便…” 这样的模板，但最好给它一个简短的自我说明的标题。
以免出现类似这样的积压：

本文插图
积累的用户故事都是相同的标题…更何况，你有没有遇到过，在每天的工作中，有人用编号来指代用户故事，而不是标题呢？
这时候我们就知道，我们扼杀了这个故事，不是吗？这可能是因为标题太长，让人摸不着头脑（请看上图），我们可以通过添加一个简明扼要的标题来轻松解决。
对于我们基础篇的例子：作为一个手机用户，我想查看所在位置的天气预报，以便我不用每次去一个新地方都要查天气预报。
这个故事的标题可以是：当前位置查询天气预报。
2）对话
我们说过，上面的卡片可以作为产品负责人与开发团队对话的起点，以实现对将要构建什么的共同理解。
所以他们见面后会讲故事，讲谁会使用这个产品，他们想要什么，为什么；首先，把注意力放在最重要的事情上，后面再讨论实施细节。
首先我们为什么要构建它？想一想什么对你的业务影响最大，对用户的结果最好。
用户为什么需要它？而我们作为企业又为什么要让他们使用它？对我们有什么好处，商业价值是什么？
有了这些，你就可以建立最小可行产品（MVP），来检验什么产品在市场上是最小的、有用的。
如果你心中有一个伟大的想法，你可以把目标、伟大的想法与团队分享，并协同为它想出故事。
这些都可以在用户故事地图工作坊中完成，因为这是一个让整个团队参与产品创作的好方法；对于较小的想法，在对话之后，我们进入第3步。
3）确认
确认的作用是记录谈话过程中发现的问题，并商定如何验证它的有效性；例如，在故事中加入验收标准。
2. INVEST
我们如何确保我们的故事已经具备进入下一个冲刺的条件？
让我们看一个简单的技巧，它将确保我们的故事已经准备好了。
它叫INVEST ，是一个缩写，它定义了一个伟大故事的6个特征：

I – 独立
N – 协商
V – 价值
E – 估算
S – 小型
T – 测试

让我们看看另一个用户故事的例子，检查它是否符合这些特征：
作为一个彩民，我想在网站上输入我的彩票号码，以便检查我是否中奖以及中了多少钱。
1）独立
意味着它可以独立完成 – 没有阻塞依赖性；例如，我们不需要登录系统来验证我们的号码是否中奖，这意味着它可以与我们已经在系统中的内容分开独立工作。
2）协商
用户故事中的内容并不是固定的，它是活的文档；当我们在开发过程中发现更多的东西时，它可能会改变，然后开发团队会和产品负责人协商。
3）价值
意味着为用户提供价值。因此是 “作为用户我想要” ，而不是 “作为产品负责人我想要” 或者 “作为开发者我想要”；除非你是为产品负责人和开发者构建工具。
为了让它变得有价值，我们要把故事想象成一个蛋糕，你想要切开蛋糕，尝到所有层的味道，而不仅仅是鲜奶油；软件开发也是一样，你要让用户品尝到所有平台的味道，而不仅仅是后端或前端。分页标题
我们不会给用户看一个假的按钮，说 “检查你是否中奖！” 如果背后没有逻辑，这个按钮没有用。
我们需要问自己：我们如何为客户提供价值就能在我们的故事完成后直接让他们使用新功能？
4）估算
通常越小越容易估算，越可测试越容易估算。为什么要估算？
如果我们能估算一个故事，就说明我们对它有足够的了解，它是可行的，我们不知道的事情就不去估算；如果我们不能估算我们的故事，它肯定需要更多的讨论，更多的细节，或者更多的研究。
5）小型
在敏捷开发中，它意味着适合一个冲刺，甚至更少；故事越小，越容易把握故事的内容，小的特征与有价值的特征关系非常密切。
如果你想把故事切成多个小故事，你需要确保所有的故事都能为用户提供价值；就像一块蛋糕，你在生日派对上为你的客人提供服务 – 所有的蛋糕都有所有层的味道，这就像我们的软件平台。
现在，想象一下，我们的彩票故事不适合在一次冲刺中完成。
我们可以做什么？也许可以分成2个小的故事，每个小的故事都可以为我们的用户提供价值。
第1个故事会检查是否中奖：作为一个彩民，我想在网站上输入我的彩票号码，以便检查我是否中奖。
标题可以是：彩民可以查询自己是否中奖。
第2个故事会查询中了多少钱，前提条件是有中奖号码：作为一个有中奖号码的彩民，我想在网站上输入我的彩票号码，以便查询我中了多少钱。
标题可以是：彩民可以查询自己中奖号码的奖金数额。
这样我们就可以在第1个故事完成后，更快地为用户提供价值；而且我们可以更快地了解有多少用户对使用新功能感兴趣。
6）测试
如果我们知道如何测试它，我们就会知道它何时完成。一个常见的做法是在故事中添加验收标准；这些都是一些用例，可以确定软件做的是它要做的事情。
验收标准提供了功能场景，测试部分包括检查边缘用例、“悲伤路径” 场景、非功能测试（如性能）等。
每个故事都有一些具体的验收标准来帮助团队把握新功能需要实现的目标；然后，是团队一致同意的完成标准，它规定了每个用户故事在上线前需要满足的一些通用标准。
我们先给彩票例子中的第1个故事添加一些验收标准：
作为一个彩民，我想在网站上输入我的彩票号码，以便检查我是否中奖。
验收标准可以是：

如果这个号码是中奖号码，用户应该看到一条信息：“今天是你的幸运日，你中奖了！”
如果该号码不是中奖号码，用户应该看到一条消息：“再试一次，我打赌下次你一定会赢！”

对于第2个故事：作为一个有中奖号码的彩民，我想在网站上输入我的彩票号码，以便查询我中了多少钱。
验收标准如下：

如果用户中奖了，中奖金额应该以货币格式显示。
用户只能查询过去30天的中奖号码等。

给定/当/然后是一种Gherkin语言格式，用于编写验收标准和自动化测试，它来源于行为驱动开发（BDD），例如：给定用户一个中奖号码，当用户在网站上输入该号码，然后中奖金额就会以货币格式显示。
如果你运行了一个带有自动测试的工具，比如Cucumber ，那就特别有用；同样，就像用户故事模板一样，这种格式是可选的。
完成标准：如果我们的彩票页面要求适配手机，并且有三种语言版本，这些通用要求可以作为我们完成标准的一部分。
四、总结篇
用户故事是为了鼓励团队内关于产品的对话，这些对话集中在三个最重要的事情上：谁会使用产品，他们会用它做什么，以及为什么。
拆分用户故事可能很复杂，但不用担心，你可以通过实践掌握它，有很多技巧也可以帮助你。分页标题
原文链接：
https://uxdesign.cc/the-story-of-user-stories-part-1-e1c8e4995f7f
https://uxdesign.cc/user-stories-in-practice-part-2-8b731566f8ca
原文作者：Maria Chec
译者：产品侠，服务设计硕士在读，产品经理实习生，英语爱好者；微信公众号：产品侠
本文由 @产品侠翻译发布于人人都是产品经理。未经许可，禁止转载
题图来自 unsplash ，基于 CC0 协议