同行评审基础和重点

1.组织中最有才干的人没有参与项目也能够发挥作用(专家的评审可以跨项目)
2.另项目成员有一种认同感和参与感
3.一种自我学习，自我培训的自适应团队的形成
4.通过留意故障帮助预防故障

 

1.进度驱动而不是质量驱动
2.评审人员是否是专家
3.评审的有效性无法很好的度量
4.没有遵循2/8原则注意评审的重点
5.评审时间被挤压，特别是工件的预审时间

 

1.评审过程是一个团队学习过程
2.三人行必有我师
3.当局者迷,旁观者清

 

由生产者的同行按照预定的规程对软件工作产品进行的评审，目的在于发现缺陷和需要改进之处。(CMM 1.1)

同行的概念在这里理解为参加评审的人员是不存在上下级关系的。

同行评审的作用在于尽可能早的消除软件工作产品中的缺陷

评审是有成本的，因此适当采用非正式评审方式可以有效的加快评审效率和速度。尽可能早的发现问题。非正式评审不要建立正式的评审计划，评审意见记录方式也很灵活，一般适合3-4人内的小组面对面Review.

 

比较正式的小组评审过程(一种正式的评价技术，由不同于作者的一组人员详细检查软件需求、设计或代码，以发现错误、与开发标准的偏离和其它问题。)

 

评审前计划：参加人，要评审的工件，背景材料，检查单。主持是否仲裁?
概述和准备：预审前背景或目标介绍，预审
小组评审会议：主持人，讲解员，记录员必不可少。小组会议不仅仅是过预审意见，最好还需要对整个工件进行评审。评审要注意重点，如只重点评某几个业务功能。对于评审会议全部用来处理预审意见的评审结论为不通过。

主持人作用：控制会议议程，围绕主体，就事论事.

作者不能担任仲裁人或讲解员；仲裁人不能担当阅读员。不推荐作者担任阅读员。

 

检查本身是为了发现设计或代码中的错误。它不是为了寻找选择对象或者争辨问题的是非。当然也不应批评设计或代码的主持者。检查对项目主持者来说应是有积极意义的，它应明显表明全体参与者都可提高程序质量，并且对所有参与者来说他都能从中获得不少体验。另外，检查组不能向项目主持者说有一些人是笨蛋应让其卷起铺盖滚蛋。像“任何知道Pascal语言的人都知道从 Num 循环到 0 是更为有效”的此类评论是根本不合适。如果真是这样，协调者应将这种情况明白无误地表达出来。

1.缺陷数严重超过预定目标的情况，评审要不通过，需要修改后重新评审
2.严格意义上需要评审修改完，验证通过基线后，后续设计开发才能够开始
3.验证人员是否认真的对评审需要修改的记录进行验证了。(往往是根本不验证就关闭)

Code Review是评审的另一种选择。在代码阅读时，你能读源代码并寻找错误。你也同时对代码的质量如其设计、风格、可读性、可维护性和有效性提出你的见解。《代码大全》

1.也是正式评审，而不是非正式评审,只是成本较低
2.还是态度问题，如何保证评审是有效的？
3.作者走读代码和他人走读代码是两种重要的Review形式，关注点不同

1.评审的工作产品
2.评审的重点(需求，设计，测试和编码重点都不尽相同)
3.评审的入口准则和出口准则
4.评审的参与人员(评审人员和其它参加人员)

 

有效的评审会议的检查标准和检查单
1.你的检查表是否着重将检查员的注意力引向过去常发生错误的地方？
2.是否侧重于缺陷检查而不是纠错？
3.在检查会议之前检查员是否有足够的准备时间？每一位检查员都作好了准备吗？
4.每一位参与者是否都扮演不同的角色？
5.会议是否开得富有成果？
6.会议是否限制在2小时之内？
7.协调者在指导检查方面接受过特殊的训练吗？
8.在每次检查中，错误类型数据是否都作了收集，以便于你今后制作检查表？
9.是否收集了准备和检查率，以便可以优化将来的准备和检查？
10.每次检查所指定的条款是否都落实了？是由协调员本人还是重新作了检查？
11.管理员是否明白为什么他不参加检查会议？

 

如果一个500行的代码或20页的的文档只发现了两个故障，说明评审是无效的，评审无效的原因是没有遵循评审主题和采取严肃的态度进行评审。除非严肃的对待评审，否则它们很可能对时间造成巨大的浪费，并且不会得到任何应用的回报，否则会被人认为随随便便的执行评审就可以了。

 

如何度量评审是否有效：通过控制图实现的统计过程控制(SPC)进行监督和控制。

评审能力基准:预审速度，评审速度，一般性缺陷，严重缺陷。

 

 

评审缺陷数<预计缺陷数

1.评审的工件业务逻辑较简单
2.评审人员没有充分的按检查单预审 (规范，态度)
3.评审人员没有经过评审的培训 (技能)
4.工作产品的质量非常好 (技能)
5.评审和预审时间是否完全应用，是否充足 (计划)

 

评审缺陷数>预计缺陷数

1.工作产品的质量较低 (技能，规范，职责，态度)
2.工作产品本身业务逻辑非常复杂 (技能)
3.次要故障多而主要故障少 (规范,态度)
4.被评审模块是项目第一个模块 (培训)

评审在很多方面是反自觉的。程序员不明白如何才能够使一组人执行的评审过程更加有效。当一个项目的关键资源是人力的时，则很难让人接受人力高度集中的评审过程能够使整个过程更加有效，并能改进质量之类的观点。因此使人们相信并使用评审是最难的过程部署任务。(一个是观念转变，观念后是态度，但首先是要有数据的支持)

评审的目的是：由一组对等的评审人员通过一个正式的且结构化的评审过程，识别出一个工作产品中存在的故障和问题。评审是有成本效益的，甚至可以用于不能执行的工作产品。评审是改进质量和提高生产率以及监督项目状态的重要技能。

 

 

1.评审应该包括外部专家,以增加项目团队的才干
2.采用一个良好定义和结构化的评审过程 (指导书，规程，培训)
3.评审只关注故障和问题，而不讨论解决 (要考虑解决思路，具体实现不考虑)
4.有效利用各种评审形式
5.监督每次评审的有效性
6.需要对评审绩效进行监控，并采取纠正和预防措施
7.首先通过实验改变观念 (但很多时候是态度问题，已经不是简单的观念问题)