Feature

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

扫描条形码
显示单价
计算总价
计算税额
打印清单

因此，一个Feature是很难进行估算的，它需要被分解成一个个更小的单位，这就是下面要讨论的User Story。Feature一般在Release Plan的层次，一个Feature可能需要几次迭代才能完成。
由于Feature是满足用户需求的交付物，因此每次交付的对象应该是一个或多个Feature。可以说Feature就是敏捷宣言中的“Working software”。

Minimal Marketable Feature (MMF)

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

Epic Story

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

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)

Independent：独立的
Negotiable：可变的
Valuable：有价值的
Estimable：可估算的
Small：足够小的
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。

Theme

Theme则是一组User Story(甚至是Epic Story)，这些User Story拥有共同的特征，为了更容易开发这些相关内容，通常会将这些User Story作为一组进行开发和管理。这组User Story就被称为Theme。比如，有关报表这个机能，包括Excel报表、Word报表、PDF报表等，那么“报表”就是一个Theme。
　　
对于Theme与Epic/Feature的关系，可以在自己的项目中进行明确定义。这取决于项目组成员的喜好。
值得注意的是，关于Epic、Feature和Theme这些概念，可以在自己的项目中自行定义，而不用一定遵守本文中的规则。

类型	含义	说明
Epic	史诗级故事	简单点，你就理解为软件的版本好了，不需要太详细的秒速，但是要说清楚这个版本需要哪些大功能
Feature	特性	你都在史诗级故事中说好了要哪些大功能了，那作为它的子级的特性自然就是每个你需要的大功能的描述，但是由于一个大功能的实现有许多众所周知或者实际做了才知道的前置的或者后发的条件，所以特性的完成一定被项目中所有成员认可是一个较长的过程，所以肯定还需要进一步细化
Story	用户故事/积压工作项	把特性细化了以后就是这个了，故事之所以叫故事是因为内容读起来就像故事，参考中小学生作文吧，故事的三要素：参与者、行为、结果，（管理员在XX界面点击了【XXX】按钮后，界面跳转至【XXXX】界面）仅供参考。可以看出，故事要细致，描述细节，有明确的验收标准，任何人看完都应该知道如何操作，测试人员也可以以此来作为测试用例。
Task	任务	这是只有开发才知道的细节了，上面几个都是无论什么人都能看懂的东西，任务描述的应该是开发中的细节，比如（修改AAA类的BBB方法，提升执行效率）或者（将XXX功能的原有做法改为使用命令模式），只有开发才懂得的细节，由于此类工作也需要耗时，而且耗时可能还不短，这会违背“快速迭代”的基本价值观，所以当一个故事涉及到此类的行为时，就可能需要较长时间来迭代，所以应该在故事下建立任务来说明工作的具体内容

项目规划中的Epic、Feature、Story和Task的关系相关推荐

【K8s超级补丁】KLTS攻略：KLTS现有成果、如何使用、RoadMap规划，如何参与到KLTS项目贡献中来
欢迎来到 KLTS新手攻略,相信通过上期<DaoCloud道客云原生开源项目KLTS,全称为Kubernetes Long Term Support,为Kubernetes早期版本提供长期免费的 ...
Epic、Feature、Story和Task的关系
在敏捷项目的估算或计划时,我们常提到以下几个概念. Epic Story Feature Minimal Marketable Feature (MMF) Theme User Story Task ...
项目管理过程中应注意的问题
软件项目从角色分工方面可以划分为研发.开发和实施三类,每个类型的项目有各自的管理过程.下面笔者就公司实施类项目的经历,从项目经理的角度谈一谈实施类项目管理过程中应该注意的一些问题,希望大家共勉. 确定 ...
SVM算法在项目实践中的应用！
↑↑↑关注后"星标"Datawhale 每日干货 & 每月组队学习,不错过 Datawhale干货作者:苏丽敏,Datawhale优秀学习者,北理工计算机硕士支持向量机 ...
IT规划中的技术体系架构
IT规划中的技术体系架构体系架构通常会建立一个共有的能帮助今后持续发展的信息扩展基础,然而,简单的设定目标是远远不够的,必须和构建人员.客户.厂商及其他相关人员进行沟通以达成共识,在构建过程中要维护该 ...
全球及中国太阳能光热发电市场重点项目规划及发展格局展望报告2021-2027年
全球及中国太阳能光热发电市场重点项目规划及发展格局展望报告2021-2027年 HS--HS--HS--HS--HS--HS--HS--HS--HS--HS--HS--HS-- [修订日期]:2021 ...
【机器学习基础】SVM算法在项目实践中的应用！
作者:苏丽敏,Datawhale优秀学习者,北理工计算机硕士支持向量机(Support Vector Machine)是Cortes和Vapnik于1995年首先提出的,它在解决小样本.非线性及高维 ...
主数据治理项目实施中存在的问题
随着互联网.大数据.云计算等技术的快速发展与应用,在企业经营管理上对于数据的收集与治理越来越重要,主数据治理作为数据治理中重要的一环,是数据决策分析.深度应用集成的重要基础,也是企业信息化建设的必经之 ...
软件开发项目规划时，SA、SD与SE的区别与重要性
做软件开发项目规划时, 常会碰到助理问我一个问题, SA,SD和SE的差别在那里 ? 这个问题我以前也有过, 还颇为困扰, 系统分析和系统设计及系统工程到底有什么差别 ? SA和SD的工作又有何不同 ...

项目规划中的Epic、Feature、Story和Task的关系