需求管理 CODEARTS REQ-如何理解敏捷需求管理的四个关键词:如何灵活使用这些概念，让需求管理更为高效？
下载需求管理 CODEARTS REQ用户手册完整版
如何灵活使用这些概念，让需求管理更为高效？
为了加深对Epic、Feature、Story和Task的理解，本文对一个案例进行需求拆分，过程中会结合CodeArts需求管理服务进行展示。
案例：
某大型商超受互联网的冲击，营业额大幅下滑。
为了减少门店消费者流失，保有市场地位和份额，决定用6个月的时间建立自己的网上商城。
- 第一步：Epic确定和创建
根据前面的介绍，在进行需求确认的时候先看颗粒度，然后再考虑其承载意义。
此处需要考虑一个问题：一个产品是一个Epic吗？产品的每个业务模块是Epic还是Feature？
- 产品通常具有战略意义，从这个角度看，产品适合作为一个Epic。但是不是所有的产品都适合，还要看产品是什么，它的颗粒度有多大。在本文的实例中，网上商城周期是6个月，目的是保有市场份额，从颗粒度和战略意义上，网上商城适合作为一个Epic。
- 每个业务模块具体是Epic还是Feature要分情况。比如：构建智慧城市是一个愿景目标，下面包括智慧交通、智慧政务、智慧社区等，这些每个业务模块都很大，用Epic进行需求占位合适一些。
在CodeArts创建一个Scrum项目，命名为“某大型商超网上商城”。进入“需求规划”界面，新建Epic：
图2 新建Epic
新建之后，单击进入到详细编辑界面。将描述信息填写完整，可以使用CodeArts提供的模板：
- 作为：对于这个Epic来说，用户角色是整个公司。
- 我想要：想要的结果就是建造网上商城。
- 以便于：目的是想要减少消费者流失，保有市场地位和份额。
同时在基本信息中设定这个Epic的起止时间、优先级、重要程度、预计工时等信息。这些信息对于团队理解产品、理解项目起到至关重要的作用，所以要进行详细填写。
图3 编写Epic
- 第二步：将Epic分解为Feature
客户要求在6个月内交付5个功能模块：促销管理、会员管理、订单管理、配送管理和客户端。团队的一个Sprint是2个星期，每个模块大概需要2-3个Sprint完成，从颗粒度和承载的意义，这5个模块适合作为Feature。
图4 Epic分解为Feature
创建之后，如需要填写详细信息，可以在详细页面进行编辑。界面信息项和前面Epic的相同，此处不再赘述。
- 第三步：Feature分解为Story
敏捷开发是渐进明细的，不要求所有需求在相同时间做到同样详细，只要求当前Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint结束时完成交付。
客户优先级中，会员管理Feature优先级高，会员管理这个Feature就要在需求梳理会议上详细分解为Story放入到产品Backlog中。经过分解后，需要包含和管理员相关的功能：积分管理、会员级别管理、用户分析、用户管理。这些具体的功能就可以作为Story。需要注意的是，分解出的Story要尽量在一个迭代内完成交付，如果无法完成就尝试继续分解。因为只有交付的Story才是有价值的，无法交付的Story对于当前Sprint来说就是浪费。分解后的Story如图5所示。
- 第四步：将Story划分为Task
在Sprint计划会议上，团队和PO要共同从产品Backlog中按照优先级顺序选择本次Sprint需要完成的Story，进入到冲刺Backlog中。团队成员认领后，将Story分解为Task，并进行估算。
此时面临一个问题：Story和Task如何区分？
- Story聚焦价值，需要在Sprint中完成，要用数天的时间，要符合INVEST原则。Story的描述是一个名词，如积分管理这个Story的完整描述是：作为管理员，我能够进行会员的积分管理，以此来划分消费等级提供不同增值服务。
- Task聚焦实现价值，通过过程性的任务来实现Story的功能。通常是1～8个小时。Task的描述是一个动作。如积分管理这个Story，功能的实现需要通过业务逻辑开发、积分规则设计和积分数据库设计这几个过程来完成，这些就是Task。如图6所示。
这样，从Epic开始，到Task结束，完成了网上商城的需求拆分。
