更新时间:2021-10-13 20:04
在软件的生命周期内所实施的对软件本身的评审。
评审是对软件元素或者项目状态的一种评估手段,以确定其是否与计划的结果保持一致,并使其得到改进。
一般来说,评审(Peer Review)包括下面几种
检视(Inspection)
团队评审(Team Review/Technical Review)
走读(WalkThrough)
成对编程(Pair Programming)
同行检查(Peer DeskCheck)
特别检查(Ad hoc Review)
评审方法间的区别(1)
评审方法间的区别(2)
评审中的误区(1)
误区一:评审参与者不了解评审过程
如果评审参与者不了解整个的评审过程,就会有一种自然的抗拒情绪,因为大家看不到做这件事情的效果,感觉到很迷茫,这样会严重的影响大家参与评审的积极性。
评审中的误区(2)
误区二:评审人员评论开发人员,而不是产品
评审的主要目的是发现产品中的问题,而不是根据产品来评价开发人员的水平。但是往往会出现把产品质量和开发人员水平联系起来的事情,于是评审变了“味”,变成了“批斗大会”,极大的打击了开发人员的自尊心,以至严重的影响了评审的效果。
评审中的误区(3)
误区三:评审没有被安排进入项目计划
参与评审需要投入大量的时间和精力,应该被安排进入项目计划中。但是现实的情况往往是,评审变成了“义务工”,参与评审的人员必须加班加点才能完成评审任务。如此一来,出现评审人员对评审对象不了解的情况也就不足为奇了。
评审中的误区(4)
误区四:评审会议变成了问题解决方案讨论会
评审会议主要的目的是发现问题,而不是解决问题,问题的解决是评审会议之后需要做的事情。但是,由于开发人员对技术的追求,评审会议往往变成了问题研讨会,大量的占用了评审会议的时间,导致大量评审内容被忽略,留下无数的隐患。
评审中的误区(5)
误区五:评审人员事先对评审材料没有足够了解
任何一份评审材料都是他人智慧和心血的结晶,需要花足够的时间去了解、熟悉和思考。只有这样,才能在评审会议上发现有价值的深层次问题。在很多的评审中,评审人员因为各种的原因,在评审会议之前对评审材料没有足够的了解,于是出现了评审会议变成了技术报告的怪现象。
评审中的误区(6)
误区六:评审人员关注于非实质性问题
经常会出现这样的问题,在评审中,评审人员过多的关注于一些非实质性的问题,比如文档的格式,措词,而不是产品的设计。出现这样的情况,可能的原因有:没有选择合适的人参加评审;评审人员对评审对象没有足够的了解,无法发现深层次的问题。
评审中的误区(7)
误区七:忽视细节
在组织评审的过程中,很多人不太注意细节。比如会议时间的设定,会议的通知,会议场所的选择,会场环境的布置,会议设施的提供,会议上气氛的调节和控制等等,而实际上这样的细节会大大影响评审会议的效果。比如,很难想象,大家在一个空气混浊、噪音很大的会议室里面能够全身心的投入。