用户故事与用例

Question

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

与用例相比，使用用户故事的好处是什么。反之亦然。什么时候使用一个而不是另一个...是否所有敏捷方法都使用用户故事？？

Answer 1

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

在任何情况下，试图为“场景”定义区分“用例”和“用户故事”的尝试都是徒劳的，因为很难找到两个权威人士达成一致。

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

Answer 2

归根结底，“敏捷”只是一个标签，人们对它的确切含义存在分歧。类似地，人们将非常不同的东西称为“用例”。

在我的经验中，两者之间的主要区别是用户故事是以用户为中心的，而且通常更短，更不正式-理想情况下，它应该很容易放在明信片上。它可能没有给出错误处理等细节。

用例可以更正式(尽管有些人也是非正式地编写它们)-它们关注与系统的每一次交互，并且很可能深入同一用例中几个不同的系统/参与者/等的更多细节。

这只是我的经验--每个人都可能以不同的方式使用过这些工具。我不会太在意标签--只要使用适合你项目的标签就行了。

Answer 3

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

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

建议用户使用的模板为：

作为(角色)我想要(某物)以便(受益)

(感谢Mike Cohn提供了这个简单的模板)

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

这类模板允许您使用不同级别的细节来描述行为。例如：

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

我的用例更像是被刻在石头上的！因此在初始版本之后更新可能是一个问题。

HTH

干杯,

抢夺