版本迭代流程

研发流程

需求阶段 ---> 开发阶段 ---> 测试阶段 ---> 发布阶段

需求阶段：产品编写需求---> 产品输出原型图/需求文档，研发预研需求 ---> 需求评审。

开发阶段：撰写技术设计文档---> 技术评审---> 拆分需求--->工时评估---> 排期，确定版本-----> 需求池锁定 --->
开发需求---> 测试用例评审---> 单元测试----> CodeReview(代码评审)--->
开发进行冒烟测试---> 提测 ---> 发提测邮件，修改需求系统的需求状态。

测试阶段：测试---> 改bug---> 产品验收。

发布阶段：发布评审checklist ----> 发布到预发布环境 ----> 发布到生产环境。

需求评审

• 需求文档，提前一天给出，研发提前看文档。没看过文档的评审，是没有意义的。

需求拆分

大部分团队都会考核需求的数量。进行需求拆分，更能体现工作量。

• 按功能拆分
  比如一个大的功能，拆分为小功能。
  功能拆分，可以由开发进行工作项拆解，然后产品录入需求系统。

• 按岗位/人力拆分
  比如前端录一个需求，后端录一个需求。

技术设计文档

详情见: https://www.cnblogs.com/expiator/p/17146417.html

版本排期--里程碑

任务/日期	技术设计评审	出接口文档	前后端联调	代码评审	冒烟测试	提测	产品验收	发版
任务1	日期1	日期2	...	...	...
任务2	日期3	...

需求池锁定

一个版本/迭代的需求定下来之后，最好能锁定需求池，否则无休止地加需求，变更需求，研发永远做不完。

测试用例评审

测试用例评审，最好在提测的前两天评审，否则可能影响开发提测。

冒烟测试

测试给出冒烟用例，开发进行冒烟测试，跑完主要的冒烟测试用例后，再提测。

提测

合代码到测试环境 ---> 执行脚本，添加动态配置等 --> 部署测试环境 --> 发提测邮件 --> 修改需求系统的需求状态，通讯软件提醒。

发布评审checklist

涉及的微服务、数据库脚本、动态配置(配置中心或文件配置)、菜单配置、历史数据处理(脚本或接口)、数据验证需要的帐号。

发布到生产环境

合代码到生产环境 ---> 执行脚本，添加动态配置等 --> 部署预发布环境 --> 预发布环境验证 --> 部署生产环境 --> 生产环境验证。