“用户故事和用例是一样的吗?”人们经常会问这个问题，关于敏捷团队应该实践使用故事还是用例的争论已经持续多年了。用户故事和用例是一回事吗?如果不是，哪一个更好?你应该使用哪一个?或者两者都使用?
虽然用户故事和用例之间有一些相似之处，但用户故事和用例是不可互换的;用户场景和用例都标识用户，它们都描述了目标，但是它们服务于不同的目的。
用户场景集中于您所描述的结果和好处，而用例可以更细粒度地描述系统将如何运行。用例在敏捷中有一席之地吗?或者它们可以相互结合使用吗?
本文将告诉您用户故事和用例之间的区别。
用户故事vs用例
用户故事往往一开始一样的用例,在每个描述了一种使用该系统,是围绕一个目标,从用户的角度来看,使用业务的自然语言,——自己不告诉整个故事。
用户故事与用例的相似性
如果我们考虑这两种方法的关键组成部分:
- 用户故事包含用户角色、目标和验收标准。
- 用例包含等价的元素:参与者、事件流和post条件分别(一个详细的用例模板可能包含更多的其他元素)。
用户故事与用例的区别
- 用户故事的细节可能不像用例那样被记录到相同的极端。
- 用户故事故意省略了许多重要的细节。用户故事的目的是通过在scrum会议上提出问题来引出对话。
- 为了更频繁地获得反馈而进行小的增量，而不是像用例中那样拥有更详细的预先需求规格说明。
什么是用户故事?
用户故事是一个记录，它捕捉用户在其工作中所做的或需要做的事情。每个用户故事都由一段用自然语言从用户的角度编写的简短描述组成。与传统的需求捕获不同，用户描述关注的是用户的需求，而不是系统应该交付的内容。这为进一步讨论解决方案和系统结果留下了空间，该系统能够真正适应客户的业务流程，解决他们的操作问题，最重要的是为组织增加价值。
3C的概念
3C指的是优秀用户故事的三个关键方面。这个概念是由用户故事实践的共同发明人Ron Jeffries提出的。现在，当我们谈到用户故事时，我们通常指的是由这三个方面组成的用户故事。
卡(Card)
用户故事被写成卡片。每个用户故事卡上都有一个简短的句子和足够的文字来提醒每个人故事是关于什么的。
谈话(Conversation）
在整个软件项目中，通过客户和开发团队之间的持续对话来发现和重新确定需求。重要的想法和决定会在涉众会议期间被发现并记录下来。
确认（Confirmation）
确认也称为用户故事的验收标准。在讨论需求的过程中，客户不仅告诉分析师他/她想要什么，还确认在什么条件和标准下接受或拒绝工作软件。定义的案例以确认书的形式书写。注意，确认关注于验证相应用户描述工作的正确性。它不是一个集成测试。
什么是用例?
用例是在20多年前由Ivar Jacobson引入的，用于在描述系统的功能需求时捕获用户(参与者)的观点。它们描述了用户使用软件系统一步步完成目标的过程。
用例是对最终用户想要“使用”系统的所有方式的描述。用例捕获用户和系统交互的所有可能方式，从而使用户实现目标。它们还捕捉了在过程中可能出现的所有问题，这些问题会妨碍用户实现目标。
用例模型由许多模型元素组成。最重要的模型元素是:
- 用例,
- 演员
- 以及它们之间的关系。
详细的用例说明
用例规范是系统提供的功能的文本描述。它捕获了角色与系统的交互。也就是说，它指定用户如何与系统交互，以及系统如何响应用户的操作。它通常以参与者和系统之间对话的形式出现。用例规格说明在用例图中由一个椭圆形表示，并且是大多数人在听到术语用例时想到的。
为什么我们仍然需要用例?
Alistair Cockburn解释说，他发现(在他咨询的公司)用户故事有三个主要问题:
- 缺乏背景(最大的目标是什么)
- 完成感，你涵盖了与目标相关的所有基础。
- 没有预见未来工作的机制。
集成用例、用户故事和故事映射技术
Visual Paradigm提供了一个完整的敏捷环境，它将用例、用户故事、故事映射、关联评估和看板集成到一个完全无缝的、自动化的端到端流程中。这个过程可以通过补充用例和故事映射工具来解决Alistair在上面提到的用户故事技术的缺点。为了更快、更好、更智能地管理您的敏捷项目，还整合了其他有用的敏捷工具。
下面的概念图概述了Visual Paradigm支持的敏捷工具。
- 将可视化模型中的需求作为产品待办事项列表项发送(用于构建故事图)
- 故事图中的用户活动，它代表了一个大的系统上下文作为一个整体
- 活动、任务和故事的垂直结构——待办事项的完整性
- 发布管理
- 根据用户的开发工作和风险评估用户描述
- 使用sprint管理开发活动
- 使用sprint任务板跟踪进度
第1点到第3点是用来补充用户故事不足的工具。其他用户敏捷工具列在第4到第7点。
