如何编写用户故事

用户故事是敏捷方法的一部分，有助于将重点从写需求转移到谈论需求。所有敏捷用户故事都包括一两句话，更重要的是，还包括一系列关于所需功能的对话。 用户故事是从希望获得新功能的人 (通常是系统的用户或客户) 的角度对特性进行简短、简单的描述。

用户故事的起源

• 在 Kent Beck 的“Extreme Programming Explained”一书中首次提到。它是非结构化文本，与大小限制的用例非常相似。
• Ron Jeffries在 2001 年介绍了3C 的概念：卡片、对话、确认
• 2003 年：用于快速评估用户故事的 INVEST 清单源自 Bill Wake 撰写的一篇文章，该文章还将首字母缩略词 SMART（特定、可衡量、可实现、相关、限时）重新用于处理用户故事技术分解所产生的任务。
• 2004 年：INVEST 首字母缩写词是 Mike Cohn 的“应用的用户故事”中推荐的技术之一。

什么是用户故事？定义

该用户故事代表的敏捷实践，特别是在使用 Scrum 框架的，即“捕获”用户的需求。
它通过以一般和非详细的方式表达要制造的产品的特性、功能和要求来做到这一点。

该用户故事是部分产品积压。在Scrum 中，产品待办列表包括需要集成到项目中的所有事物的“列表” 。该用户故事看起来很简单，但真正有效的。
它需要关注用户（和/或客户）的需求和需求以及要实现的价值。

用户的历史通常写在纸板或便利贴上，并贴在墙上或桌子上，以便于计划和讨论。通过这种方式，用户故事设法控制从编写功能到关于功能的比较的注意力。该用户的故事证明了的肯定的重要性敏捷宣言“软件的工作，而不是详尽的文档“。

用户故事有什么用？

用户故事是明确定义用户想要从产品/服务中获得什么的好方法。
一组写得很好的和优先级的用户故事当然可以帮助团队在不涉及技术细节的情况下表达和分享产品功能。

用户故事可让您了解功能对业务的重要性和影响。它还有助于让客户了解该功能的有用性及其优先级。

如果写得好，用户故事为沟通和协作提供了坚实的基础，使用户成为关注的焦点。用户故事的使用有助于在开发团队内部和与外部利益相关者之间对产品的讨论。

用户故事是由什么组成的？

每个用户故事都以一种简单易懂的方式为客户和开发人员描述了为什么和做什么。用户
的观点是需要新功能的。的信息量是，这是不可或缺的，允许开发团队，以便为实现所要求的工作的一个粗略的估计。

有多种编写用户故事的方法。通常，用户故事包含名称、简要说明以及可以认为故事完整的特定验收标准和条件。

用户故事模板

用户故事仅捕获需求的基本要素：

• 它是给谁的？
• 它对系统有什么期望？
• 为什么它很重要（可选？）？

以下是 70% 的从业者使用的用户故事的简单格式：

这里有两个例子：

• 作为客户，我想取消我的酒店预订以获得退款
• 作为在线客户，我希望能够安全地登录以访问我的帐户。

该用户的故事，使与客户和/或必要的用户对话，用户的故事通常写在索引卡或便利贴上，并安排在墙上或桌子上，以便于规划和讨论。因此，他们强烈地将重点从撰写特性转移到讨论它们。事实上，这些讨论比任何文本都重要。

用户故事的基本特征

用户故事应始终包含 6 个特征，由Bill Wake创建的首字母缩写词INVEST表示：

I ndependent：他们必须是相互独立的。

N egoitable (可协商)：它们必须是“可协商的”并对每个人的贡献开放。

V aluable：他们必须把附加价值给客户。

E stimable：它们必须是可估计的，不完全是，但足以允许粗略的计划实施。

S mall：它们必须很小，以便能够在几周的工作中实现功能。它们必须很小，因为这样估计会更精确。如果故事太复杂，我会把它分解成多个故事。

E estable：他们必须能够进行测试，必须具备对如何进行测试的信息。

首字母缩略词 INVEST 有助于记住一组广泛接受的标准或清单，以评估用户故事的质量。如果故事不符合这些标准之一，团队可能想要改写它，甚至考虑重写（这通常转化为物理撕掉旧故事卡片并编写新故事卡片）。

请参阅此处的示例，了解如何将用户故事分解为更简单的用户故事。

 

谁来编写用户故事？
任何具备编写用户故事所需技能的人都可以编写用户故事。大多数情况下，它们是由产品负责人编写的（链接到以后的帖子）。但它们也可以与整个团队合作编写。

 

验收标准
与用户故事一起，制定验收标准很重要，即必须用于评估故事是否已正确和完全实施的标准。这些标准是软件产品必须符合的条件才能被用户和/或客户接受。
验收标准对于了解何时实现用户故事的目标至关重要。

 

在软件开发中，目标通常是新产品功能，个人是某种类型的最终用户，原因是用户在目标产品功能中看到的好处。

用户故事示例：

• 作为[客户]，我想要[购物车功能]，以便[我可以轻松地在线购买商品]。
• 作为[经理]，我想[生成报告]以便[我可以了解哪些部门需要更多资源]。
• 作为[客户]，我想[收到商品时收到短信]以便[我可以马上去取货]

在上面的例子中：

• 角色代表将与要实现的系统交互以实现目标的人、系统、子系统或任何其他实体。他或她将通过与系统交互来获得价值。
• 动作代表用户的期望，可以通过与系统交互来实现。
• 收益代表与系统交互背后的价值。

这不是规则，而是通过考虑以下因素来帮助您思考用户故事的指南：

• 用户故事将为某人或某方（例如客户）带来价值。
• 用户故事正在满足用户的需求（例如，当商品到达时收到短信）
• 有理由支持实施这个用户故事（例如客户可以去取她购买的物品）

使用 3C（卡片、对话和确认）详述用户故事

XP 的另一位创建者 Ron Jeffries 描述了我们最喜欢的用户故事思考方式。用户故事具有三个主要组件，每个组件都以字母“C”开头：卡片、对话和确认，用于描述用户故事的三个要素。在哪里：

卡片

卡片代表 2-3 句话，用于描述故事的意图，可以视为对话邀请。卡片作为一个令人难忘的令牌，它概括了意图并代表了更详细的要求，其细节仍有待确定。

在将它们带到团队之前，您不必“预先”完美地写出所有产品待办事项列表项。它承认客户和团队将在他们工作时发现所需的底层业务/系统。这一发现是通过围绕用户故事的对话和协作发生的。Card通常遵循类似于以下格式的格式：

作为产品的（角色），我可以（做动作）这样我才能获得（一些好处/价值）

笔记：

• 书面文本，对话邀请，必须说明故事的“谁（角色） ”、“什么（行动） ”和“为什么（好处） ”。

 

对话

对话代表目标用户、团队、产品所有者和其他利益相关者之间的讨论，这是确定实现意图所需的更详细行为所必需的。换句话说，卡片还代表了关于意图的“对话承诺”。

• 由产品负责人促成的协作对话涉及所有利益相关者和团队。
• 对话是故事的真正价值所在，应调整书面卡片以反映当前对该对话的共同理解。
• 这种对话主要是口头的，但最常得到文档和各种类型的理想自动化测试（例如验收测试）的支持。

 

确认

确认代表验收测试，客户或产品负责人将通过这种方式确认故事的实施是否令他们满意。换句话说，Confirmation 代表了满足的条件，用于确定故事是否满足意图以及更详细的要求。

• 产品负责人必须确认故事是完整的，然后才能被认为“完成”
• 团队和产品负责人根据团队当前对“完成”的定义检查每个故事的“完成”
• 可以为单个故事建立不同于当前“完成”定义的特定验收标准，但当前标准必须得到团队的充分理解和同意。所有相关的验收测试都应该处于通过状态。

 

如何识别用户故事？

用户故事应该与利益相关者一起确定，最好是通过面对面的会议。用户故事是一个需求发现过程，而不是一个前期的需求分析过程。

在传统的需求捕获方法中，系统分析师试图了解客户的需求，然后为系统详细准备需求规范。这不是用户故事方法的工作方式。用户故事的识别更像是一个笔记过程，而不是文档过程。我们列出了识别用户故事的主要步骤如下：

1. 通过与用户的讨论，我们倾听并了解他们的问题和需求
2. 然后，同时写下他们的需求作为用户故事。
3. 这些用户故事将成为需求的来源。
4. 随后可以及时填写详细信息，从而在整个项目开发过程中为团队提供“恰到好处”的需求参考。

用户故事的生命周期

从广义上讲，整个软件项目中的每个用户故事都有六个主要状态：

待办的

通过用户和项目团队之间的沟通，发现用户故事。在这种状态下，用户故事只不过是对用户需求的简短描述。没有详细的需求讨论，没有系统逻辑，也没有屏幕设计。实际上，用户故事目前的唯一目的只是为了提醒各方将来讨论此用户故事（卡片）中写入的用户请求。将来可能会丢弃用户故事。

去做

通过不同利益相关者之间的讨论，决定了接下来几周要解决的用户故事，并将其放入一个称为冲刺的时间箱中。据说这样的用户故事处于待办事项状态。在此状态下尚未进行详细讨论。

讨论

当用户故事处于讨论状态时，最终用户将与开发团队沟通以确认需求以及定义验收标准。开发团队将把需求或任何决定写下来作为对话笔记。UX 专家可以创建线框或故事板，让用户在视觉模型中预览提议的功能并感受它。这个过程称为用户体验设计（UX 设计）。

发展

需求明确后，开发团队将设计和实现功能以满足用户的要求。

确认

开发团队实施用户故事后，最终用户将确认该用户故事。他/她将有权访问测试环境或半完整的软件产品（有时称为 alpha 版本）以确认该功能。将根据详述用户故事时所写的确认项目进行确认。在确认完成之前，用户故事处于确认状态。

完成的

最后，确认功能完成，用户故事被认为处于完成状态。通常，这是用户故事的结尾。如果用户有新的需求，无论是关于新功能，还是对完成的用户故事的增强，团队都会为下一次迭代创建一个新的用户故事。

使用 Story Map 组织用户故事

用户故事是构建更好的产品待办列表的一种有用方法，它以用户为中心，并以实用、可操作的方式描述软件需求。但是，用户故事本身并不能揭示可以让您了解用户从加载应用程序的那一刻到达到最终目标所经历的更大旅程的全貌。

用户故事地图可以帮助我们将用户故事安排成一个可管理的模型，以便系统地计划、理解和组织系统的功能。通过操纵地图的结构，我们可以识别您的待办事项中的漏洞和遗漏，并在意义结构中将用户故事相互关联；帮助有效地规划整体发布，通过每次发布为用户和业务带来价值。用户故事地图允许您向待办事项添加第二个维度。以下是您应该考虑使用此技术的几个原因：

• 它使您可以查看待办事项中的大图。
• 它为您提供了一个更好的工具来做出有关整理和优先处理积压工作的决定。
• 它促进了无声的头脑风暴和协作方法来生成您的用户故事。
• 它鼓励迭代开发方法，您的早期交付验证您的架构和解决方案。
• 它是传统项目计划的绝佳视觉替代方案。
• 它是讨论和管理范围的有用模型。
• 允许您可视化项目/产品的尺寸规划和实际选项。

用户故事地图模板

故事映射是一种自上而下的需求收集方法，并表示为一棵树。故事映射从用户活动开始。一个用户活动应该达到一个特定的目标。为了完成一项活动，用户需要执行相关的任务。这些任务可以转化为用于软件开发的史诗和用户故事。通常，用户故事地图由 3 个级别组成：用户活动/用户任务/用户故事。对于企业规模的项目，通过在第三层引入 Epics，也许 4 层结构可能更合适。

用户活动- 它们位于第二列中。这是系统必须支持的主要目标，具有切实的业务成果。整行构成了主干。

用户任务- 每个用户活动都分解为一组称为叙述流的相关用户任务。整排形成行走骨架）

史诗/用户故事- 每个用户任务都在功能实现的用户任务下直接分解为史诗/用户故事。根据您项目的复杂程度，您的团队可能会选择如上所述更适合您的 3 或 4 级故事地图。

Visual Paradigm Story Map支持 3 级和 4 级复杂性，让您可以应对各种类型的项目。

3 级故事地图（用户激活 > 用户任务 > 用户故事）

 

 

4 级故事地图（用户激活 > 用户任务 > 史诗 > 用户故事）

 

 

计划发布

使用分隔符来标识用户可能使用您的软件来实现其目标的任务片段。允许您的特定目标用户实现其目标的最少任务数量构成了一个可行的产品版本，如下图所示：

 

 

如果您想开发这样的故事地图，请查看 Visual Paradigm 的故事地图工具。

 

如何有效地使用用户故事？

就像许多其他软件开发方法一样，如果您在软件项目中正确应用用户故事，您将能够制作出高质量的软件系统，并赢得客户的信任和满意。在使用用户故事时，您需要牢记以下几点：

• 保持用户故事的描述简短。
• 在编写用户故事时，从最终用户的角度思考。
• 在开始开发之前必须定义确认项
• 在实施之前估计用户故事，以确保您团队的工作量得到控制。
• 需求是由最终用户找到的，而不是由最终用户或仅由开发团队找到。与最终用户保持良好的关系对双方来说都是双赢的。
• 沟通对于了解最终用户的需求始终很重要。

 

准备好敏捷了吗？

想要一个可以很好地管理您的 Scrum 项目的敏捷工具吗？Visual Paradigm 具有用户故事映射工具、亲和力估计工具、冲刺管理工具和任务管理。

免费尝试