专业的短链接生成工具
链接域名
短网址有效期
用户故事的故事
更新时间：2025-6-3 01:20:01 作者：爱短链
编者按：用户故事被用作软件开发过程中描述需求的表达；为了规范用户故事的表达，包括角色、活动和价值；作者分享了用户故事，回答了用户故事中最常见的问题。
让我们一起看看。
一、开篇 我会给你讲用户故事，回答用户故事中最常见的问题；我们将讨论用户故事，从来源到实践，并学习一些技能来帮助我们。
敏捷开发指南没有提到用户故事。
有一段时间，我还在想在哪里找到关于用户故事的可靠信息。
待办事项列表是否应由用户故事组成吗？如果没有必要 作为用户，我想…，以便…” 模板不是用户故事吗？所以那些写的 作为开发者…” 或者 作为产品经理…” 等等的故事呢？ 我的目的是对用户故事进行新的诠释，澄清一些围绕用户故事的误解，并指出那些最好地解释用户故事的人。
二、基础篇 1. 用户故事的故事 我将解释用户故事的来源，因为这是理解用户故事和澄清误解的最好方法。
90年代的用户故事，Kent Beck在他的《Extreme Programming Applied》一本书开始讨论用户故事。
这个想法来自一个用户告诉他的一个关于新产品的故事:如果我输入邮编，它会自动填市和州，不需要我触摸按钮！ 如果你能讲述软件能做什么的故事，并在观众心中产生动力、兴趣和愿景，为什么不在制作软件之前讲故事呢？Kent问问自己，为什么在构建产品之前不能有这种产品愿景？谁会使用这个产品，它会做什么，为什么？我们应该通过对话来帮助我们思考问题。
《User Story Mapping》一书的作者Jeff Patton故事的名字来自于我们如何使用它们，而不是如何写它们。
2. 模板 后来Connextra公司的Rachel Davis发明了我们今天使用的模板：作为一个用户，我想… 以便…” 她试图帮助同事有序地在小卡片上写故事，模板提醒我们三件最重要的事情：谁想要，想要什么，为什么。
从用户的角度思考他们的需求，比如: 作为一个手机用户，我想检查位置的天气预报，这样我就不必每次去新地方都检查天气预报。
同样，你在卡片上写的应该只是第一次促进新想法对话的起点。
卡片的概念来自Ron Jeffries的3Cs：卡片、对话、确认。
你把你的想法写在一张卡片上，实际上是写在一个软件跟踪工具或一个方便的帖子上，然后你和那些将建立它的人（开发团队）交谈，然后你有一个确认；你把结果写在文档或跟踪工具上，这样你就可以很容易地回忆对话，并知道如何验证故事是否已经完成。
你可以在Mike Cohn的《User Stories Applied》一本书读到了这一切，Mike Cohn是 用户故事 伟大的实践者和领域专家。
所以这就是我们如何从我们那里开始Kent Beck在故事中，我们得到了今天用户的故事。
加入故事 “用户” 这个词有助于关注用户，这可以解释为什么 作为开发者，我想要 只有当我们的最终用户是开发者时，模板才是准确的。
这是用户故事的故事。
它将讲故事介绍到你的产品创作中。
故事可以用模板写下来，以确保我们不会错过任何重要的信息，但当然，这是可选的；最重要的是，产品负责人和开发团队将建立产品，并对他们想要实现的目标有一个共同的理解。
三、实践篇 1. Ron Jeffries的3Cs Ron的3Cs：卡片、对话、确认；让我们来看看在实践中创建用户故事的过程。
1）卡片 卡片的概念来自于我们在前互联网时代用来寻找书籍的图书馆卡片，包括作者、标题和简短的摘要。
Ron认为类似的卡片可以用来写软件系统新功能的简短摘要，它可以包含 作为用户，我想，为了…” 这样的模板，但最好给它一个简短的自我解释标题。
避免类似的积压： 用户故事的积累是相同的标题…更何况你有没有遇到过，在日常工作中，有人用编号来指代用户故事，而不是标题？ 在这个时候，我们知道我们扼杀了这个故事，不是吗？这可能是因为标题太长，令人困惑（见上图），我们可以很容易地添加一个简洁的标题。
对于我们的基本文章的例子：作为一个手机用户，我想检查我所在位置的天气预报，这样我就不必每次去新地方都检查天气预报。
这个故事的标题可以是:查询当前位置的天气预报。
2）对话 正如我们所说，上述卡片可以作为产品负责人与开发团队对话的起点，以实现对将要构建什么的共同理解。
所以他们会讲故事，讲谁会用这个产品，他们想要什么，为什么；首先，关注最重要的事情，然后讨论实施细节。
首先，我们为什么要建立它？想想什么对你的业务影响最大，对用户的结果最好。
为什么用户需要它？作为企业，我们为什么要让他们使用它？对我们有什么好处，商业价值是什么？ 有了这些，你可以建立最小的可行产品（MVP），检验市场上最小、最有用的产品。
如果你心中有一个伟大的想法，你可以与团队分享你的目标和伟大的想法，并共同为它想出故事。
这些都可以在用户故事地图研讨会上完成，因为这是整个团队参与产品创作的好方法；对于小想法，我们在对话后进入第三步。
3）确认 确认的作用是记录谈话中发现的问题，并商定如何验证其有效性；例如，在故事中添加验收标准。
2. INVEST 我们如何确保我们的故事有条件进入下一个冲刺？ 让我们看一个简单的技巧，它将确保我们的故事已经准备好了。
它叫INVEST，它定义了一个伟大故事的六个特征： I – 独立 N – 协商 V – 价值 E – 估算 S – 小型 T – 测试 让我们看看另一个用户故事的例子，看看它是否符合这些特征： 作为一名彩票玩家，我想在网站上输入我的彩票号码，以检查我是否赢了，中了多少钱。
1）独立 这意味着它可以独立完成 – 没有阻碍依赖性；例如，我们不需要登录系统来验证我们的号码是否获奖，这意味着它可以与我们已经在系统中的内容分开工作。
2）协商 用户故事中的内容不是固定的，而是活的文档；当我们在开发过程中发现更多的东西时，它可能会改变，然后开发团队会与产品负责人协商。
3）价值 这意味着为用户提供价值。
我想要作为用户，而不是 作为产品负责人，我想要 或者 作为开发者，我想要；除非你为产品负责人和开发者建造工具。
为了让它有价值，我们想把故事想象成一块蛋糕，你想切蛋糕，品尝所有层，而不仅仅是新鲜的奶油；软件开发也是如此，你想让用户品尝所有平台的味道，而不仅仅是后端或前端。
我们不会给用户看假按钮，说 检查你是否中奖！ 如果背后没有逻辑，按钮就没用了。
我们需要问事完成后，我们需要问们的故事完成后直接为客户提供价值？ 4）估算 估计越小越容易，测试越容易。
为什么要估计？ 如果我们能估计一个故事，这意味着我们对它有足够的理解，它是可行的，我们不知道，如果我们不能估计我们的故事，它肯定需要更多的讨论，更多的细节，或更多的研究。
5）小型 在敏捷发展中，意味着适合冲刺，甚至更少；故事越小，就越容易掌握故事的内容。
小特征与有价值的特征密切相关。
如果你想把故事切成几个小故事，你需要确保所有的故事都能为用户提供价值；就像一块蛋糕，你在生日派对上为客人服务 – 所有的蛋糕都有所有层的味道，就像我们的软件平台一样。
现在，想象一下，我们的彩票故事不适合冲刺。
我们能做什么？也许可以分为两个小故事，每个小故事都能为我们的用户提供价值。
第一个故事将检查我是否中奖：作为一名彩票玩家，我想在网站上输入我的彩票号码，以检查我是否中奖。
标题可以是：彩票玩家可以检查他们是否赢了。
第二个故事将询问我赢了多少钱，前提是有中奖号码：作为一个中奖号码的彩票玩家，我想在网站上输入我的彩票号码，以查看我赢了多少钱。
标题可以是：彩票玩家可以查询中奖号码的奖金金额。
这样，我们就可以在第一个故事完成后更快地为用户提供价值；我们可以更快地了解有多少用户对使用新功能感兴趣。
6）测试 如果我们知道如何测试它，我们就知道它什么时候完成。
一种常见的方法是在故事中添加验收标准；这些都是一些用例，可以确定软件所做的就是它所做的。
验收标准提供了检查边缘用例和悲伤路径的功能场景 场景、非功能测试(如性能)等。
每个故事都有一些具体的验收标准来帮助团队掌握需要实现的新功能；然后是团队同意的完成标准，规定了每个用户故事上线前需要满足的一些一般标准。
让我们在彩票例子中的第一个故事中添加一些验收标准： 作为一名彩票玩家，我想在网站上输入我的彩票号码，以检查我是否中奖。
验收标准可为： 假如这个号码是中奖号码，用户应该看到一条信息：今天是你的幸运日，你中奖了！ 假如这个号码不是中奖号码，用户应该看到一条消息：再试一次，我打赌你下次会赢的！ 关于第二个故事：作为一个有中奖号码的彩票玩家，我想在网站上输入我的彩票号码，以查看我赢了多少钱。
验收标准如下： 如果用户中奖，中奖金额应以货币格式显示。
用户只能查询过去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 译者:产品侠，服务设计硕士，产品经理实习生，英语爱好者；微信微信官方账号:产品侠 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
让我们一起看看。
一、开篇 我会给你讲用户故事，回答用户故事中最常见的问题；我们将讨论用户故事，从来源到实践，并学习一些技能来帮助我们。
敏捷开发指南没有提到用户故事。
有一段时间，我还在想在哪里找到关于用户故事的可靠信息。
待办事项列表是否应由用户故事组成吗？如果没有必要 作为用户，我想…，以便…” 模板不是用户故事吗？所以那些写的 作为开发者…” 或者 作为产品经理…” 等等的故事呢？ 我的目的是对用户故事进行新的诠释，澄清一些围绕用户故事的误解，并指出那些最好地解释用户故事的人。
二、基础篇 1. 用户故事的故事 我将解释用户故事的来源，因为这是理解用户故事和澄清误解的最好方法。
90年代的用户故事，Kent Beck在他的《Extreme Programming Applied》一本书开始讨论用户故事。
这个想法来自一个用户告诉他的一个关于新产品的故事:如果我输入邮编，它会自动填市和州，不需要我触摸按钮！ 如果你能讲述软件能做什么的故事，并在观众心中产生动力、兴趣和愿景，为什么不在制作软件之前讲故事呢？Kent问问自己，为什么在构建产品之前不能有这种产品愿景？谁会使用这个产品，它会做什么，为什么？我们应该通过对话来帮助我们思考问题。
《User Story Mapping》一书的作者Jeff Patton故事的名字来自于我们如何使用它们，而不是如何写它们。
2. 模板 后来Connextra公司的Rachel Davis发明了我们今天使用的模板：作为一个用户，我想… 以便…” 她试图帮助同事有序地在小卡片上写故事，模板提醒我们三件最重要的事情：谁想要，想要什么，为什么。
从用户的角度思考他们的需求，比如: 作为一个手机用户，我想检查位置的天气预报，这样我就不必每次去新地方都检查天气预报。
同样，你在卡片上写的应该只是第一次促进新想法对话的起点。
卡片的概念来自Ron Jeffries的3Cs：卡片、对话、确认。
你把你的想法写在一张卡片上，实际上是写在一个软件跟踪工具或一个方便的帖子上，然后你和那些将建立它的人（开发团队）交谈，然后你有一个确认；你把结果写在文档或跟踪工具上，这样你就可以很容易地回忆对话，并知道如何验证故事是否已经完成。
你可以在Mike Cohn的《User Stories Applied》一本书读到了这一切，Mike Cohn是 用户故事 伟大的实践者和领域专家。
所以这就是我们如何从我们那里开始Kent Beck在故事中，我们得到了今天用户的故事。
加入故事 “用户” 这个词有助于关注用户，这可以解释为什么 作为开发者，我想要 只有当我们的最终用户是开发者时，模板才是准确的。
这是用户故事的故事。
它将讲故事介绍到你的产品创作中。
故事可以用模板写下来，以确保我们不会错过任何重要的信息，但当然，这是可选的；最重要的是，产品负责人和开发团队将建立产品，并对他们想要实现的目标有一个共同的理解。
三、实践篇 1. Ron Jeffries的3Cs Ron的3Cs：卡片、对话、确认；让我们来看看在实践中创建用户故事的过程。
1）卡片 卡片的概念来自于我们在前互联网时代用来寻找书籍的图书馆卡片，包括作者、标题和简短的摘要。
Ron认为类似的卡片可以用来写软件系统新功能的简短摘要，它可以包含 作为用户，我想，为了…” 这样的模板，但最好给它一个简短的自我解释标题。
避免类似的积压： 用户故事的积累是相同的标题…更何况你有没有遇到过，在日常工作中，有人用编号来指代用户故事，而不是标题？ 在这个时候，我们知道我们扼杀了这个故事，不是吗？这可能是因为标题太长，令人困惑（见上图），我们可以很容易地添加一个简洁的标题。
对于我们的基本文章的例子：作为一个手机用户，我想检查我所在位置的天气预报，这样我就不必每次去新地方都检查天气预报。
这个故事的标题可以是:查询当前位置的天气预报。
2）对话 正如我们所说，上述卡片可以作为产品负责人与开发团队对话的起点，以实现对将要构建什么的共同理解。
所以他们会讲故事，讲谁会用这个产品，他们想要什么，为什么；首先，关注最重要的事情，然后讨论实施细节。
首先，我们为什么要建立它？想想什么对你的业务影响最大，对用户的结果最好。
为什么用户需要它？作为企业，我们为什么要让他们使用它？对我们有什么好处，商业价值是什么？ 有了这些，你可以建立最小的可行产品（MVP），检验市场上最小、最有用的产品。
如果你心中有一个伟大的想法，你可以与团队分享你的目标和伟大的想法，并共同为它想出故事。
这些都可以在用户故事地图研讨会上完成，因为这是整个团队参与产品创作的好方法；对于小想法，我们在对话后进入第三步。
3）确认 确认的作用是记录谈话中发现的问题，并商定如何验证其有效性；例如，在故事中添加验收标准。
2. INVEST 我们如何确保我们的故事有条件进入下一个冲刺？ 让我们看一个简单的技巧，它将确保我们的故事已经准备好了。
它叫INVEST，它定义了一个伟大故事的六个特征： I – 独立 N – 协商 V – 价值 E – 估算 S – 小型 T – 测试 让我们看看另一个用户故事的例子，看看它是否符合这些特征： 作为一名彩票玩家，我想在网站上输入我的彩票号码，以检查我是否赢了，中了多少钱。
1）独立 这意味着它可以独立完成 – 没有阻碍依赖性；例如，我们不需要登录系统来验证我们的号码是否获奖，这意味着它可以与我们已经在系统中的内容分开工作。
2）协商 用户故事中的内容不是固定的，而是活的文档；当我们在开发过程中发现更多的东西时，它可能会改变，然后开发团队会与产品负责人协商。
3）价值 这意味着为用户提供价值。
我想要作为用户，而不是 作为产品负责人，我想要 或者 作为开发者，我想要；除非你为产品负责人和开发者建造工具。
为了让它有价值，我们想把故事想象成一块蛋糕，你想切蛋糕，品尝所有层，而不仅仅是新鲜的奶油；软件开发也是如此，你想让用户品尝所有平台的味道，而不仅仅是后端或前端。
我们不会给用户看假按钮，说 检查你是否中奖！ 如果背后没有逻辑，按钮就没用了。
我们需要问事完成后，我们需要问们的故事完成后直接为客户提供价值？ 4）估算 估计越小越容易，测试越容易。
为什么要估计？ 如果我们能估计一个故事，这意味着我们对它有足够的理解，它是可行的，我们不知道，如果我们不能估计我们的故事，它肯定需要更多的讨论，更多的细节，或更多的研究。
5）小型 在敏捷发展中，意味着适合冲刺，甚至更少；故事越小，就越容易掌握故事的内容。
小特征与有价值的特征密切相关。
如果你想把故事切成几个小故事，你需要确保所有的故事都能为用户提供价值；就像一块蛋糕，你在生日派对上为客人服务 – 所有的蛋糕都有所有层的味道，就像我们的软件平台一样。
现在，想象一下，我们的彩票故事不适合冲刺。
我们能做什么？也许可以分为两个小故事，每个小故事都能为我们的用户提供价值。
第一个故事将检查我是否中奖：作为一名彩票玩家，我想在网站上输入我的彩票号码，以检查我是否中奖。
标题可以是：彩票玩家可以检查他们是否赢了。
第二个故事将询问我赢了多少钱，前提是有中奖号码：作为一个中奖号码的彩票玩家，我想在网站上输入我的彩票号码，以查看我赢了多少钱。
标题可以是：彩票玩家可以查询中奖号码的奖金金额。
这样，我们就可以在第一个故事完成后更快地为用户提供价值；我们可以更快地了解有多少用户对使用新功能感兴趣。
6）测试 如果我们知道如何测试它，我们就知道它什么时候完成。
一种常见的方法是在故事中添加验收标准；这些都是一些用例，可以确定软件所做的就是它所做的。
验收标准提供了检查边缘用例和悲伤路径的功能场景 场景、非功能测试(如性能)等。
每个故事都有一些具体的验收标准来帮助团队掌握需要实现的新功能；然后是团队同意的完成标准，规定了每个用户故事上线前需要满足的一些一般标准。
让我们在彩票例子中的第一个故事中添加一些验收标准： 作为一名彩票玩家，我想在网站上输入我的彩票号码，以检查我是否中奖。
验收标准可为： 假如这个号码是中奖号码，用户应该看到一条信息：今天是你的幸运日，你中奖了！ 假如这个号码不是中奖号码，用户应该看到一条消息：再试一次，我打赌你下次会赢的！ 关于第二个故事：作为一个有中奖号码的彩票玩家，我想在网站上输入我的彩票号码，以查看我赢了多少钱。
验收标准如下： 如果用户中奖，中奖金额应以货币格式显示。
用户只能查询过去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 译者:产品侠，服务设计硕士，产品经理实习生，英语爱好者；微信微信官方账号:产品侠 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
