如何编写用户故事：完整指南

用户故事是正确的敏捷软件开发的重要组成部分：让我们看看它们的作用并学习如何编写用户故事。

敏捷框架是构建软件开发和委派任务的一种流行且有效的方法。 编写用户故事（不要与如何编写推荐书混淆）是敏捷开发中的一种工具，它允许开发人员了解需要做什么以及如何满足需求。 这使它们成为一个非常重要的起点——但这也意味着它们必须小心建造。 这是你应该知道的。

什么是用户故事？

这是一个在敏捷框架内的软件开发中使用的术语。 用户故事通常被认为是敏捷项目中的最小单元或满足需求的第一步。 它们是在项目完全计划好时创建的。

那么，这到底是什么意思呢？ 每个软件功能在添加到项目中时都有（或应该有）特定用途。 该目的应影响其整个开发以及如何将其纳入整体框架。 开发人员可以在需要做出决策时参考此目的，尤其是关于如何分解目标以及优先考虑什么。 “用户故事”只是描述功能目的的一种方式。

用户故事是从用户的角度编写的，通常只用一两句话。 它们捕捉用户的观点以及用户想要做什么。 完成后，好的用户故事是讨论战略目标、可以安全地放弃或应该添加哪些功能等等的一种简单方式。

如何编写用户故事

步骤 1. 获取输入

从所有者、潜在用户和项目经理那里获取输入。 一个强大的用户故事需要大量的输入才能准确。 从这些群体那里得到关于他们想做什么的明确解释。 请记住，这不应直接转化为用户故事，但会提供必要的信息。 所有者可能会说，“我需要人们能够在我的应用程序上使用 PayPal 付款”，这非常有用，但不是用户故事本身。

第 2 步。决定如何创建用户故事

这取决于您的工作流程。 在早期阶段，在规划整体框架时，将用户故事记录在索引卡或便利贴上。 后来，它们被合并到项目管理软件中。 一些团队成员跳过便利贴阶段，而其他人则依赖它——以适合你的方式为准。

第 3 步：定义、定义、再定义

定义用户：通过输入，您现在可以定义用户。 请记住，这并不总是产品功能的最终用户； 它可能因用户类型而异。 如有必要，创建用户角色。 定义用户正在执行的操作，并定义用户执行此操作的目标。 在制作用户故事以与目标受众交流时包含此关键信息。

第 4 步。写故事

开始编写您的用户故事，为了吸引读者的注意力，它应该只有一两句话。 在这里很容易做到精确和技术性，但宽泛的语言，如使命宣言，可能会有所帮助。 把故事说清楚，确保它可以解决或完成，这样你就可以回顾并确认，“是的，用户现在可以做到这一点！”

步骤 5. 进一步分解

用户故事可能需要多个步骤才能达到最终目标，这可能需要根据您使用的敏捷框架进行一些重组。 请记住，用户故事始终是框架中的最小单元。 在这个粒度级别上，用户故事应该需要几天时间才能实施。

如果他们看起来需要更长的时间，那就是重新审视并查看是否需要进一步分解和重组用户体验的迹象。 如果添加了新需求，它们还需要分解为用户故事。 虽然这几句话是有效用户故事的核心，但它们也可以随着开发的进行而扩展。 让我们仔细看看。

用户故事中的 3C 是什么？

Card ：Card阶段是指用一两句话为开发团队编写用户故事。 之所以称为卡片，是因为用户故事最初是写在索引卡片上的，许多团队仍然喜欢这样做。 该卡是其特定软件要求的核心，也是所有讨论的起点。 检查您的用户故事是否太长也很容易 - 如果它不能放在每个人都可以阅读的索引卡上，则需要缩短它。

对话：创建卡片句子后，就该敲定细节了。 这通常以开发人员之间的一系列问题开始，例如“这需要多长时间才能实现？” 或“我们如何合并此操作？” 或者“这个用户故事在这里很重要吗？” 等等。

这种对用户故事的仔细检查可能会产生额外的问题来询问项目经理和产品所有者，他们应该在必要时参与对话。 随着对话的继续，用户故事可能会被更改、改进、合并或删除，直到每个人都在同一页面上。 随着用户故事的最终确定，它们被转移到实施阶段，这是对话基本结束的标志。

确认：确认是关于验收测试，也就是验收标准。 一旦实施了更改，并且开发人员报告它已准备就绪——用户故事已经得到满足——就该测试它了。

应根据产品所有者的输入创建验收测试，并直接与用户故事联系起来。 在最好的情况下，用户只是简单地尝试执行用户故事指示的操作并查看他们是否可以。 但是验收测试可能会有所不同，并不总是像他们应该的那样考虑用户故事。 如果这产生了问题，那么是时候回到对话步骤，直到验收测试和用户故事正确对齐。 如果所有的验收测试都完成了，用户故事就会很高兴。 现在是时候继续产品开发的下一步或发布该功能了。

4C？ ：有趣的是，有些人认为有一个必不可少的 4th C：上下文。 在这种情况下，用户故事与项目更大框架中的其他用户故事一起被查看。 在这里，开发人员询问用户故事是否顺利地补充了其他用户故事，或者是否存在差距——用户需要做或理解的事情在用户故事之间被遗漏了。

理想情况下，这是在对话阶段发现的，但这并不总是发生。 一些开发团队可能希望最终审查已完成的用户故事如何融入更大的整体，以及是否需要做任何进一步的工作。

什么是用户故事的好格式？

让我们回顾一下在创建用户故事句子时非常有用的两种格式化技术。 第一个非常简单：“谁，什么，为什么？” 在句子模板中，可以这样描述：

作为 [Who the user is]，我想 [What the user Wants]（这样 [Why the user wants it]）。

此模板也可以构造为：“作为一个[角色]，我想[行动]，（以便[受益]）”，以简化术语。 遵循这种基本格式足以创建大多数用户故事。 这通常是您所需要的，并且在用于每个用户故事时可以帮助节省大量时间。

然而，有时，用户故事在更复杂的项目中更难定义。 在这种情况下，第二种用户故事模板技术可能会有用。 它叫做 INVEST，一个首字母缩写词，代表：

• 独立：故事应该完全相互独立，因此故事应该能够乱序处理。
• 可协商：故事应设计为在过程的对话部分进行更改。
• 有价值的：用户故事应该为项目展示明确的价值。 如果不能，那可能是一种资源浪费。
• 可估计的：必须根据价值和优先级来衡量用户故事，以帮助决定按重要性顺序处理哪些内容。
• 小：用户故事必须是最小的功能单元，否则应该进一步细分。
• 可测试：用户故事必须在确认过程中以可测试的方式陈述。

关于如何编写用户故事的常见问题解答

您可能还对我们关于如何撰写游戏评论的指南感兴趣。