Tagged with 用户故事

【zz】什么是用户故事(User Story)

原文地址:http://www.scrumcn.com/scrumptc/html/?191.html 什么是用户故事? 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素: 1.     角色:谁要使用这个功能。 2.     活动:需要完成什么样的功能。 3.     商业价值:为什么需要这个功能,这个功能带来什么样的价值。 用户故事通常按照如下的格式来表达: 英文: As a <Role>, I want to <Activity>, so that <Business Value>. 中文: 作为一个<角色>, 我想要<活动>, 以便于<商业价值> 举例: 作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。” 需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。 Ron Jeffries的3个C 关于用户故事,Ron Jeffries用3个C来描述它: 卡片(Card) – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述,工作量估算等。 交谈(Conversation)- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。 确认(Confirmation)- 通过验收测试确认用户故事被正确完成。   用户故事的六个特性- INVEST INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable 一个好的用户故事应该遵循INVEST原则。 独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。 可协商性(Negotiable)— [...]

[需求分析培训] 理清行为脉络-用例和用户故事-(4.1)

用例和用户故事的区别: 范围不同:用户故事包含的范围小于用例,一个事件流就可能是一个用户故事, 标准不同:用例的粒度是以业务分工为标准的,用户故事的粒度是一开发量为标准的; 描述不同:用例通常写的比较详细,用户故事写的比较概括;用例描述比较契约化(有固定的模板),用户故事的描述比较不正式。   (一)用例 用例图一些方法铺天盖地的,也可以直接到这里看看 本文只记录本次培训老师讲的内容 1、用例中的actor是相对系统来说的一个角色,use case 是用户要达到的目的;另一个方面,end user 是终端客户,不见得等价于actor;function是实现的功能,不能等价于用例; 2、用例是用户通过系统完成的特定的工作,实现特定的业务价值;一个用例的粒度是可以通过人来判断的,没有统一的标准;一般情况下,一个完成的、不会在分的(是指不会分成多个人分步完成)、可汇报的粒度就可以了。由于分工不同,用例的粒度也不同; 3、举个例子说明 技术动词+业务名词不一定等于用例:        1)“新增图书”这类不是用例,是功能;(给销售介绍产品时,也要介绍产品的价值,而不是产品的功能。销售给客户介绍时同理。)      2)用例是要有场景的,针对前面的功能,可以这样思考“什么时候需要新增图书呢?”; 4、通过一个用例图说明:   1)用例之间的三种关系:      a)包含:被包含的一定会执行,例如预订座位是一定要去检查座位信息;      b)扩展:扩展的优先级低,不一定会被执行的,例如预订座位时不一定要处理等候队列;      c)泛化:后期抽象出来的,例如办理结账可以分为现金和银行卡; 2)actor之间的关系:可能会有泛化关系,表示角色之间权限的继承。 3)从用例指向actor表示调用外部系统或者通知外部actor; 4)各个用例之间不能有判断产生分支的情况,因为用例图主要强调的是人到事之间的关系;   5、如何识别用例?一般采取流程派生发,也就是通过前期调研访谈和分析得到的流程图来抽取用例,具体步骤如下: 1)在泳道图中,把不是end user的泳道、泳道内的活动和判定去掉; 2)对剩下的各个泳道做角色画的抽象; 3)判断每个活动,需要系统实现就留着,不需要系统实现就忽略掉; 4)对每个判定菱形做一次判断,属于某个活动不需要系统支持的就忽略,其他的不属于某个活动且需要系统单独支持的就抽象成一个用例。   (二)用户故事 1、用户故事不适合强流程系统,一般大项目的早期都不会用到,除非新增几个小功能的时候可以采用; 2、用户故事一般的过程是这样的: 1)找几个人代表不同的角色,用”作为××角色,我希望系统提供××功能“的巨型表达需求; 2)让开发估算工作量,2人周能否实现这个故事?如果能就结束,如果不能,拆开故事,描述一个更小的故事,直至估算通过;