# Scrum项目需求管理流程介绍
#### 方案概述
客户的需求或原始需求，通常是抽象甚至宏观的，需要理解客户需求背后的问题本质，来把客户需求或原始需求进行规划和分解，最终分解为每个迭代可交付的最小工作项。
Scrum项目类型中，预置了敏捷实践中推荐的"Epic \> Feature \> Story \> Task"的四层模型，如下图所示。
从原始抽象宏观的需求Epic（通常翻译为史诗），经过分解为多个Feature，继而再逐步分解为Story。Story是UserStory的简称，Story是站在用户视角符合INVEST原则的最小可交付的工作项单元。一个Epic分解为一个或多个Story，并根据开发团队的人力管道和Epic的计划时间，将Story规划到一个或多个迭代中持续交付。
一个宏观抽象的Epic通过这种方式保证了每个迭代都有可以运行的软件让用户试用，获取用户反馈，不断根据反馈进行修正，最终满足用户的需求并获得商业成功。
Scrum项目使用的工作项类型介绍如表 [Scrum项目工作项说明]所示。
 表1Scrum项目工作项说明 
| **工作项类型**       | **说明**                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | **举例**                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
|:---|:---|:---|
| Epic（史诗）   | - 通常翻译为史诗，指公司的关键战略举措，可以是重大的业务方向，也可以是重大的技术演进。 企业通过对Epic的发现、定义、投资、管理和落地达成，使得企业的战略投资主题得以落地，并获得相应的市场地位和回报。   - Epic的粒度比较大，需要分解为Feature，并通过Feature继续分解细化为Story来完成最终的开发和交付。  - Epic通常持续数月（months），需要多个迭代才能完成最终的交付。 Epic应该对所有研发人员可见，这样可以让研发人员了解交付的Story承载怎样的战略举措，让研发人员能更好的理解其工作的价值。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  | Epic通常和公司的经营、竞争力、市场环境紧密相关，举例如下： - 市场差异化：用户体验全面超越竞争对手。  - 更好的解决方案：新增支持工业互联网的解决方案。  - 增加收入：产品需要在下个财季增加100万付费用户。  - 重大技术方向：产品需要全部切换为容器。                                                                                                                                 |
| Feature（特性） | - 通常翻译为特性，代表可以给客户带来价值的产品功能或特性。  - Feature向上承接Epic，向下分解为Story。 相比Epic，Feature更具体形象，客户可以直接感知，通常在产品发布时作为ReleaseNotes的一部分发布给客户。   - Feature通常持续数个星期（weeks），需要多个迭代完成交付。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | Feature应该对客户都有实际的价值，特性的描述通常需要说明对客户的价值，与产品的形态、交付模式有关，举例如下： 推荐模板：作为\<用户角色\> ...我想要\<结果\>... 以便于\<目的\> - 用户A希望提供导入、导出功能，以便于用户批量整理数据，更高效。  - 用户B希望提供超期的通知，以便于用户及时处理任务。  - 用户C希望优化鼠标拖动的体验，以便于让用户操作更快。  - 用户D希望增加昵称功能，让用户更个性化。   |
| Story（用户故事）   | - 通常翻译为用户故事，User Story的简称。是从用户角度对产品需求的详细描述，更小粒度的功能。 Story承接Feature，并放入有优先级的backlog中，持续规划、滚动调整优先级，始终让高优先级的Story更早的交付给客户。 Story应遵循如下的INVEST原则： - **Independent**：每个用户故事应该是独立的，可独立交付给客户。  - **Negotiable**：不必非常明确的阐述功能，细节应带到开发阶段跟程序员、客户来共同商议。  - **Valuable**：对客户有价值。  - **Estimable**: 能估计出工作量。  - **Small**：要小一点，但不是越小越好，至少在一个迭代中能完成。  - **Testable**：可测试。     - Story通常持续数天（days），并应在一个迭代内完成交付。  - Story的工作量估计可以使用人时、人天，也可以使用敏捷推荐的故事点。 - 故事点英文名称Story Point，故事点是一种基于敏捷的估算工作量的方法。 故事点综合了交付Story所要付出的努力、开发复杂度、风险，可以简单理解为开发所需要的成本。   - 斐波那契数列（1,1,2,3,5,8...）是故事点比较常用的计量单位，是一种相对估算法。 如3个故事点的Story的工作量是1个故事点的Story的3倍。   - 目前默认提供的用户故事点是斐波那契数列。     | Story符合INVEST原则，举例如下： 推荐模板：作为\<用户角色\>...我想要\<结果\>...以便于\<目的\> - 作为**项目经理**，希望通过过滤处理人，以便于快速查询指定人的需求。  - 作为**开发人员**，希望将无用的信息进行折叠，以便于减少视觉干扰。  - 作为**测试人员**，希望将测试用例和需求关联，以便于跟踪需求的验证。                                                                                                                              |
| Task（任务）    | 在迭代计划会议中，将纳入迭代的Story指派给具体成员，并分解成一个或多个Task，填写"预计工时"。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               | Task通常为过程性的工作，举例如下： - 开发人员A需要在今天准备好类生产环境。  - 开发人员B需要在本周内完成项目组的权限设定。  - 开发人员C需要进行代码Review。                                                                                                                                                                                                                            |
| Bug（缺陷）        | - 软件特性和功能在测试验证阶段发现的问题，通过Bug单独创建、管理和跟踪，Bug通常包括不同的优先级。  - Bug可以单独创建和跟踪。 也可以在验证某个Story时创建，这时创建的Bug属于Story的子工作项，这样便于了解每个Story发现了多少个缺陷。   - Bug的描述应该尽可能描述详细，包括但不限于： - 缺陷现象描述。建议从用户视角描述。  - 错误码。错误码可以辅助分析定位代码问题。  - 环境信息，是开发环境，测试环境还是现网环境。  - 软件栈信息，包括对应的操作系统及其版本，数据库及其版本等等。  - 缺陷是否可以复现，复现的步骤。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  | 缺陷描述模板举例： 【故障现象描述】 【F12查看错误码】 【环境信息】 【故障复现步骤】 【故障现场定位开发人员】 【开发定位初步原因】 【Chrome抓取报文】                                                                                                                                                                                                                          |
   
#### 流程介绍
Scrum是增量迭代式的软件开发方法，也是当前主流的敏捷开发过程。通过迭代冲刺的方式，持续交付，从用户需求到用户反馈实现各个迭代闭环的软件开发过程。
通过迭代计划会议、每日站会、迭代回顾、验收会议来进行简单高效的管理。管理流程如下：
#### Scrum项目典型迭代操作流程
本操作流程介绍完成一个Scrum迭代的基本步骤，依此可以重复使用在每个迭代管理中做到持续规划与交付。
表2Scrum典型迭代流程与项目管理对应操作说明 
| 操作          | 说明                                                                                                                                                                                                                                                                                                                                                                                                    |
|:---|:---|
| 新建Scrum项目  | 新建Scrum项目详细操作步骤请参见：[创建CodeArts项目](https://support.huaweicloud.com/usermanual-projectman/projectman_ug_2000.html)。项目创建成功后可进行[公共配置管理](https://support.huaweicloud.com/usermanual-projectman/projectman_01_0007.html)。 项目创建成功后，请根据实际情况邀请成员加入项目。添加成员请参见：[添加CodeArts项目成员](https://support.huaweicloud.com/usermanual-devcloud/devcloud_01_0025.html)。                  |
| 需求规划       | 根据项目分解需求，进行思维导图或甘特规划，详细信息请参见：[新建思维导图规划](https://support.huaweicloud.com/usermanual-projectman/projectman_ug_0001.html#projectman_ug_0001__section1523120185257)和[新建甘特规划](https://support.huaweicloud.com/usermanual-projectman/projectman_01_0005.html#projectman_01_0005__section1523120185257)。                                                                                                    |
| 新建工作项      | 规划好需求后，需要新建工作项。详细操作步骤请参见：[在Scrum项目中新建工作项](https://support.huaweicloud.com/usermanual-projectman/devcloud_hlp_00023.html)、[在思维导图中新建工作项](https://support.huaweicloud.com/usermanual-projectman/projectman_ug_0001.html#projectman_ug_0001__section20251640124612)和[在甘特图中新建工作项](https://support.huaweicloud.com/usermanual-projectman/projectman_01_0005.html#projectman_01_0005__section20251640124612)。 |
| 管理迭代        | 对迭代进行规划与管理，详细操作步骤请参见：[配置Scrum项目迭代计划](https://support.huaweicloud.com/usermanual-projectman/devcloud_hlp_00034.html)。                                                                                                                                                                                                                                                                                  |
| 自定义工作流（可选） | 根据需要自定义工作流，详细操作步骤请参见：[Scrum项目公共配置管理](https://support.huaweicloud.com/usermanual-projectman/projectman_01_0007.html)。                                                                                                                                                                                                                                                                                  |
| 迭代回顾      | 迭代工作完成后，可以对每次迭代进行总结，方便下次迭代改进，详细操作步骤请参见：[跟踪Scrum项目进展](https://support.huaweicloud.com/usermanual-projectman/projectman_01_0006.html)。                                                                                                                                                                                                                                                                 |