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