一、研发流程
需求评审--概要设计--设计评审--研发评估--工期确定--研发（含自测）--核心代码交叉review--转测--测试--上线评审--上线 （当前团队达成的共识）
↓
需求评审--研发评估--工期确定--概要设计--设计评审--研发（含自测）--核心代码交叉review--转测--测试--上线评审--上线 （规范流程未来目标）
需求评审完成后至测试工作结束前，测试需准备测试案例，并拉研发、产品进行测试案例评审。
二、操作规范
- 需求评审需要发邮件留痕(责任角色：产品)
- 概要设计要求数据库设计、核心功能概要设计、核心业务流程图（责任角色：开发）
- 概要设计评审需要发邮件留痕（责任角色：项目研发负责人）
- 研发在研发过程中实现功能时需要考虑并记录好发布注意事项（责任角色：开发）
- 核心代码交叉review，需要在wiki上记录（责任角色：开发） 5.1. review必须输出相关文档，文档样式我这边已经对照话费充值核心业务形成一版样例； 5.2. review必须输出问题点，通过问题点的确认、原因分析，形成解决方案和规范。
- 测试完成需要邮件留痕（责任角色：测试）
- 上线评审会（责任角色：项目研发负责人） 7.1 研发、产品、测试参加 7.2 评审发布内容、代码版本和提交情况、SQL（发布和回滚）、定时任务、参数配置、场景、注意事项 7.3 提供发布方案和回滚方案，如果没有回滚方案，需提供不能提供回滚的原因 7.4 侧重评估相关场景是否有遗漏，相关SQL是否安全，运行时长，生产影响，注意事项是否有遗漏 7.5 SQL时长评估可以在测试环境模拟生产数据量，进行测试评估
- 产品侧需要把验收的一部分工作前置，避免出现已经测试完成，才发现实现的功能不是产品预期的。（责任角色：产品）
- 发布人每次发布后需备份当前发布的程序（jar包或war包），用于快速回滚。（责任角色：发布人） 9.1 新规后的第一次发布，需同步备份之前的程序 9.2 备份的程序，需存放服务器指定目录，方便清除管理
各环节思考问题需要考虑两个维度：历史数据、历史功能等历史维度，新增功能、新增数据等未来维度。 各规范留痕责任时间：对应活动后第二个工作日结束前