4.2 单人评审 4.2.1 活动目的 对代码进行快速、灵活地评审，及早地识别和消除工作成果中存在的缺陷。 4.2.2 启动条件 代码完成时； 4.2.3 输入 代码 4.2.4 角色与职责 开发组成员/组长。 4.2.5 主要步骤 开发组成员完成各自负责代码后，由同组其他成员或者组长来进行代码评审，评审结果可录入《缺陷统计表》或者直接在代码中体现。 4.2.6 输出 缺陷统计表 4.2.7 退出条件 评审缺陷移除时 4.2.8 方法 见同行评审PPT中关于评审要点的描述 4.2.9 工具 无。 4.3 组评审 4.3.1 活动目的 对工作成果进行正式组评审，尽早地发现工作成果中的缺陷，帮助开发人员及时消除缺陷，促进项目组对被查对象和标准的共同理解。 4.3.2 启动条件 工程师已完成工作成果，并已对工作成果进行了内部检查，消除了拼写、排版等初级错误。 4.3.3 输入 待评审的工作成果和与该工作成果评审相关的一些材料，如评审检查表。 4.3.4 角色与职责 评审组：项目相关干系人，相关部门经理，相关部门副总裁（根据需要选择人员） 4.3.5 主要步骤
4.4 走查 4.4.1 活动目的 尽早地将缺陷移除；促进项目组对被查对象和标准的共同理解 4.4.2 启动条件 执行走查的工作成果完成时 4.4.3 输入 管理类文档产物、代码、 项目Demo以及与工作成果评审相关的一些材料，如评审检查表。 4.4.4 角色与职责 评审组：项目相关干系人，相关部门经理，相关部门副总裁（根据需要选择人员） 4.4.5 主要步骤 [Step1]评审 ● [Step1.1] 主持人（项目经理）宣讲 → 主持人宣讲本次评审会议的议程、重点、原则、时间限制等。 ● [Step1.2] 作者介绍工作成果 → 作者扼要地介绍工作成果。 ● [Step1.3] 识别缺陷和答辩 → 评审组根据“缺陷表”提出查找到的缺陷。 → 作者根据缺陷进行答辩，双方要对每个缺陷达成共识（避免误解）。 ● [Step1.4] 讨论缺陷解决方案 → 作者和评审组共同讨论缺陷的解决方案。 → 对于当场难以解决的问题，由主持人决定“是否有必要继续讨论”或者“另定时间再讨论”。 ● [Step1.5] 会议结束决议 针对所有缺陷给出评审结论和意见，主持人发起评审结论的确定，如评审组无法形成多数统一意见，由评审组最高领导作出最终判断。 → 评审结论有三种： （4）工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 （5）工作成果基本合格，需要作少量的修改，之后通过审核即可。 （6）工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 [Step2] 修正、跟踪与审核 ● [Step2.1] 修正与跟踪 → 作者修正工作成果，消除已发现的缺陷。 → 评审主持人和SQA跟踪每个缺陷的状态。 ● [Step2.2] 提交审核 → 作者消除所有已发现的缺陷后，再将修正后的工作成果递交给评审组审核。 ● [Step2.3] 审核工作成果 → 评审主持人（或者指定审查员）审核修正后的工作成果。审核结论有两种： （3）修正后的工作成果合格。 （4）修正后的工作成果仍然不合格，需重新修改，重复[Step3]。 4.4.6 输出 缺陷统计表、评审记录表（列入《同行评审管理表》中） 4.4.7 退出条件 评审缺陷关闭并且工作成果经过审核合格时。 4.4.8 方法 见同行评审PPT中关于评审要点的描述 4.4.9 工具 《评审检查表》 5、实施建议 希望最早进行此过程的培训，让评审人员明确目的、各评审人的职责，评审关注点。 不同设计时，不同角色评审人员关注点。 裁剪建议：可根据项目特点裁剪部分项目成果的评审。 6、涉及到的相关文件和表单 《评审检查表》 《缺陷统计表》 《同行评审管理表》 |
