敏捷开发需求管理和发布流程

敏捷开发需求管理及发布流程

目录

1目的 (2)

2变更定义 (2)

3角色及职责 (2)

4需求类型 (2)

5需求提交 (3)

6需求级别及处理 (3)

7发布规则 (4)

8有效期限 (4)

敏捷开发需求管理及发布流程1.0

一、目的

为了让业务部门的需求得到便捷反馈，准确评估，快速响应，实现过程中降低风险，确保质量，提供高效的保障服务，真正满足业务的需要和得到用户的认可，特制定本流程。

二、变更定义

改变当前业务逻辑、功能及架构、界面设计、展示内容、与其他系统的对接联动，特殊场景的支持等所进行的操作称为变更，包括但不限于对代码、配置、参数、数据等进行的修改。

三、角色及职责

四、需求类型：

- 新增需求：指根据业务逻辑，新增系统功能或界面设计、展示内容；

- 功能完善：指根据业务部门的需求，对系统现有的功能进行完善，微调，与

其他系统的对接联动，特殊场景的支持；

- 系统缺陷修改：指对一些系统功能或使用上的问题所进行的修复，这些问题是由于系统设计或实现上的缺陷而引发的；

- 取消需求：即根据业务调整，该需求不在本迭代做了。

五、需求提交

业务部门可以通过发邮件（邮件模板如下）发给研发部门人员，研发部门人员与业务部门充分沟通，了解业务真正的需求，仔细分析，确定需求级别，形成书面描述并发给需求者确认，用户确认的需求将记录在研发部门的系统中。邮件模板：

邮件标题：开发需求申请

需求类型（新增功能，完善功能，bug修复）：

需求描述：

附件或截图：

紧急程度（紧急，一般，不紧急）：

期望完成时间：

紧急：指2个工作日内必须完成；一般：指一周完成即可；不紧急：根据开发任务优先级安排

六、需求级别及处理方法

七、发布规则

1、发布系统之前必须通过测试人员和相关技术负责人或授权人的审核。

2、正常发布时间：每周四下午3点作为正式版本上线时间；

3、紧急发布：紧急发布时间根据实际情况而定，由研发部负责人确认，测试人员发起紧急发布，频次运维工程师把控。

4、发布前运维工程师需要做镜像备份。

5、发布后，测试工程师做最小化测试。如发现异常情况，但不影响用户使用，不做回滚。由测试人员发起，召集研发、运维，在线查找并修复异常。

6、发布过程中如代码遇到短时间不可修复的情况，运维发起与研发人员确认回滚操作，回滚操作确定后立即执行。

7、系统成功发布后，测试人员邮件通知产品经理、运营经理、研发经理和抄送部门总监，内容包含功能点及影响范围。

八、该流程由研发部门负责解释。2018年1月1日正式试行，有效期至新版本发布之日。