一、开篇

我将给你讲述用户故事的故事，并回答一些用户故事最常见的问题；我们将谈论用户故事，从来源到实践，并学习一些技巧来帮助我们。

敏捷开发指南对用户故事只字未提，有一段时间我还在想去哪里找关于用户故事的可靠信息。

待办事项列表是否应该只由用户故事组成？如果不用 “作为用户，我想…，以便…” 的模板，是不是就不是用户故事了？那么那些写着 “作为开发者…” 或者 “作为产品经理…” 等等的故事呢？

我的目的是对用户故事进行全新演绎，澄清一些围绕用户故事的误解，并为你指出那些对用户故事进行最好阐释的人。

二、基础篇

我将解释用户故事的来源，因为这对我来说是理解用户故事和澄清误解的最好方法。

用户故事来自于90年代，Kent Beck在他的《Extreme Programming Applied》一书中开始讨论用户故事。

这个想法来自一个用户告诉他的一个关于新产品的故事：“我输入邮编，它就会自动填入城市和州，不需要我触碰按钮！”

如果你能讲述软件可以做什么的故事，并在听众心中产生动力、兴趣和愿景，那么为什么不在制作软件之前讲故事呢？Kent问自己，为什么不能在构建产品之前就产生这种对产品的愿景呢？关于谁会使用这个产品，它将做什么，以及为什么？我们应该通过对话来帮助我们思考问题。

《User Story Mapping》一书的作者Jeff Patton坚持认为：“故事的名字来自我们如何使用它们，而不是如何写它们。”

后来Connextra公司的Rachel Davis发明了我们今天使用的模板，它是这样的：“作为一个用户，我想… 以便…”

她试图帮助同事有条不紊地在小卡片上写故事，模板提醒我们最重要的三件事：谁要、要什么、为什么。

站在用户的立场上，从他们的角度思考他们的需求，比如说：

作为一个手机用户，我想查看所在位置的天气预报，以便我不用每次去一个新地方都要查天气预报。

同样，你写在卡片上的内容应该只是一个起点，用以推动新想法的第一次对话。卡片的概念来自Ron Jeffries的3Cs：卡片，对话，确认。

你把你的想法写在一张卡片上，其实目前是写在一个软件跟踪工具中，或者是一张便利贴上，然后你和将建立它的人（开发团队）就它进行对话，然后你有一个确认；你把结果写在一个文档或者是跟踪工具中，这样你就可以很容易地回忆起对话，并且知道如何验证这个故事是否已经完成。

你可以在Mike Cohn的《User Stories Applied》一书中读到这一切，Mike Cohn是 “用户故事” 领域的伟大实践者和专家。

所以这就是我们如何从Kent Beck的故事中走来，并得出我们今天使用的用户故事。

在故事中加入 “用户” 这个词，有助于让我们的注意力集中到用户身上，这可以说明为什么 “作为开发者，我想要” 的模板只有在我们的最终用户是开发者的情况下才是准确的。

这就是用户故事的故事。

它是把讲故事引入到你的产品创作中，故事可以使用模板写下来，以确保我们不会错过任何重要的信息，但当然，这是可选的；最重要的是，产品负责人和将建立产品的开发团队，对他们想要实现的目标有一个共同的理解。

三、实践篇

Ron的3Cs：卡片、对话、确认；我们现在就通过这三件事来看看实践中创建用户故事的过程。

1）卡片

卡片的概念来自我们在前互联网时代用来寻找书籍的图书馆卡片，它们包含了作者、书名和简短的摘要。

Ron认为类似的卡片可以用来写一个软件系统新功能的简短摘要，卡片引发了对话，它可以包含 “作为用户，我想，以便…” 这样的模板，但最好给它一个简短的自我说明的标题。

以免出现类似这样的积压：

积累的用户故事都是相同的标题…更何况，你有没有遇到过，在每天的工作中，有人用编号来指代用户故事，而不是标题呢？

这时候我们就知道，我们扼杀了这个故事，不是吗？这可能是因为标题太长，让人摸不着头脑（请看上图），我们可以通过添加一个简明扼要的标题来轻松解决。

文章来源：《商业故事》 网址: http://www.sygszzs.cn/zonghexinwen/2020/1011/736.html