编写有效的用户故事 (user stories)

如何编写有效的用户故事？

用户故事是一种捕捉早期需求的强大技术。用户故事捕捉了需求的 WHO、WHAT 和 WHY，这让每个人都能更容易地尽早达成共识。然而，像其他需求一样编写用户故事需要了解一个好的用户故事的特徵是什麽。

那麽，我们如何才能写出有效的用户故事呢？在开始之前，让我们先了解用户故事的基础知识。

什麽是用户故事？

用户故事是一种从外部用户角度表示软件系统的功能或用户需求的流行格式。该格式包含三个关键元素，如下所示：
作为 <用户角色>
我想要 <做某事>
以便我可以 <实现某个目标>

用户角色代表一种用户类型（而不是单个用户）。需求是从这个用户角色的角度提出的—— **<做某事>。**用户故事的第三部分是行动的目的。

用户故事不仅代表系统功能/要求，还解释了为什麽要这样做？

用户故事示例

让我们举一个简单的例子来更好地理解用户故事的基础知识。一位客户希望获得一个用於预订机票的旅行门户。此门户的要求之一是为商务旅客搜索机票。此案例的用户故事可以如下所示：

作为 <用户>，
我想 <根据我的日程安排搜索机票>
这样我就可以 <这样我就可以参加商务会议>

用户故事的好处是每个利益相关者（客户和开发人员）都对需求有一个完整的了解。

用户故事示例

让我们举一个简单的例子来更好地理解用户故事的基础知识。一位客户希望获得一个用於预订机票的旅行门户。此门户的要求之一是为商务旅客搜索机票。此案例的用户故事可以如下所示：

作为 <用户>，
我想 <根据我的日程安排搜索机票>
这样我就可以 <这样我就可以参加商务会议>

用户故事的好处是每个利益相关者（客户和开发人员）都对需求有一个完整的了解。

编写好的用户故事

好的用户故事有哪些特点？编写好的用户故事对於项目的成功至关重要。INVEST 代表了一个好的用户故事的特徵，如下所述：

• I ndependent -用户故事应该是尽可能独立。
• N egotiable 协商——用户故事不是合同。它们不是详细的规格。它们提醒团队在开发时讨论和协作以澄清细节的功能。
• V aluable -用户故事应该是溶液的用户（或拥有者）是有价值的。它们应该用用户语言编写。它们应该是功能，而不是任务。
• E stimable – 用户故事需要可以估计。他们需要提供足够的信息来进行估算，但不能太详细。
• S small – 用户故事应该很小。不会太小。但不要太大。
• T estable - 测试——用户故事需要以可测试的方式表述，即不要太主观，并提供关於如何测试用户故事的清晰细节。

除了 INVEST 原则，在编写用户故事时还应该考虑一些重要的点：

• 在编写用户故事时，需求不会很明确。建议捕获与需求/用户故事相关的所有假设和约束。这些假设为管理风险提供了基础。
• 确保用户故事写得清楚，没有歧义。一个非常着名的例子是双周刊一词的使用。许多人将其视为 15 天一次，而其他人可能认为这是一周两次。
• 使用双方同意的用户故事格式，因为没有标准的用户故事格式，这可能会导致混淆。
• 明确提及验收标准。验收标准有助於定义完成吗？完成定义有助於确定用户故事何时完成
• 始终建议不断完善产品待办事项。这将确保新的用户故事被添加到列表中，并且低优先级的故事可能会得到足够的关注。

主题 vs 史诗 vs 用户故事 vs 任务

产品通常由数百个需求描述，这些需求组织在产品待办事项列表中。主题或史诗无法在一个 sprint 中完成，因此它们被分解为更多的用户故事，然後是一组相关的任务。史诗然後以发行版的形式交付。但即使是来自不同史诗的小用户故事也可以有一些共同点。这样一组用户故事称为主题。

产品待办列表项的粒度

您是否曾经对敏捷开发中的主题（或功能）或史诗等术语的使用感到困惑？新人可能不知道有什麽区别，甚至会导致错误。

Scrum 没有“故事”、“史诗”等。Scrum 有产品待办列表项 (PBI)，它们通常按优先级排序、拆分和细化为史诗、用户故事、技术任务、峰值和错误。待办事项整理过程中的时间方式。

主题/用户功能 (Theme and User feature)

主题提供了一种方便的方式来表明一组相关的史诗具有一些共同点，例如位於同一功能区域。通过为主题分配财务价值，管理人员可以确保交付最高价值，并且项目/计划与其目标和组织的战略方向保持一致。

史诗 (Epic)

Epic 可用作大型需求的占位符。它可能不适合冲刺，应该分解成故事。史诗通常在最初的产品路线图中定义，并随着了解的更多而分解为产品待办列表中的故事，通常以用户故事格式编写。史诗中分解的故事具有共同的目标和特定的结果或高级用户需求或某人使用服务的旅程或过程的一部分。

用户故事 (User Story)

用户故事是敏捷中用户功能的最小单位，可以在一个敏捷冲刺中交付。它们通常使用故事点进行估计，并使用 INVEST 标准进行定义。用户故事应该向客户提供一个垂直的功能切片，这些功能在迭代结束时是有价值的和完整的。用户故事必须为用户提供特定的价值，并且必须可以用简单的语言描述，概述所需的结果。

任务 (Task)

任务是故事的分解部分，涉及故事将如何完成。如果需要，可以估计任务时间。任务通常由从事工作的人员（开发人员、QA 等）定义，而故事和史诗通常由客户或产品所有者代表客户创建。因此，任务不再需要业务用户可以理解，因此可以是高度技术性的。将故事分解为任务的过程也有助於开发团队更好地了解需要完成的工作。

使用 Story Map 组织您的产品待办事项列表

通过 Jeff Patton 和其他人的努力，用户故事地图正在成为一种流行的用户故事管理技术。用户故事工具允许您通过将用户需求细分为用户活动、用户任务、史诗和用户故事，为产品待办事项建立多个级别和维度。通常，敏捷开发团队在协作会议中使用故事地图来确定最终用户想要实现的预期结果。

灵活的结构复杂或简单的项目

Visual Paradigm 的故事地图支持 3 或 4 级层次结构 的需求收集，适用於复杂、中等或简单的项目。故事地图从从不同来源（即用例、BPMN、WBS 甚至思维导图）接收到的用户特徵的集合开始进入故事地图的待办事项，这些用户特徵将被实现为用户活动并成为相关的行走骨架（用户任务）。这些任务可以进一步分解为史诗，然後是软件开发的用户故事。

中型项目的三层故事地图

3 级故事地图涉及三个部分：活动 > 任务 > 故事（默认）

更复杂项目的 4 级故事地图

4级故事地图将史诗添加到3级地图中：活动>任务>史诗>故事（可配置为）

• What is Agile Software Development?
• What is User Story?
• What is User Story Mapping?
• User Story vs Use Case for Agile Software Development
• Use Case Driven Approach for Agile Development
• How to Use Wireframes with User Stories?
• Identify User Requirements with Use Case Diagrams