为什么要进行需求结构化管理？
首先，并不是说任何情况下都需要进行软件项目需求的结构化管理。
如果只是事务性质的管理需求，也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联，那么不需要思考需求结构化管理这个问题。这种情况下，不管是用 DevCloud 的 Scrum 项目模板还是看板项目模板，都可以管理好需求和软件项目。
只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，我们才需要去思考需求结构化管理的问题，此时，我们需要使用 DevCloud 提供的 Scrum 项目模板，因为里面有 Epic-Feature-Story 的需求结构，以及需求规划功能可以辅助我们进行需求的结构化管理。
以什么为依据进行需求结构化管理？
需求结构化管理，应该以什么为脉络来建立这个结构呢？
软件研发无非是分为项目型软件研发和产品型软件研发两种，项目通常来讲都是临时性的，或者说短期性的，而产品或者软件系统是长期性的，或者说我们会持续维护、更新其功能特性的。
项目复项目，我们很可能通过持续地完善和刷新同一套软件产品或系统来达成项目目标，交付软件项目所要求的功能特性的。这就意味着，我们的需求结构化管理，需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息，则可以通过需求的不同属性甚至标签等方式来实现。
使用 DevCloud 进行需求结构化管理的一种方式
针对产品或系统建立 DevCloud 项目
也即一个产品或系统，建立一个 DevCloud 项目，该产品或系统的所有需求，都在此 DevCloud 项目里面进行管理。
确立 Epic-Feature-Story 的需求结构
-
这个产品或系统的业务模块作为 Epic，比如用户中心、购物车、配送管理等，比如一家货运云商，他们的油卡业务，就适合作为一个 Epic，针对油卡的各种功能，就可以作为 Feature 展开；Epic 要承载业务价值，也即 Epic 需要是对企业本身是有意义的；
-
针对前面业务模块的具体展开、拆开，就可以作为 Feature，也可以简单理解为一个业务流程、用户流程；以前面用户中心为例，用户信息可以是一个 Feature、我的订单可以是一个 Feature、地址管理可以是一个 Feature；或者以油卡为例，购买油卡、我的油卡等就可以作为不同的 Feature；Feature 要承载用户价值，也即对于用户来说，是可以理解这个 Feature，且认可其价值的，通常 Feature 也是用户可以直接感知、可以操作的；
-
Feature 往往还是有些大有些复杂，那就需要拆成颗粒度更小的 Story，用来承载一个具体的用户操作，例如可以查看到所有订单、可以过滤订单、可以修改用户昵称、可以自定义头像等功能；
-
再往下一级的 Task，就主要是为了分工协作，也即是说，如果 Story 可以包干到人，那么不再拆分 Task 也是可以的；Task 往往是关于工程师需要具体做的工作，也就跟业务价值、用户价值、用户单步操作都没有了什么关系，通常都是把 Story 按照具体的组件、模块进行拆分，例如前端、后台、数据库之类的，或者是按照工作流程分工来拆分，例如 UCD、开发、测试、部署等；
如下图所示，各层级为：
1.Epic：用户中心
2. Feature：地址管理
3.Story：用户可以新建地址
4. Task：【Web 端】页面入口及地址编辑表单、【数据库】用户地址数据表设计和实现
不同模块以及版本的管理
可以通过工作项的属性来进行管理，如下图：
- 模块：Web 端
- 发布版本号：1.0.1.2
至于模块清单的维护，可以在工作项编辑状态，点击“模块”字段右侧的小齿轮图标，即可在弹出窗口进行操作，可以添加、修改、删除模块：
在工作项管理的 Backlog 视图下，通过“设置显示字段”增加“模块”字段后，既可以很方便地看到工作项相关的模块，当然也可以进行过滤：
本文转载自 华为云产品与解决方案 公众号。
评论