我正在尝试将我的要求写成用户故事。从瀑布世界移开，我对用例更加熟悉。
我喜欢用例的一个方面是每个与系统的交互都是明确定义的，以及所有备用和异常的操作流程。
UC-01
成功案例：
例外
5a上。用户中止，合同未保存
替代流程
1a上。用户使用过滤器来选择客户
敏捷方法中会捕获异常和备用流程在哪里？
答案 0 :(得分：2)
他们不会被捕获。
您正在从错误的角度接近用户故事。来自瀑布，这是一个很常见的误解。
此示例中的故事应该类似于：
作为用户，我想向客户添加合约，以便[在此处插入值]
从示例中您可以注意到两件事：
我无法完成它，因为我不知道这个故事的值对客户是什么。这非常重要，因为它推动了对故事的任何谈判。例如，人们不想花很多时间在有很小边际价值的故事上。
没有太多细节。这是故意的，因为故事试图捕获问题或机会，而不是解决方案。 作为用户，我可以通过多种理论方式实现向客户添加合同的目标。
故事的重点是让用户实现目标。
通常情况下，您可以在“卡背面”或ALM工具的备注字段中详细说明您当前推测的故事，但我正在尝试要弄清楚故事是如何实施的。
您的开发人员期望在迭代期间与您的客户代表进行交互，以讨论/原型化/尝试各种不同的可能解决方案，以便故事的目标是高效，有效地实现了。
一个非常简单且非常典型的典型示例：如果您忘记了边缘情况，备用流量或异常，该怎么办？有了故事，这没问题：开发人员发现它，与产品代表聊天，他们制定了处理它的计划。
您可以这样做，因为很明显，处理这些案例是用户故事的一部分。对于解决方案应该是什么，而不是应该实现的要求，要求不是这样。
答案 1 :(得分：0)
> Where would the exception and alternate flows be captured in an Agile approach?
用例是一种功能文档。 可以创建此文档
在Scrum中，您可以在没有方案的情况下在Backlog中添加功能请求“添加客户”。
答案 2 :(得分：0)
许多敏捷实践并未规定您必须将您的要求作为具有验收标准的用户故事编写。所需要的只是订购的需求列表（又名Product Backlog）。在sprint计划会话中向团队提供这些要求时，他们应该是足够清晰的信息，以便团队理解和构建。做太少的梳理和过度分析要求之间有一个很好的界限;这需要时间才能正确。
话虽如此，通常会使用用户故事，因为它们对参与过程的多方有意义，其中其他形式的要求仅限于特定受众;即你必须教人们如何阅读和理解用例，但不必为用户故事这样做。显然写它是一个不同的问题。
答案 3 :(得分：0)
我喜欢@Sklivvz和@ k3b的答案。
关于你的例子。
首先：正如Sklivvz所写，用户故事定义了问题和目标。我对侧面跟踪和例外的看法不同。在我看来，那些是小故事。有自己的优先权。即取消流程的能力可能比某些验证问题的故事更高。
我的答案简短：为主要目标，次要目标，例外和备用流程撰写故事。
积极的副作用：产品所有者（您？）有机会优先处理这些故事。
答案 4 :(得分：0)
同意上面的一些内容，并希望添加以下内容（希望这很有用）。
用例并不特定/仅与瀑布有关，它们仅仅是系统的可视行为（用例）以及这些行为与其他系统行为之间的关系，以及系统（参与者）的外部实体之间的关系。
没有理由不能通过用例和用例场景进一步描述用户故事。
请记住，仅仅因为你正在练习（我猜，但不限制）敏捷并不意味着你无法设计东西。只是不要让设计对结果更有价值，即产品（尽管在复杂的安全系统中应该是这样）。
答案 5 :(得分：-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格式来描述用户故事。确保捕获用户故事的真实价值非常重要。否则，从业务角度来看，很容易做出一些非常糟糕的决定。