技术评审

在工作中,我们经常可以听到以下的声音:

    “我们不进行评审,是因为我们项目比较特殊,没有时间……”。

    “我们的项目已经进行了测试,不需要再进行评审了”。

    “评审都是在走过场,没有效果……”。

    业界公认评审是质量控制最有效的手段之一,但评审在很多公司却没能很好地实施,甚至没有实施,公司也未能从中获益。一方面因为员工不清楚评审的目的、评审和测试的区别,认为评审只不过是除了测试以外的锦上添花的过场。另一方面也因为许多公司制定的评审流程流于形式,缺乏可操作性,也未对员工进行评审流程的培训,未能在评审流程执行过程中提供适当的指导和监督。

    Why-为什么要技术评审?

    测试无疑是质量控制最常用的方法之一,因此很多公司认为对产品进行了测试就万事大吉了。而评审是一种在产品开发过程中尽早发现缺陷的手段。根据IBM的统计数据显示:大多数企业的产品开发中,2/3的缺陷都是在需求和设计阶段引入的。因此,通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。

    缺乏技术评审,或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”,开发人员不得不拼命加班“救火”,而最终由于缺陷越来越多,产品上市时间也所剩无几,不得不遗憾地放弃——产品只能带着缺陷发布给客户,听天由命了。

    案例:某产品由于未经严格评审,而匆促上市,结果发现设计指标不符合规格书要求,设计中未考虑工程和维护的问题,产品质量问题多多,生产的单板直通率低,生产效率不高,结果开发工作重新回炉,导致客户投诉不断,用户怨声载道,严重影响用户关系和公司产品形象;导致所有开发人员全部出去救火,开发周期大大加长,开发投入增加,库存积压占用资金。

    评审的目的在于:越早发现问题,总体成本越低,因此要评审,评审,再评审!等到测试已经太迟了!

    What-什么是技术评审?

    测试和技术评审都是有效的质量控制手段,但也有明显的区别。

    类似地,技术评审和测试的目的都是为了寻找缺陷,寻找缺陷的目标不是证明它是正确的,而是证明产品不能工作。

    测试是在产品运行时进行的动态分析,测试的对象为原型、中间产品和最终产品。相对地,评审是一种静态分析,评审对象通常是技术文档、计划、测试用例和测试数据、测试结果等。

    How- 如何做好技术评审?

    1. 技术评审常见的问题

    许多公司虽然执行了技术评审,但却未能从中获益,这往往是因为以下的原因导致的:

    .没有评审计划,没有充分的准备
    .专家选择不合适
    .评审会议偏离主题和重点,过多争论占用大量时间
    .没有使用Checklist作为指导
    .问题修改后跟踪不力……

    由此可见,评审效率不高的原因主要是因为缺乏可操作的评审规程、评审执行和跟踪不力导致的。因此,针对不同类型的工作产品,应制定包括多种评审类型的规程,并借助检查单的使用来提高评审的可操作性。

    2. 常见的技术评审的类型

    常见的技术评审包括了走查(Walkthrough)、轮查(Pass Around)、正式的同行评审(Peer Reviews)等。

    1) 走查(Walkthrough):是大名鼎鼎的面向对象方法学的开发者之一Yourdon 定义的方法,它由作者启动和主持评审,作者向评审者展示文档。优点是启动快,成本低,缺点是容易被作者误导过程。

    2) 轮查(Pass Around):作者向评审者作简要介绍,但不参加评审过程;评审者独立进行评审,并记录发现结果、准备报告。

    3) 同行评审:评审者与作者是地位平等的同行/专家,而不是领导对员工的评价;是最为结构化的评审方法;可以作为同行之间学习和分享经验的机会。

   

posted @ 2008-11-24 23:43  赖文华.NET  阅读(440)  评论(0编辑  收藏  举报