scrum项目需求管理流程介绍-九游平台

epic（战略举措）

• 通常翻译为史诗，指公司的关键战略举措，可以是重大的业务方向，也可以是重大的技术演进。

  企业通过对epic的发现、定义、投资、管理和落地达成，使得企业的战略投资主题得以落地，并获得相应的市场地位和回报。

• epic的粒度比较大，需要分解为feature，并通过feature继续分解细化为story来完成最终的开发和交付。
• epic通常持续数月（months），需要多个迭代才能完成最终的交付。

  epic应该对所有研发人员可见，这样可以让研发人员了解交付的story承载怎样的战略举措，让研发人员能更好的理解其工作的价值。

feature（特性）

• 通常翻译为特性，代表可以给客户带来价值的产品功能或特性。
• feature向上承接epic，向下分解为story。

  相比epic，feature更具体形象，客户可以直接感知，通常在产品发布时作为releasenotes的一部分发布给客户。

• feature通常持续数个星期（weeks），需要多个迭代完成交付。

feature应该对客户都有实际的价值，特性的描述通常需要说明对客户的价值，与产品的形态、交付模式有关，举例如下：

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抓取报文】