搜故事,从300万个故事到海量知识百科的华丽转变!

敏捷:什么是用户故事User Story

时间:2016-05-16

什么是用户故事

提示:本文共有 2116 个字,阅读大概需要 5 分钟。

摘要:

一件用户通过系统完成他一个有价值的目标(买一罐饮料)的事。这样的过程就叫“用户案例user case”或者“用户故事user story”。本文描述了敏捷开发的技巧:如何以用户故事管理项目.

什么是用户故事user story

假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。

因此,我们的客户就是他们的市场经理。谈需求的时候,有一回他这样说:“用户往售货机每塞一个硬币,售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时,代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮,售货机就放一罐饮料到出口,然后找零钱给他。”

上面的话描述的是一件事情,一件用户通过系统完成他一个有价值的目标(买一罐饮料)的事。这样的过程就叫“用户案例user case”或者“用户故事user story”。也就是说,上面我们的客户所说的话,就是在描述一个用户故事(user story)。 我解释一下为什么用故事这个词,没兴趣也可以忽略。在一个系统面前,每个用户要完成同样的目标,都要做这个系统设定的例行的事,这件事情不是一个例子,所以不叫事例,这也不是故事,也不能算一段历程,而是一个例行的事。

如果我们想要记下这段用户故事,我们可能会用这样的格式:

名称:卖饮料

事件:

1. 用户投入一些钱。

2. 售货机显示用户已经投了多少钱。

3. 如果投入的钱足够买某种饮料,这种饮料对应的按钮的灯就会亮。

4. 用户按了某个亮了的按钮。

5. 售货机卖出一罐饮料给他。

6. 售货机找零钱给他。

注意到,一个用户故事里面的事件可以这样描述:

1. 用户做XX。

2. 系统做YY。

3. 用户做ZZ。

4. 系统做TT。

5. ...

用户故事只是描述系统的外在行为

一个用户故事只是以客户能够明白的方式,描述了一个系统的外在行为,它完全忽略了系统的内部动作。比如,下面有下划线的那些文字,就属于不应该出现在用户故事中的系统内部动作:

1. 用户投入一些钱。

2. 售货机将塞进来的钱存在钱箱里,然后发送一条命令给屏幕,屏幕显示目前已经投入的金额。

3. 售货机查询数据库里面所有饮料的价格,判定钱足够买哪些饮料,对于钱足够买的那些饮料,对应的按钮的灯就会亮起来。

4. 用户按下一个亮起来的按钮。

5. 售货机卖出一罐饮料给用户,然后将数据库里面该饮料的存货数量减1。

6. 售货机找零钱给用户。

不管是口头描述的,还是书面形式,这样的内容是描述用户故事时一个很常见的错误。特别的,千万不要提及任何有关数据库,记录,字段之类的对客户一点意义都没有的东西。

评估发布时间

用户故事是用来干嘛的?假定客户希望在50天内递交这个系统。我们做得了吗?为了解答这个问题,我们就要在项目开始的阶段,试着找出所有的用户故事,然后评估一下,每一项历程需要多长的开发时间。可是,怎么评估呢? 比如,我们现在收集了下面这些用户故事:

卖饮料:如上面所说的。 取消购买:在投入了一些钱后,用户可以取消购买。 输入管理密码:授权的人可以输入管理密码,然后增加存货,设定价格,拿走里面的钱等等。 补充饮料:授权的人可以在输入管理密码后增加存货。 取出钱箱里的钱:授权的人在输入管理密码后,可以取出钱箱里的钱箱里面的钱。 安全警报:有些事情经常发生的话,系统会自动打开安全警报。 打印月销售报表:授权的人可以打印出月销售报表。

然后找出里面最简单的用户故事(这里的“简单”,意思是说实现周期最短)。我们不一定非常精准的判断哪个最简单。只要挑出你觉得最简单的就行了。比如,我们觉得“输入管理密码”是最简单的用户故事。然后我们判断说,这个用户故事算1个“故事点(story point)”。 用户故事 故事点卖饮料 取消购买 输入管理密码 1补充饮料 取出钱箱里的钱 安全警报 打印月销售报表

不过一般我们不会列出清单,而是做出一堆卡片贴在墙上,每张卡片记录一个用户故事,然后将故事点写在卡片上面:

这样的一张卡片就叫“故事卡(story card)”。

用户故事通常按照如下的格式来表达:

英文:

As a , I want to , so that .

中文:

作为一个 角色 , 我想要 活动 , 以便于 商业价值

举例:

作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。

Ron Jeffries的3个C

关于用户故事,Ron Jeffries用3个C来描述它:

卡片(Card) 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述,工作量估算等。

交谈(Conversation) 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

确认(Confirmation) 通过验收测试确认用户故事被正确完成。

看到此处说明本文对你还是有帮助的,关于“敏捷:什么是用户故事User Story”留言是大家的经验之谈相信也会对你有益,推荐继续阅读下面的相关内容,与本文相关度极高!

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。
相关阅读
敏捷:什么是用户故事User Story

敏捷:什么是用户故事User Story

故事,用户,饮料,系统,售货机,客户,管理,密码,按钮,卡片,钱箱,一个用户,最简单,存货,报表,目标,项目,评估,安全警报,用户按,我的网,事件,假定,价格,历程,动作,数据库,格式,过程,行为

2014-03-02 #故事会

敏捷:什么是用户故事User Story

敏捷:什么是用户故事User Story

故事,用户,饮料,系统,售货机,客户,管理,密码,按钮,卡片,钱箱,一个用户,最简单,存货,报表,目标,项目,评估,安全警报,用户按,我的网,事件,假定,价格,历程,动作,数据库,格式,过程,行为

2013-05-06 #小故事

敏捷:什么是用户故事User Story

敏捷:什么是用户故事User Story

故事,用户,饮料,系统,售货机,客户,管理,密码,按钮,卡片,钱箱,一个用户,最简单,存货,报表,目标,项目,评估,安全警报,找零钱,用户按,我的网,事件,假定,价格,历程,动作,数据库,格式,过程

2009-05-01 #短篇故事

用户故事User Story

用户故事User Story

故事,用户,客户,需求,测试,团队,角色,速率,功能,用户代理,软件,开发人员,工作量,系统,经理,好的,用户角色,验收测试,价值,大小,细节,项目,产品,人员,卡片,计划,部分,一个用户,可以通过,虚拟人物

2020-07-25 #故事会

用户故事User Story

用户故事User Story

太长,鱼骨,软件,技术,项目,了好久,大牛们,很好用,我现在,给了我,非常专业,在官

2020-09-04 #经典故事

用户故事User Story

用户故事User Story

太长,鱼骨,软件,技术,项目,了好久,大牛们,很好用,我现在,给了我,非常专业,在官

2009-06-29 #长篇故事

用户故事User Story

用户故事User Story

故事,用户,需求,测试,客户,团队,用户代理,速率,经理,大小,系统,软件,验收测试,部分,项目,人员,功能,开发人员,技术支持,渔网,方法,领域专家,合作,工作,一个故事,可以用,可以通过,接触到,这个故事,非常重要

2020-07-25 #故事会

用户故事User Story

用户故事User Story

故事,用户,需求,测试,客户,团队,用户代理,速率,经理,大小,系统,软件,验收测试,部分,项目,人员,功能,开发人员,技术支持,渔网,方法,领域专家,合作,工作,一个故事,可以用,可以通过,接触到,这个故事,非常重要

2008-11-23 #故事会