Ben Grimwade 分享了他对用户故事的看法，它们为何重要以及它们如何融入更广泛的敏捷框架。
译自 How To Write User Stories: A Beginners Guide，作者 Ben Grimwade。
我目前在金融科技领域管理着几个工程团队。我们的工作涉及大型分布式系统和严格的要求。虽然我最初使用的是更“传统”的流程，但我最终发现了敏捷和用户故事。
说实话，我第一次听说用户故事时，觉得它们太简单了。然而，一旦我尝试了它们，我就意识到它们带来了清晰度并减少了团队的困惑。
在本文中，我想分享我对用户故事的看法，它们为什么重要以及它们如何融入更广泛的敏捷框架。我还将讨论敏捷和瀑布模型之间的区别，解释积压工作如何运作，并向您展示冲刺如何组织一切。阅读完这篇博文后，您应该对如何有效地使用用户故事有一个很好的了解。
敏捷在2001年获得发展势头，当时一群开发者在犹他州会面，讨论改进软件构建方法。他们意识到传统方法往往会将团队锁定在难以更改的计划中，即使出现了新的信息。敏捷宣言诞生于这次会议。它重视可工作的软件、团队协作和对不断变化的需求的开放性。
许多方法——例如 Scrum 和极限编程——都源于这些核心思想，强调更短的周期、频繁的反馈和较小的功能发布。
用户故事是一个简短的陈述，它告诉你谁需要什么，他们需要什么，以及为什么它有价值。你通常可以通过句子结构来识别它：
“作为一名[用户类型]，我希望[行动]，以便[目标]。”
例如：“作为一名经常购物的顾客，我希望保存我的支付信息以便下次结账更快。”
这句话突出了用户（经常购物的顾客）、行动（保存支付信息）和原因（更快结账）。它迫使你在追求设计或技术细节之前考虑用户的目标。
如果你写得好，团队会立即看到他们帮助的是谁以及解决了什么问题。这将工程师与客户联系起来，并确保他们交付所需的东西。用户故事鼓励更以用户为中心的思维方式。
你可以将广泛的功能分解成更小的用户故事。此外，你可以根据哪些目标最重要来优先考虑这些故事。
此外，如果业务需求发生变化，你可以轻松地在积压工作中重新排序它们。
团队可以讨论每个故事，并确定他们是否理解它。此外，测试人员和 开发人员可以提出关于边缘情况的问题，以便在编码开始之前澄清所有内容。
用户故事往往保持在较高的层次，但验收标准带来了具体的细节。可以将它们视为一份清单，用于阐明如何确认故事已完成。例如，如果你的用户故事说：
“作为一名访客，我希望注册每周新闻通讯，以便了解新产品的信息，”
验收标准可能如下所示：
- 系统只接受有效的电子邮件地址。
- 用户会看到成功注册的确认信息。
- 系统向新订阅者发送欢迎消息。
有了这些要点，开发人员和测试人员就知道成功是什么样子了。产品负责人也可以查看是否缺少任何内容并添加更多细节。
积压工作是存储所有用户故事、错误报告和未来改进想法的地方。产品负责人（或任何管理积压工作的人）会对这些项目进行排序，以便最高价值的任务显示在顶部。
例如，如果我正在开发一个在线市场，一个高优先级的用户故事可能是：
“作为一名卖家，我希望快速列出我的产品以吸引更多潜在买家。”
积压工作中较低的项目可能涉及可选功能或可以等到核心产品稳定后再执行的任务。
团队还将改进这些项目，添加验收标准或澄清细节。这个过程，通常称为“积压工作梳理”，确保它足够清晰，以便在你的团队准备好处理一个故事时随时处理。
Sprint是一个短周期——通常为两周——团队从中选择一些故事并承诺完成它们。这通常包括：
产品负责人提出最高优先级的项目。然后，团队提出问题，评估工作量，并决定要管理多少个故事。
团队在Sprint期间构建、测试和审查每个故事。他们还使用显示哪些故事是“待办”、“进行中”或“已完成”的看板或工具来跟踪进度。
最终，团队向利益相关者展示已完成的故事，利益相关者可以提供反馈或请求更改。这可能会导致积压中出现新的或更新的故事。
团队反思Sprint的进展。是否有任何障碍？他们能否改进流程？这个持续改进的循环是敏捷的关键部分。
像“作为用户，我想做一些事情”这样的陈述并不能指导团队——清晰度很重要。确保遵循“作为[用户类型]，当我[执行特定操作]时，我[获得结果]”。
例如，“作为管理员用户，当我正确输入用户名和密码并登录时，我将被重定向到管理员控制台。”
相反，如果你在一个故事中塞入过多的技术细节，你可能会忽略主要用户目标。保持故事本身简洁，并将更深入的笔记存储在其他地方。
你不需要：“作为已登录但不是管理员用户的用户，当我输入管理员URL并尝试访问它时，我将看到错误消息“您没有权限查看此资源”，该消息以粗体、红色、斜体文本显示，并转换为本地语言，并在用户停留期间一直显示在屏幕上。”
这太长且过于复杂。
你需要：“作为标准用户，当我尝试访问管理员控制台时，会显示错误消息。”
其余细节留给验收标准。
如果你跳过验收标准，你可能不知道故事何时完成。此外，测试人员将没有直接的方法来验证工作。
“作为客户，我想跟踪订单、更新我的个人资料和请求退款。”这三个是三个独立的需求，将它们分开可以简化测试和完成。
从严格的流程转向敏捷，我发现用户故事很容易理解，但很难掌握。有时，我的团队编写的故事过于宽泛或过于狭隘地关注代码。多年来，我们已经了解到，最好的用户故事听起来像是用户在谈论他们想要完成的事情，而不会深入到技术细节中。
我还发现验收标准起到了温和的安全网的作用。它们确保每个人（开发人员、测试人员和产品负责人）在故事被认为“完成”之前都同意故事必须做什么。这种一致性减少了误解和后期意外。
用户故事是保持软件项目按计划进行的直接方法。它们将对话从技术任务转移到实际用户目标。验收标准为每个故事提供可衡量的目标，而敏捷实践（如Sprint和频繁审查）则创造了定期与利益相关者联系的机会。你的积压工作组织所有内容，并帮助你决定接下来要处理哪些故事。一旦Sprint开始，你的团队就可以专注于少量故事，交付可工作的软件并收集宝贵的反馈。