同行评审对于软件企业来说是很有效的一种方式，无论是国外还是国内企业越来越认识到了同行评审的重要性，但是在实施的过程中效果不是很理想，常常会出现走形式，使评审会议变成了讨论会议，对具体的问题争论不休，经常跑题，使评审的效果大大的降低。我在实施的过程中根据同行评审的要求，总结出来以下经验供大家参考，同行评审的目的是及早高效的发现并消除开发过程中出现的缺陷。很多公司也制定了相应的评审流程，项目开始的时候也做了评审计划，但是在具体的实践中把握不好一些细节的东西，这些主要的问题大多数发生在评审会议的组织上，而这些细小的环节才是评审是否成果的关键。只有评审会议比较完满了，其他修改bug、消除缺陷都比较容易完成。我在这里主要讲一下评审会议的组织，至于评审计划、评审执行过程的数据采集、测量等环节不再详述。
评审会议流程一般采取以下几个步骤：评审会议的准备、评审会议的召开、评审会议的跟踪三大环节。
一、评审会议的准备
会议的发起人召集会议，发出评审通知（评审内容、会议时间、会议地点、参加人员等），并且将相关待评审的相关资料也发送给参加会议的评委；主要的目的有两个：第一、让参加会议的人员对会议的内容有一定的了解，在会议前做好准备，避免盲目的参加会议而浪费自己和其他人的时间；第二、如果该评委在会议时间有其他紧急的事情，可以及早反馈给会议召集人，必便召集人重新确定评委或者评审会议改期召开。
二、评审会议的召开
一般情况下，确定一个会议主持人；其主要的职责是控制会议的进度、时间、协调会议中出现的偏差。
对于待评审的工作产品由其生产者采用“走读”的形式进行讲解，在讲解的过程中回答评委提出的问题。
会议记录人主要是记录会议中发现的所有问题，方便会后的修改完善。
sqa人员参加会议主要的关注点在于对照sqa的检查表checklist检查评审的流程是否符合规范。
三、评审会议的跟踪
将记录的问题汇总到《评审记录表》，由项目组进行修改、完善；sqa监督所有问题是否封闭。
附录：
（1）列举重要工作产品评审的重点：
a计划的评审
主要是关注的核心在于估计是否准确；人员安排是否合理；以上两个方面如果合理，项目的进度就不会出很大的问题。
b需求的评审
主要关注需求来源、需求的准确性、需求的完整性，避免产生二义性；最好让测试人员和客户参加，以便让各角色达成共识。
c总体设计的评审
在总体设计评审中，最好将已经评审通过的需求文档从配置管理库中提出，对照总体设计是否和需求一致；另外，技术领域专家参加评审还要关注于设计的合理性、可实现性以及完整性。
d代码评审
由项目组内进行代码审核，主要关注代码的格式、整体逻辑、变量的命名、程序注释等表面的属性；至于运行质量应当放在单元测试中解决。
e管理性的评审
管理性的评审一般放在里程碑、项目结束后进行。准备的资料包括前期工作的总结，是否按照计划执行、出现的问题的数目、解决了多少、未解决的问题、是否对后期有影响等。
（2）评审中应当把握的几个原则：
a评审工作产品，而不是评审生产者
评审涉及到别人和自我。如果进行的恰当，可以使所有参与者体会到温暖的成就感。如果不恰当，则可能陷入审问的气氛之中。应当温和的指出错误，会议的气氛应当是轻松和建设性的；不要试图贬低或者羞愧别人。主持人应当加以引导，以保证会议始终处于恰当的气氛和态度中，如果失去控制应立即休会。
b制定日程，并且遵守日程
各中会议都有一个主要的缺点：放任自流。评审会议必须保证不要离题和按照计划进行。主持人要有维持会议的程序的责任，有人在转移话题的时候应当提醒。
c限制争论和辩驳
评委提出问题时，未必所有人都能认同该问题的严重性或者能马上打成一直的意见。不要花费时间争论这一问题，应当记录在案，留会后讨论。
d对各个问题发表见解，但是不要试图解决所有记录的问题
评审会议不是解决问题的会议。问题的解决由生产者自己或者其他人的帮助下完成。问题的解决方案应当在会后进行。
e作书面笔记
有时候让记录员在黑板上作笔记是个好主意，在记录的时候，评委可以推敲措词，确定问题的优先次序。
f限制参与人数，并且坚持事先做准备
俩个人的脑袋好过一个，但是14个脑袋未必就好过4个。将评审涉及的人员数量保证保持在最小的值上。所有参与会议的人员要事先作好准备。
g为每个可能要评审的工作产品建立一个检查表
检查表能帮助评审主持人组织会议，并帮助每个与会人员将注意力集中在重要问题上。
h为评审分配资源和时间
评审要占项目组的资源和时间。所以，评审会议一定要作为软件工作活动的任务加以调度。可以在综合计划中考虑进去。
i对所有的评审者进行有意义的培训
为了提高效率，所有参与评审会议的人都应当接受正式的培训。
j会议时间的控制
为了提高效率，每次评审会议只评审一个工作产品，并且时间最长不能超过2个小时。所以要求，在评审准备时候各位评委事先作好准备。
同行评审对于软件企业来说是很有效的一种方式，无论是国外还是国内企业越来越认识到了同行评审的重要性，但是在实施的过程中效果不是很理想，常常会出现走形式，使评审会议变成了讨论会议，对具体的问题争论不休，经常跑题，使评审的效果大大的降低。我在实施的过程中根据同行评审的要求，总结出来以下经验供大家参考，同行评审的目的是及早高效的发现并消除开发过程中出现的缺陷。很多公司也制定了相应的评审流程，项目开始的时候也做了评审计划，但是在具体的实践中把握不好一些细节的东西，这些主要的问题大多数发生在评审会议的组织上，而这些细小的环节才是评审是否成果的关键。只有评审会议比较完满了，其他修改bug、消除缺陷都比较容易完成。我在这里主要讲一下评审会议的组织，至于评审计划、评审执行过程的数据采集、测量等环节不再详述。
评审会议流程一般采取以下几个步骤：评审会议的准备、评审会议的召开、评审会议的跟踪三大环节。
一、评审会议的准备
会议的发起人召集会议，发出评审通知（评审内容、会议时间、会议地点、参加人员等），并且将相关待评审的相关资料也发送给参加会议的评委；主要的目的有两个：第一、让参加会议的人员对会议的内容有一定的了解，在会议前做好准备，避免盲目的参加会议而浪费自己和其他人的时间；第二、如果该评委在会议时间有其他紧急的事情，可以及早反馈给会议召集人，必便召集人重新确定评委或者评审会议改期召开。
二、评审会议的召开
一般情况下，确定一个会议主持人；其主要的职责是控制会议的进度、时间、协调会议中出现的偏差。
对于待评审的工作产品由其生产者采用“走读”的形式进行讲解，在讲解的过程中回答评委提出的问题。
会议记录人主要是记录会议中发现的所有问题，方便会后的修改完善。
sqa人员参加会议主要的关注点在于对照sqa的检查表checklist检查评审的流程是否符合规范。
三、评审会议的跟踪
将记录的问题汇总到《评审记录表》，由项目组进行修改、完善；sqa监督所有问题是否封闭。
附录：
（1）列举重要工作产品评审的重点：
a计划的评审
主要是关注的核心在于估计是否准确；人员安排是否合理；以上两个方面如果合理，项目的进度就不会出很大的问题。
b需求的评审
主要关注需求来源、需求的准确性、需求的完整性，避免产生二义性；最好让测试人员和客户参加，以便让各角色达成共识。
c总体设计的评审
在总体设计评审中，最好将已经评审通过的需求文档从配置管理库中提出，对照总体设计是否和需求一致；另外，技术领域专家参加评审还要关注于设计的合理性、可实现性以及完整性。
d代码评审
由项目组内进行代码审核，主要关注代码的格式、整体逻辑、变量的命名、程序注释等表面的属性；至于运行质量应当放在单元测试中解决。
e管理性的评审
管理性的评审一般放在里程碑、项目结束后进行。准备的资料包括前期工作的总结，是否按照计划执行、出现的问题的数目、解决了多少、未解决的问题、是否对后期有影响等。
（2）评审中应当把握的几个原则：
a评审工作产品，而不是评审生产者
评审涉及到别人和自我。如果进行的恰当，可以使所有参与者体会到温暖的成就感。如果不恰当，则可能陷入审问的气氛之中。应当温和的指出错误，会议的气氛应当是轻松和建设性的；不要试图贬低或者羞愧别人。主持人应当加以引导，以保证会议始终处于恰当的气氛和态度中，如果失去控制应立即休会。
b制定日程，并且遵守日程
各中会议都有一个主要的缺点：放任自流。评审会议必须保证不要离题和按照计划进行。主持人要有维持会议的程序的责任，有人在转移话题的时候应当提醒。
c限制争论和辩驳
评委提出问题时，未必所有人都能认同该问题的严重性或者能马上打成一直的意见。不要花费时间争论这一问题，应当记录在案，留会后讨论。
d对各个问题发表见解，但是不要试图解决所有记录的问题
评审会议不是解决问题的会议。问题的解决由生产者自己或者其他人的帮助下完成。问题的解决方案应当在会后进行。
e作书面笔记
有时候让记录员在黑板上作笔记是个好主意，在记录的时候，评委可以推敲措词，确定问题的优先次序。
f限制参与人数，并且坚持事先做准备
俩个人的脑袋好过一个，但是14个脑袋未必就好过4个。将评审涉及的人员数量保证保持在最小的值上。所有参与会议的人员要事先作好准备。
g为每个可能要评审的工作产品建立一个检查表
检查表能帮助评审主持人组织会议，并帮助每个与会人员将注意力集中在重要问题上。
h为评审分配资源和时间
评审要占项目组的资源和时间。所以，评审会议一定要作为软件工作活动的任务加以调度。可以在综合计划中考虑进去。
i对所有的评审者进行有意义的培训
为了提高效率，所有参与评审会议的人都应当接受正式的培训。
j会议时间的控制
为了提高效率，每次评审会议只评审一个工作产品，并且时间最长不能超过2个小时。所以要求，在评审准备时候各位评委事先作好准备。