首页 > 代码库 > Scrum中的User Story

Scrum中的User Story

我们通常用User Story来描述Backlog里的各个Backlog项,User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值。
    User Story要由Stakeholder(利益相关者)来编写。User Story的形式很简单,人们可以很容易地掌握编写User Story的方法。这样就可以保证是由与项目相关领域专家们来编写User Story,而不是开发人员。
    我们通常把User Story写在一张小卡片上,同时在卡片上标明它的优先级和预计完成时间,以便开发人员根据任务的优先级来制定Sprint Backlog。而且,Stakeholder可以随时更改一个Story的优先级,那么此时开发人员就应该相应地调整Story的开发次序。
    一个User Story的大小和复杂度应该在一个Sprint中开发完毕为宜。如果User Story太大,可能会导致对它的开发横跨几个Sprint。这种情况是需要避免的。此时就应该将这个User Story分解。
    User Story有一个通用的公式格式,大家可以套用一下试试,很简单。
    作为<某个角色>,我可以<做什么>,以完成<什么目的>。
    例如:作为一个病人,我可以预约一个医生,让他给我看病。
    这种表达方式清晰明了,提供了足够的信息以供测试。更详细的实现细节会在要完成这个User Story的Sprint开始之前确定下来,并补充到Sprint Backlog中去。这是一种把客户需求分解为可测试的且有优先级的任务的有效方式。
    为了能及时、高效地完成每个Story,Scrum团队会把每个Story分解成若干个Task。每个Task都是可以在明确的时间内完成的,而且时间是以小时为计量单位的。
    特别提示:每个Task的时间最好不要超过8小时,就是要保证1个工作日内完成,如果做计划时发现有些Task的时间超过了8小时,就说明Task的划分有问题,需要特别注意。

 

http://www.cnblogs.com/zgqys1980/archive/2011/01/04/1925781.html

Scrum中的User Story