【发布时间】：2010-09-27 14:09:33
【问题描述】：
用例只是多个用户故事吗？
使用用户故事而不是用例有什么好处......反之亦然......何时使用一个而不是另一个...... 是否所有敏捷方法都使用用户故事？
【问题讨论】：
标签： requirements user-stories use-case
【发布时间】：2010-09-27 14:09:33
【问题描述】：
归根结底，“敏捷”只是一个标签，人们对它的确切含义存在分歧。同样，人们将非常不同的事物称为“用例”。
根据我的经验，两者之间的主要区别在于用户故事以用户为中心，并且通常更短且不太正式 - 理想情况下，它应该很容易放在明信片上。它可能没有提供错误处理等的详细信息。
用例可以更加正式（尽管有些人也非正式地编写它们）——它们关注与系统的每一次交互，并且可能会更详细地介绍几个不同的系统/参与者/等在同一个用例中。
不过，这只是我的经验 - 每个人都有可能以不同的方式使用这些工具。我不会太在意标签 - 只需使用适合您项目的标签即可。
【讨论】：
-
人们大多不同意，因为他们对敏捷哲学了解不够。
您可以将用例视为用户故事，但反之则不然。一个用例将涵盖故事的多个“结局”、特殊要求（例如，表单字段必须以 xyz 格式输入，如果用户以错误格式输入字段，则显示错误消息 123）。此外，用例可以包含对外部文档的附加引用，例如安全指南。
【讨论】：
-
同意，看看你是否喜欢我的总结
一句话，没有。
用例通常是详细的规范，说明某些特定功能将如何工作，或特定用户将如何使用系统。它通常是特定用户（或演员）的声音，并且相当独立。
另一方面，用户故事是“讨论邀请”。它通常是一两个句子。 Here 是一个很好的资源。 Mike Cohn 的User Stories Applied 非常值得。
典型的语法是“作为一个
用户故事不是独立的，而是旨在邀请开发人员和客户（或客户代理）之间讨论故事。
【讨论】：
实际上，最初的用例（参见Jacobson's OOSE）非常轻量级，就像现在的用户故事一样。随着时间的推移，它们不断发展，直到现在“用例”的通用格式是包含输入、输出、继承、使用关系、伪代码等的复杂文档。程序员通常会尝试将所有内容都转换为编程。
无论如何，试图从“场景”中区分“用例”和“用户故事”是徒劳的，因为很难找到两个同意的权威。\
就个人而言，我发现“[Actor] [verbs] [noun] to get [business value]”模式很有帮助。如果超过一段文字，可能是太大了。
【讨论】：
-
我要强调的是，“商业价值”是其中非常重要的一部分，因为它可以帮助进行估算以及进行验收测试。
用例不是用户故事的汇编。
用户故事通常比用例简单得多。我认为用例试图涵盖与系统某些方面的行为有关的所有内容。即所有行为、所有错误路径和所有异常处理。
推荐给用户的模板是：
作为一个（角色）我想要（某事）以便（受益）
（感谢 Mike Cohn 提供这个简单的模板）
这样表达的行为描述更加灵活。
这种模板让您可以使用不同级别的详细信息来描述行为。例如：
- 对于在更晚的 sprint 中实施的那些故事，您可以以高级方式描述行为，例如作为一名运营团队成员，我想远程监控系统，以便在旅途中确定系统运行状况。
- 对于在下一个 sprint 中实施的那些故事，您可以用一种稍微更详细的方式来描述行为，例如作为一名运维团队成员，我希望拥有一个专门的运维专用登录名，以便检查系统运行状况。
- 对于当前 sprint 中正在实施的那些故事，您可以以非常详细的方式描述行为，例如作为一名运营团队成员，我希望有一个 Web 界面，以便我可以检查摄取 ftp 服务器的当前状态。
恕我直言，用例更加刻板！因此，在初始版本之后更新可能会出现问题。
HTH
干杯，
罗伯
【讨论】：
用户故事是敏捷开发中使用的一种工具，可确保您创建用户真正需要的产品。
- 它描述了为什么您应该制作这个或那个功能，而不是HOW或WHAT功能。
- 根据我的个人经验，这是平衡客户和开发人员的愿景以创造更好产品的好方法。
与美国不同，用例侧重于谁使用您的产品。这就是区别。
我想说，对于敏捷开发人员来说，没有像用户故事这样的工具。如果您想学习如何成功编写它们，请查看this 帖子。
【讨论】：