如何编写高质量的用户故事

本文详细介绍了如何在敏捷开发过程中编写高质量用户故事（User Story），包括用户故事的定义、结构、撰写技巧以及如何与产品待办列表（Product Backlog）中的其他工作项（PBI）相结合，以提高软件开发效率和产品质量。原文: How to Write High-Quality User Story

从用户故事开始

用户故事是敏捷项目管理中必不可少的部分，是构建产品待办列表（Product Backlog）层级架构的核心 PBI（Product Backlog Item），也是开发团队在每个冲刺阶段为客户提供的主要价值。因此，在敏捷开发中，理解用户故事以及提高其质量至关重要。如何写好用户故事有很多技巧和最佳实践，一旦理解了这些内容，就能极大提高敏捷项目的绩效，此外还可以将这些实践应用到其他类型的 PBI 上，如 bug、变更规范、重构等。

本文假定读者了解产品待办列表（Product Backlog）和产品待办项 (PBI)。

• 产品待办列表（Product Backlog）是敏捷的核心工具，敏捷团队将需求、估算、进度状态、沟通等所有信息整合在一起。在瀑布式项目中，又被称为 WBS（Work Breakdown Structure）。

• 产品待办项（Product Backlog Item) 是产品待办列表中的一项工作，可以是工单、任务或问题。敏捷团队根据 PBI 进行计划、工作和交付。

什么是用户故事？

在敏捷中，"用户故事"（User Story）有两种含义：一种是 PBI 类型，另一种是描述用户可以用产品做什么的句子。在本文中，当我提到"用户故事"时，主要使用第一种含义。

用户故事（User Story）中包含一些信息，定义了用户可以使用产品完成的需求。作为最佳实践，用户故事应包含三组信息：用户故事（句子）、验收标准和可视化文档。

产品待办列表层级架构和用户故事

产品待办列表的架构层级包括四个层次：主题（theme）、史诗（epic）、用户故事（user story）和任务（task）。有些人认为应该是五层，但根据我的研究和经验，通常四层就足够了，也更常用。用户故事位于史诗和任务之间的第三层。

主题代表高层业务战略和长期目标。史诗是无法在一个冲刺周期内完成的，有价值的大型产品待办项（PBI），必须分解成几个较小的用户故事。用户故事是有价值的单个 PBI，足够小，可以在一个冲刺周期内完成。最后，任务是用户故事的细分。下表提供了每个 PBI 的细节、长度和示例。

当用户故事过大时，应将其划分为更小的用户故事。创建"用户故事"的最佳实践之一是确保其足够小，可以在一个冲刺周期内完成。较小的实施和发布周期可以减少错误数量并提高软件质量。软件复杂度会随着实施规模的扩大而呈指数级增长，而非线性增长。然而，创建小的用户故事可能具有挑战，因为软件本身具有内聚性。因此，更好的拆分用户故事是产品待办列表管理的关键。

Humanizing Work, LLC 的 The Story Splitting Cheat Sheet 提供了各种拆分技巧。文中列出了多种方法，并附带每种方法的解释。本文只介绍两个例子。

• 业务规则变化（Business Rule Variations）

• 主要工作（Major Effort）

• 简单/复杂（Simple/Complex）

• 数据变化（Variations in Data）

• 数据录入方法（Data Entry Methods）

• 推迟执行（Defer Performance）

• 业务（Operations）

• 拔出钉子（Break Out a Spike）

主要工作示例 根据所需工作量拆分用户故事。

[用户故事]作为用户，我想使用一些社交平台账户登录。

[拆分] - 作为用户，我想用 Instagram 帐户登录； - 作为用户，我想用 X (Twitter) 帐户登录； - 作为用户，我想用 Github 帐户登录。

*数据变化示例 基于 CRUD（创建、读取、更新、删除）的数据拆分验收标准

[用户故事]作为管理员，我想操作用户的数据。

[拆分] - 作为管理员，我想创建一个新的用户账户。 - 作为管理员，我想读取用户数据。 - 作为管理员，我要更新用户数据。 - 作为管理员，我要删除用户数据。

此外，还可以应用 INVEST 框架，稍后将对此进行说明。INVEST 框架提供了如何制作优质 PBI 以及分解 PBI 的方法。

史诗与用户故事

Epic 是 PBI 类型之一，位于主题和用户故事之间的第二层。Epic 比用户故事大，不能在一个冲刺周期内完成，它是多个用户故事的集合。如果发现一个用户故事太大，无法在一个冲刺周期内完成，就应该拆分成几个，可以将用户故事升级为 Epic，并在其下创建多个用户故事。

用户故事（句子）

用户故事（User Story）在句子上下文中是一个简单的句子，由谁、做什么和为什么组成，概述了用户想用产品做什么以及原因。这三个要素涵盖了所有必要方面，让我们无论身处何种岗位，都能获得全面的见解。无论你是开发人员还是业务人员，都应该能够完全理解需要构建什么来满足用户期望。然而，由于用户故事只提供了概述，缺乏细节，因此你需要知道如何编写带有验收标准的详细需求，下面将以如下图片为例加以详细说明。

作为句子的用户故事示例

结构：作为一名……，我希望……

示例：作为用户，我希望使用唯一凭证访问平台，以便安全使用。

可视化文档

使用可视化文档可以让团队更好的理解产品需求。这些图像可以有多种形式，如草图、线框图或复杂的设计，只要能清晰直观的表达产品的外观和功能即可。"用户故事"和"验收标准"都是基于文本的表达方式，在效果上有局限性，而可视化文档可以弥补这些不足。作为人类，我们倾向于通过视觉来处理信息，而使用视觉图像可以帮助我们更深入的了解产品。

验收标准

验收标准是敏捷方法的重要方面，用于表示需求并补充用户故事。验收标准可以用于验收测试，从而消除了单独编写文档的需要。在传统瀑布式项目中，需求和测试用例是分开记录的，这就造成了工作冗余和效率低下。验收标准被认为是敏捷方法的重大创新，也是专业性的标志，需要技能、知识和经验来实施，并对质量控制产生重大影响。

由 Cucumber 创始人 Aslak Hellesøy 开发的"小黄瓜语法"（Gherkin Syntax）是一种广泛使用的验收标准编写规范，由四个简单元素组成：场景（Scenario）、给定（Given）、何时（When）以及然后（Then），描述了软件应如何运行。该框架涵盖了软件行为的所有基本方面，是定义需求和验收测试的理想选择。

[介绍] "场景"描述测试（需求）的内容。"给定"描述用户采取任何行动前的初始情境或状态。"何时"描述用户采取的行动。"然后"描述用户行动的预期结果或后果。

[示例] 场景：成功登录。给定：用户已有账户。何时：输入电子邮件地址和密码。然后：按下登录按钮。然后：登录平台。

统一语言（Ubiquitous language）

统一语言是由 领域驱动设计 的作者埃里克-埃文斯（Eric Evans）提出，改进了用户故事（User Story）和验收标准（Acceptance Criteria）。统一语言是一本词典，定义了技术和业务专业人员之间的通用术语。使用统一语言并与团队成员分享，每个人都能准确理解用户想要做什么以及产品应如何运行，从而避免误解。

例如，你的产品有多种类型的用户，你将他们划分并定义为客户和管理员。在登录页面，将"用户"替换为"管理员"，指定哪些用户将使用该页面，如下所示。

[非统一语言] 作为用户，我希望使用独特的凭证访问平台，以便安全使用。

[使用统一语言] 作为管理员，我希望使用唯一的凭证访问平台，以便安全使用。

FR 和 NFR

编写"用户故事"和"验收标准"并不难，但需要考虑实际软件开发中的许多问题。请注意以下问题：

• 如果用户没有账户，系统应如何操作

• 如果有 100 个用户同时尝试登录，系统应该如何运行？

• 电子邮件地址和密码允许的最少和最多字符数是多少？

• 哪些浏览器与系统兼容--Safari、Chrome 还是 Edge？

• 哪些设备与系统兼容--智能手机、平板电脑还是笔记本电脑？

• 系统对色盲等残疾用户是否具有良好的可用性？

• 对于阅读小字有困难的老年用户来说，显示的字是否足够大？

• 不使用鼠标的用户能否轻松登录系统？

由于缺乏经验的软件工程师或项目经理往往会忽略这些具体要求，因此业余从业人员和专业从业人员之间存在着差异。这些详细需求可分为两类，即功能性需求（FR）和非功能性需求（NFR）。由于其复杂性，需求定义是最耗时的过程之一，需要全面的分析和更多的沟通。

INVEST 缩写

INVEST 框架是一套有助于确保用户故事质量的准则，首字母缩写分别代表独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimable）、小规模（Small）和可测试（Testable）。通过遵循这些标准，可以减少错误数量，避免不必要的需求，并做出更准确的估算。

• 独立：用户故事应该是独立的，这样才更易于管理和开发。依赖关系会导致编程和管理的复杂性。

• 可协商：用户故事应该是可协商的，允许开发团队对需求和估算进行讨论和完善。如果估算或范围不够现实，开发人员必须提出警告，并与产品负责人协商如何处理。

• 有价值：用户故事应能为用户带来价值，而不仅仅是产品负责人、Scrum Master 或开发人员。用户故事的价值需要在 Scrum 团队内外进行讨论，并通过反馈进行验证。

• 可估算：用户故事应该是可估算的，这样项目团队才能制定冲刺计划。

• 小：用户故事应该足够小，以便在冲刺阶段内完成，因为编程的复杂性会随着故事的增大呈指数增长，而非线性增长。一个大的用户故事可能会造成错误，导致估算不准确。因此，应将其拆分成几个较小的用户故事。

• 可测试：用户故事必须是可测试的。可测试性是通过验收标准来实现的，验收标准扮演着两种角色：需求和测试用例。

并非总能满足上述所有标准，但重要的是要牢记这些标准，并尽量满足，实践证明它们是切实有效的。例如，由于软件产品的性质，在某些情况下可能无法实现完全独立。不过，可以通过讨论使其具有一定程度的独立性。

三人原则

一旦创建了用户故事、验收标准和可视化表述，就必须对其进行审核，以避免出现任何错误。审查的最佳实践之一是"三人"原则。这项技术包括一名测试人员、一名业务人员和一名开发人员。如有必要，一个人可以扮演多个角色。

• "测试人员"：验收标准用于验收测试。测试人员或质量保证人员应参与了解和进行测试。

• "业务人员"：为确保产品符合预期，产品负责人（业务人员）必须负责检查和批准验收标准，无论这些标准是否由他们创建。

• "软件工程师"：为了评估可行性并预测任何技术挑战，开发人员必须仔细审核需求。需要注意的是，需求会对项目的范围和估算产生重大影响，因此开发人员必须与产品负责人进行协商。如果验收标准过多，开发人员应与产品负责人讨论是否可以减少其中一些标准以满足预期。

3C 模式（卡片、对话和确认）

罗恩-杰弗里斯（Ron Jeffries）是 敏捷宣言 的最初签署人之一，也是敏捷软件开发运动的创始人，他提出了 3C 模型。该模型概述了有效定义需求的三步流程，这三个步骤分别是卡片（Card）、对话（Conversation）和确认（Confirmation），每一步都建立在前一步的基础上。在第一步中，需求被记录在用户故事卡片中。第二步是"对话"，利益相关者详细讨论用户故事。第三步是"确认"，在用户故事中添加验收标准和可视化文档。了解这一基本流程对于编写高质量需求以及防止误解至关重要。

其他 PBI

产品待办列表不仅包含用户故事，还包含其他内容，如错误修复、变更需求、重构和维护任务等。据我所知，这些 PBI 并没有标准格式，所以需要在团队中定义自己的标准。上述技巧、技术和实践并不仅限于用户故事，也可用于其他类型的 PBI。INVEST 是个可用于任何类型 PBI 的最佳实践，甚至适用于瀑布式项目中的 WBS。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！