评审机制
评审机制
注：本文里评审的英文名称是Review。他在不同的场合或语境下可以翻译为：复习、回顾、评审、检讨、检阅、走读。 均表示同一个意思。
1 目的
评审被用来评估作品的内容。
2 描述
对商业分析工作产品进行不同类型评审。 每种评审都是为满足组织和商业分析师的需求而设计，并使用以下维度：
- 目标：明确评审的目的。
- 技术：识别一种正式或非正式的方式来执行审查。
- 涉众：确定谁应该参与审查活动。
每个评审都专注于一个工作成果，而不是涉众的技能或行为。 工作成果可以是一组交付成果、单个交付成果、交付成果的一部分，也可以是正在进行的工作。 对于已完成的工作成果，审查的目的通常是消除缺陷或让审阅者了解内容。 为了处理进行中的工作，评审可能会被用来解决一个问题或疑问。
每个评审都包含商业分析师作为涉众。 评审员可能是同行，尤其是在处理中的工作时，或者验证工作产品完整且正确的涉众。 评审步骤取决于所使用的技术。
评论可以包括：
- 工作成果概览和评审目标，
- 供评审人员使用的检查表和参考资料，
- 审查工作成果并记录发现，以及
- 验证任何重做。
商业分析师根据评审者的反馈更新工作产品。
3 元素
.1 目标
在评审之前，清楚地向所有涉众传达目标。 目标可能包括一个或多个目标，例如：
- 修复缺陷，
- 确保符合规格或标准，
- 确保工作成果完整无误，
- 为一个方法或解决方案达成共识，
- 回答问题，解决问题或探索替代方案，
- 向审阅者介绍工作成果，以及
- 评估工作成果的质量。
.2 技术
评审可以是正式或非正式的。在评审过程中使用的技术是为了支持评审目标而选择的。
商业分析师在进行审查时通常会使用以下技术：
- 检查：一种正式技术，包括对工作成果的整体概述、个人审查、记录缺陷、团队合并缺陷以及跟进以确保进行了更改。重点是消除缺陷并创建高质量的工作成果。虽然通常由同行完成，但也可用于涉众评审。
- 正式走查（也称为团队评审）：这是一种正式技术，使用个人审查和团队综合活动，通常在审查中看到。 步行为同行评审和涉众评审提供帮助。
- 单一问题评审（也称为技术评审）：这是一种正式的技术，专注于一个问题或一个标准，在此之前审查者会仔细检查工作成果，然后在一次会议中解决这个问题。
- 非正式走查：这是一种非正式技术，商业分析师会预演草稿中的工作产品，并征求反馈。评审人员在联合评审会议之前可以做最少的准备。
- 桌面检查：由未参与工作成果创建的审查者提供口头或书面反馈的一种非正式技术。
- 互相传递：一种非正式的技术，其中多个评审人员提供口头或书面反馈。 工作成果可能被复制到一份工作成果副本中进行审查，或者从一个人传递给另一个人。
- 非正式的：商业分析师寻求同行的非正式审查或帮助的一种非正式技术。
.3 参与者
参与任何特定审查的涉众角色 [1]取决于审查的目标、选择的技术以及可能已经实施的组织标准。
在某些情况下，由于主管或经理的专业知识，他们可能成为审查员之一。在这种情况下，主持人会小心谨慎地避免影响其他涉众坦诚的程度或不恰当地影响团队决策。
表 10.37.1 评审角色
| 角色 | 描述 | 职责 | 适用技术 |
|---|---|---|---|
| 作者 | 工作产品的创作者 | 回答关于工作产品的问题，听取建议和评论，并在审查后将改动整合进工作产品中。 | 所有 |
| 审阅者 | 同行或利益相关者 | 根据审查目标检查工作产品。对于缺陷检测审查，审阅者会在审查会议之前审查工作产品，并记录发现的缺陷和改进建议。 | 所有 |
| 主持人 | 中立主持人（不应为作者，以避免影响审查公正性） | 协调审查会议，确保参与者专注于审查目标，并确保工作产品的每一个相关部分都得到讨论。在会议开始前核实审阅者已审查工作产品，并确保所有审阅者参与审查会议。 | 检验；正式走查；有助于单个问题审查 |
| 记录员 | 具备较强沟通能力的中立参与者 | 记录审查会议期间提出的全部缺陷、建议、评论、议题、关注点和未解决的问题。熟悉主题内容能使记录员清晰记录各项内容。 | 检验；正式和非正式走查 |
4 使用考虑
.1 优势
- 可以帮助在工作成果生命周期早期发现缺陷，从而消除后期发现的缺陷需要花费的昂贵代价。
- 评审中的所有相关方都会参与到最终结果中来；他们对高质量的结果有切身利益。
- 评审人员可以在方便的时间进行桌面检查和审阅，而不是在进行中的工作被打断去参加会议。
.2 限制
- 严格的团队评审需要时间和精力。因此，只有最重要的工作成果才会使用检查或正式演示技术进行评审。
- 一个或两个评审人员进行非正式评审在所需的努力方面是切实可行的，但是它们提供的消除所有重大缺陷的保证比使用更大的团队和更正式的过程要少。
- 对于桌面检查和轮流审查，作者可能很难验证每个涉众都进行了独立审查。
- 如果评审意见通过电子邮件共享和讨论，可能会有很多信息需要处理，这使得作者很难解决分歧或建议修改的不同之处。
本文同步发表在 软件需求探索的http://www.srs.pub/babok/pingshen.html
-
商业分析中的五十种分析方法和技巧之39-角色与权限矩阵.http://www.srs.pub/babok/juese-yu-quanxian-juzhen.html ↩
