标签：blog http ar sp strong on 问题 log bs
我们通常用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
标签：blog http ar sp strong on 问题 log bs
原文地址：http://www.cnblogs.com/daishuguang/p/4118832.html
