|
评审过程 总结工作产品评审过程的活动 认出正式评审中的不同角色和责任 解释不同类型评审的区别：非正式评审(informal review)、技术评审(technical review)、走查(walkthrough)和审查(inspection)。 应用评审技术到工作产品以发现缺陷 解释影响评审成功的主要因素 评审过程基本含义 评审，也就是所谓的人工检查，是对所有不同文档或者代码检查技术的统称； 评审可以是非正式的评审，也可以是正式的评审。评审过程的形式和以下因素相关： 开发过程的成熟度 法律法规方面的需求 审计跟踪的需要 …… 评审的目标 查找和发现缺陷 增加对评审对象的理解 讨论和确定评审对象采用的技术和方法 ……  评审的优点 评审可以使移除缺陷的成本更低 ； 评审可以缩短开发时间。如果在早期识别和修正了缺陷，用来执行动态测试的成本和时间就可以减少； 由于存在缺陷的数量减少，产品整个生命周期的成本就会降低 ； 降低系统运行的故障率。通过评审在产品开发早期发现尽量多的缺陷，并进行修改，可以提高产品的质量，从而减少系统运行的故障； 评审可以提高后续发布的产品的质量。评审是通过一组人来进行的，因而评审过程中可以相互学习。通过改进每个人的工作方法，从而提高个人的技能水平； 评审可以提高文档编写的质量。通常一个明确的文档要求，可以使作者发现一些遗忘的问题，即文档要进行评审，可以迫使文档相关人更加关注文档相关的标准和要求； 整个团队对被检查目标的质量负责，因此，整个小组的成员可以对文档的内容理解达成共识；    评审过程的组成 计划阶段 预备会阶段 个人准备阶段 评审会议阶段 返工阶段 跟踪结果阶段 计划阶段的任务 什么文档需要进行评审？定义文档评审的目标； 评审对象是否准备完毕？ 选择文档评审的方式：结对评审还是团队评审； 评审人员和评审主持人是谁？任命文档评审的主持人； 什么时候进行评审工作？ 需要花费的工作量是多少？ …… 计划阶段出口准则 评审对象package已经准备好，包括评审对象、和评审对象相关的文档，比如所有的输入文档、评审的指南、规则和检查表等； 评审相关的参与人员已经指定，并且进行了相关评审方面的培训； 评审计划和时间、评审目标等已经定义；  预备会议阶段的活动 分发文档； 参与人员的角色和负责的职责，比如是负责技术领域还是流程方面； 解释评审的目标和过程； 建议的评审速度，和缺陷的记录形式； 检查入口准则（针对更正式的评审类型）；  个人准备阶段的活动 每个评审人员各自准备评审工作：目的是发现文档中可能存在的缺陷、也可以是疑问或者改进的建议； 每个评审人员各自记录发现的缺陷，其中的疑问等，并全部记录在评审日志文件中； 完成后，将评审日志文件发给评审主持人；  个人准备阶段的出口准则  评审会议阶段的活动  缺陷的严重程度 严重缺陷（评审对象不能满足它设计的目的，在批准评审对象之前必须修正相关缺陷）； 重要缺陷（影响评审对象的可用性，批准评审对象之前应该修改相关缺陷）； 一般缺陷（小的偏差，基本不影响使用）； 好的（没有缺陷，返工时无需修改）；  评审的结果 通过：无需进行修改； 有条件通过：需要修改，但不需要进一步评审； 未通过：需要进一步的评审或其它的检查措施； 评审的通用准则 评审会议的时间尽量限制在2个小时内。如果需要，可以在当天再发起另外一个评审会议； 如果一个或多个专家（评审人员）没有出席，或者他们准备不充分的话，主持人有权取消或中止会议； 评审过程中不讨论开发方案、设计方法以及其他常见的风格问题； 主持人一般情况下不作为评审人员； 提交讨论的是被评审的文档（检查对象），而不是作者： 评审人员必须要注意他们的言语以及表达的方式； 作者不应该为自己或文档辩护。（这意味着：作者不应该被攻击或者被迫处于一个防御的位置。但是作者对他们决定的辩护或解释，应该视为合理和有帮助的）； 跟踪结果阶段 跟踪结果阶段的活动 检查缺陷是否已解决； 检查出口准则； 将文档评审过程中的数据记录到评审数据库中； 记录、计算和分析得到的数据； 分析其中的经验和教训，并定义可能的改进计划，比如针对检查表、评审过程等的改进建议； 评审失败的原因  角色和职责 经理 主持人 评审员 记录员 观察员 作者 …… 评审的主要类型 技术评审：技术相关的工作产品的评审； 走查（Walkthrough） 审查（Inspection） 技术评审（Technical Review） 非正式评审（Informal Review） 管理评审：针对项目计划和开发过程相关的分析和评审； 目的是监控过程、判定计划和进度的状态，或评估为达到特定目的管理方法的有效性； 管理评审一般在项目得到里程碑、完成项目主要阶段，或者针对项目进行经验总结的时候开展； 走查的目的 走查的特点 审查的目的 审查是最正式的评审之一，遵循正式严谨的一个评审过程。通常每个评审人员都是从作者的直接同事中选出，并且具有固定的角色 ； 主要目的：发现文档的不清晰要点和可能的缺陷，以及度量文档质量、改进产品质量和开发过程 ； 审查的特点 由专门接受过培训的主持人（不是作者本人）来领导； 根据入口准则、出口准则和检查表定义正式的评审过程； 定义了不同的角色和职责，通常是同行检查； 审查会议之前需要进行准备； 审查之后出具审查报告和发现问题的列表； 对问题列表的更新有正式的跟踪过程； 技术评审的目的 评审关注的焦点是文档和规格说明的一致性、文档目的的适用性以及和标准的一致性； 技术评审有各种不同的版本：从非常不正式的到有严格定义、有正式过程定义的技术评审； 主要目的：讨论、评估、发现缺陷、解决技术问题、检查和规格及标准符合程度； 技术评审的特点非正式评审的目的 非正式评审是评审的精简版。但是，它或多或少以一种简单的方式遵循评审的通用过程。比如结对编程、结对测试、代码交换 等； 非正式评审的主要目的：以较低的成本发现问题 ； 非正式评审的特点 没有正式的评审过程； 对设计文档和代码以技术评审为主； 评审的过程和结果可能是文档化的； 根据不同的评审人员，评审的有效性不同； 评审技术对比 如何选择不同的评审类型 评审结果的表现形式有助于选择评审类型。是否需要具体的文档，或者通过非正式的方式进行检查就足够了？ 寻找合适的时间来进行评审的难易程度？把5或7个技术专家召集起来参加一个会议或多个会议是否非常困难？ 是否需要有不同领域的技术知识？ 需要多少有资质的评审参与人员？评审人员有激励机制吗？ 评审的收益（预期结果）和投入评审相关的工作量是否相一致，或者说是否值得？ 评审对象是否需要正式的记录？是否可以通过工具支持来开展分析活动？ 管理层是否支持评审活动？在项目工作面临时间压力的时候，管理层是否会缩减评审工作量？ …… 评审的注意事项 评审的每一种类型，没有统一的描述，每种评审类型也没有明确的界限，且经常在不同场合使用不同的术语； 评审的类型更多的是由公司的组织结构来决定，根据项目的需要进行相应的裁减，以提高评审的效率； 参与评审的项目人员的协同合作有利于项目质量的提高； 评审的方式可以是多种多样：面对面方式、电话会议方式、视频会议方式等； 评审成功的因素 每次评审都有明确的目的，比如评审的主要目的是提高被评审文档的质量、发现其中的问题和模糊的描述观点、偏差； 对发现的缺陷持欢迎态度，并且发现的问题必须以中性和客观的方式进行记录； 能够正确处理不同人员之间的想法和心理方面的问题，个人的特性和心理都会对评审产生很强的影响；评审文档的作者应该将评审作为一种正面的经历； 使用检查表和指南来提高评审过程中发现问题的效率； 管理层可以为软件开发过程中的文档评审计划足够的资源（时间和人力），来支持一个有效的评审过程； 成功运用评审的一个重要方面是不断从评审过程本身来学习经验教训，比如评审过程的持续改进； 提供评审技术方面的培训，特别是针对正式的评审技术，比如审查技术的培训； 管理层对评审过程的支持（在项目计划中安排足够的时间来进行评审活动）； 强调学习和过程的改进； |
|
|
来自： blackhappy > 《我的图书馆》
