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

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

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

kaverjody

发帖: 12粉丝: 10

级别 : 版主

发消息 + 关注

发表于2019年09月10日 10:29:01 3205 8
直达本楼层的链接
楼主
显示全部楼层
【DevCloud· 敏捷智库】如何进行需求结构化管理?

封面.png


为什么要进行需求结构化管理?

首先,并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求,也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联,那么不需要思考需求结构化管理这个问题。这种情况下,不管是用DevCloudScrum项目模板还是看板项目模板,都可以管理好需求和软件项目。只有在需求较多、且需求之间存在关联,而且即便是已经实现的需求也需要进行一定的管理、维护的情况下,我们才需要去思考需求结构化管理的问题,此时,我们需要使用DevCloud提供的Scrum项目模板,因为里面有Epic-Feature-Story的需求结构,以及需求规划功能可以辅助我们进行需求的结构化管理。

以什么为依据进行需求结构化管理?

需求结构化管理,应该以什么为脉络来建立这个结构呢?软件研发无非是分为项目型软件研发和产品型软件研发两种,项目通常来讲都是临时性的,或者说短期性的,而产品或者软件系统是长期性的,或者说我们会持续维护、更新其功能特性的。项目复项目,我们很可能通过持续地完善和刷新同一套软件产品或系统来达成项目目标,交付软件项目所要求的功能特性的。这就意味着,我们的需求结构化管理,需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息,则可以通过需求的不同属性甚至标签等方式来实现。

使用DevCloud进行需求结构化管理的一种方式

接下来,我们介绍推荐的一种方式。

一、针对产品或系统建立DevCloud项目

也即一个产品或系统,建立一个DevCloud项目,该产品或系统的所有需求,都在此DevCloud项目里面进行管理。

1566272863087.png

二、确立Epic-Feature-Story的需求结构

  • 这个产品或系统的业务模块作为Epic,比如用户中心、购物车、配送管理等,比如一家货运云商,他们的油卡业务,就适合作为一个Epic,针对油卡的各种功能,就可以作为Feature展开;Epic要承载业务价值,也即Epic需要是对企业本身是有意义的;

  • 针对前面业务模块的具体展开、拆开,就可以作为Feature,也可以简单理解为一个业务流程、用户流程;以前面用户中心为例,用户信息可以是一个Feature、我的订单可以是一个Feature、地址管理可以是一个Feature;或者以油卡为例,购买油卡、我的油卡等就可以作为不同的FeatureFeature要承载用户价值,也即对于用户来说,是可以理解这个Feature,且认可其价值的,通常Feature也是用户可以直接感知、可以操作的;

  • Feature往往还是有些大有些复杂,那就需要拆成颗粒度更小的Story,用来承载一个具体的用户操作,例如可以查看到所有订单、可以过滤订单、可以修改用户昵称、可以自定义头像等功能;

  • 再往下一级的Task,就主要是为了分工协作,也即是说,如果Story可以包干到人,那么不再拆分Task也是可以的;Task往往是关于工程师需要具体做的工作,也就跟业务价值、用户价值、用户单步操作都没有了什么关系,通常都是把Story按照具体的组件、模块进行拆分,例如前端、后台、数据库之类的,或者是按照工作流程分工来拆分,例如UCD、开发、测试、部署等;

    如下图所示,各层级为:

  1. Epic:用户中心

  2. Feature:地址管理

  3. Story:用户可以新建地址

  4. Task:【Web端】页面入口及地址编辑表单、【数据库】用户地址数据表设计和实现

    2.png

三、不同模块以及版本的管理

可以通过工作项的属性来进行管理如下图:

  • 模块:Web

  • 发布版本号:1.0.1.2

3.png

  • 至于模块清单的维护,可以在工作项编辑状态,点击模块字段右侧的小齿轮图标,即可在弹出窗口进行操作,可以添加、修改、删除模块:

4.png

  • 在工作项管理的Backlog视图下,通过设置显示字段增加模块字段后,既可以很方便地看到工作项相关的模块,当然也可以进行过滤:

5.png

参考附录

相关文章

相关书籍

  • Mike Cohn:《用户故事实战》

敏捷

举报
分享

分享文章到朋友圈

分享文章到微博

太宰治

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2019年09月10日 11:16:16
直达本楼层的链接
沙发
显示全部楼层

大佬级的分享!收藏了。期待后续更多内容。

点赞 评论 引用 举报

XXXXXXXXXXXXXXXXXX

发帖: 1粉丝: 3

级别 : 新手上路

发消息 + 关注

发表于2020年03月04日 17:30:56
直达本楼层的链接
板凳
显示全部楼层

学到了,我去实践看看

点赞 评论 引用 举报

自由的风

发帖: 5粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年05月08日 09:53:12
直达本楼层的链接
地板
显示全部楼层

建立结构化的管理,脉络很重要,感谢作者分享,学习了。

点赞 评论 引用 举报

yhl

发帖: 3粉丝: 1

级别 : 中级会员

发消息 + 关注

发表于2020年06月17日 23:40:28
直达本楼层的链接
5#
显示全部楼层

讲的很好,清晰易懂,学到了哈

以什么为依据进行需求结构化管理?

以产品或系统的功能特性的脉络为依据

谢谢老师


点赞 评论 引用 举报

hw43783673

发帖: 1粉丝: 0

级别 : 注册会员

发消息 + 关注

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

介绍推荐的这种方式非常好。

针对产品或系统建立DevCloud项目


确立Epic-Feature-Story的需求结构

  • 这个产品或系统的业务模块作为Epic,比如用户中心、购物车、配送管理等,比如一家货运云商,他们的油卡业务,就适合作为一个Epic,针对油卡的各种功能,就可以作为Feature展开;Epic要承载业务价值,也即Epic需要是对企业本身是有意义的;

  • 针对前面业务模块的具体展开、拆开,就可以作为Feature,也可以简单理解为一个业务流程、用户流程;以前面用户中心为例,用户信息可以是一个Feature、我的订单可以是一个Feature、地址管理可以是一个Feature;或者以油卡为例,购买油卡、我的油卡等就可以作为不同的FeatureFeature要承载用户价值,也即对于用户来说,是可以理解这个Feature,且认可其价值的,通常Feature也是用户可以直接感知、可以操作的;

  • Feature往往还是有些大有些复杂,那就需要拆成颗粒度更小的Story,用来承载一个具体的用户操作,例如可以查看到所有订单、可以过滤订单、可以修改用户昵称、可以自定义头像等功能;

  • 再往下一级的Task,就主要是为了分工协作,也即是说,如果Story可以包干到人,那么不再拆分Task也是可以的;Task往往是关于工程师需要具体做的工作,也就跟业务价值、用户价值、用户单步操作都没有了什么关系,通常都是把Story按照具体的组件、模块进行拆分,例如前端、后台、数据库之类的,或者是按照工作流程分工来拆分,例如UCD、开发、测试、部署等;,各层级为:

  1. Epic:用户中心

  2. Feature:地址管理

  3. Story:用户可以新建地址

  4. Task:【Web端】页面入口及地址编辑表单、【数据库】用户地址数据表设计和实现

    2.png

三、不同模块以及版本的管理

可以通过工作项的属性来进行管理

  • 模块:Web

  • 发布版本号:1.0.1.2


点赞 评论 引用 举报

张辉

发帖: 78粉丝: 29

级别 : 金牌会员

发消息 + 关注

发表于2020年07月05日 19:31:34
直达本楼层的链接
7#
显示全部楼层

Epic和feature太大,分类方法见仁见智。主要是用户故事story。这个应该是有明确的定义和标准的。比如INVEST原则,又比如3C原则(card-conversation-confirmation)

一般来说是这样的:

英文:
As a <Role>, I want to <Activity>, so that <Business Value>.
中文:
作为一个<角色>, 我想要<活动>, 以便于<商业价值>

task可以认为是story的分解,比如可以是为了完成一个story,各部分的协作分工情况。有可能从前端到后端到DB全部涉及。那么就可以把这些人的任务具体分解到task。

华为devcloud在需求规划这块已经涉及得比较成熟。但关键还是如何去写好story.有一个好的story,才会有一个好的系统。人家说,产品会讲故事才会卖得好就是这个道理。

点赞 评论 引用 举报

Lhosv

发帖: 1粉丝: 1

级别 : 中级会员

发消息 + 关注

发表于2020年07月25日 22:32:14
直达本楼层的链接
8#
显示全部楼层
如何进行需求结构化管理?


1、 需求判断

当我们收集到需求的时候就要判断该需求是不是伪需求,那么如何判断呢。我一般使用 用户——场景——需求,来判断。比如,教务老师想要在学生离开学校的时候给家长发送学生的离校通知。然后结合自己的产品定位以及该需求的使用频率大不大,我们目前的技术架构能否满足该需求,来判断该需求的优先级当我们确定我们要满足该需求,开发相应的功能,那么就把需求加入需求池。

2、 需求池的管理

需求池是对现有需求的汇总和统计,它的主要作用是帮助产品经理进行需求的管理和跟踪。每个公司对需求池的规范都不一致。之前我们公司没有需求池一说,都是产品经理根据自己的判断来进行,所以在工作中就造成了一些信息上的丢失,需要重复很多工作,造成了工作上的不便。所以我特地查找资料整理了一下,规范工作流程,方便自己及同事。

3、 需求的跟进

需求池中的需求在需求评审后会有一个开发计划,开发周期等,这时候合格的产品经理会通知提出该需求的人,通知他该需求的相关情况。这会给人一种你这个人非常靠谱的印象,且乐意再次给你提出相应的需求。当技术开发完成后也要进行验收,当该需求上线是最好再发一个通知,感谢相应付出的人,包括需求提出人和技术等,还需要告知运营,这不至于开发完相应的功能没人知道。

点赞 评论 引用 举报

进阶中的小白

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年08月31日 11:10:16
直达本楼层的链接
9#
显示全部楼层

讲的很具体很详细了,感谢大佬分享

点赞 评论 引用 举报

游客

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