用户故事与用例

Question

用例只有多个用户故事吗？

使用用户故事而不是用例的好处是什么好处。

Answer 1

实际上，原始用例（请参阅 雅各布森的奥斯）非常轻巧，就像用户故事一样。随着时间的流逝，他们演变为“用例”的通用格式，现在是一个复杂的文档，其中包含输入，输出，继承，使用关系，伪代码等。程序员通常，尝试将所有内容转换为编程。

无论如何，试图定义如何区分“用例”和“用户故事”“场景”非常徒劳的，因为很难找到两个同意的当局。

就个人而言，我发现模式“ [Actor] [动词] [名词]获取[业务价值]”有帮助。如果它已经结束了一段文本，那么它可能太大了。

Answer 2

当涉及到它时，“敏捷”只是一个标签，人们完全不同意它的含义。同样，人们将非常不同的事物称为“用例”。

根据我的经验，两者之间的主要区别是用户故事专注于用户，通常更短，更正式 - 理想情况下，它应该很容易适合明信片。它可能没有提供错误处理等的详细信息。

用例 能够 要变得更加正式（尽管有些人也非正式地编写它们） - 他们专注于与系统的每一次互动，并且很可能会在同一用例中更详细地了解几个不同的系统/演员/等。

不过，这只是我的经验 - 每个人都有可能以不同的方式使用这些工具。我不会对标签太挂好 - 只需使用适合您的项目的功能即可。

Answer 3

用例不是用户故事的汇编。

用户故事通常比用例要简单得多。我认为用例试图绝对涵盖与系统某些方面的行为有关的一切。也就是说，所有行为，所有错误路径和所有异常处理。

用于用户的推荐模板是：

作为（角色）我想要（某物），以便（受益）

（感谢Mike Cohn提供此简单模板）

这样表达的行为的描述更加敏捷。

这种模板使您可以使用不同级别的细节来描述行为。例如：

1. 对于那些在以后的冲刺中实现的故事，您可以以高水平的方式描述行为，例如，作为OPS团队成员，我想远程监视系统，以便在路上确定系统健康。
2. 对于在下一个冲刺中实现的那些故事，您可以描述行为是一种稍微详细的方式，例如，作为OPS团队成员，我想只有专用的OPS登录名，以便我可以检查系统健康。
3. 对于在当前冲刺中实现的那些故事，您可以以高度详细的方式描述行为，例如作为OPS团队成员，我想拥有一个Web界面，以便我可以检查Ingest FTP服务器的当前状态。

恕我直言，用用例雕刻在石头上！因此，在初始版本之后可能要更新是一个问题。

Hth

干杯，

抢

Answer 4

用一个词，不。

用例通常是详细的规格，列出了某些特定功能如何工作，或者特定用户将如何利用系统。它通常是在特定用户（或演员）的声音中，并且是相当独立的。

另一方面，用户故事是“讨论邀请”。通常是一个或两个句子。 这里 是一个很好的资源。还有迈克·科恩（Mike Cohn） 应用用户故事 值得。

典型的语法是“作为u003Cuser>我需要u003Cfunctionality>达到u003Cbusiness value>“或”u003Cbusiness value>作为一个u003Cuser>我需要u003Cfunctionality>“这驱动了故事的价值。

用户故事是 不是 本来是独立的，但要邀请开发人员与客户（或客户代理）之间的故事讨论。

Answer 5

您可以将用户酶视为用户故事，而不是相反。用户酶将涵盖故事的多个“结局”，特殊要求（例如，必须以格式XYZ输入表单字段，并显示错误消息123如果用户以错误的格式输入字段）。此外，用户酶可以包括对外部文档的其他参考，例如安全准则。

Answer 6

用户故事 是用于敏捷开发中的工具，以确保您创建用户真正需要的产品。

• 它相当描述 为什么 您应该做这个或该功能而不是 如何 或者 什么功能.
• 从我的个人经验来看，这是平衡客户和开发人员创建更好产品的愿景的好方法。

与我们不同用例 专注于谁使用您的产品。这是区别。

我会说，敏捷开发人员作为用户故事没有其他此类工具。如果您想学习如何成功编写它们，请查看 这个 邮政。