|
技术评审
|
| 在工作中，我们经常可以听到以下的声音： “我们不进行评审，是因为我们项目比较特殊，没有时间……”。 “我们的项目已经进行了测试，不需要再进行评审了”。 “评审都是在走过场，没有效果……”。 业界公认评审是质量控制最有效的手段之一，但评审在很多公司却没能很好地实施，甚至没有实施，公司也未能从中获益。一方面因为员工不清楚评审的目的、评审和测试的区别，认为评审只不过是除了测试以外的锦上添花的过场。另一方面也因为许多公司制定的评审流程流于形式，缺乏可操作性，也未对员工进行评审流程的培训，未能在评审流程执行过程中提供适当的指导和监督。 Why-为什么要技术评审？ 测试无疑是质量控制最常用的方法之一，因此很多公司认为对产品进行了测试就万事大吉了。而评审是一种在产品开发过程中尽早发现缺陷的手段。根据IBM的统计数据显示：大多数企业的产品开发中，2/3的缺陷都是在需求和设计阶段引入的。因此，通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。 缺乏技术评审，或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”，开发人员不得不拼命加班“救火”，而最终由于缺陷越来越多，产品上市时间也所剩无几，不得不遗憾地放弃——产品只能带着缺陷发布给客户，听天由命了。 案例：某产品由于未经严格评审，而匆促上市，结果发现设计指标不符合规格书要求，设计中未考虑工程和维护的问题，产品质量问题多多，生产的单板直通率低，生产效率不高，结果开发工作重新回炉，导致客户投诉不断，用户怨声载道，严重影响用户关系和公司产品形象；导致所有开发人员全部出去救火，开发周期大大加长，开发投入增加，库存积压占用资金。 评审的目的在于：越早发现问题，总体成本越低，因此要评审，评审，再评审！等到测试已经太迟了！ What-什么是技术评审？ 测试和技术评审都是有效的质量控制手段，但也有明显的区别。 类似地，技术评审和测试的目的都是为了寻找缺陷，寻找缺陷的目标不是证明它是正确的，而是证明产品不能工作。 测试是在产品运行时进行的动态分析，测试的对象为原型、中间产品和最终产品。相对地，评审是一种静态分析，评审对象通常是技术文档、计划、测试用例和测试数据、测试结果等。 How- 如何做好技术评审？ 1、技术评审常见的问题 许多公司虽然执行了技术评审，但却未能从中获益，这往往是因为以下的原因导致的： 没有评审计划，没有充分的准备 专家选择不合适 评审会议偏离主题和重点，过多争论占用大量时间 没有使用Checklist作为指导 问题修改后跟踪不力…… 由此可见，评审效率不高的原因主要是因为缺乏可操作的评审规程、评审执行和跟踪不力导致的。因此，针对不同类型的工作产品，应制定包括多种评审类型的规程，并借助检查单的使用来提高评审的可操作性。 2、常见的技术评审的类型 常见的技术评审包括了走查（Walkthrough）、轮查（Pass Around）、正式的同行评审（Peer Reviews）等。 1) 走查（Walkthrough）：是大名鼎鼎的面向对象方法学的开发者之一Yourdon 定义的方法，它由作者启动和主持评审，作者向评审者展示文档。优点是启动快，成本低，缺点是容易被作者误导过程。 2) 轮查（Pass Around）：作者向评审者作简要介绍，但不参加评审过程；评审者独立进行评审，并记录发现结果、准备报告。 3) 同行评审：评审者与作者是地位平等的同行/专家，而不是领导对员工的评价；是最为结构化的评审方法；可以作为同行之间学习和分享经验的机会。 3、同行评审简介 在软件CMM中首次提出了同行评审（Peer Reviews）这个概念，它的目标是在产品开发过程中尽早发现缺陷，从而以较低的成本尽早解决缺陷。这种方法借鉴了IBM的范根检查法（Fagan Inspection）的优点，是一种结构化的正式的评审方法。 同行评审有明确的角色定义： 协调员（Moderator）：保证评审按流程进行。 朗读者（Reader）：评审的技术领导，把焦点放在有争议的问题方面。 记录员（Recorder）：负责记录缺陷。 评审员（Reviewer）：负责发现缺陷，除了作者外，所有的其他角色都可以担任评审员。 作者（Author）：负责修正缺陷。 同行评审通常包括六个步骤：制定计划、召开准备会议、评审人员独立预审、召开评审会议、返工、跟进返工结果。各个步骤的活动说明如下： 1) 计划：选择参与者；准备检查单。 2) 准备会：分配各参与人员的角色；作者对产品作概要介绍。 3) 个人预审：评审者研究评审文档，使用检查单寻找缺陷，记录发现结果。 4) 评审会议：读者阅读评审文档，评审员发现缺陷，对有争议的问题进行讨论；作者一般保持沉默，除非读者要求对产品作解释。 5) 返工：作者修正错误。 6) 跟进：检查修正工作的进展；分析错误原因；分析评审过程，补充完善检查单。 附：做好技术评审的小贴士 不因为时间紧迫和缺少预算而省略评审 评审前充分准备和沟通 安排合理的预审时间以便评审人员阅读评审材料 技术评审应当“就是论事”，不要把评审会开成“批斗会”，不要打击有失误的开发人员的工作积极性，更不准搞人身攻击，如挖苦、讽刺等 评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消除缺陷的办法，而不是替开发人员消除缺陷 把技术评审作为交流、提高的机会 记录评审中出现的问题，跟踪改进 定期改进技术评审检查单，把检查单作为持续改进的重要载体 评审者必须是领域内的专家 When-常见的技术评审点举例 在对工作产品建立基线之前进行评审，目的是发现缺陷。 附：TR2中使用的检查要素节选 项目 评审要素 需求分配与系统架构 产品包需求是否充分转换成设计需求？ 所有产品包需求（包括客户需求、可服务性/可维护性/可靠性等）是否清晰地定义并映射到产品概念中？ 产品概念的功能分解是否清晰地描述（譬如已经画成框图）？ 硬件和软件的集成方案是否考虑并确定好？ 根据被选产品概念形成的系统架构是否满足需求文档中的性能目标要求？ 技术方案选择 产品选择的技术的生命周期是否符合产品的规划？ 硬件概念是否可以用已有的芯片技术来实现，或者该技术的成熟度是否满足开发和交付的需要？ 选择的产品概念的风险和局限是否进行评估和记录？ 所有和包需求、设计需求、产品概念相关的问题是否被记录和进行风险评估？ 是否已经确定产品的标准和规范？ 在选择产品概念过程中是否对方案提供商进行了深入分析（包括产品选用的技术、平台、OS、关键物料等）？ |
