用户故事不等于软件需求

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

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

什么是用户故事

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

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

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

后来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)。如下图:

user-story-mapping-example

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

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

impact-mapping-example

 

联系Bob

Bob Jiang

CST (Certified Scrum Trainer) at JD.com
姜信宝 - Bob Jiang

中国北方第一位CST(Certified Scrum Trainer)
敏捷认证CSM (Certified ScrumMaster) http://bobjiang.com/csm/

敏捷教练;旨在帮助企业改进工作方法以取得更好的商业价值
《Scrum精髓》译者,Certified LeSS Practitioner
博客:http://bobjiang.com

敏捷一千零一夜联合发起人。
联系Bob
姜信宝 - Bob Jiang 中国北方第一位CST(Certified Scrum Trainer) 敏捷认证CSM (Certified ScrumMaster) http://bobjiang.com/csm/ 敏捷教练;旨在帮助企业改进工作方法以取得更好的商业价值 《Scrum精髓》译者,Certified LeSS Practitioner 博客:http://bobjiang.com 敏捷一千零一夜联合发起人。