用户故事指南：停止编写功能，开始编写用户故事

在快速发展的产品开发世界中，很容易陷入罗列功能的陷阱。团队经常创建包含复选框的文档，比如“登录”、“搜索”或“导出为PDF”。这些都是功能。它们是输入项。它们描述的是系统做什么，而不是为什么重要。当你专注于功能时，可能会构建出无法真正解决实际问题的解决方案。

从以功能为中心的思维转向以用户为中心的写作，会彻底改变项目的整体方向。它将讨论的重点从技术实现转移到用户价值。本指南将探讨为何你应该停止编写功能，转而编写用户故事。我们将介绍一个优质故事的构成要素，如何定义验收标准，以及如何让团队围绕有意义的成果达成一致。

理解核心差异 🧠

在深入探讨具体操作之前，我们必须明确功能与故事之间的区别。功能是软件系统的一个独立功能或能力，它是静态的。用户故事是关于需求的对话的占位符，它是动态的。

考虑这句话：“增加暗黑模式。”这是一个功能。它告诉工程团队去修改CSS变量并切换UI元素。它没有说明谁需要这个功能，也没有解释原因。它假设价值是不言自明的。

现在考虑这个用户故事：“作为一名夜间工作的平面设计师，我希望切换到暗色界面，以便在长时间编辑过程中减轻眼睛疲劳。”这句话提供了背景信息。它明确了用户角色，也定义了带来的好处。

当你编写功能时，你只是交付一个任务清单。当你编写用户故事时，你则邀请协作。功能是输出，而故事是结果。

用户故事的构成 🧩

虽然经典格式很简单，但真正的深度在于细节。一个精心撰写的用户故事遵循特定结构，以确保所有相关人员都能清晰理解。

• 谁： 用户角色或用户类型。
• 做什么： 他们需要执行的动作或具备的能力。
• 为什么： 他们获得的价值或好处。

这种格式迫使作者思考其中的人性因素。如果你无法填写‘为什么’部分，那很可能你还没有一个有效的用户故事，而只是一个愿望清单上的项目。验证‘为什么’是优先级排序的第一步。

弱故事示例：

“作为一名用户，我希望上传一个文件。”

这太模糊了。是哪种文件？多大？如果失败会怎样？业务目标是什么？

强故事示例：

“作为一名项目经理，我希望上传大型CSV数据集，以便能够批量更新员工记录，而无需手动输入。”

它明确了角色、动作、限制条件（大型CSV文件）以及业务目标（无需手动输入即可批量更新）。

INVEST模型 📏

为了确保你的故事质量高，它们应遵循INVEST标准。这个框架有助于判断一个故事是否已准备好进入开发阶段。

• I – 独立性： 故事不应依赖于另一个故事首先完成。依赖关系会造成瓶颈。
• N – 可协商性： 细节并非一成不变。它们应在开发人员和产品负责人之间保持开放讨论。
• V – 有价值： 它必须为用户或业务创造价值。如果不能，为什么要开发它？
• E – 可估算： 团队必须能够估算所需的工作量。如果范围不明确，这个故事就太模糊了。
• S – 小型化： 它应该小到可以在一个冲刺或迭代内完成。
• T – 可测试： 必须有明确的标准来判断故事是否完成。

当一个故事不满足“可测试”标准时，它通常只是一个伪装成故事的功能列表。验收标准是让故事可测试的关键。

功能与用户故事对比 📊

可视化两者的区别有助于明确在何时使用哪种格式。尽管用户故事是开发工作的黄金标准，但功能在高层规划中仍然有其位置。

方面	功能列表	用户故事
焦点	系统能力	用户价值
背景	低（技术性）	高（人性化）
灵活性	僵化	可协商
结果	交付的功能	解决的问题
利益相关方支持	更难证明合理性	更容易证明合理性
最适合	路线图与高层规划	冲刺规划与执行

使用功能来规划路线图以显示方向，使用用户故事来定义冲刺中的工作。混淆两者会导致混乱。

编写验收标准 ✅

没有验收标准的用户故事是一个你无法兑现的承诺。验收标准定义了故事的边界。它们告诉开发者何时停止编码，告诉测试人员何时停止测试。

有效的验收标准应清晰、简洁且无歧义。避免使用“用户友好”或“快速”之类的表述，这些是主观的。应使用可衡量的术语。

不良标准：

• 页面应快速加载。
• 表单必须易于使用。

良好标准：

• 在4G网络下，页面必须在2秒内加载完成。
• 如果邮箱字段为空，表单必须阻止提交。
• 用户在提交后必须在1秒内收到确认消息。

一些团队使用“给定-当-则”格式来组织这些标准。这种方法与测试框架高度契合，确保逻辑得到覆盖。

• 给定： 初始上下文或状态。
• 当： 动作或事件。
• 则： 预期结果。

示例：

给定我已登录，当我点击导出按钮时，我应立即看到下载开始。

用户故事编写中的常见陷阱 🚧

转向用户故事并非一蹴而就。团队常常在一些常见错误上挣扎，这些错误会削弱整个流程。

1. “作为开发者”的故事

这是一个常见错误。像“作为开发者，我想要重构数据库”这样的故事是技术任务，而不是用户故事。尽管技术债务确实存在，但应从价值角度来表述。“作为系统，我希望能优化查询，从而降低用户加载时间。”如果业务方无法理解其价值，这项工作可能会被降级。

2. 巨型故事陷阱

史诗（Epics）是跨越多个迭代的大型工作集合，对于跟踪大型项目至关重要。然而，不要将史诗与用户故事混淆。史诗是一组用户故事的集合。不要试图像估算单个故事一样估算史诗，应将其拆解。

3. 忽视“为什么”

如果你只写了“做什么”却忘记了“为什么”，团队就会造出错误的东西。工程师需要理解问题才能找到最佳解决方案。如果没有“为什么”，他们可能会构建一个技术上更优越但无人需要的解决方案。

4. 过度设计定义

不要为每个故事都写一部小说。如果一个故事太复杂，就需要将其拆分。目标是清晰，而不是文档的完整性。对话本身就是文档。书面文字只是对那次对话的提醒。

协作胜于文档 🤝

关于用户故事最大的误解之一，就是认为它们是文档。它们不是。它们是对话的触发点。真正的价值在于产品负责人、开发人员和测试人员之间的讨论。

这通常被称为“三位朋友”对话。在故事进入冲刺之前，这三个角色应共同对其进行评审。

• 产品负责人： 明确业务价值和需求。
• 开发人员： 识别技术限制和实现细节。
• 测试人员： 识别边界情况和验收标准。

当你编写功能时，这种协作往往发生得太晚，代码已经写好了。而当你编写故事时，这种协作发生在工作开始之前，从而节省了时间和返工。

优先级与价值 📈

用户故事让优先级排序变得更容易。因为每个故事都与特定的用户价值相关联，所以更容易对其进行排序。你可以问：“哪个故事能为用户带来最大的价值？”

功能列表通常根据难度或技术债来排序。而用户故事则基于影响程度来排序。这种对齐确保团队始终在处理最重要的事情。

使用MoSCoW（必须有、应该有、可以有、不会有的）或加权最短作业优先（WSJF）等技术来为你的故事排序。这些方法依赖于故事格式所提供的明确价值定义。

处理技术需求 🛠️

那些不直接影响用户的需求怎么办？技术债、基础设施升级和安全补丁都是真实的工作。它们通常不符合“作为用户”的模板。

你对这些事项有两个选择。

1. 将其表述为系统故事： “作为一个系统，我希望能降低延迟，以确保应用在高负载下保持稳定。”
2. 使用技术探索： 如果价值未知，创建一个有时间限制的探索性故事，以获取足够的信息来估算实际工作量。

永远不要在不解释好处的情况下将技术工作隐藏在用户故事中。如果团队不理解其好处，就会认为这项工作是不必要的负担。

转变团队文化 🔄

从功能转向故事是一种文化转变。它需要信任。你必须信任你的团队能够理解用户。你也必须信任用户能够提供反馈。

从小处着手。选择一个即将到来的冲刺，要求所有事项都以用户故事的形式编写。举办一次培训会来解释“为什么”。如果故事不清晰，鼓励团队提出问题。

监控结果。衡量交付速度。衡量用户的满意度。当团队看到故事能带来更好的结果时，采用就会变得自然而然。

衡量成功 📊

你怎么知道这种方法是否有效？请关注以下指标：

• 减少返工： 更少的错误和误解意味着修复错误所花费的时间更少。
• 更快的入职培训： 当故事解释了价值时，新团队成员能更好地理解产品。
• 更好的利益相关者沟通： 当利益相关者看到用户价值而非技术任务时，他们会更加关注。
• 更高的速度： 在明确的验收标准下，团队可以更快地推进，同时不降低质量。

如果你看到了这些改进，说明你的工作流程已经成功转变。如果没有，就重新审视你的验收标准和协作习惯。

常见问题 ❓

我还能继续使用待办事项列表吗？

可以。待办事项列表只是工作列表的一种。你可以拥有一个用户故事的待办事项列表。事实上，用户故事的待办事项列表是最佳的待办事项列表，因为它按价值进行组织。

如果我不了解用户怎么办？

使用通用的角色。如果你没有具体数据，“作为客户”是可以接受的。然而，随着你收集到更多数据，应努力创建具体的角色。具体性有助于做出更好的决策。

这只适用于敏捷团队吗？

尽管在敏捷开发中很受欢迎，但这一原则适用于任何开发方法。任何希望打造有价值产品的团队，都会从关注用户成果而非功能输入中受益。

我该如何处理缺陷？

缺陷通常以故事的形式编写：“作为一个用户，我无法保存我的数据，因此我希望系统能自动保存我的进度。” 这将缺陷视为对价值承诺的失效。

关于价值的最后思考 🌟

软件开发的目标是解决问题。功能只是解决问题的工具。用户故事是确保你正确使用这些工具的地图。

通过将关注点从功能转向用户故事，你就能让团队与最重要的人——用户——保持一致。你减少了浪费，提高了清晰度，并打造出真正引起共鸣的产品。

从今天开始。查看你当前的待办事项列表。识别出功能，将其重写为故事。问一问“为什么”。你将立即看到其中的差异。