requirements - 用户故事与用例

Question

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

使用用户故事而不是用例有什么好处……反之亦然……何时使用一个而不是其他……所有敏捷方法都使用用户故事吗？

Answer 1

实际上，最初的用例（参见Jacobson 的 OOSE）非常轻量级，就像现在的用户故事一样。随着时间的推移，它们发展到现在“用例”的通用格式是包含输入、输出、继承、使用关系、伪代码等的复杂文档。程序员通常会尝试将所有内容转换为编程。

无论如何，试图从“场景”中定义“用例”与“用户故事”的区别是徒劳的，因为很难找到两个同意的权威。\

就个人而言，我发现模式“[Actor] [verbs] [noun] to get [business value]”很有帮助。如果它超过了一段文字，它可能太大了。

Answer 2

归根结底，“敏捷”只是一个标签，人们不同意它的确切含义。同样，人们将非常不同的事物称为“用例”。

根据我的经验，两者之间的主要区别在于用户故事以用户为中心，并且通常更短且不那么正式——理想情况下，它应该很容易放在明信片上。它可能没有提供错误处理等的详细信息。

用例可以更加正式（尽管有些人也可以非正式地编写它们）——它们关注与系统的每次交互，并且很可能在同一个用例中更详细地介绍几个不同的系统/参与者/等。

不过，这只是我的经验——每个人都有可能以不同的方式使用这些工具。我不会太在意标签——只要使用对你的项目有用的东西。

Answer 3

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

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

推荐给用户的模板是：

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

（感谢 Mike Cohn 提供这个简单的模板）

像这样表达的行为描述更加灵活。

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

1. 对于那些在更晚的 sprint 中实施的故事，您可以以高级方式描述行为，例如，作为一名运营团队成员，我想远程监控系统，以便在旅途中确定系统健康状况。
2. 对于在下一个 sprint 中实施的那些故事，您可以描述行为是一种稍微更详细的方式，例如，作为一名运维团队成员，我希望有一个专门的运维人员登录，以便我可以检查系统健康状况。
3. 对于当前 sprint 中正在实施的那些故事，您可以以非常详细的方式描述行为，例如，作为一名运维团队成员，我想要一个 Web 界面，以便我可以检查摄取 ftp 服务器的当前状态。

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

高温高压

干杯，

抢

Answer 4

一言以蔽之，没有。

用例通常是详细的规范，说明某些特定功能将如何工作，或者特定用户将如何使用系统。它通常是特定用户（或演员）的声音，并且是相当独立的。

另一方面，用户故事是“讨论邀请”。它通常是一两个句子。这是一个很好的资源。Mike Cohn 的用户故事应用非常值得。

典型的语法是“作为 <user> 我需要 <functionality> 来实现 <business value>”，或“为了实现 <business value> 作为 <user> 我需要 <functionality>”，这将故事的价值带回家.

用户故事并不意味着是独立的，而是旨在邀请开发人员和客户（或客户代理）之间的故事讨论。

Answer 5

您可以将用例视为用户故事，但反之则不然。一个用例将涵盖故事的多个“结局”、特殊要求（例如，表单字段必须以 xyz 格式输入，如果用户以错误格式输入字段，则显示错误消息 123）。此外，一个用例可以包括对外部文档的附加引用，例如安全指南。

Answer 6

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

• 它描述了为什么你应该做这个或那个特性而不是HOW或WHAT 特性。
• 根据我的个人经验，这是平衡客户和开发人员的愿景以创造更好产品的好方法。

与美国不同，用例侧重于 WHO 使用您的产品。这就是区别。

我想说，对于敏捷开发人员来说，没有像用户故事这样的工具。如果您想学习如何成功编写它们，请查看这篇文章。