注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

集思广益

我以我心看世界,此刻我就是世界的中心!

 
 
 

日志

 
 

企业都在做技术评审,效果不好人尽皆知 - Michael的日志  

2009-04-12 20:49:56|  分类: 资料收集 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

在工作中,我们经常可以听到以下的声音:
“我们不进行评审,是因为我们项目比较特殊,没有时间……”。

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

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

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

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

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

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

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

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

评审会议偏离主题和重点,过多争论占用大量时间

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

Walkthrough)、轮查(Pass Around)、正式的同行评审(Peer Reviews)等。

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

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

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

CMM中首次提出了同行评审(Peer Reviews)这个概念,它的目标是在产品开发过程中尽早发现缺陷,从而以较低的成本尽早解决缺陷。这种方法借鉴了IBM的范根检查法(Fagan Inspection)的优点,是一种结构化的正式的评审方法。

协调员(Moderator):保证评审按流程进行。

朗读者(Reader):评审的技术领导,把焦点放在有争议的问题方面。

记录员(Recorder):负责记录缺陷。

评审员(Reviewer):负责发现缺陷,除了作者外,所有的其他角色都可以担任评审员。

同行评审通常包括六个步骤:制定计划、召开准备会议、评审人员独立预审、召开评审会议、返工、跟进返工结果。各个步骤的活动说明如下:

准备会:分配各参与人员的角色;作者对产品作概要介绍。

个人预审:评审者研究评审文档,使用检查单寻找缺陷,记录发现结果。

评审会议:读者阅读评审文档,评审员发现缺陷,对有争议的问题进行讨论;作者一般保持沉默,除非读者要求对产品作解释。

附:做好技术评审的小贴士

安排合理的预审时间以便评审人员阅读评审材料

技术评审应当“就是论事”,不要把评审会开成“批斗会”,不要打击有失误的开发人员的工作积极性,更不准搞人身攻击,如挖苦、讽刺等

评审人员的职责是发现工作成果中的缺陷,并帮助开发人员给出消除缺陷的办法,而不是替开发人员消除缺陷

定期改进技术评审检查单,把检查单作为持续改进的重要载体

When-常见的技术评审点举例

在对工作产品建立基线之前进行评审,目的是发现缺陷。

图:常见的技术评审点

企业都在做技术评审,效果不好人尽皆知 - Michael的日志 - andy - Andy

产品包需求是否充分转换成设计需求?

所有产品包需求(包括客户需求、可服务性/可维护性/可靠性等)是否清晰地定义并映射到产品概念中?

产品概念的功能分解是否清晰地描述(譬如已经画成框图)?

硬件和软件的集成方案是否考虑并确定好?

根据被选产品概念形成的系统架构是否满足需求文档中的性能目标要求?

产品选择的技术的生命周期是否符合产品的规划?

硬件概念是否可以用已有的芯片技术来实现,或者该技术的成熟度是否满足开发和交付的需要?

选择的产品概念的风险和局限是否进行评估和记录?

所有和包需求、设计需求、产品概念相关的问题是否被记录和进行风险评估?

是否已经确定产品的标准和规范?

在选择产品概念过程中是否对方案提供商进行了深入分析(包括产品选用的技术、平台、OS、关键物料等)?

做评审需要各个部门通力配合,需要公司具备专家资源,这都是一般的企业所缺乏的,走过场是正常显现罢了
  评论这张
 
阅读(127)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018