2011-09-16 22:59:20 cheny_com 阅读数 10272
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13673 人正在学习 去看看 张传波

这是敏捷开发用户故事系列的第一篇。(栏目目录

全系列将涉及何为用户故事,面向客户价值编写故事,用户建模,产品待开发项的分类,故事颗粒度,故事的组织结构,等等若干问题,力求将此中问题尽量解决干净。

本系列文章假设正在编写一个“敏捷开发管理软件”,因为来阅读的都是做敏捷开发的,又都是做软件的,会更熟悉一些。

用户故事三要素:角色,功能,价值

按“作为一个……,可以……,以便……”样式和思路写成的用户需求,就是用户故事。

样式是技法层面的东西,它保证了无需太多思考,用户故事中即包含角色、功能、价值这三个要素。

角色

角色切记不要总是写“作为一个用户”,而是要把用户区别对待。这样才能更好地理解他们使用什么功能,如何使用,为何使用。

比如“作为一个开发人员,可以登录批量编辑页面,以便高效率地编辑多个故事”就是一个危险的举动,因为如果有多个程序员同时这么做,存储的时候会发生冲突(这个页面后来被删除了)。但“作为一个项目经理,可以登录迭代计划首页,同时编辑多个迭代的信息”则是可行的,因为项目经理一般就有一个,而且这个功能使用次数很少,即使有多个人有权限使用,偶然发生冲突的损害,与平时效率提高相比,也微乎其微。

所以把角色特化出来后,更容易理解功能的价值和风险。

日后另有文章详述如何识别角色,以及如何基于关键角色编写故事。

功能

功能即用户能亲自执行的操作。

应区分用户操作和产品功能之间的关系,因为产品功能可能也提供了用户所需的价值,但却极可能不便于操作。

一个例子是之前我使用一个XX手机,联系方式上在“拨出”之外,总是有一个“编辑拨出”,后来才知道是为了能在前面加拨17951之类的IP电话前缀。写成用户故事,差不多是:“作为一个用户,可以使用编辑拨出在拨打长途前输入IP前缀,以便节省话费。”不过这个功能从来没用过,因为太费劲。实际使用中要么我会把外地电话录入的时候就加上17951,要么一个电话就打出去了管它三七二十一。

后来又使用另外一款Android手机,因为别的原因安装了360,发现它有一个自动IP功能,写成用户故事,就是“作为一个用户,可以在拨打长途的时候自动使用IP拨出功能,以便节省话费。”这个功能每月可以给我节省不下20块钱,如果他有一天收费,我必会买。

价值

价值是完成操作后,客户所得到的价值。

价值里边,常常要带有一点褒义词,或有一些吸引人的内容,比如前面的“高效地”“节省话费”。

潘家宇老师当年提到何为“用例”的时候提到了类似的概念:“用例就是那个你能卖掉的东西。”用户故事也是用来被卖掉的东西,看不到价值的就不是用户故事。

比如上面的360的用户故事写得就比较好,估计如果有读者没装360,看完本文立刻就去。

底层的一些功能看不到直接的用户价值,怎么办?系列中另有一篇描述用户故事的分类。

 

本篇先简单说明一下用户故事的定义,更多内容将逐步展开。

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2011-12-28 16:47:24 fuzengbin 阅读数 1522
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13673 人正在学习 去看看 张传波

用户故事(User  Story)描述的是一件用户通过系统完成他一个有价值的目标,用户故事只是描述系统的外在行为,完全忽略系统的内部动作。

用户故事形式简单,故事写作者使用起来方便;用户故事从用户角度出发描述需求,利于用户、需要分析人员和开发人员之间的沟通。

 一个 User Story  的大小和复杂度应该以能在一个 Sprint  中开发完毕为宜。

尽量在系统的开始阶段,尝试找出所有的用户故事。然后,为每一个用户故事评估Story Point(复杂度)和 Stack Rank(优先级)。

由产品经理(Product Owner)确认每一次冲刺需要完成哪些用户故事。 召开计划会议,将每一个用户故事分解为工作任务(Task),由团队成员认领并承诺在规定的时间内完成。 每一次冲刺完成后,召开评审会议,与 Product Owner 进行用户故事的确认,对于确认通过的用户故事,可以将关联的工作任务关闭,对于确认未通过的用户故事,考虑是否将本次冲刺计划延迟或将这些用户故事放到下一轮冲刺计划中。

功能测试人员参与计划会议,充分理解每一项用户故事,对表述不当的地方尽早提出改进建议,在开发人员编写单元测试用例的同时根据用户故事开始编写功能测试用例;

 

 

2011-04-14 20:17:00 cheny_com 阅读数 2037
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13673 人正在学习 去看看 张传波

敏捷开发中的用户故事采用的语法模式看似简单,却蕴含着深刻的思想。

“作为一个……,可以……,以(以便)……”不同于一般专注于功能的需求条目描述方法,三个……把角色、功能、价值跃然纸上。然而使用不当,却有可能形似而神不似。

下面就三个部分分别举出一个例子。

 

网络游戏的排行榜功能:“作为一个玩家,可以通过显示排名,以便让自己在服务器中的地位获得认可。”

这个功能可以激发玩家的“斗志”,鼓励购买道具,是个不错的想法,但实现起来却有技术问题:服务器中的玩家太多了,实时查看排名非常不现实。另一个问题是小虾米们其实对自己的排名不太关心,即使关心,也不会为了提升排名去购买道具,只有一批(也有上百个)顶级大佬才会真正受此蛊惑。

这个故事后来被改为:每周重新排名一次,而且只显示TopXXX(很像csdn的“排名两万以外”)。所以如果写成故事,就变成:

“作为一个排名靠前的付费玩家,可以通过显示排名,以便让自己在服务器中的地位获得认可(以刺激消费)。”

当然,对小虾米们也有刺激消费的方法,比如打怪掉落了一个很棒的道具,却要花钱买打孔材料和镶嵌宝石,即使用保健因素而非激励因素让他们消费,那是另外一个故事了。笔者曾经体验过的一个游戏中有帮派战争,大号会争当“连斩狂客”,小号则有“寻宝冠军”可得,且人人均有积分,因此各层人物都争相参加。

这个故事让我们理解到:“用户”这个词太笼统了,如果他们的“价值观”差别很大,就要分别为他们写故事,才能吸引他们使用功能,达成价值观。

 

权限查询功能:“作为管理员,可以查询所有用户的权限,以了解所有用户的权限”。

一种很常见的写之无味不写不行的故事,因为好像功能=价值。其实管理员不会平白无故地查看所有用户权限的,多半有其目的:有人反映自己访问不了某个文件,有个项目死活加不上新用户,有人刚刚离职,有三个外包团队的人需要在最近三个月在项目中作为成员一起工作……

知道这些就好多了,当点击“权限”这个tab后,多半不会出现“所有用户的权限”(倘若想想有10000人的企业),而是继续出现几个子链接:查询个人权限,项目成员,人员离职,限时权限(外包人员管理)……

当然,这需要一大堆故事了,但如果一个给客户带来明确价值操作友好的产品正是我们所追求的,我们极有可能选择开发其中最高价值的几个,然后再留下之前那个“万能”但又什么都干不太好的。

这个故事让我们理解到:功能不等于价值,要理解用户操作功能的业务目的,不要随意抛出万能的功能。

 

杀毒软件的防打扰功能:“作为一个用户,可以选择‘认可所有相似操作’,以便同意或禁止连续的相似操作。”

这看起来也是个很不错的功能,但笔者曾经在安装软件的时候用到这个功能,尽管选择了“认可所有相似操作”,窗口仍然跳个不停,直到后来仔细查看弹出的信息,原来在软件安装过程中要进行很多“不相似”的操作:修改注册表,创建C盘目录,向system32中拷贝dll……而这个杀毒软件在处理的时候,连注册表不同位置的修改都认为是“不同的操作”。

要改好这个故事,就要从最后的客户价值入手。比如如果安装软件是最常见的需要“认可所有相似操作”的过程,就可以写一个这样的故事:

“作为一个用户,可以在安装软件时选择‘认可本次安装操作’,以便一键完成正常的安装操作。”当然何为“正常”的操作需要额外说明,但整体客户价值却更精准地表达出来了。

这个故事让我们理解到:“客户价值”是要从客户的角度来理解的,否则极可能跑偏。

插播一段技术变革带来的软件体验变革。在传统exe软件的时代,构造一个“界面”是很累的事情,所以仔细想想Word/Excel,无论你是编辑它、观看它、评审它、审批它、使用(Excel)它,看到的都是一个界面。而且由于这些产品都是被设计为单个用户使用的

 

       最后留下几个思考题让大家费费脑筋:

在手机上输入“我”的时候,经常(接近80%)被识别为“舟义”等罕见文字,怎么办?(假设我们是汉王)

       Visio中画图的时候经常发现图形之间有细微的未对齐,需要放大到400%之后才能调整好,怎么办?(假设我们是微软,其实这个问题不久前我才知道被一个叫做“SmartDraw”的软件解决了,但估计微软是放弃了。)

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2017-04-13 09:02:05 huver2007 阅读数 850
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13673 人正在学习 去看看 张传波

用户故事

一、什么是用户故事?

用户故事也是一种常见的需求描述的方法,它从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

1. 角色:谁要使用这个功能。

2. 活动:需要完成什么样的功能。

3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值。

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

英文:As a , I want to , so that .

中文:作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例:

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

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

Ron Jeffries的3个C

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

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

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

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

二、用户故事的六个特性- INVEST

一个好的用户故事应该遵循INVEST原则。

INVEST = Independent, Negotiable, Valuable, Estimable,Small, Testable

· 独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

· 可协商性(Negotiable)— 一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。

· 有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。

· 可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。

· 短小(Small)— 一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。

· 可测试性(Testable)—一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子:软件应该是易于使用的。

 

附件是一个比较详细的用户故事拆解与拆分的例子。

2015-10-25 19:02:29 Jeppe 阅读数 5584
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13673 人正在学习 去看看 张传波
用户故事(user story)是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:
1. 角色:谁要使用这个功能。
2. 活动:需要完成什么样的功能。
3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值。


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

英文:
As a <Role>, I want to <Activity>, so that <Business Value>.
中文:

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

举例:

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

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


用户故事来描述产品需求是敏捷开发实践必须学习和转变的第一项工作,最经典的三段论,“作为一个…(角色),可以<能够>…(功能),以便…(客户价值),这个语法很好地表明了需求的三个最重要的要素:角色,功能,客户价值。

  为什么需要角色,

  1. 有利于特定的用户核实,有一个“角色“字段,都令沟通工作可以与适当的角色进行,完成的产品自然也就令这些角色的人员满意。

  2. 有利于开发人员理解场景,角色与“普通用户/管理员/执行人“这些区别,可以使开发人员更容易理解产品的用户,风格、操作人员的熟练程度、操作习惯。

  功能描述最好遵从以下两条规则

  1. 主语-谓语原则

  比如,作为一个会议系统管理员,可以显示所有用户的提问,以便。。。。

  是不是别扭,对可以转换成“可以查看所有用户的提问“,这样是通过角色+谓语的方式来描述

  2. 动宾词组原则

  在功能动作描述的时候,尽量采用动词+宾语的描述,如新建用户,查看所有评论等。

  所以对于功能的描述应该是: 把角色作为主语,功能主题的描述采用动宾结构。

  用户价值

  用户价值看似很简单,但是其实是很难写,而且很重要。

  如:作为会议管理员,可以查看所有用户的提问,以便了解哪些用户发表的评论。看上去这种价值描述不错。但是如果系统只是为了查看的话,会议管理员为什么要查看?如果评论很多,他如何查看?

  所以用户故事的价值描述,给需求分析做了一些价值挖掘的要求,团队要去挖掘角色做这一动作的价值,要为角色挖掘出必要且合理的理由。

  用户故事作为需求分析和研发的依据,是在敏捷开发实践过程中首先需要去实践的一个重要环节,看似简单的用户故事,在实际操作中是相对困难的,如何从传统的功能描述转变成客户和研发团队都能理解的用户,这里有很多技巧。包括如何确定角色,用户故事颗粒度,用户故事的评估等问题。

推荐大家一本书科恩(美)的《用户故事与敏捷方法》。


没有更多推荐了,返回首页