用户故事已经足够了！

敏捷的迷雾

敏捷的核心是一套指导原则，由各种流程、方法和框架的创建者和实践者进行解读。就像一种语言有多种方言一样，同一个词在不同的方言中含义略有不同。问“什么是用户故事？”这个问题，你会得到十几个不同的答案。用户故事可以是一个需求、一个功能、一个描述、一个最终目标、一个高级抽象、一小部分业务价值等等，这取决于你问的对象和时间;)

我倾向于同意Mike Cohn 的定义：用户故事是对功能的描述。当然，这只会把问题转移到“什么是功能？”。快速谷歌一下，我们就会发现有很多定义：功能是指功能、能力、需求、以 形式表达的客户价值函数、Epic 的一部分等等。诸如此类，不胜枚举。

这是一种我见过很多次的常见模式，我敢打赌你也遇到过：一个利益相关者要求查看“用户故事”。利益相关者后来抱怨说，用户故事太技术性或太抽象，或者涉及了错误的参与者。

以下是一个例子：

As an end-user 
I want to log-in with my social media credentials
so I don't have to remember extra usernames and passwords

这算是一个用户故事吧？你可以把它交给你的利益相关者，但他们可能会抱怨这太普通了，没有任何价值。他们说得没错。然后你给他们讲这个故事：

As an end-user
When I log-in I want to be re-directed to the login page of my selected Identity Provider
So that, upon entering my credentials, the IP can redirect me back to our system with a valid SAML token

利益相关者茫然地看着你。你不明白问题出在哪里。他们想要用户故事，你也给了他们，这到底是怎么回事？问题是，利益相关者想要一些非常具体的东西，但他们找不到合适的词语来表达，因为“用户故事”这个词本身就很有内涵。我们先搁置一下这个问题。

需求领域模型

John Ferguson Smart在其著作《BDD in Action》一书中详细阐述了影响图的使用，这是Gojko Adzic提出的一种技术，对于回答需求和规范模型中的重大问题非常有用：

• 我们为什么要建立这个系统？
• 谁从中受益？
• 我们需要建造什么？
• 我们将如何建造它？

这些可以直接转换为需求和规范域实体：

• 业务目标（为什么）：我们系统的预期效益
• 利益相关者（谁）：受我们系统影响的人
• 能力（什么）：使利益相关者能够实现业务目标的系统能力
• 功能（如何）：有助于交付功能的功能

就这样，我们拥有了定义明确的领域实体。我们的需求在利益相关者和业务目标的语境下，由功能来表示。我们的规范是特性，它描述了我们将要实现的系统功能，以交付系统的功能。按照真正的 BDD 方式，特性由用户故事及其后的一系列场景/验收标准来描述。特性并非用户故事！我们也可以使用用户故事来描述功能、特性和业务目标。

1. 我们的系统要求是受益利益相关者和有效业务目标背景下的能力
2. 我们可以用用户故事来描述功能和业务目标。但这并不意味着故事就是这些东西。
3. 我们的规范是对交付功能所需的系统行为的描述，即功能

用户故事只是需求域实体的描述设备。

让我们回到我们困惑的利益相关者。当他们向你索要用户故事时，他们想要的是功能！他们想要你提供的系统功能描述，以便帮助他们实现目标。不多不少。用户故事不是领域实体，它们只是描述符。我们需要开始使用领域实体，而不是描述符来沟通。

因此，我们向利益相关者提供以下内容：

Feature: Login with Twitter
As a end-user with a Twitter account
I want to log-in with my Twitter credentials
so I don't have to know extra usernames and passwords

  Scenario: First-time login with Twitter, already signed-on
    Given the user visits our system's login page
    And the user hasn't signed-on our system with Twitter before
    And the user is not already signed onto Twitter
    When the user chooses to sign-on our system with Twitter credentials
    Then the user is presented with a Twitter login page

  Scenario: First-time login with Twitter, not currently signed-on
    Given the user visits our system's login page
    And the user hasn't signed-on our system with Twitter before
    And the user is already signed onto Twitter
    When the user chooses to sign-on our system with Twitter credentials
    Then the user is presented with a Twitter permissions and confirmation page

... (more scenarios)

请注意，为了更好地描述和说明我们的功能，我们在功能标题下方呈现了一个用户故事。另请注意，即使我们没有使用用户故事，我们的功能仍然有效且可用。用户故事并非功能本身！它只是为我们提供了一个很好的叙述，因此在我们的功能中使用它很有用。但仅此而已。我们不是在创建用户故事，而是在定义功能。

作为开发人员、产品负责人或业务分析师，我们常常被客户的愿望、需求和期望淹没。我们的第一个问题应该是：“利益相关者应该能够使用我们的系统做什么才能满足他们的愿望或需求？” 回答完这个问题后，我们的下一个问题应该是“我们将如何交付这种功能？” 这个思考过程的结果将为我们提供一组规范（功能），这些规范（功能）能够满足利益相关者对实现某些业务目标的需求。所以，让我们拨开迷雾，开始更多地讨论功能和特性，而不是泛泛而谈它们的各种描述。用户故事到此为止！