共识内容
在需求评审前，提前了解上下游业务逻辑
- 产品提供可用于了解的账号&环境
与人沟通时
- 和其他团队或第三方对需求内容或接口需求时，追问是否达成一致（方式：让对方复述）
- 会后将会议结论同步至群内
- 每个阶段都提供下个阶段时间（需求评审完当场确定技术方案评审时间和用例评审时间）
- 产品：注重预审，重要数据都要与研发确认一遍；PRD加入性能需求；产品验收时，发现一丁点奇怪现象就刨根问底直到找出奇怪现象的原因。
- 研发：涉及第三方接口都验证，直接和对方语音一次性沟通说明清楚
- 涉及另外团队直接让需求方和接口提供方沟通
- 产品需求->与研发预审->需求评审->用例评审(由第三步决定)->测试过程只提bug给需求对接负责人
阶段Check
需求评审
需求内审：
- 产品：产品无法评估可行性时，让研发评估整体可行性
- 产品：在prd中考虑性能需求
- 产品：细化需求评审颗粒度
- 研发：不熟悉的技术做调研，至少先做出demo来再估排期
- 测试：在需求评审后，测试验证测试环境能否支持需求实现
需求正审：
- 产品：复杂流程性需求，提供业务流程图
技术评审
- 研发时间>=3天都需要开展技术方案评审
- 涉及另外团队直接让需求方和接口提供方沟通
- 以后需求问题都直接找迭代负责人，由迭代负责人去协调解决
- 研发：涉及到外部接口，输出详细接口文档，每个字段都要做验证
- 研发：数据流图，服务依赖
开发阶段
- 研发：前端提测前，对照prd或者ue图自测，后端执行研发自测计划，输出测试报告
- 研发：开发环境数据无法满足开发及时提出
- 研发：多方参与技术评审，实现方应该拿到字段后自测
- 研发：发现问题拿到证明结果，一定要找对方核对确认
- 研发：多加注意技术拿到的数据是否准确，及时验证
- 研发：多与外部沟通，大数据量接口在测试阶段进行压测
- 研发：前端后续涉及到时间要对接清楚，前端提需求，后端要标清字段
用例评审
- 测试：用例评审前，做需求分析
- 测试：提前熟悉依赖方数据信息
- 测试：建立主流程研发自测计划与测试计划，给研发和测试使用
测试阶段
- 研发：测试环境数据有问题，上灰度后需要自测，没数据要造数据做验证。
- 研发：发测试环境后研发要自测通过后方可提测
- 研发：针对不确定的bug，需要进行详细标注并和产品进行沟通，由产品确定是否为bug
- 研发：bug原因在jira评论中描述清楚
研发：只要是重新打开的bug，研发需要多做3步：
- 1、增加测试数据组
- 2、了解并熟悉上下游的业务
- 3、研发出测试报告（测试出测试报告模板）
上线阶段
上线准备CheckList
- 检查配置
- 新服务域名验证
- 本地master分支要自己本地能运行通
- 是否刷库，刷库内容是否已准备完
- 需要运维处理的内容也在群里同步
- 需要服务器，域名，数据库都需要和运维提前沟通并确定申请时间
Checklist项
- [x]
| 阶段 | 待办 | 说明 |
|---|---|---|
| 需求评审 | 产品：整体可行性评估涉及上下游业务，是否已了解清楚Prd中是否考虑性能需求是否有业务流程图研发评估可行性未知技术点，提前完成demo测试需求评审后，测试验证各环境是否支持————用例评审具体时间技术方案评审具体时间 | |
| 技术评审 | 注：研发时间>=3天都需要开展技术方案评审涉及到外部接口，输出详细接口文档，每个字段都要做验证数据流图，服务依赖 | |
| 开发阶段 | 开发环境是否满足开发上下游业务的熟悉了解涉及另外团队接口验证接口是否满足需求，数据是否正确大数据量接口在测试阶段进行压测前端核实后端接口是否满足要求（时间格式，数据格式等）前端提测前，对照prd或者ue图自测，后端执行研发自测计划，输出测试报告 | |
| 用例评审 | 用例评审前，做需求分析提前熟悉依赖方数据信息建立主流程研发自测计划与测试计划，给研发和测试使用 | |
| 测试阶段 | 测试环境数据有问题，上灰度后需要自测，没数据要造数据做验证bug原因在jira评论中描述清楚针对不确定的bug，需要进行详细标注并和产品进行沟通，由产品确定是否为bug发测试环境后研发要自测通过后方可提测只要是重新打开的bug，研发需要多做3步：1、增加测试数据组2、了解并熟悉上下游的业务3、研发出测试报告（测试出测试报告模板） | |
| 上线阶段 | 上线准备CheckList检查配置新服务域名验证本地master分支要自己本地能运行通是否刷库，刷库内容是否已准备完需要运维处理的内容也在群里同步需要服务器，域名，数据库都需要和运维提前沟通并确定申请时间 |
