在一个所有东西都可以洞察、都有上下文和数据的世界里，如果将指标度量限制在软件开发过程的一部分里，那是没有意义的。部门的工作不会在提交到 Git 时停止，也不是在工单分配到你时才开始。从第一次关注一个工作项，到它进入生产代码，融于现有的解决方案，有许多地方可以做得很好，但也有更多的地方可能会出错。度量这些领域，就像度量管道中的其他领域一样，这对于改进至关重要。我们将花一点时间回顾相关的术语和概念，然后再深入研究 Jobber 的开发过程，看看我们如何：
为开发分支集成即时 QA 构建，简化 QA 过程；
简化 PR 流程，加快相关工作的审批和测试；
集成用于处理故障和中断的新服务；
发现工程师没有足够的时间埋头工作的原因（是会议！），以及为什么与开发人员交谈和采用工程指标一样重要。
对于这些度量，业界普遍接受的标准是由谷歌 DORA 团队制定的，包括部署频率（DF）、变更提前期（LTC）、平均恢复时间（MTTR）和变更失败率（CFR）四个关键指标。这 4 个指标分别度量将代码部署到生产环境的频率（DF）、开发完成和部署之间的时间间隔（LT）、从严重的生产问题中恢复所需的时间（MTTR）以及新增热修复代码在生产环境中引发问题的频率（CFR）。概括地说，这些关键指标是对客户影响、做事速度以及所提供服务的一致性或质量所做的一般分类。如果你关心的是影响、速度和质量这样的东西，那么你就需要某种形式的指标，让你可以跟踪进度。
在Jobber（一家家居服务运营管理软件提供商），我们跟踪这些指标，更多的是作为产品开发部门，为的是以可度量的方式跟踪进展。这些指标可以帮助我们的团队在进行变更时保持敏捷，并在执行过程中以数据为驱动。如果一个团队想要尝试一种新的 Bug 分类方法，或者一种新的 PR 流程，那么我们不仅可以实时跟踪，并与他们之前的表现进行比较，还可以以部门为单位绘制这个指标，从而防止来自更大部门的噪音破坏我们的数据。然后，这些个人或团队战术层面的指标会向上汇总到小组、部门，最终到整个组织。这样，我们就能够根据需要准确下钻到任何层次，从个人一直到 Jobber 这个整体，并且可以与其他组织进行比较。
我们不仅会追踪这 4 个关键指标，还会对收集到的数据做些说明，这很重要。在个人、团队或部门层面，都有一些噪音是非常符合人性的，那种上下文信息非常宝贵。当我们尽可能多地收集不同方面的数据时，我们也会考虑这些指标的人性方面、项目难度、任务转换或个人情况对个人、团队甚至部门的一个或多个关键指标的影响。
也就是说，指标（DORA 的 4 个关键指标及其他指标）帮助 Jobber 对开发过程做了一些更改。其中包括投资于按需构建的 CI/CD 管道（不仅适用于生产环境，也适用于开发环境），那使得我们在工程师提出修复方案几分钟内就可以向内部涉众和测试人员发布测试构建，极大地影响了我们的 LTC。我们还简化了 PR 审查流程，减少了发布补丁、新成果和主版本所需的步骤，大大减少了 DF。在审查了一些故障指标之后，我们集成了用于处理中断和技术事件的新服务，真正改善了我们的 MTTR。下面，让我们更深入地了解下这些案例。
当我们开始更仔细地研究我们的指标时，我们意识到，开发过程有许多可以改进的地方。具体地说，在研究变更提前期和部署频率时，我们发现自己落后于竞争对手的关键步骤是快速有效地向内部团队交付代码的能力。我们发现，与同等规模的公司相比，我们从第一次变更评审准备好到实际评审之间的时间间隔要长许多。通过进一步地研究，我们发现，加快将构建交付给产品所有者、涉众和其他 QA 负责人的速度，可以让这些循环更紧凑，提高部署速度。我们为所有新 PR 推出了按需的 Bitrise 移动构建，这意味着现在只需要 30 分钟就可以向所有感兴趣的人交付包含更改或修订内容的版本。这不仅加快了我们的特性开发速度，而且还加快了代码评审过程，对 MTTR 和 CFR 指标产生了重要的影响。
在查看平均恢复时间和变更失败率指标时，我们发现，我们并没有像自己希望的那样高效。我们对故障的响应还算积极，但仍有改进的空间，特别是在事件的沟通和组织方面。我们将 Allma 整合为 Slack 频道中的一个问题协作层，围绕事件组织集中沟通。以前，人们很难“跳进去”帮助解决问题，因为它通常分散在多个不同的地方。Allma 工作流让我们可以集中讨论切实的问题，让多方介入、监督或对问题的解决做出贡献，进而帮助我们理清其中的误解和困惑。这就和前面的情况一样，监视指标让我们不仅可以发现具体技术或框架的更改，还可以发现流程和工具的更改。
我们来看一个具体的问题，它的出现方式非常有趣。在查看我们的工程度量工具 Jellyfish 时，我们注意到一个基本问题：我们的 IC（个人贡献者）编码不够多！我们在评价工程师时会使用 PR 数和“编码日”，这是一个粗略的估计，即工程师一天中花在代码上的时间与花在其他事情上的时间比。我们看到，在过去的一年里，我们的 IC 花在代码上的时间越来越少，而花在其他事情上的时间越来越多。一个简单而又显而易见的解决方案是“多编码”，但就像任何指标或数据问题一样，有时候，一个信号在告诉你一些东西的同时，也经常会导致很多噪音。消除噪音的最佳方法是将指标放大，了解 IC 的切身经历，有时需要进行一些艰难的对话。
开展这类对话的基础是信任，否则你将无法从中获得任何有用的上下文信息。在 Jobber，虽然在决策时，我们会查看尽可能多的数据，但我们认识到，这最多只能占一半，另一半是被度量者的生活经历。我们从不以数据来评判 Jobberino；数据要放在团队和小组的上下文中来考虑，而不是用数据给他们本人或他们的工作下定义。也就是说，我们将指标视为真实问题的线索，而不是用它衡量某人对于公司的价值。所以当我们着手分析 PR 减少的原因时，我们首先要做的就是找到问题的源头，直接与工程师进行探讨，看看是什么妨碍了他们开展构建特性和解决漏洞这些对他们而言很重要的工作。
我相信，对于这一点，很多阅读这篇文章的人都了解。当我们深入研究数据和相关上下文时，不出所料，问题的源头是会议。具体来说，会议安排时间不合适经常会打断所有重要的技术流程。你或许也知道，许多需要工程师处理的问题都至少需要 4 个小时的时间才能解决。因此，会议会打断所有重要的流程，妨碍问题的解决。这些问题通常也是最难解决的，所以你还要付出机会成本，因为最重要的问题也是最难解决的。在这种情况下，一个相对正常的指标（IC 花费在编码上的时间）背后隐藏了大量有用的更改和信息。现在，除了粗略地度量他们的生产时间之外，我们正积极监控工程师可用的大块时间。如果我们没有首先度量我们的工程工作，就永远不会发现这些信息，如果我们没有相互信任的环境，让我们处理信号而不是噪音，我们肯定也不会有那些关键的上下文对话。
除了这 4 个关键指标之外，我们还有各种有趣的指标。我们不仅会度量已解决缺陷的数量，还会度量每周关闭的缺陷的数量，或者一个 PR 在关闭之前所花费的时间（以及已审核 PR 被的数量和对这些 PR 的评论！）我们甚至会度量团队和部门更新内部文档和维基资源的次数，以及每周重新投入到其他开发或文档中的次数。总之：如果你不跟踪它，你就无法度量它；如果你不度量它，你就无法改善它。特别是对于工程经理以及更高的级别，当他们对策略、流程和工具做小调整、修改和大调整时，他们会希望了解所有具体的更改是成功还是失败。我们不必担心自己的功能被打上 OKR 标签，我们应该把同样的热情和活力投入到追踪我们对业务发展的贡献上。一定要先确保脚踏实地，然后再去数据中寻找神奇的趋势线。
原文链接：
https://www.infoq.com/articles/team-level-metrics-matter/
相关阅读：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论