最佳实践：敏捷需求管理——如何写好用户故事丨IDCF

丁仿，圣略咨询首席敏捷教练，研发效能（DevOps）工程师（中级）课程学员

在敏捷项目管理中，用户故事（User Stories）是需求管理的核心工具。本篇文章将从用户故事的基本概念、编写技巧、常见误区及最佳实践四个方面展开，为大家提供一份详尽的指南。

一、用户故事的基本概念

1.1 用户故事的定义

用户故事是一种简单且非正式的描述，用于捕捉产品需求，从用户的角度出发，明确用户希望实现的功能或解决的问题。通常，一个用户故事格式如下：

作为[用户角色]，我希望[实现某个目标]，以便[达到某个目的]。

1.2 用户故事的特点

• 简单明了：用户故事应简短，易于理解，避免复杂的技术细节。

• 用户导向：始终从用户的需求和视角出发。

• 可讨论：用户故事的目的是引发团队讨论，以进一步细化需求。

• 独立性：每个用户故事应尽可能独立，以便能够独立开发、测试和交付。

• 可测试：每个用户故事应包含可验证的验收标准，以确定完成情况。

1.3 为什么要使用用户故事

1.3.1 促进沟通与协作

用户故事的简洁和用户导向性使得它们非常适合在团队中引发讨论和协作。通过用户故事，团队成员能够更好地理解用户需求，从而在开发过程中更好地合作，减少误解和沟通障碍。

1.3.2 提高灵活性

用户故事短小精悍，便于快速调整和迭代。这种灵活性使得团队能够更快地响应变化，不断优化和改进产品，确保最终交付的产品更符合用户需求。

1.3.3 聚焦用户价值

用户故事强调用户价值，每个用户故事都围绕用户希望实现的目标展开。这有助于团队在开发过程中始终关注用户需求，确保所开发的功能真正对用户有用。

1.4 用户故事与需求文档的区别

1.4.1 表达方式

传统需求文档通常详尽而繁琐，包含大量的技术细节和业务逻辑。而用户故事则简洁明了，关注用户需求和用户价值，以便于团队理解和讨论。

1.4.2 适应性

传统需求文档往往在项目初期就固定下来，后续修改难度大。而用户故事具有高度的灵活性，可以在开发过程中不断调整和优化，更好地适应变化的需求。

1.4.3 目标导向

需求文档通常以系统功能和技术实现为导向，缺乏用户视角。而用户故事则始终从用户角度出发，确保开发的每个功能都对用户有价值。

1.4.4 沟通方式

需求文档通常需要花费大量时间阅读和理解，可能导致沟通不畅。而用户故事简单易懂，能够快速引发团队讨论，促进沟通和协作。

二、编写高质量用户故事的技巧

2.1 清晰定义用户角色

清晰定义用户角色是编写用户故事的第一步。了解用户的背景、需求和痛点，有助于编写更贴近实际的用户故事。可以通过创建用户角色画像（Persona）来深入理解用户。

例子：

• 作为在线购物者，我希望在结账时看到商品的运费，以便了解总支付金额。

• 作为内容管理员，我希望能够编辑和发布文章，以便保持网站内容的更新和质量。

2.2 采用INVEST原则

高质量的用户故事通常遵循INVEST原则：

• Independent（独立的）：用户故事应独立存在，不依赖其他故事。

• Negotiable（可协商的）：用户故事应简洁，不拘泥于细节，以便在讨论中进一步完善。

• Valuable（有价值的）：用户故事应对用户或业务有明确的价值。

• Estimable（可估量的）：用户故事应有足够的信息，使团队能够估算工作量。

• Small（小型的）：用户故事应足够小，以便在一个迭代中完成。

• Testable（可测试的）：用户故事应包含明确的验收标准，以验证完成情况。

例子：

作为客户，我希望能够搜索产品，以便快速找到我需要的商品。

• Independent：搜索功能独立存在，不依赖其他功能。

• Negotiable：搜索结果页面的布局可以在讨论中确定。

• Valuable：用户能够快速找到所需商品，提高购物体验。

• Estimable：开发团队能够估算出搜索功能的开发时间。

• Small：搜索功能可以在一个迭代中完成。

• Testable：测试用例包括搜索特定商品和检索正确结果。

2.3 引入验收标准

验收标准是用户故事的关键组成部分，它定义了用户故事完成的条件。验收标准应具体、可测量，以确保开发团队理解需求并能验证完成情况。

例子：

作为在线购物者，我希望在结账时看到商品的运费，以便了解总支付金额。

验收标准：

• 用户能够在购物车页面看到每件商品的运费。

• 用户能够在结账页面看到总运费。

• 运费计算准确无误。

2.4 使用BDD（行为驱动开发）格式

行为驱动开发（BDD）提供了一种更结构化的用户故事编写方式，通过Given-When-Then格式，明确描述用户故事的场景、操作和预期结果。

例子：

作为在线购物者，我希望在结账时看到商品的运费，以便了解总支付金额。

验收标准：

Given 用户在购物车页面

When 用户点击结账按钮

Then 系统应显示商品的运费

2.5 定期审视和重构用户故事

用户故事并不是一成不变的。随着项目的进展和需求的变化，用户故事需要定期审视和重构，以保持其相关性和准确性。定期的需求审查会议是确保用户故事质量的有效方式。

例子：

一个初始用户故事可能是：

作为内容管理员，我希望能够编辑和发布文章，以便保持网站内容的更新和质量。

经过讨论和重构后，可能细化为多个小用户故事：

1. 作为内容管理员，我希望能够编辑文章标题和正文，以便修正内容错误。

2. 作为内容管理员，我希望能够添加和编辑文章标签，以便分类和检索文章。

3. 作为内容管理员，我希望能够将文章标记为发布或草稿，以便控制文章的发布状态。

三、常见误区及解决方案

3.1 用户故事过于详细

许多团队在编写用户故事时，倾向于将其写得过于详细，涵盖大量技术细节。这样会限制团队的灵活性和创造性。解决方案是保持用户故事简洁，详细信息可在讨论中补充。

例子：

过于详细的用户故事：

作为XX用户，我希望系统能够在数据库中存储我的订单信息，并在结账时从数据库中读取，以便确保订单数据的持久性。

改进后的用户故事：

作为XX用户，我希望系统能够保存我的订单信息，以便在结账时查看订单详情。

3.2 缺乏验收标准

没有验收标准的用户故事难以验证完成情况，容易导致需求偏差。解决方案是始终为每个用户故事定义明确的验收标准，确保其可测试性。

例子：

没有验收标准的用户故事：

作为用户，我希望能够搜索商品。

改进后的用户故事：

作为用户，我希望能够搜索商品，以便快速找到所需商品。

验收标准：

• 用户在搜索栏输入关键词后能够看到相关商品列表。

• 搜索结果包含商品名称、价格和缩略图。

• 搜索结果准确匹配关键词。

3.3 用户故事过大

过大的用户故事难以在一个迭代中完成，容易导致延迟。解决方案是将大用户故事拆分为更小的、独立的用户故事，遵循“Small”原则。

例子：

过大的用户故事：

作为普通用户，我希望能够管理我的账户信息，包括更改密码、更新个人资料和查看订单历史。

改进后的用户故事：

1. 作为普通用户，我希望能够更改密码，以确保账户安全。

2. 作为普通用户，我希望能够更新个人资料，以保持信息准确。

3. 作为普通用户，我希望能够查看订单历史，以便追踪我的购买记录。

3.4 忽视用户价值

一些用户故事关注技术实现而忽视用户价值，导致产品不符合用户需求。解决方案是始终从用户角度出发，确保每个用户故事都能为用户或业务带来明确的价值。

例子：

关注技术实现的用户故事：

作为开发者，我希望系统能够使用MySQL数据库，以便实现数据存储。

改进后的用户故事：

作为用户，我希望系统能够保存我的订单信息，以便在结账时查看订单详情。

四、最佳实践

4.1 用户故事工作坊

组织用户故事工作坊是提升用户故事质量的有效方式。在工作坊中，产品负责人、开发团队、用户代表等共同参与，通过头脑风暴和讨论，明确需求和编写高质量的用户故事。

例子：

在一次用户故事工作坊中，团队讨论了在线购物平台的需求。通过头脑风暴和讨论，生成了多个用户故事：

1. 作为购物者，我希望能够通过分类浏览商品，以便快速找到感兴趣的商品。

2. 作为购物者，我希望能够添加商品到购物车，以便一次性购买多件商品。

3. 作为购物者，我希望能够查看商品评价，以便做出购买决策。

4.2 持续用户反馈

持续收集和分析用户反馈，有助于及时调整用户故事，确保其符合用户需求。可以通过用户访谈、调查问卷、用户测试等方式，获取第一手用户反馈。

例子：

通过用户访谈了解到用户在结账时常常忘记使用优惠券，团队据此增加了一个新用户故事：

作为购物者，我希望在结账时提醒我使用优惠券，以便节省费用。

4.3 使用工具和模板

利用敏捷管理工具和用户故事模板，有助于规范用户故事编写流程，提高效率。例如，某项目管软件提供了丰富的用户故事模板和插件，方便团队管理和追踪用户故事。

例子：

在软件中创建用户故事模板：

作为[用户角色]，我希望[实现某个目标]，以便[达到某个目的]。

验收标准：

- [条件1]

- [条件2]

- [条件3]

通过模板，团队能够快速创建和填充用户故事，提高工作效率。

4.4 设立用户故事验收会议

设立定期的用户故事验收会议，由团队共同审视和评估每个用户故事，确保其质量和可行性。这不仅能提高用户故事的质量，还能增强团队的协作和沟通。

例子：

在一次用户故事验收会议中，团队审视了以下用户故事：

作为购物者，我希望能够通过分类浏览商品，以便快速找到感兴趣的商品。

经过讨论，团队补充了以下验收标准：

验收标准：

• 分类列表应显示在主页导航栏。

• 用户点击分类后应看到相关商品列表。

• 每个分类下至少显示20个商品。

4.5 与开发团队密切合作

用户故事不仅是产品负责人的工作，开发团队的参与同样重要。通过与开发团队密切合作，确保用户故事的可行性和实现路径。同时，开发团队的反馈也能帮助改进用户故事的编写。

例子：

在用户故事讨论会上，开发团队指出某些功能实现的技术难度较大，产品负责人据此调整了用户故事的优先级和实现方式：

原用户故事：

作为购物者，我希望能够在商品列表中看到实时库存，以便确认商品是否有货。

调整后用户故事：

作为购物者，我希望能够在商品详情页看到库存状态，以便确认商品是否有货。

通过调整，团队能够更高效地完成用户故事，满足用户需求。

结语

编写高质量的用户故事是敏捷需求管理中的重要一环。通过明确用户角色、遵循INVEST原则、引入验收标准、使用BDD格式、定期审视和重构用户故事，可以有效提升用户故事的质量，进而提高团队的工作效率和产品质量。同时，避免常见误区并采纳最佳实践，能够帮助团队更好地管理需求，满足用户的期望。希望本篇文章能为您在敏捷项目管理中提供有价值的指导和参考。

用户故事不仅是需求管理的工具，更是团队沟通和协作的桥梁。通过持续学习和实践，不断优化用户故事的编写方法，敏捷团队能够更好地响应变化，快速交付高质量产品，实现用户和业务价值的最大化。

参考书籍

1. 《用户故事与敏捷方法》 Mike Cohn著

2. 《Scrum精髓：敏捷转型指南》Kenneth Rubin