目标
- 通过明确技术难度，根据不同难度等级需求输出不同详尽程度或要求的技术方案，避免技术方案质量的不可控。
- 通过理清技术实现思路，尽早发现在实现产品需求/功能中在技术实现上的问题，避免返工，提高代码质量。
- 通过梳理当前技术实现的全流程任务，进行任务拆分和工时预估，由相关人员进行规模预估的评审，尽可能及时发现风险和问题，避免因估算规模偏差大导致计划的不可控。
评审成员
评审形式
- 所有评审不限线上或线下形式
- 技术方案输出前如已判定故事为高难度高风险技术实现，及时邀请评审团成员参与共同需求评审或线下沟通
-
开发者：评估技术难度等级，确定技术方案输出标准
需求澄清会后，由相关开发成员在当前迭代下创建「前/后端技术方案评审」任务单，并根据以下技术难度标准判定进行技术难度等级评估 | 技术难度 |
前端判定标准标准 |
后端判定标准 | 方案输出标准 | | 归档要求 |
评审人 | | —- | —- | —- | —- | —- | —- | —- | | | | | 前端 | 后端 | | | | 简单 |
- 无业务变更风险
- 影响范围单一
|
- 无性能风险，判定标准见下方注释
- 影响范围单一
|
- 改动点
- 影响范围
|
- 配置项
- 接口设计
- 表设计
| 评审单中描述 |
| | 标准 |
- 无复杂交互
- 有业务变更但风险可控
- 影响范围广但明确
- 小规模改动底层框架
|
- 存在性能风险，判定标准见下方注释
- 影响范围广但明确
- 小规模改动底层框架
- 引入新的小型第三方库
|
- 改动组件
- 业务流程
- 影响范围
- 潜在风险
|
- 业务流程
- 配置项
- 接口设计
- 表设计
| 可根据实际情况：
- 评审单中描述
- wiki文档记录
|
| | 复杂 |
- 新项目/新业务
- 影响范围广
- 大规模改动底层框架
- 引入或升级NPM包依赖
- 组件库新增或者升级组件
- 复杂交互
|
- 新项目/新业务
- 影响范围广
- 大规模改动底层框架
- 引入新的大型第三方库
- 引入新的基础设施组件
|
- 调研过程记录
- 选型依据
- 影响范围
- 潜在风险
- 组件文档
|
- 调研过程记录
- 选型依据
- 版本/配置变更流程
- 业务流程
- 配置项
- 接口设计
- 表设计
| wiki文档记录 | |
开发者：输出技术方案，拆分任务，预估工时，创建评审单
若有收获，就点个赞吧
0 人点赞
