用例和用户故事是否相同？
使用用户故事比使用用例有什么好处，反之亦然。何时使用其中一种而不是另一种。所有的敏捷方法都使用用户故事吗？
6个回答
12
实际上，最初的用例（参见Jacobson's OOSE）非常简单，就像现在的用户故事一样。随着时间的推移，它们发展成了一个常见的“用例”格式，包括输入、输出、继承、使用关系，伪代码等复杂文档。总的来说，程序员试图将所有东西转化为编程。
无论如何，试图定义“用例”与“用户故事”和“场景”的区别是相当徒劳的，因为很难找到两个权威人士达成共识。
就我个人而言，我认为模式“[演员] [动词] [名词] 以获得[业务价值]”是有帮助的。如果超过一段文字，可能太大了。
无论如何，试图定义“用例”与“用户故事”和“场景”的区别是相当徒劳的，因为很难找到两个权威人士达成共识。
就我个人而言，我认为模式“[演员] [动词] [名词] 以获得[业务价值]”是有帮助的。如果超过一段文字，可能太大了。
- Charlie Martin
1
2我要强调的是，“业务价值”是其中非常重要的部分，因为它可以帮助估计并产生验收测试。 - Robert Koritnik
8
当谈到“敏捷”时，它只是一个标签，人们对它的定义存在分歧。同样地，人们称不同的事物为“用例”。
根据我的经验，两者之间的主要区别在于用户故事侧重于用户，并且通常更短，不太正式 - 理想情况下，它应该容易适合明信片。它可能不会详细说明错误处理等内容。
用例可以更正式（尽管有些人也会以非正式方式编写它们） - 它们关注系统的每个交互，并且可能会更详细地介绍同一用例中的几个不同系统/参与者等。
但这只是我的经验 - 可能每个人都会以不同的方式使用这些工具。不要过于纠结于标签 - 只需使用适合您的项目的工具即可。
根据我的经验，两者之间的主要区别在于用户故事侧重于用户，并且通常更短，不太正式 - 理想情况下，它应该容易适合明信片。它可能不会详细说明错误处理等内容。
用例可以更正式（尽管有些人也会以非正式方式编写它们） - 它们关注系统的每个交互，并且可能会更详细地介绍同一用例中的几个不同系统/参与者等。
但这只是我的经验 - 可能每个人都会以不同的方式使用这些工具。不要过于纠结于标签 - 只需使用适合您的项目的工具即可。
- Jon Skeet
1
1人们大多数情况下持不同意见，是因为他们对敏捷哲学了解不够。 - Robert Koritnik
5
用例不是用户故事的汇编。
用户故事通常比用例简单得多。我认为用例试图涵盖系统某个方面行为的所有内容，即所有行为、所有错误路径和所有异常处理。
用户的推荐模板为：
“作为（角色），我希望（某事）以便（获益）”。
（感谢Mike Cohn提供这个简单的模板）
像这样表达行为的描述更加敏捷。
这种模板让您可以使用不同级别的详细信息描述行为。例如：
1.对于那些在较晚的冲刺中实施的故事，您可以以高级别的方式描述行为，例如作为一名运维团队成员，我希望远程监视系统，以便在路上确定系统健康状况。
2.对于那些在下一个冲刺中实施的故事，您可以稍微详细地描述行为，例如作为一名运维团队成员，我希望拥有专用的运维登录，以便检查系统健康状况。
3.对于那些在当前冲刺中实施的故事，您可以以高度详细的方式描述行为，例如作为一名运维团队成员，我希望拥有Web界面，以便检查摄取FTP服务器的当前状态。
在我看来，用例要固定得多！因此，在初始版本之后更新可能会成为问题。
希望有所帮助。
祝好，
罗布
用户故事通常比用例简单得多。我认为用例试图涵盖系统某个方面行为的所有内容，即所有行为、所有错误路径和所有异常处理。
用户的推荐模板为：
“作为（角色），我希望（某事）以便（获益）”。
（感谢Mike Cohn提供这个简单的模板）
像这样表达行为的描述更加敏捷。
这种模板让您可以使用不同级别的详细信息描述行为。例如：
1.对于那些在较晚的冲刺中实施的故事，您可以以高级别的方式描述行为，例如作为一名运维团队成员，我希望远程监视系统，以便在路上确定系统健康状况。
2.对于那些在下一个冲刺中实施的故事，您可以稍微详细地描述行为，例如作为一名运维团队成员，我希望拥有专用的运维登录，以便检查系统健康状况。
3.对于那些在当前冲刺中实施的故事，您可以以高度详细的方式描述行为，例如作为一名运维团队成员，我希望拥有Web界面，以便检查摄取FTP服务器的当前状态。
在我看来，用例要固定得多！因此，在初始版本之后更新可能会成为问题。
希望有所帮助。
祝好，
罗布
- Rob Wells
4
一句话，不行。
用例通常是详细的规格说明，阐述某个特定功能如何工作或某个特定用户如何使用系统。它通常以特定用户（或演员）的语气为主，并且相当自成体系。
另一方面，用户故事是“讨论邀请”。它通常只有一两个句子。这里是一个很好的资源（链接）。Mike Cohn的《用户故事应用》也很值得一读。
典型的语法是“As a <user> I need <functionality> to achieve <business value>”，或者“To achieve <business value> as a <user> I need <functionality>”，这强调了故事的价值所在。
用户故事并非为了独立存在，而是为了在开发人员和客户（或客户代表）之间引发对故事的讨论。
- Cory Foy
2
您可以将用例视为用户故事，但反之则不行。 用例将涵盖故事的多个“结局”，特殊要求（例如，表单字段必须以格式xyz输入，并在用户以错误格式输入字段时显示错误消息123）。 此外，用例还可以包括对外部文档的其他参考，如安全指南。
- Elie
1
同意，看看我的总结是否符合您的要求。 - pabloelustondo
1
User Stories是敏捷开发中用来确保你创建的产品真正符合用户需求的工具。
- 它描述了为什么应该实现这个或那个功能，而不是如何或者什么功能。
- 从我的个人经验来看，这是平衡客户和开发人员愿景以创建更好产品的绝佳方式。
与用户故事不同，用例侧重于谁使用你的产品。这就是区别所在。
我认为对于敏捷开发人员来说，没有其他比用户故事更好的工具了。如果你想学习如何成功地编写它们，请查看this文章。
- Julia Says
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接