Murali Krishna告诉我们：

未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在於每一 个用户故事都是一个“可独立分配”的需求（特徵）单位。要达到“可独立分配”，就要从“用户”如何使用系统来表达用户故事。这样才让你实现到一个能让用户交流，端到端（用户界面到后端）的功能单位。

原文：

Failure to effectively transition to Agile development is often based on a fundamental failure to understand what a User Story is.

The most important aspect of a User Story is that it's an independently *schedulable* unit of requirement (feature). The key to achieving the "independently schedulable" characteristic of a user story is that you express it in terms of how a "user" would use it. This leads you to a unit of functionality that's implemented end-to-end (UI to backend) that a user can actually interact with.

最近开始有正规的敏捷开发过程管理，得到一个资深老大的指点，觉得有必要把这部分整理一下。

对于用户故事的理解

用户故事（User Story）是从用户的角度对系统功能的描述。所以，又被称为使用者故事。

尽管在敏捷实践的书中，认为用户故事应当由用户来撰写，实际上这个通常可操作性都不是很好。

这一点上，我觉得可以认为：用户故事就是开发人员（技术、产品）等对于用户描述的系统功能的理解。好吧，要承认，这个对于开发人员的要求大大的提高了，他不仅要能够与用户进行无碍的交流，还要求他有一定的专业背景（否则鬼知道用户在说什么），还要能够具有一定的抽象总结概括能力。

OK，这又回到了以往传统瀑布模型开发过程中需求分析阶段。

回顾下做需求分析的步骤和方法：

  1. 清晰定义角色与职责
  2. 准备工作：确定需求调查的方式，包括但不限于
    1）与用户交谈，向用户提问题。
    2）参观用户的工作流程，观察用户的操作。
    3）向用户群体发放调查问卷（问题列表）。
    4）与同行、专家交谈，听取他们的意见。
    5）分析已经存在的同类软件产品，提取需求。
    6）从行业标准、规则中提取需求。
    7）从Internet上搜查相关资料。
    如果要使用调查问卷，那么就需要事先准备。还需要与被调查者建立联系，确定调查的时间、地点、人员等。
  3. 执行调查，随时记录调查过程中所获取的需求信息。
  4. 分析需求信息，消除错误，归纳与总结共性的用户需求。
  5. 撰写用户需求说明书。
  6. 需求确认，邀请行业专家和用户（包括客户和最终用户）一起评审《用户需求说明书》。

一般而言，用户需求说明书都有特定的文档。通常，《用户需求说明书》主要内容包括：

  • 产品介绍；
  • 描述用户群体的特征；
  • 产品应当遵循的标准或规范；
  • 描述产品的功能性需求；
  • 描述产品的非功能性需求，如用户界面、软硬件环境、质量等需求。

在敏捷开发中，需求最终会被描述成User Story。开发人员依照用户故事中的描述估测完成所需要的时间，并指定该User Story的优先级。这样，最终，所有的User Story组成了Product Backlog。

** 关于Product Backlog的话题咱以后再说，今天只关注User Story。

怎么写用户故事？

在敏捷中，用户故事是最基本的设计单元，它是从用户的角度出发对功能的一段简要描述。啰嗦一下，用户故事是轻量级的需求描述。用户故事没有什么强制性的语法。但是，按照大致符合这样一个形式来考虑用户故事是比较有益的：

作为【用户的类型】，我希望可以【先这样做，然后那样做，就应该得到...的结果】以便【业务价值】。

例如：“作为购书者，我希望可以根据ISBN来找到一本书，以便能更快的找到正确的书。”

在做用户故事时，需要注意每个用户故事用的是用户的语言，它只描述一个功能（feature），而不要涉及设计或实现上的内容。

从这个角度来说，用户故事应该是直白的。换句话说，它应当是个阐述句，其中应当尽可能少用形容词。它应当一眼看上去，就能明白需要做什么事情。

一般而言，每个用户故事的开发周期不要太长（1－5天），否则用户故事应当切分为多个子用户故事。

不需要一开始对所有的故事都进行详细的描述，但计划放在下一个sprint中的故事应该比较清楚。

在文章Advantages of User Stories For Requirements（http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements）中指出每一个用户故事都包括三方面：

  1. Written description of the story, used for planning and as a reminder
  2. Conversations about the story that serve to flesh out the details of the story
  3. Tests that convey and document details that can be used to determine when a story is complete

 

 

用户故事的应用

 

用户故事的优点

在文章Advantages of User Stories For Requirements（http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements）中讨论了用户故事相比较与传统需求用例的优点，包括:

  1. 精确（Precise）：用户故事强调说话沟通，文字语言而往往不仔细。We act as though written words are precise, yet they often aren’t.
  2. 可以很好的预估开发计划。Useful for planning：user stories are written so that each can be given an estimate of how difficult or time-consuming it will be develop. Use case, on the other hand, are generally too large to be given useful estimates. Also, a story is implemented all in a single iteration of an agile project, while it’s common to split a use case across multiple iterations (even though those iterations are usually longer than on a story–driven project).
  3. 推迟考虑细节（Spare me the details）：在一个长周期的项目开始时，团队只需要建立一个目标级的用户故事后就可以开始开发过程。在需要时，再考虑用户故事的细节，把它拆分为多个更细的子用户故事。User stories encourage the team to defer collecting details. An initial place–holding goal–level story (“A Recruiter can post a new job opening”) can be written and then replaced with more detailed stories once it becomes important to have the details. This technique makes user stories perfect for time–constrained projects. A team can very quickly write a few dozen stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and can be coding much sooner than a team that feels compelled to complete an IEEE 830–style software requirements specification.

用户故事的缺点

Alistair Cockburn，另一位敏捷社区内的名家，从他过往使用用户故事的经验中指出使用用户故事所遇到的问题：

  1. 用户故事和Backlog上的项目不能提供设计师工作所需要的内容脉络——用户在做什么时候情况下做这事情，这行动的内容前文后理，以及在这一刻的高层目标。
  2. 用户故事和Backlog上的项目不能提供项目团队所需要的“完整性”——我发现开发队伍对项目估算的故事点随著工作开始以后不断增加，犹如无止境的一样。开发人员及项目赞助人也为此感到同样的沮丧。到底项目确确实实有多大呢？
  3. 跟 完整性有关的是，用户故事和Backlog上的项目不能提供一个合适的机制来考虑到未来工作的困难程度（原则上他们可以, 只是实际上他们不行）——我不断收到这样的投诉，「我们问客户 (产品负责人)一条问题，他/她用上两星期时间才回覆我们。我们找错了人吗？」不是，他们没找错人，他们是过程出问题——有些问题需要长时间研究，因为不 同部门和用户组要找出什么是正确，平衡各方需要的答案。分析员看著用例中一系列的伸延的形势可以找出那一个较容易，那一个较困难，再进一步进行相关的研 究。用户故事和 Backlog 项目未能及时达到适合作出来那考虑的粒度——伸延的形势通常要在Sprint中才能观察到，这已经太迟。