再顶尖的软件工程师也照样出错。犯错不可怕，重要的是及早发现并解决这些错误，而不是等到错误的定位变得艰难，修正时需要付出庞大代价才出手。这就是CMMI和5000A中同行评审的目的（Intent）！
虽然同行评审在国内CMMI或5000A三级组织的质量控制体系中都貌似常委位置，但我看到的评审基本上扮演政协的角色。
不少留言希望我能聊聊同行评审的一些问题及有效对策，这里我做了一些梳理，但限于篇幅限制（手机快速阅读类文章超过2000字的基本属于不知趣），只能舍弃一些细节。这么说吧，四句话概括同行评审的问题：缺乏评审文化，计划性差，评审方法不正确，领导不重视、不要求。
下面的建议呢，希望能帮助开拓思路，就算没有药到病除，也不要放弃治疗。继续实践，逐步完善！
三个常见的同行评审文化问题
问题一：许多技术人员不习惯把自己的东西拿出来评审，也有些人从心里不愿评审别人的工作。
应对办法：有效的培训当然是必须的，软件开发是团队行为，让大家认识同行评审的三大好处：发现缺陷，改进过程，知识共享。建议从一些非正式评审开始（如互查，结对子等），逐步让大家接受这个实践，使之成为工程人员常态化的工作。
问题二：有些评审变成了人的评审，整个过程作者俨然是对方主辩手。兄弟，大学生辩论赛你一定拿过奖吧？
应对办法：管理层必须创造一个安全宽松的评审环境，对产品不对人，承诺发现的缺陷数据不会用来考核。团队应该遵循这样一个准则：己所不欲勿施于人。在选择评审组成员时，适当考虑规避潜在的冲突。
问题三：评审组长（moderator）不能有效的控制评审过程。
应对办法：评审组长是评审过程中最重要的一个角色，这个角色需要情商智商双高啊。不妨考虑建立一个资源池，对评审组长做专门培训，同时不断筛选，逐步形成一个称职的评审组长团队。
四个常见的同行评审计划问题
问题一：计划里看不到评审活动，许多人认为评审会拖项目进度的后腿。
应对办法：确保进度计划包含评审活动信息——内容、人员和时间。根据需用开发生命周期，明确相关产出物的评审点。通过关注返工工作量比例，让大家认识到评审必要性。
问题二：一旦项目组面临进度或其它压力，评审基本是第一时间领盒饭的。
应对办法：培训！让大家全面理解质量成本的概念，以数据服人，牺牲质量追进度基本死的都很惨。
问题三：评审成员职责不清，除了作者都是友情赞助，即无动力，也无压力。
应对办法：可以参考下Ron Radice 的同行评审的书，里面给出了相关评审角色及对应的职责。建立适当的激励机制，奖励发现有效问题多的员工。
问题四：不恰当的评审内容，要么都评，要么都不评。没有把有限的资源到关键点。
应对办法：解决评审计划的关键是掌握评审速率。根据实际约束条件，评审组长需要和作者一起确定需要评审的内容、评审方式、人员和时间。
Ron‘s Peer Review Book
九个常见的评审方法方面问题
问题一：使用不恰当的评审方法和分析技术。
应对办法：不同的评审对象需要不同的评审方法和分析技术，针对需求、设计、代码、测试用例、手册等进行针对性的培训。
问题二：评审讨论会要不纠结于一些历史旧账，要不就变成了一个群英献计献策大会，没人关注缺陷，严重跑偏。
应对办法：及早评审，拖后评审容易纠结之前一些技术决策。在培训中明确评审的定位，在作者的解决方案上找出错误。
问题三：评审仅能发现某些类型的问题。
应对办法：走正式评审流程，同时做一些缺陷泄露分析，分析结果给和评审员分享，用在后续评审中，
问题四：大部分评审发现的问题都是不重要的小问题，极少发现严重问题。
应对办法：首先确定这些严重问题是如何被发现的，反思如何针对性的改进现有评审的检查项及分析方法，同时看看评审速率是否需要调整。
问题五：虽然做了无数次评审，仍然搞不拎清合适的评审速率，走马观花也是必然。
应对办法：养成习惯，做好数据收集模板，每次评审结束记录员花几分钟填下数据。逐步确定ROI较好的速率点。
问题六：只会一种评审方式，技术评审和管理评审没有区别。
应对办法：学习！业界各种评审方法学习并本地化。通过培训及指南让团队选择合适的方法。
问题七：评审检查单缺乏针对性，像个漏洞百出的网，貌似想捕住所有鱼结果啥也抓不到。
应对办法：泄露分析！针对性！
问题八：不控制评审规模，每个阶段安排一次评审，一次可以评一天，造成低效无反馈！
应对办法：用精益思想把规模打小，300页需求可以增量编制，增量评审。如果我们做十次，每次学到的都可以用在后面的分析和评审中。
问题九：收集了一些评审数据（CMMI和5000A有要求），但不知道如何使用这些数据。
应对办法：速率驱动分析评审数据，做好评审规划，找出ROI的合适点。
四个常见同行评审中管理者的问题
问题一：许多管理者对同行评审的态度是：不支持也不反对。不支持是因为觉得评审不值得做，不反对是因为这是CMMI或5000A的要求。
应对办法：还是那句话，拿数据服众！用试点数据验证效果，真正让领导全面理解评审的定位价值。
问题二：管理者不对同行评审提出任何要求。
应对办法：让最高管理者发布评审方针，指定一位高管负责整个组织的评审工作。
问题三：管理者参加一些不应该参加的技术评审，结果就是一鸟入林百鸟无声。
应对办法：在方针中明确不同评审的参与者，严格执行，当然说明原因。
问题四：管理者用评审收集的缺陷数据考核技术人员。
应对办法：讲清楚这种做法的危害，同样在方针中明确禁止误用评审数据。
CMMI 2.0把同行评审上升为实践域，但并不意味着它在中国软件组织就能发挥真正作用。还是重要的事情说三遍，继续实践，逐步完善！继续实践！继续！
