评审培训讲义.ppt

收集了08年至今9个结项项目的评审度量数据得到的。 * 75% * * * 评审速率 3.56 页/人时 * 评审效率 0.59 个/人时 * 评审缺陷密度 0.41 个/页 * 同行评审评审员选择六维度法则： 　　1，上游; (我基于其产出的作者) 　　2，下游; (将使用本工作产品继续后道工序) 　　3，同行; (指和自己共同从事这块的人) 　　4，交互关系的同行; (如概要设计：有接口关系的其他子系统概要设计人员) 　　5，验证人员; (如系统需求和用户需求将被系统测试人员和用户方验收测试人员验证，则可以邀请他们参加) 　　6，其他专家; (业务专家，技术专家，标准化专家，QA专家等) * 管理评审 技术评审 * 项目工期情况——关键路径是否按计划完成了?如果没有按计划完成：提前或拖期的原因是什么?在后续阶段如何采取改进措施?对后续阶段的工期有什么影响? 工作量——计划投入工作量、实际投入工作量、挣值、计划与实际工作量的偏差分析、后续的投入工作量预测 质量——在本阶段通过测试与同行评审发现的缺陷个数、缺陷密度、【缺陷的趋势分析】、缺陷的分类、缺陷的关闭情况等等。通过上述的质量分析，判断本阶段的工作产品的质量情况，以决定是否要采取相应的质量措施加强质量管理。 需求变更——需求变更了几次?需求变更带来的工期与工作量变化是多少?需求变更的工作量/项目的估计总工作量。 配置项的变化情况——建立了哪些基线?基线中包含了哪些配置项?基线变更过几次?基线审计出的问题是否关闭了? 风险评估——识别了并已发生的风险有哪些?识别了但未发生的风险有哪些?为识别出来但是发生的风险有哪些?新识别出来的风险有哪些? 后续阶段的计划——后续的开发过程是否需要调整?后续的工作产品是否调整?后续的开发计划是否合理? * 我公司的度量数据 文档类型 度量项 均值 单位 计划 评审速率 1.70 页/人时 评审效率 0.91 个/人时 评审缺陷密度 0.31 个/页 需求 评审速率 2.16 页/人时 评审效率 0.59 个/人时 评审缺陷密度 0.41 个/页 设计 评审速率 3.56 页/人时 评审效率 0.44 个/人时 评审缺陷密度 0.32 个/页 测试 评审速率 1.75 页/人时 评审效率 0.61 个/人时 评审缺陷密度 0.42 个/页 评审问题数量分布 场景一：某次需求审查，预审阶段发现的缺陷为10个，会议上发现的缺陷为20个。 分析：对于审查这种评审方式，发现问题应该主要是在会前发现，而不是在记录会议上，上述的数据表明预审时各位专家的投入不够，本次评审的质量不高，需要考虑是否重新评审或者采取其他补救措施。 评审周期 场景二：某次需求评审持续进行了1天的时间。 分析：会议周期太长，无法保证各位专家能够高效地的投入到评审工作中，建议拆分为多次评审。 预审工作量 场景三：审查250页的需求文档，有5位专家参与，其中2位专家花费了1小时进行了预审，其他3位专家没有进行预审。 分析： 2位专家投入的个人评审时间偏少，3位专家没有准备，建议推迟评审的时间以便于各位专家事先进行准备。 评审速率 场景四：某次设计审查30页文档，平均个人评审花费的时间为1小时。而业内度量数据，平均的速率应该为不超过5页/小时。 分析：本次设计审查个人评审投入的时间不够。 评审效率 场景五：某次需求审查的效率为2.6个/人时，组织级建立的基线为 0个/人时---1.6个/人时 分析：本次审查的效率超出了组织级基线，过程判定为异常，需要进行特殊原因分析，判断是审查不够仔细？还是文档太简单？或者是专家水平高等？ 缺陷密度 场景六：某次需求审查，发现的缺陷密度为3个/页，组织级的审查退出准则为1.5个/页。 分析：应进行原因分析，判断是需求文档本身的质量太差？还是本次审查的水平高？准备充分？或是审查的技术手段有改进？ 第五章 评审的陷阱 陷阱1：评审结果被用于作者的业绩评估 后果 尽量少地找出错误成为评审心照不宣的目标，评审的投资回报降低 老在争论是否算一个缺陷 评审员可能不会直接指出错误 为了避免惩罚，不将自己的工作产品交付评审，同时也会拒绝评审同事的工作以避免使人受到惩罚 ?对策 评审时对事不对人，评审的是产品，而不是评审作者 依据产品最终的结果来考核开发者 陷阱2：评审员选择不恰当 症状 人员过多，导致过多的争议 评审员所代表的角色不全 一些评审员的资质不够，抱着学习的目的 ?对策 列出各类文档或产品的评审角色 评审会议不宜超过7人 陷阱3：评审过程没有被遵循 症状 随意简化 走过场 放弃 原因 没有把质量作为产品或项目成功的驱动力 ?提示 在一个已经陷入进度超期、需求混乱、人员疲惫之困境的项目中引入评审是