用户故事与用例兼容吗？
在网上搜索，敏捷贤者认为用例和用户故事是两个不同的东西： Mike Cohn： 用户故事不是用例 Alistair Cockburn： 用户故事之于用例就像瞪羚之于凉亭 Extreme Programming.org： 用户故事与用例的目的相同，但并不相同。 用例驱动方法是需求捕获最热门的技术之一，现在有些人认为它是一种过时的旧式技术，它与许多问题相关联，导致您的团队由于用例问题而不是“敏捷” ： 前期需求——试图定义前期所有方面的细节将导致大量的精力和时间的浪费，因为很多工作都需要重做。 功能分解：用例的功能性质自然导致系统在具体和抽象用例方面的功能分解，这些用例通过扩展关联并包括用例关联。 如果你在网上搜索关键词“用例 vs 用户故事”，你会发现一长串关于用例方法的缺点、问题或陷阱的文章，而与用户故事相关的好处甚至更长。 . 有趣的是，IT 行业的变化如此之快，对于人们从过去的“时尚”事物转变为现在的“较新时尚”事物的人来说甚至更快。 有趣的是，有些人喜欢以二元模式感知事物，并通过象征性地与它们相关联来追逐时尚的东西，而不是真正地实践它。有些人甚至不想让其他人知道他们仍在使用用例，或者它们可能被认为是过时的和过时的。 现在有些人把用户故事和用户案例相关的等号： 敏捷 = 用户故事或敏捷 = 用户故事 + Scrum 用户故事 = 恰到好处 & 及时 用户故事=满足用户期望和满意 用例 = 前期详细需求捕获 用例 = <<include>> + <<extends>> = 功能分解 用例是“用户输入”->“系统响应”唯一样式 用例 = 旧式和过时 作为工具供应商，我们在方法、工具和技术方面相当中立。就个人而言，我想强调一下，我是敏捷开发、用户故事和 Scrum 流程的忠实拥护者。特别是与以下概念相关的强调原则和最佳实践： 需求发现而不是需求交付 根据上述原则，在敏捷开发过程中产生了两个重要属性 准时制 正好 （我会写更多与上述原则相关的帖子，与我在 1992-1995 年的博士研究领域密切相关 - 元模型和模式转换） 现在，让我们回到主题“用例与用户故事”。好吧，重量级的敏捷贤者已经为此投了票，我是否如此固执地试图通过争论他们相似甚至相同来推翻他们的“投票”？ 让我给你看一个例子来说明用户故事是否与用户案例“如此不同”： 例子 好的用户故事不仅仅是陈述。一个标准的用户故事由三个部分组成，通常称为三个 C。 每个用户故事的第一个“C”应遵循以下标准化格式： 作为[角色]，我想[做某事]，以便[受益] 这是要放入卡片的用户故事的最少内容。 对话是用户故事的第二个“C”的内容，代表最终用户、项目所有者和开发团队之间的讨论。在这些转换中，它记录了口头讨论，或许多其他有用的信息，如电子邮件、线框图或任何其他与项目相关的内容。 用户故事的最后一个“C”是确认，它是用于确认用户故事实施正确并成功交付的验收标准。 让我进一步详细说明如何开发用户故事的确认部分。在这里，我们使用最知名的模板 Gherkin，它采用 Given-When-Then 公式来指导用户故事验收测试的编写： （给定..和）一些上下文 （当..和）一些动作被执行 （然后..和）执行一些操作 诸如 Cucumber 和 Jbehave 测试框架之类的工具鼓励使用 Given/When/Then 模板来进行自动化测试，尽管它也可以纯粹用作启发式方法，而不管是否使用工具。 让我们收集“注册课程”用户故事的所有信息并将其放入 3C 格式： 我采用了常用的 3 Cs 格式来表示“注册课程”用户故事。同样，我还采用了最广泛使用的格式来描述用例描述所阐述的相同“注册课程”用例。我对用户故事的确认部分（最后一个 C）的步骤进行了编号，这与我在用例描述中输入的步骤编号相关联。它们是场景的相同“九步”，以不同的顺序放置在每种方法中。我相信这两种模型表示对于他们相应的圣人和追随者来说都是可以接受的。然后，问题又来了，用户故事与用户案例非常相似，但它们是不同的，还是步骤的顺序导致了对用例方法的各种批评？ 语义等价但含义不同？ 让我们调查一下建模领域是否有类似的案例，以便与这里的情况进行比较，或者它可能有助于我们对“用户故事与用例”进行投票，但不要盲目跟风或重复圣人如鹦鹉般的说道。 示例：语义等价…continue reading →
