评审流程规范

评审范围

需求内审、开发设计评审、开发计划评审、测试点评审、代码评审、SQL变更

评审流程A

适用于：需求内审、开发设计评审、开发计划评审、测试用例、代码评审

评审流程B

适用于：SQL变更、发版流程

评审要素

需求内审

1. 需求是完整、正确、可行、必要、具有优先级、无二义性和可验证的：
   • 与已知的需求或系统需求是否相互冲突或者重复？
   • 对其他需求的内部引用是否正确？
   • 是否描述了需求背景？
   • 是否每个需求都通过了演示（提供完整原型/UI）？
   • UI和原型是否冲突？
   • 是否定义并描述了功能的内在逻辑（算法）？
   • 是否遗漏了必要的信息？如果有遗漏的话，是否标记为待确定的问题？
   • 是否有预期的错误条件所产生的系统行为说明？
   • 是否对每个需求都定义了实现优先级？
   • 在现有的资源内，是否能实现所有的需求？
2. 产品经理的关注层面是价值驱动和成本驱动方面，应该明白不是所有的需求都要去实现，一些看上去很明显费力不讨好的需求应该果断地舍弃。

开发（接口）设计评审

1. 技术栈引用是否存在版权风险
2. 业务需求复杂流程详细设计
3. 性能分析
4. 数据库表结构设计（参考数据库规范）
5. 接口字段、文档、兼容分析（参考接口规范）
6. 异常处理机制

开发计划评审

1. 开发计划的时间粒度，以 0.5~1 天为宜，禁止出现超过 2 天的计划项
2. 开发计划的任务拆解粒度是否清晰、合理、可度量
3. 是否设立里程碑、检查点

测试点评审

1. 需求功能点覆盖
2. 预期结果是否正确
3. 错误场景是否可验证

代码评审

1. 是否遵循编码规范
2. 业务逻辑清晰、正确
3. 性能影响

SQL变更

1. 数据查询、验证
2. 数据备份、回滚方案
3. 锁表、对线上环境影响等风险防范
4. 业务数据变更风险防范

评审结束标准

评审会不是“研讨会”
1. 评审期间提出的所有问题都已经解决 2. 相关文档中的所有更改都已经正确完成 3. 所有待确定的问题已经全部解决，或者已经对每个待解决的问题明确了解决过程、计划、目标日期和责任人 4. 邮件发送评审纪要，包含上述内容