用户故事与用例兼容吗？

在网上搜索一番，敏捷智者们认为用例和用户故事是两种不同的东西：

• 迈克·科恩：用户故事不是用例
• 艾利斯泰尔·柯克本：用户故事之于用例，正如瞪羚之于凉亭
• 极限编程网：用户故事与用例的目的相同，但并不等同。

用例驱动的方法曾是需求获取中最热门的技术之一，但现在有些人认为这是一种过时的、老旧的方法，与许多问题相关，这些问题会导致你的团队无法真正实现“敏捷”：

• 前期需求——试图定义所有前期方面的细节，会导致大量精力和时间的浪费，因为大部分工作最终都需要重新做。
• 功能分解：用例的功能性自然导致系统在具体和抽象用例层面的功能分解，这些用例通过扩展和包含的用例关联关系相互联系。

如果你用关键词“用例 vs 用户故事”在网上搜索，会发现大量文章指出用例方法的缺点、问题或陷阱，而关于用户故事优势的列表甚至更长。有趣的是，IT行业变化如此迅速，而人们从过去所谓的“时髦”事物转向现在“更时髦”事物的速度更是惊人。

有趣的是，有些人喜欢以二元对立的方式看待事物，并通过象征性地关联潮流事物来追逐它们，而不是真正地实践。有些人甚至不愿让别人知道他们仍在使用用例，否则可能会被认为过时且老派。

现在有些人将用户故事与用例等同起来：

• 敏捷 = 用户故事，或敏捷 = 用户故事 + 敏捷
• 用户故事 = 刚好足够 & 刚好及时
• 用户故事 = 满足用户期望 & 令人满意
• 用例 = 前期详细的需求获取
• 用例 = <<包含>> + <<扩展>> = 功能分解
• 用例仅是“用户输入” → “系统响应”的模式
• 用例 = 旧式 & 过时

作为工具供应商，我们在方法、工具和技术方面保持中立。我个人想强调的是，我非常推崇敏捷开发、用户故事和敏捷流程。特别是与以下概念相关的底层原则和最佳实践：

• 需求发现而非需求交付
• 在上述原则下，敏捷开发过程呈现出两个重要特性：
  • 刚好及时
  • 刚好足够

（我将撰写更多与上述原则相关的个人见解文章，这与我1992-1995年博士研究领域密切相关——元模型与模式转换）

现在，让我们回到“用例 vs 用户故事”这个话题。事实上，那些重量级的敏捷智者们已经投了票，难道我还要如此固执地试图推翻他们的“投票”，声称它们相似甚至相同吗？

让我举一个例子，来说明用户故事是否真的与用例“如此不同”：

示例

好的用户故事远不止是一些陈述。一个标准的用户故事由三个部分组成，通常被称为三个C。

每个用户故事的第一个“C”应遵循标准化的格式：

作为一个[角色]，我希望[做某事]，以便[获得好处]

这是用户故事卡片中必须包含的最基本内容。

对话是用户故事第二个“C”的内容，代表最终用户、项目负责人和开发团队之间的讨论。在这些对话中，记录了口头讨论，以及其他许多有用的信息，例如电子邮件、线框图或项目相关的其他内容。

用户故事的最后一个“C”是确认，即验收标准，用于确认用户故事已被正确实现并成功交付。

让我进一步详细说明如何开发用户故事的确认部分。在这里，我们使用最著名的模板——Gherkin，它采用Given-When-Then公式来指导用户故事验收测试的编写：

• (Given.. and) 某些上下文
• (When.. and) 执行某些操作
• (Then.. and) 执行某些操作

像Cucumber和Jbehave这样的测试框架鼓励使用Given/When/Then模板进行自动化测试，尽管它也可以纯粹作为一种启发式方法使用，而无需依赖任何工具。

让我们收集“注册课程”用户故事的所有信息，并将其整理为3C格式：

我采用了常用的3C格式来表示“注册课程”用户故事。同样，我也采用了最广泛使用的格式来描述同一“注册课程”用例，该用例由用例描述详细说明。我为用户故事的确认部分（最后一个C）的步骤编号，这些编号与我在用例描述中添加的步骤编号相对应。它们是同一“九步”场景，但以不同顺序应用于每种方法。我认为这两种模型表示方式对于各自的倡导者和追随者都是可以接受的。那么问题再次出现：用户故事与用例非常相似，但又有所不同，还是步骤顺序导致了对用例方法的各种批评？

语义等价但含义不同？

让我们调查一下建模领域是否存在类似情况，以便与当前情况对比，或这或许能帮助我们独立判断“用户故事 vs 用例”，而不是盲目追随大众或像鹦鹉一样重复智者的话。

示例：语义等价

在UML中，我们可以使用顺序图来描述用例场景，但通常不会使用协作图来实现相同目的；尽管这两种图在语义上是等价的。换句话说，顺序图和协作图中参与场景的对象数量相同，传递的消息数量也相同，且这些消息在相同的一组对象之间传递以完成场景中的任务。然而，前者侧重于时间，后者侧重于空间。在使用场景建模时，顺序图更为直观；而协作图则更适合用于建模对象之间的结构关系。例如，您希望将参与对象的场景以结构化方式表示到MVC框架（模型/视图和控制层）中。

我个人认为，使用用户故事并不会让我的团队变得敏捷，而使用用例会让我的团队变得“过于前置”。最重要的是我们以何种心态和最佳实践来应用和使用这些工具。我并不太担心别人认为我“老派”或过时，因为我实际上正在践行敏捷。

我仍然记得结构化分析与设计的时代，也许我们可以在1980年代没有OOP支持的情况下，通过ADA中的抽象数据类型来应用面向对象的分析与设计原则，对吧？不幸的是，你甚至可能从未接触过抽象数据类型的概念！哦！天啊，我无意中透露了——我老了吗？还是我应该积极一点——经验丰富？