Review-评审流程培训.ppt

* 评审(Review)过程培训 项目管理部 * 为什么要进行评审 技术工作之所以需要接受同行评审就好比铅笔需要橡皮一样，请记住： 凡人皆有错！(如果你还是凡人的话) 我们离不开同行评审的第二个原因是： 尽管人们善于找出自己所犯的部分错误，但是相对于其他任何人而言，大量的各种错误还是很容易逃脱创作者的眼睛，这被称为思维定势。 第三个原因： 许多缺陷是在早期阶段引入的。 缺陷发现越晚，纠正费用越高。 由于缺陷数量的放大原因，每个进入下个步骤的缺陷都可能引起下个步骤中的多个缺陷，导致消除缺陷成本的剧增。 * 评审过程是质量保证的重要手段。 评审也是一种静态测试，通过对工作产品的检查，力图消除已经明显呈现的错误或未来可能发生的潜在问题。 一般将评审分为：正式评审、非正式评审。 评审的概念 * 评审案例分析 案例一 　　某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。  案例二  某软件公司在用户处开完物资管理系统的需求评审会后，与会人员在离开会议室时纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。 　　　　 案例三 　　某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的某企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副总提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。 　　 案例四 　　某软件公司内部举行产品的需求评审会，主要是公司内部的相关领域的专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。 　　 案例五 　　某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划的主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。  * 以上的现象可以在很多项目中都可以看到。概括起来，在评审中常见的问题是： 　　◇?报告很长，短时间内评审者根本就不能把需求报告读懂、想清楚； 　　◇?没有作好前期准备工作，评审的效率很低； 　　◇ 评审的节奏无法控制； 　　◇?找不到合格的评审员，与会的评审员无法提出深入的问题； 　　…… 　　那么究竟如何做好评审呢？ 我们先往后看，最后再回过头来看这几个案例，共同寻找问题和解决方法  评审案例分析 * 评审分类——正式评审和非正式评审 正式评审：比较正式和严格的评审过程，评审人员做预审、举行评审会议。 非正式评审：形式比较灵活，通常在同伴（同行）之间开展。 共同重点：评审准备 制定评审策略：选择要评审的工作产品，确定评审方式。 确定执行评审需要的资源，确定评审计划。 建立评审的规程和准则。 通知参与评审人员。 * 正式评审——参与角色 项目经理 工作产品拥有者 评审员 评审记录员 评审验证员 ü 可兼任 ? 不可兼任 ü ü ü 评审组织者 ? ? ? * 检查入口准则 是否符合文档标准 是否通过检查单检查 准备评审包 （工作产品/参考资料/ 检查单/评审记录表） 指定评审小组成员 拥有者自检工作产品 组织者规划本次评审 组织者将评审包及检查单、《评审通知单》发送给评审员 工作产品名称 参与角色 评审小组成员和角色 Review召开时间、地点 Review关注范围和重点 通知单内容： 必要时可组织介绍会议 正式评审——评审准备 《评审通知单》 * 介绍会议 组织者裁决是否召开介绍会议。 若召开，则： 工作产品拥有者 必要时可组织预审会议 组织者 正式评审——介绍会议 * 阅读工作产品与相关材料 识别缺陷并记录在《评审记录表》 记录预审花费时间 提交《评审记录表》给组织者 评审员做好预审 发现的缺陷 存在的问题 个人时间花费 预审需记录的要点： 评审准备期，评审员要尽量与拥有者沟通疑惑点，以便了解双方在工作产品上的认识。 评审对象是工作产品,而不是作者。 准备工作要充分：组织者根据准备情况，裁决是否增加准备工作投入 正式评审——预审 《评审记录表》 评审会议 组织者召开评审会议 拥有者讲解工作产品 讨论确定问题 记录员记录所有问题及分类，并向全体与会者 宣读缺陷记录 会议给出评审结论，指定验证员 组织者更新评审记录表 * 《评说记录表》中记录的问题 会上发现的问题 当争执不下时，组织者应作出裁决 大家共同确认的问题 严重 中等 一般 缺陷的一般分类 缺陷的一般状态 刚