同行评审阻碍或促进敏捷开发

本文要点

• 团队的同行评审流程对于敏捷的成功至关重要；
• 结构化同行评审流程的核心有三个属性；
• 评审透明度对于在组织层面采用敏捷非常重要；
• 如何建立清晰、实际的沟通预期；
• 如何选择评审指标实现有意义的流程改进。

你可以看下这个吗？

你得看下这个……

喂，你。现在。

当代码或文档需要评审时，经常会出现这样的情况。因为一些原因，你的工作需要评审。首先，同行可能提供有价值的反馈，他们可以带来新的视角，发现你在数小时的工作后可能没有觉察的错误。其次，在快节奏的敏捷团队中，你需要不断地凝聚共识，这样就不会积压待沟通事项。最后，对于高度监管行业的团队，同行评审可能是更大的软件保证计划的一个必要部分。

随着越来越多的软件开发团队趋向于敏捷方法，软件发布变得越来越频繁。如果你不能同步加速同行评审周期，那么你可能会为了在规定的时间内完成工作而开始牺牲质量。然后，那会转换成技术债务的累积。如何避免这种情况呢？需要结构化，不过是灵活的结构。

结构化迭代沟通

大多数团队都没有一个明确的内部沟通计划。他们采用的工具通常没有定义沟通规范。如果你的团队采用了 Slack 或其他的通讯应用，那么很快，短暂的即时聊天就会变得很普遍。期望是另外一个人会在一个相对比较短的时间内回复。如果你给同一个人发送一封电子邮件，那么他可能更长的时间才会回复。因为对于工具的固有期望，这是可以接受的。

就像团队会慎重他们应该使用什么库管理工具或性能测试工具一样，他们也应该考虑使用什么工具进行同行评审最合适，以及那些工具对他们的行为会产生什么影响。

例如，如果我的团队的代码评审流程只是 GitHub 上的一系列 Pull Request，那么我们能够推动集中式流程的改进吗？如果我的团队是通过发送电子邮件附件来进行文档评审，那么我们能指望长期的开发可追溯性吗？这些问题可能是你想问的，但重要的是，在问之前，头脑中要有一个可以作为最终目标的实实在在的愿景。

结构化同行评审流程的三个属性

每个评审流程都有类似的基本过程。有编码人员编写了新代码或现有代码的变更。然后，评审人员参与进来，评论并找出缺陷。接下来，编码人员修复 Bug，评审人员验证修复后的 Bug。有几种常见的流程变体（提交前、提交后等）和常见的方法（临时、基于会议、基于工具），但是，有关那些主题的详细信息是另外一篇博文的内容。

不管你有什么独特的喜好，一个理想的结构化敏捷开发评审流程都有三个关键的属性。

1. 它应该明确预期和规则。

当有人要求针对他们的代码进行反馈时，他们到底是在要求什么？是要求人们说明你的偏好以及你可以如何采用不同的做法？如果我们不只是要求获得“反馈”，那么我们就可以更快获得更好的反馈。一个结构化的同行评审流程要求评审者查看并评估 x、y、z 的质量。你的团队或相关的编码人员可以决定那些检查项是什么。

检查项可以包括来自运行单元测试和侵入测试的任何东西，以便可以检查是否符合编码标准，是否添加了恰当的注释。开始的时候，会有一个团队在大多数情况下都已经在做的基本检查项清单，但是可能偶尔会有疏漏。随着不同的评审类型出现，你可以相应地增加和调整。

通过创建清单和清楚说明同行评审流程，每个人都可以知道谁评审以及评审人员做了什么。它还减少了评审范围蔓延。如果评审者什么都评论，那么他们可能会针对某个东西提出一个公认的复杂问题，那会让你泄气。

由于同行评审流程最终应该发挥质量度量的作用，所以你的流程应该有规则，而且那些规则应该是可执行的。制定一份指导原则，说明谁参与哪种类型的评审。如果你推出了一项新特性，并希望它可以正常工作，就需要一定数量经验丰富的开发人员参与到评审中。如果你希望把代码评审作为培训策略，那么就需要新成员参与一定数量的评审，作为他们入职的一项内容。如果没有定义好的规则，就没有什么能阻止团队成员胡乱提问题或不提问题。

2. 它应该能够促成多对多的透明化评审。

敏捷运动受到欢迎，这部分是因为筒仓开发会导致不必要的沟通压力。就像那些现在更大程度上跨职能的团队，部门应该开放他们的流程，那样，整个组织的软件开发就可以有一个清晰的跟踪审计。在制造业，这个概念被称为数字主线。

为了在团队层面和组织层面实现流程改进，你需要不断汇总分析关键绩效指标（KPI）。只有团队使用的工具有跨团队、跨部门数据交互时，你才能收集到这种数据。这种交互可以实现明显更好的缺陷跟踪。

收集数据只是完成了一半挑战。为了进行有意义的分析，选择对于你的团队而言最有意义的自定义 KPI，并长期对它们进行追踪。用于评审流程的工具应该支持此类分析和自定义报表。

除了有意识的改进流程外，透明化还能促进协作。如果软件架构师在应对一项设计挑战时做了会影响测试的修改，那么团队的测试人员应该能够访问最初的同行评审，看看修改意图。意图分析，尤其是通过文本媒介，会给整个软件开发带来多重风险。那是个高风险的电话游戏。当团队和职能部门共享信息时，他们更容易直接获得答案，无障碍协作。

3. 它应该使用自动化系统和模板代替通常的人工设置。

SmartBear 的 2017 代码评审现状报告显示，57% 的开发团队会进行基于会议的同行代码评审。将近 75% 的团队会进行“过肩”即时评审。虽然这些方法可能会有效，但它们要么需要手工文档，要么完全不记录。结构化同行评审流程的目标应该是尽可能减少这种手工帐。

采用基于工具的方法进行同行评审可以自动化许多设置和文档。像 SmartBear 提供的工具 Collaborator 就使团队可以创建评审模板，自动通知，生成自定义报表。这些特性可以大幅减少同行评审流程的阻力。

虽然本文的重点是结构化流程，但是，我们要重点说一下，敏捷宣言中有一条重要的原则似乎和这个观点相悖，“个体和交互胜过过程和工具”。通过模板化同行评审流程，你可以把大量的流程工作放在开发过程的后台进行。开发人员很清楚检查清单，不需要为每次评审都从头创建一个。管理人员可以自定义和优化评审过程，不需要不断督促团队成员改变他们的行为。自定义并自动化同行评审流程使个人可以有更多的时间交流和构建。

进展跟踪

过多的数据或信息可能会成为负担。正如前面提到的那样，如果你的团队能够识别出几个有意义、容易跟踪的指标，那么你就可以成功地改进流程。小团队可能会希望设置一个自定义的满意度指标，如赞同 / 不赞同或分为 1 到 5 级。如果管理着看到了一种趋势，他们就可以定性地研究问题。

对于使用结对编程方法的团队，像缺陷密度这样的代码评审指标可以作为开发悟性的客观代表。既然大多数团队都知道谁是最顶级的编码人员，那么使用一个指标作为真相来源可以减少偏好或认识疏忽导致的问题。通过跟踪每位编码人员代码中的缺陷密度，你可以把高效的开发人员和缺陷率较高的同行结对，从而提升团队整体技能。另外，考虑下如何把它用在回顾过程中。你可以轻松识别出一次冲刺中进步最大的编码人员或最优秀的编码人员。

对于比较大的开发团队，像评审过的代码行数（LOC）和评审耗时这样的指标可以提供评审流程的更高级视图。例如，如果评审过的 LOC 数量非常高，而缺陷密度非常低，则说明你们的编码人员都是全明星，或者你们的评审人员评审得太粗太快。获得所有这些指标后，你就可以检查个人或团队花在评审上的时间，并做出改进。

引入行业基准，更好地了解这些指标的实际意义。例如，根据 SmartBear 和思科开展的一项调查，在一个小时内评审的理想 LOC 数量大约是 500。这种行业基准可能并不完全适合你的团队，因此，随着时间推移，开发自己的内部基准。把团队当前的效率和行业基准以及本团队的历史评审数相比较，团队负责人可以更好地评估例外情况。

你的同行评审流程反映出团队的什么状况

我前面提到过，像电子邮件、即时通讯应用这样，不同工具的特点不一样，它们对用户行为和预期的影响也不一样。这也适用于团队的同行评审流程。如果你的流程具有严密的结构，那么，在某种程度上，你的团队就会采用你强调的行为。

那不是说每个开发人员都会立马成为代码评审的圣徒或者所有的评审总是会有恰当的记录。而是说，你的团队有机会建立沟通预期，提出明确的质量值，促成跨团队协作，推动开发。在完工定义框架中引入代码和文档评审的敏捷团队能够确保每个人都了解每一个作为更大用户故事和项目组成部分的工件。

使用同行评审交流这些信息的特别之处在于，评审是一个活生生的过程。从一次冲刺到下一次冲刺，每位编码人员和评审人员都面对着这些检查清单和规则。作为敏捷团队，你自然会反复调整，直到它们符合团队的独特需求和偏好。然后，你创建自己的生存宣言，反复重申优先事项和价值，直到它们嵌入到团队文化和代码中。

关于作者

Patrick Londa 是 SmartBear 软件公司 Collaborator 数字营销经理。他有在 Clean 科技公司及数字健康领域培育敏捷创业公司的背景，现在专注于软件质量、流程追溯和同行评审系统，面向的是高度监管、影响大的公司。

查看英文原文： Peer Reviews Either Sandbag or Propel Agile Development