3

I'm attempting to write my requirements out as User Stories. Moving from a waterfall world, I am much more familiar with Use Cases.

One of the things I like about Use Cases is each interaction with the system is well-defined, as well as all the alternate and exception flows of action.

UC-01

Success Scenario:

  1. The user navigates to the customer
  2. The user clicks the Add Contract button
  3. The user fills in the Contract Name, Contract #, Start Date and End Date fields
  4. The system asks for confirmation
  5. The user fills clicks the save button, and the contract is saved

Exceptions

5a. The user aborts, and the contract is not saved

Alternate flow

1a. The user uses the filter to select the customer

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

4

6 回答 6

2

他们不会被这样俘虏。

您从错误的角度处理用户故事。来自瀑布，这是一个很常见的误解。

在这个例子中你的故事应该是这样的：

作为用户，我想向客户添加合同，以便 [在此处插入值]

从示例中您可以注意到两件事：

  1. 我无法完成它，因为我不知道这个故事对客户有什么价值。这非常重要，因为它推动了对故事的任何谈判。例如，人们不想在价值非常低的故事上花费大量时间。

  2. 没有太多细节。这是故意的，因为故事试图抓住问题或机会，而不是解决方案。作为用户，我可以通过多种理论方法来实现向客户添加合同的目标。

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

通常，您可以在“卡片背面”或 ALM 工具的注释字段中写下有关您当前推测故事将如何实施的详细信息，但我要说明的一点是，故事在如何实现方面是可以协商的被实施。

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

一个非常简单但又非常典型的典型示例：如果您忘记了边缘情况、备用流程或异常怎么办？有了故事，这没问题：开发人员发现了它，与产品代表聊天，然后他们制定了处理它的计划。

您可以这样做，因为很明显，处理这些情况是用户故事的一部分。要求并非如此，它规定了解决方案应该是什么，而不是它应该实现什么。

于 2013-07-08T13:58:48.090 回答
0

agree with some of the above and would like to add the following (hope this is useful).

Use Cases are not specifically/only related to waterfall, they are merely a means to visual behaviours (use cases) of a system and the relationships between those behaviours and other system behaviours, and external entities to the system (actors).

There is no reason why a user story cannot be further described by use cases and use case scenarios.

Remember, just because you are practicing (I guess, but not restricted too) Agile that does not means you cannot design stuff. Just don't let the design have more value over the result i.e the product (although in complex . safety systems this should be the case).

于 2013-10-28T23:45:35.300 回答
0

许多敏捷实践并不要求您必须将您的需求写成带有验收标准的用户故事。所需要的只是一份已订购的需求列表（又名产品待办列表）。在 sprint 计划会议中向团队提供这些要求时，它们应该是最少的信息，仍然足够清晰，以便团队理解和构建。做得太少修饰和过度分析需求之间有一条细线；这需要时间才能正确。

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

于 2013-07-08T22:47:35.087 回答
0 
> Where would the exception and alternate flows be captured in an Agile approach?

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

  • 在实施之前（如瀑布中的规范）
  • 在实施期间或之后或根本不实施（敏捷）

在 Scrum 中，您只会在没有场景的情况下在待办事项列表中有一个功能请求“添加客户”。

于 2013-07-08T18:05:30.680 回答
0

我喜欢@Sklivvz 和@k3b 的答案。

关于你的例子。

首先：正如 Sklivvz 所写，用户故事定义了问题和目标。我对支线和例外的看法不同。在我看来，这些都是小故事。有自己的优先权。即取消该过程的能力可能比某些验证问题故事具有更高的优先级。

简而言之，我的答案是：为主要目标、次要目标、例外情况和备用流程写一个故事。

积极的副作用：产品负责人（你？）有机会优先考虑这些故事。

于 2013-07-10T14:52:57.463 回答
-1

当您最初捕获故事时，它们应该非常简短并专注于收益。

当您与团队讨论解决方案并准备开始实施时，您应该记录它并提供更多详细信息。

我喜欢 Given/When/Then 格式，我会将这个用例重新编写成这个（真正的目标可能不同，但你仍然会明白主要思想）：

Title:
As a user I want to add contract to customers so that I can track contracts history

Given customers list
When user clicks to Customer
Then he sees Customer Details view
And Add Contract button
[mockup]

Given Customer Details view
When user clicks Add Contract button
Then he see a popup with fields:
Contract Name - field spec: [default value, max lenth, etc]
Contract # - [field spec]
Start Date - [field spec]
End Date - [field spec]
[form mockup]

Given user filled form correctly
When he click Save button
Then he sees confirmation dialog ["Do you really want to add this contract?"]

[注意：我认为这个确认是愚蠢的，不需要]

Given user see a confirmation dialog 
When he clicks Yes
Then the contract is saved
And user sees success message "Contract is saved for customer XXX"


Given user see a confirmation dialog 
When he clicks No
Then the contract is not saved
And confirmation dialog closes

注意：这个场景很可能是一个单独的用户故事

Given home page
When I click Add Contract link
Then I see Contract form
And "Select customer" drop down field

...

如您所见，您可以很容易地使用 Given/When/Then 格式来描述用户故事。确保捕获用户故事的真正价值非常重要。否则很容易做出一些从业务角度来看非常糟糕的决定。

于 2013-07-08T16:25:07.363 回答