第三章 评审标准设计原则：可度量、可重现、可执行、可追溯
适用场景
本章适用于所有需建立版本评审检查点的研发交付流程，包括但不限于需求评审、设计评审、代码审查、测试准入准出、发布前复审等节点。当团队需要让评审从“主观感受”转向“客观证据”时，必须先对齐四个设计原则。
前置条件
- 已定义评审节点清单（如PRD评审、HLD评审、UT报告评审）。
- 已确定每个节点的责任角色（评审组长、评审员、记录员、整改人）。
- 已有基础的评审活动模板或检查项列表可被改造。
操作步骤
- 识别评审要素：列出该节点需要检查的所有维度（功能正确性、性能指标、安全合规、代码规范等）。
- 为每个要素分配度量单位：如“查询响应时间 ≤ 200ms”、“单元测试覆盖率 ≥ 80%”、“高危漏洞数为0”。
- 定义重现条件：明确输入数据要求、环境版本、操作序列，使得不同评审员在相同条件下能得到一致结论。
- 转化为可执行检查动作：将抽象标准拆解为“运行脚本xxx并比对结果”、“检查xxx字段值”、“验证有无xxx日志”。
- 建立追溯标识：每个标准关联唯一的评审标准编号（RSN），并注明来源（行业规范、客户需求、历史缺陷库）。
- 试跑与校准：选择近期3个历史评审样例，用新标准重新打分，调整阈值直到团队共识达成。
输入输出物
| 输入物 | 输出物 |
|---|---|
| 原始评审检查项清单（非标准化） | 标准化评审标准表（含RSN、度量指标、重现条件、执行动作、追溯来源） |
| 历史评审记录（至少3个样例） | 试跑校准报告（差异分析、阈值调整记录） |
| 版本规划中各里程碑角色职责定义 | 每个评审节点的责任矩阵（RACI） |
责任边界
- 评审流程设计师（SOP Owner）：负责提炼原则、编写标准表、组织试跑校准。
- 技术负责人/架构师：提供重现环境和执行动作的技术可行性判断。
- QA/SQA：审核度量指标的行业合理性及可测性。
- 版本经理：确认标准与版本发布条件的对齐关系。
记录材料
- 标准化评审标准表（Excel或在线表格）：包含字段：RSN、节点名称、维度、度量指标、重现条件、执行步骤、追溯来源、版本、所属人。
- 试跑校准会议纪要：记录每次校准的评审项目、分歧点、最终调整值。
- 原则合规自检表：每增加一条标准，自检四项原则是否符合（可度量、可重现、可执行、可追溯）。
异常处理
| 异常场景 | 处理措施 |
|---|---|
| 某维度无法找到客观度量指标（如“代码可读性”） | 降级为“强制检查清单”（如必须包含注释率≥20%、无魔法数字），并标记为“弱度量”，后续版本迭代提升 |
| 重现条件依赖特定硬件/环境，评审员无法复现 | 录制基线环境镜像或提供标准化Docker容器，纳入评审平台工具链 |
| 追溯来源为历史缺陷，但缺陷记录已丢失 | 标注“来源：历史缺陷（ID待补）”，并触发缺陷库数据补齐流程 |
| 试跑中发现多条标准相互矛盾（如性能与安全冲突） | 交由架构师给出优先级排序，并在标准表中增加“冲突处理规则”字段 |
验收标准
- 每个评审节点至少包含5条符合四项原则的标准化条目。
- 随机抽选2条标准，由两位不同角色（如开发+测试）独立执行，结果完全一致（可重现验证通过）。
- 所有标准在试跑过程中未出现无法执行的情况（环境缺失/指令不清晰等）。
- 每条标准都能通过RSN追溯到具体的需求编号/缺陷编号/行业文档章节。
⚠ 避坑提醒： 不要将“评审意见”本身作为标准。例如：“代码需整洁”不具备可度量性，应改为“单函数行数 ≤ 80行，圈复杂度 ≤ 10”。同时避免定义“可通顺阅读”这类主观描述，必须使用数字、枚举值、条件分支等可验证术语。
💡 最佳实践： 对复杂维度（如安全性）可拆分到“最小可验证粒度”。例如：“所有用户输入必须经过HTML转义”可以写成执行动作：“扫描所有Controller层的参数，检查是否有 @XssFilter 注解，且存在对应过滤实现类”。
注意： 可追溯不意味着每个标准都要复制URL。更高效的做法是建立“标准-来源”关联表，在标准表中只存储来源ID，通过统一数据字典查询。避免标准表本身因URL变动而失效。
✏️ 现场练习： 请拿出你当前负责的某个评审节点（如功能设计评审），写出一条原检查项（如“接口设计合理”），然后按照本流程SOP将其转化为四项原则完备的标准。对比如下：
原检查项：接口设计合理
转化为：
RSN-003-01: 接口参数校验（可度量：所有必填参数必须有@NotEmpty，边界值测试通过率100%；
可重现：使用DemoClient请求示例（见附件），返回状态码必须为200；
可执行：运行Postman测试集合“api_validation.postman_collection”；
可追溯：来源自《API安全规范》第4.2条）