建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

FloraRen

发帖: 11粉丝: 5

级别 : 注册会员

发消息 + 关注

发表于2020年01月07日 17:27:15 3547 11
直达本楼层的链接
楼主
显示全部楼层
【DevCloud · 敏捷智库】读懂敏捷需求管理的4个关键词

封面.png


我们常见到Epic、Feature、Story和Task这些和敏捷相关的概念,它们之间的关系是什么?我们如何灵活使用这些概念,从而让敏捷的需求管理更为高效?本文为你解答,建议收藏。

什么是Epic、Feature、Story和Task

Epic、Feature、Story和Task用来划分需求颗粒度的标签,可以看作需求占位符,分别代表需求颗粒度从大到小。每个层级的需求本身又承载着一些意义,在进行需求划分的时候可以进行参考。

  • Epic:史诗,是项目的愿景目标。通过Epic的落地达成,使公司可以获得相应的市场地位和回报,具有战略价值。通常需要数月完成。

  • Feature:可以带来价值的产品功能和特性。相比Epic,Feature更具体,更形象,客户可以感知,具有业务价值。通常需要数周,多个Sprint才能够完成。

  • Story通常所说的用户故事,是User Story的简称。是从用户角度对产品功能的详细描述,承接Feature,并放入产品Backlog中,持续规划,滚动调整,始终让高优先级Story交付给客户,具有用户价值。Story要符合INVEST原则(Idependent, Negotiable,Valuable,Estimable,Small,Testable),通常需要数天,并在一个Sprint中完成。

  • Task:是团队成员要完成的具体任务。在Sprint计划会议上,将Story分配给成员,然后由成员分解为Task,并预估工时,通常在一天内完成。  

将上面的描述简单整理,如下表所示。

image.png

它们之间关系是什么

Epic-Feature-Story-Task是一种将需求进行结构化管理的方法,在使用时是从上到下逐层分解,形成自下而上的依赖。如下图所示。

image.png

在实际的开发过程中,需求会发生变化,我们要不断的调整,在调整中避免偏离目标方向,每次新建需求的时候都要记得向上对齐到Epic,保证所添加的Story和Task和它们上层是有关联的,这样就可以在一定程度上保证团队在朝着目标前进。更多关于需求结构化管理的内容,请阅读【参考附录】【DevCloud· 敏捷智库】如何进行需求结构化管理?

我们如何灵活使用这些概念,让需求管理更为高效

为了帮助大家加深对 Epic、Feature、Story和Task的理解,我们对一个案例进行需求拆分,过程中会结合项目管理平台进行展示,以华为云DevCoud为例。

案例:某大型商超受互联网的冲击,营业额大幅下滑。为了减少门店消费者流失,保有市场地位和份额,决定用6个月的时间建立自己的网上商城。

第一步: Epic确定和创建

根据前面的介绍,在进行需求确认的时候先看颗粒度,然后再考虑其承载意义。

※思考:一个产品是一个Epic吗?产品的每个业务模块是Epic还是Feature?

  • 产品通常具有战略意义,从这个角度看,产品适合作为一个Epic。但是不是所有的产品都适合,还要看产品是什么,它的颗粒度有多大。在本文的实例中,网上商城周期是6个月,目的是保有市场份额,从颗粒度和战略意义上,网上商城适合作为一个Epic。

  • 每个业务模块具体是Epic还是Feature要分情况。比如:构建智慧城市是一个愿景目标,下面包括智慧交通,智慧政务,智慧社区等,这些每个业务模块都很大,用Epic进行需求占位合适一些。

我们在DevCoud创建一个Scrum项目,命名为某大型商超网上商城,进入到【需求规划】的界面,在【Epic】下面新建,如下图所示。

image.png

新建之后,点击进入到详细编辑界面。将描述信息填写完整,可以使用DevCloud提供的模板,如下:

作为 <用户角色> ,对于这个Epic来说,用户角色是整个公司。

我想要 <结果>,想要的结果就是建造网上商城。

以便于 <目的> ,目的是想要减少消费者流失,保有市场地位和份额。

同时在基本信息中设定这个Epic的起止时间,优先级,重要程度,预计工时等信息。这些信息对于团队理解产品、理解项目起到至关重要的作用,所以要填写详细。编辑界面如下图所示。

image.png

第二步:将Epic分解为Feature

客户要求在6个月内交付5个功能模块:促销管理、会员管理、订单管理、配送管理和客户端。团队的一个Sprint是2个星期,每个模块大概需要2-3个Sprint完成,从颗粒度和承载的意义,这5个模块适合作为Feature。创建如下。

image.png

创建之后,如需要填写详细信息,可以在详细页面进行编辑。界面信息项和前面Epic的相同,此处不再赘述。

第三步:Feature分解为Story

敏捷开发是渐进明细的,不要求所有需求在相同时间做到同样详细,只要求当前Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint结束时完成交付。

客户优先级中,会员管理Feature优先级高,会员管理这个Feature就要在需求梳理会议上详细分解为Story放入到产品Backlog中。经过分解后,需要包含和管理员相关的以下功能: 积分管理、会员级别管理、用户分析、用户管理。这些具体的功能就可以作为Story。需要注意的是,我们分解出的Story要尽量在一个迭代内完成交付,如果无法完成就尝试继续分解。因为只有交付的Story才是有价值的,无法交付的Story对于当前Sprint来说就是浪费。分解后的Story如下图所示。

image.png

第四步:将Story划分为Task

在Sprint计划会议上,团队和PO要共同从产品Backlog中按照优先级顺序选择本次Sprint需要完成的Story,进入到冲刺Backlog中。团队成员认领后,将Story分解为Task,并进行估算。

※思考:Story和Task如何区分?

  • Story聚焦价值,需要在Sprint中完成,要用数天的时间,要符合INVEST原则。Story的描述是一个名词,如积分管理这个Story的完整描述是:作为管理员,我能够进行会员的积分管理,以此来划分消费等级提供不同增值服务。

  • Task聚焦实现价值,通过过程性的任务来实现Story的功能。通常是1-8个小时。Task的描述是一个动作。如积分管理这个Story,功能的实现需要通过业务逻辑开发,积分规则设计和积分数据库设计这几个过程来完成。这些就是Task。如下所示。

image.png

这样,从Epic开始,到Task结束,我们完成了网上商城的需求拆分。

总结:使用Epic、Feature、Story、Task管理需求时,需要注意以下几个方面。

1.敏捷开发中需求是逐步细化的,遵循自上而下的方式去分解需求。

2.Epic和Feature都是颗粒度比较大的需求,是用户对于产品的期望和功能特性的描述。

3.分解为Story的时候,目前正在进行的Sprint需要分的更小更细,将来的Sprint需求(可能是3个及以上)就不需要那样细分。当进行到某个Sprint时,再进行分解,细分成一组更小、更细的条目。

4.只有当前Sprint的Story进行Task分解。

5.所有这些粗略和详细的Story都放在产品Backlog中,整个列表要遵循DEEP( Detailed appropriately, Emergent , Estimated , Prioritized )原则,定期梳理和排序优化,保证高优先级的需求优先实现和交付。

6.在整个过程中需要和客户一直保持沟通合作,这样才能保证我们实现的功能是客户真正想要的。

写在最后

本文通过一个用户场景来帮助大家理解Epic、Feature、Story、Task的含义以及如何使用。因为没有相同的项目,所以在开发过程中还要结合产品和业务本身的特点,进行具体问题具体分析。为了更好的分析问题,我们需要扎实的掌握Epic、Feature、Story、Task的含义并理解他们之间的关系。相信随着大家深度使用,一定能运用的得心应手。敏捷路上,你我同行!

参考附录

1、Kenneth S. Rubin. Scrum精髓[M].北京:清华大学出版社。

2、Mike Cohn.用户故事与敏捷方法[M].北京:清华大学出版社。

3、【DevCloud· 敏捷智库】如何进行需求结构化管理?

4、文章博客地址:https://bbs.huaweicloud.com/blogs/142259


附件:【DevCloud•敏捷智库】读懂敏捷需求管理的4个关键词.pdf

 

游客,如果您要查看本帖隐藏内容请回复

举报
分享

分享文章到朋友圈

分享文章到微博

黄药师(黄隽)

发帖: 33粉丝: 5

级别 : 注册会员

发消息 + 关注

发表于2020年01月08日 08:35:01
直达本楼层的链接
沙发
显示全部楼层

用一个具体需求例子来阐述了需求层级管理的实践(Epic, Feature, Story, Task),并结合了工具使用,这样更容易理解。赞,共同学习。

评论

谢谢岛主鼓励~

... 查看全部
点赞 评论 引用 举报

忐忑如风一样的男子

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年01月09日 17:13:16
直达本楼层的链接
板凳
显示全部楼层

好文章,写的很棒,一起学习下

评论

感谢回复,期待更多的留言交流学习

... 查看全部
点赞 评论 引用 举报

远方丶奇迹

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年01月09日 18:28:23
直达本楼层的链接
地板
显示全部楼层

清晰的讲解方式,很容易理解,受益匪浅。

评论

谢谢

... 查看全部
点赞 评论 引用 举报

自由的风

发帖: 5粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年05月08日 09:49:05
直达本楼层的链接
5#
显示全部楼层

实际在使用的时候,有时候项目过大这四层结构是无法承载的,但是整体的逐层拆解的思路还是很实用的,感谢分享。

评论

是的,E-F-S-T也不是需求管理的银弹,总有无法适配的时候,重点是理解结构之间的框架和逻辑关系,用在我们的需求管理实践中。

... 查看全部
点赞 评论 引用 举报

kingtest

发帖: 13粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年05月27日 09:19:58
直达本楼层的链接
6#
显示全部楼层

讲的很清楚,很详细。

评论

谢谢

... 查看全部
点赞 评论 引用 举报

忐忑如风一样的男子

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年06月05日 16:21:55
直达本楼层的链接
7#
显示全部楼层

思路清晰,有条有理,收藏

评论

感谢回复,期待更多的留言一起交流学习

... 查看全部
点赞 评论 引用 举报

Lhosv

发帖: 1粉丝: 1

级别 : 中级会员

发消息 + 关注

发表于2020年06月23日 00:25:02
直达本楼层的链接
8#
显示全部楼层

什么是Epic、Feature、Story和Task?

image.png

四者之间关系如下图所示

image.png

两张图很直白,一看就懂,收进相册了,感谢

评论

感谢回复,期待对这两张图实践理解后的更新分享。

... 查看全部
点赞 评论 引用 举报

Hello Digger

发帖: 9粉丝: 0

级别 : 高级会员

发消息 + 关注

发表于2020年06月30日 00:12:57
直达本楼层的链接
9#
显示全部楼层

自上而下敏捷需求分解步骤小结:

第一步—— Epic确定和创建(根据颗粒度和战略意义弄清Epic是什么)

第二步——将Epic分解为Feature(分析业务模块是否适合作为Feature)

第三步——Feature分解为Story(Story要尽量在一个迭代内完成交付)

第四步——将Story划分为Task(只有当前Sprint的Story进行Task分解)


评论

括号中的要点抓的很准确,赞

... 查看全部
点赞 评论 引用 举报

恺帝帝

发帖: 1粉丝: 0

级别 : 注册会员

发消息 + 关注

发表于2020年07月02日 00:58:21
直达本楼层的链接
10#
显示全部楼层

我们如何灵活使用这些概念,让需求管理更为高效?

第一步: Epic确定和创建

根据前面的介绍,在进行需求确认的时候先看颗粒度,然后再考虑其承载意义。

※思考:一个产品是一个Epic吗?产品的每个业务模块是Epic还是Feature?

  • 产品通常具有战略意义,从这个角度看,产品适合作为一个Epic。但是不是所有的产品都适合,还要看产品是什么,它的颗粒度有多大。在本文的实例中,网上商城周期是6个月,目的是保有市场份额,从颗粒度和战略意义上,网上商城适合作为一个Epic。

  • 每个业务模块具体是Epic还是Feature要分情况。比如:构建智慧城市是一个愿景目标,下面包括智慧交通,智慧政务,智慧社区等,这些每个业务模块都很大,用Epic进行需求占位合适一些。

第二步:将Epic分解为Feature

客户要求在6个月内交付5个功能模块:促销管理、会员管理、订单管理、配送管理和客户端。团队的一个Sprint是2个星期,每个模块大概需要2-3个Sprint完成,从颗粒度和承载的意义,这5个模块适合作为Feature。

第三步:Feature分解为Story

敏捷开发是渐进明细的,不要求所有需求在相同时间做到同样详细,只要求当前Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint结束时完成交付。


评论

感谢回复,期待更多的留言交流分享

... 查看全部
点赞 评论 引用 举报

hw84820715

发帖: 5粉丝: 2

级别 : 中级会员

发消息 + 关注

发表于2020年07月11日 18:59:08
直达本楼层的链接
11#
显示全部楼层

敏捷管理之分层管理

传统软件开发(或者说瀑布式软件开发)方法,对于需求的看法是 – 尽可能详细的了解需求、分析需求以形成详尽的需求文档,然后就把文档交付给开发部门。敏捷软件开发中则是完全不一样的做法。首先敏捷需求是ODDE的,其中有一个点很重要就是Detailed Rightly (Appropriated) – 详略得当。

什么是详略得当

细粒度

细粒度的意思是这些产品列表条目是相对比较明确的,详细的。团队对于这些条目的认知是达成一致的。经常有学员问我,那这些条目到底多大合适?这里有一个经验值供参考(根据行业不同会有很大不同) – 一般来说,一个团队在一个迭代内完成6-12个条目为宜。细粒度一般也意味着马上要做的条目。

粗粒度

粗粒度指的是这些条目的细节还不清楚,团队有可能没有达成共识。粗粒度一般是接下来2-3个迭代要做的条目,并且会在产品列表梳理会上,对粗粒度的条目进行拆分、澄清,从而有可能变成细粒度的条目。

下一版本

有一些条目是近期不会考虑的,但从产品规划上需要有考虑的。比如正在做一个安卓APP,从长远来看是需要做iOS版本的,不过可能要3个月后才会考虑。这样的条目就是下一版本的。

为什么详略得当很重要

敏捷需求是有分层的,正如上一节讨论的,分为:已完成,细粒度,粗粒度,下一版本。

,产品列表中的条目也是可以分为鱼虾级别(故事)、大海级别(Epic)和风筝级别(Theme)。

那么为什么详略得当如此重要呢?

这是因为产品列表条目,我们(作为人类)不可能一次获得所有信息。在产品开发的早期,获得的信息尤其少,那这个时候做出的需求分析(或决策)怎么可能包含所有的条目呢?因此条目就不可避免的有大海和风筝,只有少量的鱼虾可以完成。随着完成的鱼虾越来越多,我们获得的信息也越来越多,对产品的认知也越来越清楚,从而能够做出更加可信的决策。


评论

需求结构化的分层管理中,详略得当是很难把握,究竟鱼虾、大海、风筝具体如何区分,团队成员如何能理解共同使用相同语言,感谢分享。

... 查看全部
点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册