用户故事与用例

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

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

实际上,最初的用例(参见Jacobson的OOSE)非常轻巧,就像现在的用户故事一样.随着时间的推移,它们的进化,直到"使用情况"的通用格式现在是投入,产出,继承,利用的关系,伪码等复杂文档的程序员,一般情况下尝试一切转换成编程.

在任何情况下,尝试从"用户故事"一"用例"定义什么区别来回一个"情景"是相当徒劳的,因为它很难找到两个部门谁同意.\

就个人而言,我觉得模式"[演员] [动词] [名词]得到[商业价值]"有帮助.如果它克服了一段文字,那可能太大了.

归结为它"敏捷"只是一个标签,人们对它的含义完全不同意.同样,人们将"用例"称为非常不同的东西.

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

用例可以更正式(尽管有些人也非正式地编写它们) - 它们专注于与系统的每次交互,并且可能在同一用例中更详细地了解几个不同的系统/参与者/等.

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

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

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

为用户推荐的模板是：

作为（角色）我想要（某事）以便（收益）

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

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

这种模板可让您使用不同级别的细节来描述行为。例如：

对于将在以后的sprint中实施的故事，您可以以较高的方式描述行为，例如，作为运维团队成员，我想远程监视系统，以便在旅途中确定系统的运行状况。

对于在下一个sprint中实现的故事，您可以描述行为是一种更为详细的方式，例如，作为运维团队成员，我希望拥有专用的运维专用登录名，以便检查系统运行状况。

对于当前sprint中正在实施的那些故事，您可以以非常详细的方式描述行为，例如，作为ops团队成员，我想要一个Web界面，以便可以检查摄取ftp服务器的当前状态。

恕我直言，用例更多是用石头雕刻的！因此，在初始版本之后进行更新可能会成为问题。

高温超导

干杯，

抢