为什么说用户故事不适合表达需求

图片左侧描绘的是一堆令人困惑的用户故事。试着浏览一下，看看是否能看出要点 — — 你不会的。

图片右侧通过使用描述性标题总结功能，展示了一种清晰明了的替代方案。易于阅读和理解。

该图巧妙地说明了如何以错误的方式应用用户故事，使其变得复杂且难以理解。不幸的是，根据我的经验，大多数人完全按照图片中传达的方式应用用户故事。

然而，当你以这种方式使用用户故事时，你就错过了它们的全部意义，也没有获得它们的好处。理论上，你可能可以勾选“用户故事”框，但实际上，它离用户还很远。

让我们了解用户故事的本质，以说明为什么你不应该这样使用它们。

1. 用户故事绝不是虚构的

它被称为用户故事是有原因的。

它不叫需求故事、规范故事或特性故事。用户故事必须是关于用户的真实故事。

如果你不用先与真正的用户或客户交谈就能当场编造出一个用户故事，那么它就不是一个用户故事，而是一个用户童话。它只是你想象出来的。

如果您编造了完整的用户故事，您怎么能期望在现实世界中获得成功呢？

用户故事是一种非虚构作品，基于定性和定量数据。用户故事之所以有效，是因为它们讲述了关于谁将使用该产品、他们希望实现什么以及预期收益的事实故事。

2. 用户故事不是需求载体或功能描述

某事物应该如何运作与它应该实现的目标是不同的。

让我们通过讨论用户故事格式来刷新我们的记忆：

作为 < 用户类型 >，我想要 < 某个目标 >，以便 < 某个原因 >

用户故事描述了一种想要出于特定原因实现某个目标的用户类型。这与您的产品的功能无关。

需求和功能用于描述产品应如何工作。但您需要从客户（用户故事）开始，然后逆向而行。您可以从用户故事开始。

问题是，用户故事通常太大，需要拆分。正如我们在敏捷术语中所说，它们是史诗——太大而无法直接和立即处理。

将“史诗”用户故事拆分成更小的用户故事通常不是一个好主意。史诗是关于用户及其期望实现的利益。然后，当你将其拆分成更小的部分时，它通常不再是关于用户，而是关于它应该如何工作。你实际上是将用户故事拆分成功能 故事。

在这种情况下，用户故事就不再适用了。就像图片中那样，它们变得太复杂，变得毫无用处。

当你难以用用户故事格式表达较小的内容时，你就会注意到这一点。你需要认真思考，找出用户的子目标，并阐明这些子目标背后的原因。

问题在于，用户通常并不真正关心这些子目标或产品产生的中间利益，这些往往只是达到目的的一种手段。用户故事是从产品的角度构建的，而用户利益只是在一系列步骤的最后才获得的。

在这种情况下，不要使用用户故事来拆分工作。存在许多更好的替代方案，它们不需要您发明与用户实际想要实现的目标和原因相差甚远的子目标和理由。

以下是一些鲜为人知的用户故事替代方案：

• 工作故事
• 问题故事
• 改进案例
• FDD 功能

3. 用户故事不是你写下来的东西

我意识到这一点可能违反直觉。请耐心听我说。我会尽力解释清楚。从需求和验收标准的角度来看，我们认为合同最重要——我们写下的内容。如果您仅将用户故事作为要满足的合同，您将永远无法充分发挥其优势。

用户故事不是关于你写下的内容，而是关于理解的内容。共识应该优先于试图达成完美合同。这也是为什么敏捷宣言包含这样一句话：“客户合作优先于合同谈判”。你最初达成的协议并不比你想要实现的目标重要。

如果没有共同理​​解，你的合同就永远不会完美，即使你对合同的描述非常完美。这听起来很奇怪吗？请允许我详细说明一下。

即使达成共识，合同也不会完美无缺，但团队的成立是为了最大限度地提高他们做出正确决策的机会。当你做复杂的工作时，合同难免会有缺陷。

更抽象一点：当我开始担任产品负责人时，我曾担任过软件测试员和业务分析师。写下它的工作原理是我的强项。

但我发现，无论我把所有内容记录得多么完美，人们还是会犯错误。问题是，我写下的任何东西都是我自己的想法，而不是团队的想法。在改进过程中，团队会盯着长长的项目要点列表，然后就不再关注它了，因为它看起来很棒。此外，他们觉得解决方案的所有权在我手中，而不是整个团队。

重要的不是你写下了什么，而是他们理解了什么。这似乎是一个微不足道的区别，但事实并非如此。对话才是最重要的。你写下的东西可以提醒人们最初的对话。

当你提供完美的用户故事时，团队会陷入一种虚假的安全感，认为关注并不重要。通过一起编写所有内容，它就是一个团队合作的产品，你可以最大限度地提高共同理解。

正确完成用户故事

用户故事的粒度应足够高，以描述真实的用户目标并解释我们的用户为何想要实现该目标。一旦拆分用户故事，请当心，因为您可能进入了迪士尼乐园，而不是谈论扎根于现实的用户故事。

在本文开头的示例中，用户故事描述了登录功能。诸如登录之类的功能非常基础、基本（且商品化），因此用用户故事来描述它们通常没有多大意义。

您可以将用户故事拆分成更多用户故事，但您经常会自欺欺人，因为它不再是用户故事，而是功能故事。这也很酷，但用户故事存在很好的替代方案，可以更好地解释您要做的事情。

无论你使用什么模板来描述你想要构建的东西，你能做的最重要的事情就是进行对话。共同理解是通过相互交谈来建立的，而不是躲在屏幕后面盯着可能被误解的文字。

除非有人通过记住一次精彩的对话真正理解它的意义，否则无论你写下什么都无关紧要。

Jeff Patton将其比作两个不同的人观看同一张假日照片：对于真正在场的人来说，它描绘的画面与没有在场的人来说完全不同。只有一起去那里，你们才能达成共识，讲述一个故事，而单凭照片（或你制作的任何需求文档）是无法创造的。

作者：Maarten Dalmijn