敏捷估算/计划中几个概念间的关系

keaide

在敏捷项目的估算或计划时，我们常提到以下几个概念。　　· Epic Story
　　· Feature
　　· Minimal Marketable Feature (MMF)
　　· Theme
　　· User Story
　　· Task
　　本文将说明这几个概念的意义和他们间的关系。项目管理者联盟
　　1. Feature
　　Feature是可以为顾客提供价值的东西，它代表一个产品可以做什么，或提供什么服务;是可以满足用户的需求，为客户服务，为用户带来真正的价值的成果物的特性。
　　Feature相对复杂，可由一组动宾结构的句子表达，如一个超市的交易可以描述为：
　　· 扫描条形码项目管理论坛
　　· 显示单价
　　· 计算总价bbs.mypm.net
　　· 计算税额

keaide

· 打印清单

　　因此，一个Feature是很难进行估算的，它需要被分解成一个个更小的单位，这就是下面要讨论的User Story。Feature一般在Release Plan的层次，一个Feature可能需要几次迭代才能完成。

　　由于Feature是满足用户需求的交付物，因此每次交付的对象应该是一个或多个Feature。可以说Feature就是敏捷宣言中的“Working software”。项目管理培训

　　2. Minimal Marketable Feature (MMF)

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

keaide

　3. User Storytraining.mypm.net

　　在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 .

　　如：bbs.mypm.net

　　作为文档编辑者，我希望文档修改后，在退出编辑时提醒我保存文档，以便我不会丢失数据。

　　User Story具有以下六大特点(INVEST)：

　　· Independent：独立的

　　· Negotiable：可变的

Sunleth

keaide

· Valuable：有价值的

　　· Estimable：可估算的

　　· Small：足够小的项目经理圈子

　　· Testable：可验收的/可测试的

　　由于User Story具有可验收的特性，因此使用User Story来跟踪开发进度更加准确。也可使用Task来跟踪开发进度，但Task的完成度有时不是那么容易清晰的定义或可视的，而User Story的完成度则是可视的。

　　注意，有的文章中认为User Story是由Feature组成的，那实际上这个Feature，应该是Functionality。项目管理培训

　　4. Task

　　项目中可以执行的工作单位，通常就是迭代计划中项目(如Sprint Backlog中的项目)。一个User Story一般会分解为一个或多个Task，通过这些Task来实现。如显示单价这个User Story，可以分解成：

　　· 设计讨论会

　　· 服务器查询单价编码

　　· 服务器查询单价测试blog.mypm.net

　　· 客户端显示单价编码

　　· 客户端显示单价测试

　　当然一项Task也可能不实现任何User Story。如：Release plan meeting。

keaide

5. Epic Story

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

　　6. Theme

　　Theme则是一组User Story(甚至是Epic Story)，这些User Story拥有共同的特征，为了更容易开发这些相关内容，通常会将这些User Story作为一组进行开发和管理。这组User Story就被称为Theme。比如，有关报表这个机能，包括Excel报表、Word报表、PDF报表等，那么“报表”就是一个Theme。

　　对于Theme与Epic/Feature的关系，可以在自己的项目中进行明确定义。这取决于项目组成员的喜好。

keaide

因此，从层次上讲，这几个概念的关系应该是：

keaide

或者是：

keaide

值得注意的是，关于Epic、Feature和Theme这些概念，可以在自己的项目中自行定义，而不用一定遵守本文中的规则。只要在自己的项目中，通过绘制类似上面的关系图来明确他们的关系，并得到各个成员的认同即可。

quhp1978