Epic、Feature、Story和Task的关系

在敏捷项目的估算或计划时,我们常提到以下几个概念。

  • Epic Story
  • Feature
  • Minimal Marketable Feature (MMF)
  • Theme
  • User Story
  • Task

本文将说明这几个概念的意义和他们间的关系。

Feature

Feature是可以为顾客提供价值的东西,它代表一个产品可以做什么,或提供什么服务;是可以满足用户的需求,为客户服务,为用户带来真正的价值的成果物的特性。
Feature相对复杂,可由一组动宾结构的句子表达,如一个超市的交易可以描述为:

  1. 扫描条形码
  2. 显示单价
  3. 计算总价
  4. 计算税额
  5. 打印清单
    因此,一个Feature是很难进行估算的,它需要被分解成一个个更小的单位,这就是下面要讨论的User Story。Feature一般在Release Plan的层次,一个Feature可能需要几次迭代才能完成。
    由于Feature是满足用户需求的交付物,因此每次交付的对象应该是一个或多个Feature。可以说Feature就是敏捷宣言中的“Working software”。

Minimal Marketable Feature (MMF)

了解了什么时Feature后,我们再来讨论MMF。顾名思义,MMF就是一组最小的,可以市场化的机能。首先,它是Feature,其次,它强调的是市场化这个概念。市场化意味着它能够提交到用户手中使用,并可以从用户那里得到相应的回报。MMF可以使得投资提前取得收益,这对于一个企业来说,是非常重要和实用的。

User Story

在Feature的讨论中提到了,Feature是由一组动宾结构的句子组成的。这些动宾句子描述的就是一个个User Story。一个Feature可以分解成多个User Story,每个User Story不能单独被使用,而是一起构成一个Feature。
一个User Story必须是清晰的,可以为客户增加价值,而且更重要的是能够被估算。因此User Story通常是进行估算的基本单位,通常使用Story Point来进行估算。User Story是在迭代的层级,一个User Story要在一个迭代内完成。
另外,User Story也是进行需求分析的工具。通过询问谁、做什么、为什么,能够简单明了地扑捉客户的需求。因此User Story通常写成以下形式:
As a , I want , so than .
如:
作为文档编辑者,我希望文档修改后,在退出编辑时提醒我保存文档,以便我不会丢失数据。
User Story具有以下六大特点(INVEST):

  1. Independent:独立的
  2. Negotiable:可变的
  3. Valuable:有价值的
  4. Estimable:可估算的
  5. Small:足够小的
  6. Testable:可验收的/可测试的
    由于User Story具有可验收的特性,因此使用User Story来跟踪开发进度更加准确。也可使用Task来跟踪开发进度,但Task的完成度有时不是那么容易清晰的定义或可视的,而User Story的完成度则是可视的。
    注意,有的文章中认为User Story是由Feature组成的,那实际上这个Feature,应该是Functionality。

Task

项目中可以执行的工作单位,通常就是迭代计划中项目(如Sprint Backlog中的项目)。一个User Story一般会分解为一个或多个Task,通过这些Task来实现。如显示单价这个User Story,可以分解成:
· 设计讨论会
· 服务器查询单价编码
· 服务器查询单价测试
· 客户端显示单价编码
· 客户端显示单价测试
当然一项Task也可能不实现任何User Story。如:Release plan meeting。

Epic Story

顾名思义,Epic Story的规模和复杂性,要大于User Story,它首先是一个大User Story。由于它非常大,无法或不容易进行估算,因此一般会分解成为更小的User Story,进行估算和开发。关于Epic和Feature,谁的复杂性更高,谁的规模更大,则还没有一个统一的说法,有的项目中,会定义Epic Story在Feature之下;而有的项目中则相反。因此在使用这个概念时,应该在项目中有一个明确的定义。无论Epic Story是在Feature之上还是之下,它与Feature同样是在Release Plan的层级,一般是通过一个或多个迭代才能完成。

Theme

Theme则是一组User Story(甚至是Epic Story),这些User Story拥有共同的特征,为了更容易开发这些相关内容,通常会将这些User Story作为一组进行开发和管理。这组User Story就被称为Theme。比如,有关报表这个机能,包括Excel报表、Word报表、PDF报表等,那么“报表”就是一个Theme。
对于Theme与Epic/Feature的关系,可以在自己的项目中进行明确定义。这取决于项目组成员的喜好。
因此,从层次上讲,这几个概念的关系应该是:
在这里插入图片描述
例:
Epic:可以理解为一个大版本。1.0,2.0,3.0之类的,规划的大模块,比如电商做了自营,接着做商家入驻
Feature:特性嘛,比如1.1,1.2,1.3。比如支付加了支付宝,登录支持扫码了。
Backlog:要做的,还没开始的需求
Task:正在进行的需求
或者是:
在这里插入图片描述
值得注意的是,关于Epic、Feature和Theme这些概念,可以在自己的项目中自行定义,而不用一定遵守本文中的规则。只要在自己的项目中,通过绘制类似上面的关系图来明确他们的关系,并得到各个成员的认同即可。

refers:
https://www.yuque.com/jingwhale/blog/vvpxff

猜你喜欢

转载自blog.csdn.net/yao_zhuang/article/details/113922911