用户故事 userstory

User Story模板 

User Story可以遵循以下模板:As a <User Type> I want to <achieve goal> So that  I can <get some value>
 翻译成中文就是:作为一个<某种类型的用户>,我要<达成某些目的>,我这么做的原因是<开发的价值>。

 
User Story应遵循INVEST规则

  1. Independent 独立性,避免与其他Story的依赖性。
  2. Negotiable 可谈判性,Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细,开发人员可以给出适当的建议。
  3. Valueable 有价值性, Story需要体现出对于用户的价值
  4. Estimable 可估计性,Story应可以估计出Task的开发时间。
  5. Sized Right 合理的尺寸, Stories应该尽量小,并且使得团队尽量在1个sprint(2 weeks)中完成。
  6. Testable 可测试性, User Story应该是可以测试的,最好有界面可以测试和自动化测试。每个任务都应有Junit Test.

一些经验:

  1. 永远不要在User Story中使用And和Or,因为这是些分支词就表示分支任务,把它们拆成两个Story.
  2. 数据整理:通常情况下1个sprint(2周一次迭代)可以做4~5个Story,极端大的Story不可大于1个sprint。
  3. 数据整理:通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。
  4. User Story用于描述用户故事,不要包括任何的技术,框架等内容。Task可以包括框架,技术等内容。

什么是用户故事?

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

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

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

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

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

英文:

As a <Role>, I want to <Activity>, so that <Business Value>.

中文:

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

举例:

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

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


你可能感兴趣的:(用户故事 userstory)