在快速发展的软件开发世界中，清晰就是货币。沟通有效的团队能够更快地交付更优质的产品。这种沟通的核心在于用户故事。它不仅仅是一个待办事项列表中的任务；它是一场对话的承诺，是价值的载体，也是对齐的工具。
本指南将带你逐步了解如何编写高质量的用户故事。我们将从基本定义出发，逐步深入到映射和优化等高级技巧。到最后，你将掌握一个实用的框架，能够写出开发者能理解、测试人员可验证、利益相关者可优先处理的故事。让我们开始吧。
用户故事到底是什么？🤔
用户故事是从希望获得新功能的人的角度出发，对一个功能的简短而简单的描述，通常指系统的用户或客户。它不是一份规格说明书，而是一场对话的占位符。
与传统的、可能僵化且冗长的需求文档不同，用户故事旨在轻量化。它们关注的是谁，是什么，以及为什么.
标准格式
大多数敏捷团队使用标准模板以确保一致性。该模板有助于将重点放在用户价值上，而非技术实现细节。
- 作为：我想要：以便：
- 作为： [用户角色]
- 我想要： [操作或功能]
- 以便： [收益或价值]
设想一个用户需要重置密码的场景。一个写得不好的需求可能是：“系统应允许通过电子邮件重置密码。”而一个用户故事则会这样表述：
- 作为注册用户
- 我想要通过电子邮件重置我的密码
- 以便我可以在不联系客服的情况下恢复对账户的访问
这种格式迫使团队思考背后的价值。它将对话从“我们如何构建这个按钮”转变为“用户为什么需要访问这个按钮”。
INVEST模型：优质故事的标准 🌟
并非所有用户故事都具有同等质量。有些模糊不清，有些过于庞大，有些在技术上根本无法测试。为了筛选出低质量的条目，团队通常使用INVEST模型。这个缩写代表独立性、可协商性、价值性、可估算性、小规模和可测试性。
独立性
一个故事应尽可能独立。如果一个故事必须等到另一个故事完成后才能讨论，就会造成瓶颈。虽然软件中存在依赖关系，但应明确管理。理想情况下，团队应能独立选取一个故事并完成，而无需依赖特定的上游任务。
可协商性
故事描述不是一份合同，而是一次对话的提醒。细节应在开发团队和产品负责人之间进行协商。这种灵活性使团队能够提出比最初请求更优的技术解决方案。
价值性
每个故事都必须带来价值。如果一个故事无法为用户或业务带来价值，就不应存在。价值可以是功能性的、技术性的（如减少技术债务），或与合规相关。如果你无法阐明其价值，这个故事很可能没有必要。
可估算性
团队必须能够估算完成该故事所需的工作量。如果一个故事过于模糊或依赖未知技术，就无法估算。在这种情况下，故事需要进一步拆分，或通过技术探索（spike）进行研究。
小规模
故事应足够小，能在单个冲刺内完成。如果故事过大，就会变成一个项目。大型故事难以测试、难以估算，也难以优先排序。将其拆分为更小的增量，有助于获得更快的反馈。
可测试性
一个故事必须有明确的验收条件。如果你无法为它编写测试用例，就无法验证其是否完成。这直接关联到“完成的定义”。
| 标准 | 应提出的问题 | 示例问题 |
|---|---|---|
| 独立性 | 我们能否在不依赖其他故事的情况下构建这个？ | “登录”依赖于“用户资料” |
| 可协商性 | 我们是否愿意改变解决方案？ | 使用“API X”而非“功能Y” |
| 价值性 | 这能帮助用户吗？ | “更改字体颜色以匹配品牌” |
| 可估算性 | 我们知道这需要多长时间吗？ | “与未知第三方集成” |
| 小规模 | 这个能在一次冲刺中完成吗？ | “构建整个仪表盘” |
| 可测试的 | 我们可以为此编写一个测试吗？ | “让应用运行得更快” |
逐步指南：编写用户故事 🛠️
编写用户故事是一个迭代的过程，很少能一次完成。以下是一种系统化的方法，用于起草能够经得起推敲的故事。
步骤1：识别用户角色
在写下任何一个字之前，先明确你为谁而写。面向管理员的故事与面向普通浏览者的故事是不同的。使用角色卡或现有资料，确保你理解他们的目标和限制。
步骤2：定义动作
明确用户想要做什么。避免使用“管理”或“处理”等模糊动词。使用“点击”、“保存”、“删除”或“导出”等具体动作动词。这种清晰性有助于开发人员理解所需的具体交互。
步骤3：阐明价值
这是最关键的部分。用户为什么关心？如果你跳过“以便”这一部分，就可能开发出无人使用的功能。要经常挑战团队，让他们解释其带来的好处。
步骤4：添加上下文和约束条件
有时一个故事需要额外的上下文信息，例如技术限制、法规要求或边缘情况。应将这些信息放在描述字段中或作为附加到故事的评论，而不是放在标题中。
步骤5：对照INVEST标准进行审查
在将故事加入待办事项列表之前，用INVEST标准进行检查。它是否符合要求？如果不符合，就进行优化。现在花五分钟优化一个故事，总比在开发过程中花五小时修复误解要好。
验收标准：完成的边界 ✅
验收标准定义了故事的边界。它们是故事被视为完成所必须满足的条件。如果没有这些标准，“完成”就是主观的。
验收标准的类型
有几种方式可以组织验收标准。最有效的方法通常取决于团队的工作流程。
- 基于场景：使用Given/When/Then语法有助于理清逻辑流程。
- 清单：简单的项目符号，用于验证特定结果。
- 规则：必须满足的数学或逻辑规则。
- 用户流程：描述用户在使用该功能时的完整旅程。
验收标准示例
让我们来看看不同故事类型下标准有何不同。
| 故事重点 | 验收标准示例 |
|---|---|
| 功能 | |
| 安全 | |
| 性能 | |
| 可用性 |
编写有效标准
编写这些标准时，应保持其原子性。不要将多个条件合并到一个句子中。每个标准应是一个单一可测试的条件。这使得测试人员更容易验证工作成果，也让开发人员清楚地知道具体需求。
避免使用“快速”、“简单”或“现代”等主观词汇，应替换为可测量的术语，如“低于200毫秒”、“少于3次点击”或“符合WCAG 2.1标准”。
用户故事地图：可视化用户旅程 🗺️
有时，仅列出故事是不够的。你需要看到整体图景。用户故事地图是一种用于可视化用户体验并将故事组织成连贯发布计划的技术。
构建骨架
首先识别用户执行的主要活动。这些就是你的横向骨架。对于一个电子商务网站，这些活动可能包括：浏览、搜索、添加到购物车、结账和管理账户。
添加步骤
在每个活动下方，列出所需的特定步骤。这些就是你的用户故事。按执行顺序将它们水平排列。这构成了用户旅程的主干。
优先排序以准备发布
地图构建完成后，可以横向切分。最上层代表最小可行产品（MVP）。下一层增加更多价值。这有助于团队根据用户价值而非技术便利性来确定优先开发的内容。
地图绘制的好处
- 提供产品的整体视图。
- 识别用户流程中的缺口。
- 促进更好的规划和发布调度。
- 促进设计师与开发人员之间的协作。
细化与估算 📏
编写故事只是完成了一半工作。团队必须理解其中的范围和工作量。这发生在细化会议期间。
澄清模糊之处
在细化过程中，团队会提出问题。例如：“如果用户没有网络会怎样？”“我们如何处理重复的邮件？”这些问题揭示了隐藏的复杂性。不要等到冲刺开始才提出这些问题。
估算故事
团队通常使用相对估算而非小时数。这承认了估算时间是困难的，且因人而异。常用的方法包括：
- 规划扑克：团队成员使用卡片投票决定规模。
- 故事点：一个数值，代表复杂性、工作量和风险。
- T恤尺码： 小号、中号、大号、加大号，用于高层级规划。
无论采用哪种方法，目标都是达成共识。如果团队意见分歧较大，故事就需要进一步拆分或进行更深入的研究。
常见的陷阱，应避免 ⚠️
即使是经验丰富的团队，在处理用户故事时也会犯错。意识到这些常见陷阱可以节省大量时间和精力。
1. 将技术性任务写成用户故事
像“重构数据库模式”或“升级库版本”这样的任务很重要，但它们不是用户故事。它们是技术任务。虽然这些任务应该存在于待办事项列表中，但应将其视为技术债务或基础设施工作，而不是直接的用户价值。如果你必须为此写一个故事，可以这样表述：“作为一个开发者，我希望更新库，以避免安全漏洞。”
2. 忽略“以便”部分
跳过价值声明会导致功能蔓延。团队会构建看起来不错但并未解决实际问题的功能。必须始终要求团队证明其价值。
3. 描述内容过于冗长
一个故事的描述不应像小说一样。如果一个故事需要10页的文档才能说明，那就太大了。应该将其拆分。描述应为简要总结，必要时可附上详细规格的链接。
4. 将故事视为固定合同
记住故事具有可协商性。如果团队发现更好的解决方案，应该提出。对最初要求的僵化遵守会抑制创新。
5. 忽略边缘情况
故事通常只关注正常流程。测试人员和开发人员必须明确指出边缘情况。如果输入为空会怎样？如果网络中断会怎样？这些都必须包含在验收标准中。
协作与沟通 🗣️
用户故事是一种协作工具。它将产品负责人、开发团队和测试人员凝聚在一起。如果没有沟通，故事就只是屏幕上的文字。
三友会议
一种常见做法是“三友会议”。这包括产品负责人、开发人员和测试人员在故事进入冲刺前共同讨论。他们一起审查故事，以确保理解一致并覆盖全面。
- 产品负责人： 确认价值和优先级。
- 开发人员： 确认技术可行性和复杂性。
- 测试人员：确认可测试性及边缘情况。
持续反馈
不要等到冲刺评审才获取反馈。尽早与利益相关者分享故事的草稿，获取他们对措辞和价值主张的意见。这可以降低构建错误内容的风险。
视觉辅助工具
仅靠文字是不够的。使用线框图、原型图或图表来补充故事。一张图片比一段文字更能快速解释复杂的流程。将这些成果直接附加到故事记录中。
关于故事编写的最后思考 🎯
掌握用户故事的艺术需要练习。这要求思维方式从撰写需求转变为促进对话。目标不是创建完美的文档，而是建立清晰的理解。
从小处着手。专注于INVEST模型。确保每个故事都带来价值。如果感觉故事过大，愿意进一步拆分。让团队参与编写过程。
当执行得当时，用户故事将成为交付工作的核心。它们能统一团队，明确愿景，并确保每一行代码都有其目的。持续优化你的方法，让故事引导你的工作。