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

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

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

什么是用户故事？

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

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

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

如何编写用户故事

步骤 1. 获取输入

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

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

这取决于您的工作流程。 在早期阶段，在规划总体框架时，会在索引卡或便利贴上捕获用户故事。 后来，它们被纳入项目管理软件中。 有些团队成员会跳过便利贴阶段，而其他团队成员则依赖它 - 无论哪种方式适合您。 您可能还想知道如何写序言。

步骤 3. 定义、定义、定义

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

第四步：写故事

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

步骤 5. 分为进一步的步骤

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

如果看起来需要更长的时间，则表明需要重新审视用户体验，看看是否需要进一步分解和重组用户体验。 如果添加新需求，还需要将它们分解为用户故事。 虽然这几句话是有效用户故事的核心，但随着开发的进行，它们也可以扩展。 让我们仔细看看。 您可能还对了解什么是用户体验写作感兴趣。

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

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

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

对用户故事的仔细检查可能会产生额外的问题，需要询问项目经理和产品负责人，必要时应让他们参与对话。 随着对话的继续，用户故事可能会被更改、细化、合并或删除，直到每个人都在同一页面上。 当用户故事最终确定后，它们将被转移到实施阶段，这表明对话基本上已经结束。

确认：确认就是关于验收测试，也称为验收标准。 一旦实施了更改，并且开发人员报告它已准备就绪（用户故事已得到满足），就可以对其进行测试了。

验收测试应该根据产品负责人的输入来创建，并直接与用户故事联系起来。 在最好的情况下，用户只是尝试执行用户故事指示的操作，看看是否可以。 但验收测试可能会有所不同，并且并不总是按照应有的方式考虑用户故事。 如果这会产生问题，则需要返回到对话步骤，直到验收测试和用户故事正确对齐。 如果所有验收测试都完成，用户故事就会很令人满意。 现在是时候继续产品开发的下一步或发布该功能了。

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

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

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

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

作为一个[用户是谁]，我想要[用户想要什么]（以便[用户为什么想要它]）。

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

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

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

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

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