需求规划和需求分解

更新时间： 2019/09/26 GMT+08:00

需求规划工作项说明

需求规划是以思维导图的形式将工作项的层级结构展示出来，更直观的展示父子关系，在需求规划中新建工作项后，会自动生成到Epic、Feature、Backlog和迭代页面列表中。

项目中已创建的工作项，如果从属于Epic根节点，会自动同步到需求规划页面。
按照工作项类型层级关系（从大到小依次为“Epic > Feature > Story > Task/Bug”类型）进行需求规划，具体为添加Epic类型工作项、给Epic工作项添加Feature类型子工作项、给Feature工作项添加Story类型子工作项。

说明：

为了快速实现产品核心功能，并尽快上线，尽早收集用户反馈，将产品的各个Feature中最能体现用户价值的Story设置为“高”优先级。

确保将产品的基本功能打通上线，而不是对某一个Feature做过度设计。

表1 需求规划工作项说明
工作项类型	说明	举例
Epic（战略举措）	中文通常翻译为史诗，指公司的关键战略举措，可以是重大的业务方向，也可以是重大的技术演讲。企业通过对Epic的发现、定义、投资、管理和落地达成，使得企业的战略投资主题得以落地，并获得相应的市场地位和回报。 Epic的粒度比较大，需要分解为Feature，并通过Feature继续分解细化为User Story来完成最终的开发和交付。 Epic通常持续数月（months），需要多个迭代才能完成最终的交付。 Epic应该对所有研发人员可见，这样可以让研发人员了解他们交付的Story承载怎样的战略举措，让研发人员能更好的理解其工作的价值。	Epic通常和公司的经营、竞争力、市场环境紧密相关，举例如下：例1 市场差异化：用户体验全面超越竞争对手。例2 更好的解决方案：新增支持工业互联网的解决方案。例3 增加收入：产品需要在下个财季增加100万付费用户。例4 重大技术方向：产品需要全部切换为容器。
Feature（特性）	中文通常翻译为特性，代表可以给客户带来价值的产品功能或特性。 Feature向上承接Epic，向下分解为User Story。相比Epic，Feature更具体形象，客户可以直接感知，通常在产品发布时作为ReleaseNotes的一部分发布给客户。 Feature通常持续数个星期（weeks），需要多个迭代完成交付。	Feature应该对客户都有实际的价值，特性的描述通常需要说明对客户的价值，与产品的形态、交付模式有关，举例如下：推荐模板：用户<角色> …希望<结果>… 以便于<目的> 例1 用户A希望提供导入、导出功能，以便于用户批量整理数据，更高效。例2 用户B希望提供超期的邮件通知，以便于用户及时处理任务。例3 用户C希望优化鼠标拖动的体验，以便于让用户操作更快。例4 用户D希望增加昵称功能，让用户更个性化。
Story（用户故事）	中文通常翻译为用户故事，User Story的简称。是从用户角度对产品需求的详细描述，更小粒度的功能。 Story承接Feature，并放入有优先级的backlog中，持续规划、滚动调整优先级，始终让高优先级的Story更早的交付给客户。 Story应遵循如下的INVEST原则： Independent：每个用户故事应该是独立的，可独立交付给客户。 Negotiable：不必非常明确的阐述功能，细节应带到开发阶段跟程序员、客户来共同商议。 Valuable：对客户有价值。 Estimable：能估计出工作量。 Small：要小一点，但不是越小越好，至少在一个迭代中能完成。 Testable：可测试。 Story通常持续数天（days），并应在一个迭代内完成交付。 Story的工作量估计可以使用人时、人月，也可以使用敏捷推荐的故事点。故事点英文名名称StoryPoint，故事点是一种基于敏捷的估算工作量的方法。故事点综合了交付Story所要付出的努力、开发复杂度、风险，可以简单理解为开发所需要的成本。斐波那契数列（1,2,3,5,8...）是故事点比较常用的计量单位，是一种相对估算法。如3个故事点的Story的工作量是1个故事点的Story的3倍。 DevCloud目前默认提供的用户故事点是斐波那契数列。用户也可以通过自定义字段设置自己的计量单位。	Story符合INVEST原则，举例如下：推荐模板：用户<角色>…希望<结果>…以便于<目的> 例1 作为项目经理，希望通过过滤处理人，以便于快速查询指定人的需求。例2 作为开发人员，希望将无用的信息进行折叠，以便于减少视觉干扰。例3 作为测试人员，希望将测试用例和需求关联，以便于跟踪需求的验证。
Bug（缺陷）	软件特性和功能在测试验证阶段发现的问题，通过Bug单独创建、管理和跟踪，Bug通常包括不同的优先级。 Bug可以单独创建和跟踪。也可以在验证某个Story时创建，这时创建的Bug属于Story的子工作项，这样便于了解每个Story发现了多少个缺陷。 Bug的描述应该尽可能描述详细，包括但不限于：缺陷现象描述。建议从用户视角描述。错误码。错误码可以辅助分析定位代码问题。环境信息，是开发环境，测试环境还是现网环境。软件栈信息，包括对应的操作系统及其版本，数据库及其版本等等。缺陷是否可以复现，复现的步骤。说明：以上的信息可以通过项目设置中的Bug设置，进行自定义设置。可以设置为工作项描述的模板，也可以设置为自定义的字段，这样可以约束团队成员都按照模板要求填写缺陷的必要信息。	缺陷描述模板举例：【故障现象描述】【F12查看错误码】【环境信息】【故障复现步骤】【故障现场定位开发人员】【开发定位初步原因】【Chrome抓取报文】
Task（任务）	在迭代计划会议中，将纳入迭代的Story指派给具体成员，并分解成一个或多个Task，填写“预计工时”。	Task通常为过程性的工作，举例如下：例1 开发人员A需要在今天准备好类生产环境。例2 开发人员B需要在本周内完成项目组的权限设定。例3 开发人员C需要进行代码Review。

需求规划

进入项目查看页面。

单击“工作 > 需求规划”菜单。

图1 需求规划

表2 需求规划参数说明
参数项	说明
状态	需求规划页面筛选，可以通过勾选感兴趣的工作项状态按需显示工作项。
优先级	三种颜色分别代表“高”、“中”、“低”优先级。
导入	既可以下载模板填写关键字后导入，也可以从其它项目导出的xls,xlsx导入。
导出	将被勾选“状态”的工作项导出压缩包，解压后为xlsx文件。
+/-	单击可以展开或隐藏该类型下所有子工作项。
	查看详情：查看此工作项详情，可以修改详细内容。
	删除：删除此工作项及其所有子工作项。
	插入子主题：输入名称即可新增一条子工作项，其它信息可以新建后单击名称继续编辑。说明：工作项“处理人”名称，新建时默认是该工作项“创建人”；可以通过查看工作项详情中设置其它成员为“处理人”。工作项截止日期，默认是创建该工作项时间的第二天；可以通过查看工作项详情编辑工作项具体起止时间。
	也可以通过键盘的快捷键，快速完成创建节点，创建子节点，删除节点的操作

添加Epic类型工作项（可添加多个），设置Epic工作项名称（如“Epic1”）后回车。
添加Epic工作项有如下方式：
- 单击。
- 选中总节点“需求规划”后摁“Insert”键。
- 选中已添加好的Epic工作项（如“Epic1”），摁“Enter”键。
- 将鼠标移动到总节点“需求规划”上，单击。
- 单击添加好的Epic工作项或单击可以查看Epic工作项详情。
- 双击添加好的节点，可以重新设置工作项名称。
给Epic工作项添加Feature子工作项（可添加多个），设置Feature工作项名称（如“Feature1”）后回车。
给Epic工作项添加Feature子工作项有如下方式：
- 选中已添加好的Epic工作项（如“Epic1”），摁“Insert”键。
- 选中已添加好的Feature工作项（如“Feature1”），摁“Enter”键。
- 将鼠标移动到已添加好的Epic工作项（如“Epic1”）上，单击。
- 单击添加好的Feature工作项或单击可以查看Feature工作项详情。
- 双击添加好的节点，可以重新设置工作项名称。
给Feature工作项添加Story子工作项（可添加多个），设置Story工作项名称（如“Story1”）后回车。
给Feature工作项添加Story子工作项有如下方式：
- 选中已添加好的Feature工作项（如“Feature1”），摁“Insert”键。
- 选中已添加好的Story工作项（如“Story1”），摁“Enter”键。
- 将鼠标移动到已添加好的Feature工作项（如“Feature1”），单击。
- 单击添加好的Story工作项或单击可以查看Story工作项详情。
- 双击添加好的节点，可以重新设置工作项名称。
给Story工作项添加Task子任务（可添加多个），设置Task工作项名称（如“Task1”）后回车。

调整需求规划图

在需求规划图中，可以选中工作项拖拽对工作项进行排序、还可以调整各级别工作项之间的层级关系。

点击放大

说明：

有子工作项的工作项只能往上一级别类型调整。
无子工作项的工作项可以往上或往下一级别类型调整。
需求规划完成后，规划好的工作项显示在对应页面中，如下：
- 所有添加好的Epic工作项显示在“工作 > Epic”页面中。
- 所有添加好的Feature工作项显示在“工作 > Feature”页面中。
- 所有添加好的Story工作项显示在“工作 > Backlog”页面中。
单击工作项，可以查看工作项详情。