将操作的所有用例流映射到用户故事

Question

我试图把我的需求写成用户故事。从瀑布世界出发，我更熟悉用例。

关于用例，我喜欢的一件事是，与系统的每一次交互都是定义良好的，以及所有替代的和异常的动作流。

UC-01

成功情景：

1. 用户导航到客户。
2. 用户单击“添加契约”按钮。
3. 用户填写合同名称、合同#、开始日期和结束日期字段。
4. 系统要求确认
5. 用户填充单击“保存”按钮，然后保存合同。

例外情况

5a。用户中止，合同未保存。

交替流

1a.用户使用筛选器选择客户。

在哪里可以用敏捷方法捕获异常和备用流？

Answer 1

他们不会被抓到的。

你是从错误的角度接近用户故事。来自瀑布，这是一个相当常见的误解。

在本例中，您的故事应该如下所示：

作为一个用户，我想向客户添加一个契约，以便在这里插入值

在这个例子中，您可以注意到两件事：

1. 我无法完成它，因为我不知道这个故事对顾客有什么价值。这是相当重要的，因为它推动任何关于这个故事的谈判。例如，一个人不想花太多的时间在有很小价值的故事上。
2. 没有太多细节。这是故意的，因为故事试图抓住问题或机会，而不是解决方案。作为一个用户，有许多理论方法可以实现我的目标，即向客户添加合同。

故事的重点是让用户实现他们的目标。

通常，您可以写详细信息，说明您目前如何推测故事将在“卡片背面”或ALM工具中的便条字段中实现，但我想指出的是，故事在实现方式上是可协商的。

期望您的开发人员在迭代期间与您的客户代表进行交互，讨论/原型/尝试各种不同的可能解决方案，以便高效和有效地实现故事的目标。

一个非常简单而又非常典型的例子:如果你忘记了边缘情况、交替流或异常怎么办？对于故事，这是没有问题的:开发人员发现了它，与产品代表聊天，他们制定了一个处理它的计划。

您可以这样做，因为很明显，处理这些案例是用户故事的一部分。对解决方案应该是什么而不是它应该达到的目标的要求则不是这样。

Answer 2

> Where would the exception and alternate flows be captured in an Agile approach?

用例是特性文档的一种形式。可以创建此文档。

• 在实施之前(如瀑布中的具体情况)
• 在执行期间或之后或根本不执行(agil)

在Scrum中，在没有场景的情况下，在待办事项中只需要一个特性请求"Add“。

Answer 3

许多敏捷实践并没有规定您必须将您的需求写成带有接受标准的用户故事。所需要的是一个需求列表(也称为产品待办事项清单)。当在sprint计划过程中将这些需求提供给团队时，它们应该是足够清晰的、足以让团队理解和构建的最小数量的信息。在做太少的修饰和过度分析需求之间有一条细微的界限；这需要时间才能正确。

尽管如此，用户故事通常被使用，因为它们对参与过程的多个方面有意义，其中其他形式的需求仅限于特定的受众；也就是说，您必须教人们如何阅读和理解用例，而不必为用户故事这样做。显然，写它是一个不同的问题。