用户故事与用例

Question

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

使用用户故事比使用案例有什么好处..反之亦然......何时使用其他人... 所有敏捷方法都使用用户故事吗？

Answer 1

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

在任何情况下，尝试定义“用例”与“用户故事”区别于“场景”的内容是非常徒劳的，因为很难找到两个同意的权威。\

就个人而言，我发现模式“[Actor] [动词] [名词]得到[商业价值]”很有帮助。如果它完成了一段文字，那可能太大了。

Answer 2

当谈到它时，“敏捷”只是一个标签，而人们对于它的含义并不完全不同意。同样，人们将“用例”称为非常不同的东西。

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

用例可以更正式（虽然有些人非正式地写它们） - 他们专注于与系统的每次互动，并且可能会更详细地了解几个不同的系统/演员/在同一个用例中使用。

这只是我的经验 - 很可能每个人都会以不同的方式使用这些工具。我不会太喜欢标签 - 只需使用适合您项目的内容。

Answer 3

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

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

用户的推荐模板是：

  

作为（角色）我想要（某些）以便（好处）

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

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

此类模板允许您使用不同级别的详细信息描述行为。例如：

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

恕我直言用例更加刻在石头上！因此，在初始版本之后更新可能会出现问题。

HTH

欢呼声，

罗布

Answer 4

总之，没有。

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

另一方面，用户故事是“讨论邀请”。通常是一两句话。 Here是一个很好的资源。而Mike Cohn的User Stories Applied非常值得。

典型的语法是“作为＆lt;用户＆gt;我需要＆lt;功能＆gt;以实现＆lt;商业价值＆gt;”，或“实现＆lt;商业价值＆gt;作为＆lt; user＆gt;我需要＆lt;功能＆gt; “它将故事的价值带回家。

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

Answer 5

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

Answer 6

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

• 它描述了为什么，而不是如何或什么功能。
• 根据我的个人经验，这是平衡客户和开发人员的愿景以创建更好产品的好方法。

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

我想说，没有其他针对敏捷开发人员的工具如User Stories。如果您想学习如何成功编写它们，请参阅this帖子。