(转)同行评审要点

http://blog.csai.cn/user2/50889/archives/2010/44043.html

1、思想

中国人常说的同行评审更多包含了“评价”的意味&＃xff0c;目的是验证正确性&＃xff0c;而实际上&＃xff0c;同行评审的本意是Review&＃xff0c;即复查的意思&＃xff0c;目的在于找出问题。这一点必须成为所有组织、参加评审会人员应建立的共识。

可是&＃xff0c;我们经常听到“评审通过了”这样的话从被评审工作产品承制者口中说出来&＃xff0c;听上去似乎在说“我的工作真牛”。就像我们不想花大量的测试成本来验证自己的程序无错一样&＃xff0c;采用成本昂贵的评审技术也不是为了验证被评审工作产品是无错的&＃xff0c;而是帮助我们尽早的发现问题、找到错误&＃xff0c;避免问题延误到后期解决而付出惨痛的代价。



2、方法

统一了思想以后&＃xff0c;接下来的重点就是“方法得当”&＃xff01;为什么呢&＃xff1f;因为相对而言&＃xff0c;中国文化中还是比较缺乏“评审文化”的。中国人通常不愿意接受“当面指出问题”这种沟通方式&＃xff0c;更不要说“众目睽睽”之下被人指出问题。

而且&＃xff0c;在软件开发团队中评审的价值并没有得到很多的认同&＃xff0c;大家就更难从心里接受和赞同同行评审活动。要想慢慢的创建企业的评审文化&＃xff0c;就必须建立对这种评审活动的认同&＃xff0c;而要建立对评审活动的认同&＃xff0c;就必须看到评审的效果&＃xff1b;而要看到评审的效果&＃xff0c;最快的是通过正式化程度较低的评审手段。



3、语言

如果说前面讲的是中国人通常不是好的、积极的“被评审者”&＃xff0c;那么这里想要说的是&＃xff0c;中国人还经常不是好的、有效地“评审者”。

“你这个地方有问题......”

“你这个地方错了......”

“你这里怎么能这么写&＃xff0c;应该写成......”

设想一下&＃xff0c;当这样的语言朝你飞来的时候&＃xff0c;你会做出何种反应呢&＃xff1f;这种不良的语言习惯是破坏评审会气氛的一大杀手&＃xff0c;因为你一不小心就变成了高高在上的“评价者”。

实际上&＃xff0c;在评审会中大家应以“建议者、协作者”的身份、角色出现在会议中&＃xff0c;这首先需要大家改变评审时的语言习惯&＃xff0c;最重要的是将“你......”改成“我......”&＃xff0c;如&＃xff1a;

“你这个地方有问题......” --> “我没有看懂&＃xff0c;你能解释一下吗&＃xff1f;”

“你这个地方错了......” --> “按我的理解&＃xff0c;这个地方和实际情况有些不一致&＃xff0c;建议确认一下”

“你这里怎么能这么写&＃xff0c;应该写成......” --> “如果我写的话&＃xff0c;我会写为......”



4、人员

要开好评审会&＃xff0c;选择合适的参与人员是很重要的&＃xff1a;要点在于合适&＃xff0c;而非越多越好。具体来说&＃xff0c;包括以下几个方面&＃xff1a;

同级&＃xff1a;同行评审的原文是“Peer Review”&＃xff0c;Peer的意识就是同级&＃xff0c;千万不要一开评审会就请高级领导&＃xff0c;很多人连“当着别人的面被指出问题”都受不了&＃xff0c;何况是当着领导的面啊。

该来的人要请&＃xff1a;对于评审内容所涉及的第一责任人&＃xff0c;一定要请他们参加

不该来的人不要请&＃xff1a;评审应保持尽量小的范围&＃xff0c;要直接的相关人员参与&＃xff0c;一方面可以保证参与者对评审内容很熟悉&＃xff0c;另一方面可以保证参与者关心同行评审。



5、内容

有一次&＃xff0c;笔者参加一个需求分析的同行评审会&＃xff0c;却发现同行评审的内容有300多页&＃xff0c;评审时间为2个小时。试问&＃xff0c;如此多的内容可以在2个小时内得到充分评审吗&＃xff1f;

每次评审应选择合适范围的内容&＃xff0c;不应求大求全&＃xff0c;对于规模较大的评审内容&＃xff0c;应对评审内容进行拆分&＃xff0c;分为几次评审&＃xff0c;这样才可以保证评审的效果。

那应如何对大规模的评审内容进行拆分呢&＃xff1f;其实在软件设计中有“高内聚低耦合”的设计原则&＃xff0c;在评审内容的拆分上&＃xff0c;可以充分借鉴“高内聚低耦合”的原则&＃xff0c;使每次评审的内容内部关联性最高。