引言
我们常见到Epic、Feature、Story和Task这些和敏捷相关的概念，它们之间的关系是什 么？我们如何灵活使用这些概念，从而让敏捷的需求管理更为高效？本文为您详细剖 析这四个关键词。
什么是 Epic、Feature、Story 和 Task？
Epic、Feature、Story和Task用来划分需求颗粒度的标签，可以看作需求占位符，分 别代表需求颗粒度从大到小。每个层级的需求本身又承载着一些意义，在进行需求划 分的时候可以进行参考。
● Epic：史诗，是项目的愿景目标。通过Epic的落地达成，使公司可以获得相应的 市场地位和回报，具有战略价值。通常需要数月完成。
● Feature：可以带来价值的产品功能和特性。相比Epic，Feature更具体，更形 象，客户可以感知，具有业务价值。通常需要数周，多个Sprint才能够完成。
● Story：通常所说的用户故事，是User Story的简称。Story是从用户角度对产品功 能的详细描述，承接Feature，并放入产品Backlog中，持续规划，滚动调整，始 终让高优先级Story交付给客户，具有用户价值。Story要符合INVEST原则
（Idependent、Negotiable、Valuable、Estimable、Small、Testable），通常 需要数天，并在一个Sprint中完成。
● Task：是团队成员要完成的具体任务。在Sprint计划会议上，将Story分配给成 员，然后由成员分解为Task，并预估工时，通常在一天内完成。
Epic、Feature、Story 和 Task 之间关系是什么？
Epic-Feature-Story-Task是一种将需求进行结构化管理的方法，在使用时是从上到下 逐层分解，形成自下而上的依赖。如下图所示。
在实际的开发过程中，需求会发生变化，我们要不断的调整，在调整中避免偏离目标 方向，每次新建需求的时候都要记得向上对齐到Epic，保证所添加的Story和Task和它 们的上层是有关联的，这样就可以在一定程度上保证团队在朝着目标前进。
更多关于需求结构化管理的内容，请参考如何进行需求结构化管理。
我们如何灵活使用这些概念，让需求管理更为高效？
为了加深对Epic、Feature、Story和Task的理解，本文对一个案例进行需求拆分，过程 中会结合DevCloud项目管理服务进行展示。
案例：
某大型商超受互联网的冲击，营业额大幅下滑。
为了减少门店消费者流失，保有市场地位和份额，决定用6个月的时间建立自己的网上商城。
● 第一步：Epic确定和创建
根据前面的介绍，在进行需求确认的时候先看颗粒度，然后再考虑其承载意义。
此处需要考虑一个问题：一个产品是一个Epic吗？产品的每个业务模块是Epic还 是Feature？
– 产品通常具有战略意义，从这个角度看，产品适合作为一个Epic。但是不是 所有的产品都适合，还要看产品是什么，它的颗粒度有多大。在本文的实例 中，网上商城周期是6个月，目的是保有市场份额，从颗粒度和战略意义上，
网上商城适合作为一个Epic。
– 每个业务模块具体是Epic还是Feature要分情况。比如：构建智慧城市是一个 愿景目标，下面包括智慧交通，智慧政务，智慧社区等，这些每个业务模块 都很大，用Epic进行需求占位合适一些。
我们在DevCoud创建一个Scrum项目，命名为“某大型商超网上商城”。进入
“需求规划”界面，新建Epic，如下图所示。
新建之后，点击进入到详细编辑界面。将描述信息填写完整，可以使用DevCloud 提供的模板：
– 作为：对于这个Epic来说，用户角色是整个公司。
– 我想要：想要的结果就是建造网上商城。
– 以便于：目的是想要减少消费者流失，保有市场地位和份额。
同时在基本信息中设定这个Epic的起止时间，优先级，重要程度，预计工时等信 息。这些信息对于团队理解产品、理解项目起到至关重要的作用，所以要进行详 细填写。
● 第二步：将Epic分解为Feature
客户要求在6个月内交付5个功能模块：促销管理、会员管理、订单管理、配送管 理和客户端。团队的一个Sprint是2个星期，每个模块大概需要2-3个Sprint完成，
从颗粒度和承载的意义，这5个模块适合作为Feature。
创建之后，如需要填写详细信息，可以在详细页面进行编辑。界面信息项和前面 Epic的相同，此处不再赘述。
● 第三步：Feature分解为Story
敏捷开发是渐进明细的，不要求所有需求在相同时间做到同样详细，只要求当前 Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个 大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint 结束时完成交付。
客户优先级中，会员管理Feature优先级高，会员管理这个Feature就要在需求梳 理会议上详细分解为Story放入到产品Backlog中。经过分解后，需要包含和管理 员相关的以下功能: 积分管理、会员级别管理、用户分析、用户管理。这些具体的 功能就可以作为Story。需要注意的是，我们分解出的Story要尽量在一个迭代内完 成交付，如果无法完成就尝试继续分解。因为只有交付的Story才是有价值的，无 法交付的Story对于当前Sprint来说就是浪费。分解后的Story如下图所示。
● 第四步：将Story划分为Task
在Sprint计划会议上，团队和PO要共同从产品Backlog中按照优先级顺序选择本次 Sprint需要完成的Story，进入到冲刺Backlog中。团队成员认领后，将Story分解 为Task，并进行估算。
– Story聚焦价值，需要在Sprint中完成，要用数天的时间，要符合INVEST原 则。Story的描述是一个名词，如积分管理这个Story的完整描述是：作为管理 员，我能够进行会员的积分管理，以此来划分消费等级提供不同增值服务。
– Task聚焦实现价值，通过过程性的任务来实现Story的功能。通常是1-8个小 时。Task的描述是一个动作。如积分管理这个Story，功能的实现需要通过业 务逻辑开发，积分规则设计和积分数据库设计这几个过程来完成。这些就是 Task。如下所示。
这样，从Epic开始，到Task结束，我们完成了网上商城的需求拆分。
小结
使用Epic、Feature、Story、Task管理需求时，需要注意以下几个方面。
1. 敏捷开发中需求是逐步细化的，遵循自上而下的方式去分解需求。
2. Epic和Feature都是颗粒度比较大的需求，是用户对于产品的期望和功能特性的描 述。
3. 分解为Story的时候，目前正在进行的Sprint需要分的更小更细，将来的Sprint需求
（可能是3个及以上）就不需要那样细分。当进行到某个Sprint时，再进行分解，
细分成一组更小、更细的条目。
4. Task是对当前Sprint的Story进行的分解。
5. 所有这些粗略和详细的Story都放在产品Backlog中，整个列表要遵循DEEP
（Detailed appropriately、Emergent、Estimated、Prioritized）原则，定期梳理 和排序优化，保证高优先级的需求优先实现和交付。
6. 在整个过程中需要和客户一直保持沟通合作，这样才能保证我们实现的功能是客 户真正想要的。
本文通过一个用户场景来帮助大家理解Epic、Feature、Story、Task的含义以及如何使 用。在现实业务中，没有相同的项目。因此在开发过程中还要结合产品和业务本身的 特点，进行具体问题具体分析。
参考文献
● 《Scrum精髓》，Kenneth S. Rubin
● 《用户故事与敏捷方法》，Mike Cohn 取任务。在敏捷中，不管是敏捷宣言还是Scrum指南，都没有指派（assign）一词，
而是使用了一个术语自组织，如下：
● 最佳的架构、需求和设计出自于自组织的团队（敏捷宣言12项原则）。
● 自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导
（Scrum指南）。
● 他们是自组织的。没有人（即使是Scrum Master）有权告诉开发团队应该如何把 产品待办列表变成潜在可发布的功能增量（Scrum指南）。
那么“自组织”是什么呢？
从敏捷宣言和Scrum指南关于任务的工作方式上来看，在我们践行敏捷的时候，主要 发挥的是开发团队自身的主观能动性，开发团队由原来的控制性转变成了自组织性，
在Scrum指南中指出“领取工作在Sprint计划会议和Sprint期间按需进行。”可以理解 为，在每日Scrum站会上基于目标领取任务。另外，Mike Cohn也表示过，不建议在计 划会议中领取开发任务，这样可能会导致目标由团队变为了个人，进而违背了敏捷的