用户故事不等于软件需求

常常听到敏捷转型的团队提到，我们的一个迭代可以完成几个几个用户故事。那个故事怎么怎么样。那么什么是用户故事？用户故事就是软件需求吗？

我们先来看一下什么是用户故事

什么是用户故事

用户故事指的是从用户的角度出发，来描述用户想要得到的功能。常见的格式为：

作为<某个用户>，我想要<功能>，以便于<实现某个价值>

用户故事需要采用日常用语或者用户听得懂的语言来描述，尤其注意避免使用晦涩的技术专用术语。

后来Ron Jefferies同学建议，好的用户故事符合3C原则：Card，Conversation，Confirmation；Jeff Patton同学，把这个3C继续扩充为5C（并总结为用户故事生命周期）：Card, Conversation, Confirmation, Construction, Consequence。

用户故事这个方法最开始的初衷是非常好的，希望技术人员（一般来说是研发人员）可以以用户的角度来思考问题。但在实际应用中，有些团队就会出现下面这样的例子：

作为一个系统的用户，我想要接口A，以便于和系统进行交互。

大家仔细体会，为什么这是一个反例？

那么对于敏捷软件开发当中，需求是个什么东东，是不是都是用户故事呢？

我的观点是，用户故事不是软件需求。

什么是软件需求

需求分析指的是在创建一个新的或改变一个系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作。（摘自wikipedia）

从上面的定义中可以看出，软件需求的定义更加广泛，而不仅仅是从用户的角度考虑用户所需要的功能。并且用户故事也只是展现功能的一种形式。

软件需求可能包含（但不限于）：功能（可以用用户故事展现）、原型、探索、技术改进、缺陷等。

功能的展现形式可以有（但不限于）：用户故事、用例、关键词短语.

因此，不要把用户故事当作是需求，需求有更大的定义和更多的展现形式。而用户故事是一个相对较小的概念。

用户故事不等于软件需求。

在敏捷当中是如何管理需求呢，请继续往下看。

敏捷需求是如何呈现与管理

对于敏捷转型的组织来讲，需求是首先要考虑的事情，这是团队的起点（输入点）。因此敏捷需求是很重要的一步，但这个在Scrum当中并未有很多的提及。

Scrum中有产品列表（Product Backlog）以及条目（Item）来管理需求，产品列表是如何产生的，条目何时是就绪的，何时是完成的。这些都需要在实践中不断摸索。

如何建立产品列表

用户故事地图是一个创建产品列表很好的方式。这是因为产品列表是一维的，排序的，这样很难找出相互有业务关联的条目。通过用户故事地图这种方式，可以很好的组织需求条目。如果你的组织需要这样的工作坊，也可以单独和我联系（jiangxb@gmail.com）。如下图：

如何把业务目标和需求条目进行关联

常常在平时的开发中，开发人员不清楚为什么要开发一个功能，或者是不了解背景，或者是不清楚业务目标。有一个非常有用的工具（影响地图）可以帮助团队。如果你的组织需要这样的工作坊，也可以单独和我联系（jiangxb@gmail.com）。例子如下图：