衡量和改进 DevOps 团队的生产力一直是一个重大挑战。从纯粹的技术指标到更注重业务的指标，指标的选择往往令人担忧，特别是它可能最终导致完全过时的选择。在 DevOps 实践普及的时代，几乎每项实践都在制定标准，DevOps 指标也不例外。
通常，DevOps 团队的生产力被认为是衡量其高效编写和部署高质量软件的能力，这些软件运行良好且易于维护。从商业角度来看，公司希望更准确地衡量其开发人员的生产力，原因如下：
本质上，公司始终在寻找有约束力的指标，帮助他们识别员工行为，并最终激励员工提高绩效。同时，公司也希望指标能够证明其投资的合理性。
乍一看，衡量 DevOps 生产力似乎是一项简单的任务。除非，正如我们所见，你想把它做好。在这种情况下，它非常困难。为了说明这一点，让我们看看许多公司用来衡量开发人员生产力的传统指标。其中包括：
很多人误以为存在一个简单有效的方法，可以用一个非常好的指标来衡量 DevOps 团队的生产力。实际上，没有一个单一的指标可以用来评估生产力，因为它取决于太多因素，这些因素在不同的行业、组织和具体情况下可能会有所不同。实际上，可能会使用几个指标的加权组合，但即使这样，指标和具体权重也会因情况而异。
此外，声称生产力主要由个人决定是一个神话。当然，个人绩效本身具有巨大的价值，但最终对团队的贡献作为一项基于团队的活动至关重要。众所周知，项目成功不仅仅取决于个人的独立成功。它还取决于 DevOps 团队如何协同工作。事实上，整体大于部分之和。
我们必须区分具体指标和框架。指标仅仅是我们衡量的概念，如果没有上下文，它们就毫无意义。框架是对如何建立和使用一系列指标（你不需要将它们全部应用）的指南，以便在特定上下文中了解团队的表现，以及采取哪些措施才能达到你想要的结果。
最常见的错误之一是采用一个框架并应用所有指标。框架是想法、概念和关系的简单总结，因此你可以根据自己的上下文、环境和团队选择一组指标，并对这些指标进行解释，以确定团队是否处于应有的位置。
接下来，我们将考察三个最流行的框架，用于衡量 DevOps 团队的生产力。
DORA 是一组指标，旨在衡量软件工程团队在敏捷和 DevOps 开发环境中的绩效。简而言之，这种方法基于更有效的数据，并且可以客观地评估 DevOps 团队的绩效。
这些指标源于 DORA（DevOps 研究与评估）的工作，DORA 是一个由学术研究人员 Nicole Forsgren、Jez Humble 和 Gene Kim 于 2014 年创立的组织。2018 年，谷歌收购了该组织，并将它的研究和指标整合到其云平台中。
该机构的目标是在软件开发公司进行研究和评估，以确定最有效的实践和评估团队绩效的关键指标。
“DevOps 状态报告”是 DORA 研究成果，在全球范围内得到广泛使用，并已成为行业参考。自创建以来，该报告拥有 30,000 多名参与者，为改进软件开发和运营流程提供了宝贵的见解。
DORA 调查使用四个主要指标评估软件开发中工程团队的绩效，这些指标分为速度和稳定性。
虽然这些指标很有用，但不能将它们视为主要目标。重点应该始终是构建高质量的软件 - 对于用户来说高效且有用 - 当然，除了为企业创造价值之外。也就是说，让我们深入了解这些指标，它们将支持构建数字产品的整个过程。
速度指标
部署频率
这衡量了团队将代码部署到生产环境的频率。高部署频率可能表明该团队可以持续快速地为用户提供价值，响应市场需求并根据用户需求调整软件。DORA 研究将部署频率分为三类：
变更交付周期
这衡量了从进行代码更改到成功部署到生产环境的时间。更短的交付周期可能表明该团队可以快速有效地交付新功能或修复程序，快速响应市场变化和用户需求。
DORA 调查还将变更交付周期分为三类：
稳定性指标
变更失败率
此指标衡量了导致失败的部署比例，例如生产环境中的事件或回滚更改的需要。更低的失败率可能表明该团队可以在部署更改时管理风险并维护软件质量，这对于真正高效的小组至关重要。
DORA 调查将变更失败率分为三类：
平均恢复时间
此指标有助于评估团队处理事件和故障的能力。它衡量了故障后恢复服务所需的平均时间，表明该团队在识别、诊断和解决问题方面的效率。
DORA 研究将平均恢复时间分为三类：
简而言之，DORA 指标之所以独特，是因为它们不仅仅局限于交付速度，还涵盖了软件随时间的运行稳定性。这确保了软件的质量不会在初始交付后受到影响。此外，它允许在稳定性、可靠性和其他质量指标方面密切监控软件的性能。
至于有效性，这些指标是有意义的，但它们并没有涵盖生产力的所有方面。许多方面被遗漏了，例如开发人员满意度和相关的指标。原始研究的作者自己在一些采访中提到，这些指标是不完整的，可以进行扩展。这导致了 SPACE 的创建。
SPACE 框架是一组指标，旨在提供对软件工程团队绩效的全面了解。与可能只关注速度或产出的传统方法不同，SPACE 框架强调多个维度，以捕捉工程团队的整体生产力和福祉。它由该领域的研发人员和实践者开发，旨在解决现代软件开发环境的复杂性，尤其是在敏捷和 DevOps 实践中。
主要观点是，评估生产力不仅仅是衡量一个维度，并且存在一些相关的误解。以下，我将简要讨论其中的一些：
误解：生产力只与开发人员生产力有关
大量的开发工作量可能是由多种因素造成的，例如低效的系统或不充分的计划导致的过度工作时间。仅依靠活动指标无法进行奖励或惩罚，因为它们缺乏上下文。诸如提交次数或代码审查等简单指标也可能存在错误，并且没有考虑到结对编程等活动。此外，由于糟糕的计划或不良的文化造成的紧迫期限导致的加班，可能会损害生产力评估。
**错误观点：生产力只关乎个人表现**
过度关注个人生产力会损害团队整体，助长英雄文化。粗略地说，在这样的公司里，20% 的人完成了 80% 的工作，这是有害的，应该加以打击，而不是用个人指标来鼓励。
**错误观点：单一生产力指标可以说明一切**
认为单一、通用的指标可以评估整个组织或行业中的团队是一个错误。生产力包含几个重要的维度，并且受上下文的影响很大。例如，将初创公司与银行进行比较是具有误导性的。
**错误观点：生产力度量只对管理者有用**
许多开发人员认为生产力指标毫无用处，因为它们被领导者滥用。然而，这些指标也对开发人员自身有益，帮助他们组织和理解自己的优先事项。研究表明，高生产力与更高的工作满意度和幸福感相关联。
**错误观点：生产力只与系统和工具有关**
工具无法捕捉到诸如指导和知识共享等无形活动，而这些活动对生产力至关重要。这些无形活动与更常见的衡量标准一样重要。
该框架提出了五个度量维度，避免了常见的错误和误区。
**S：满意度和福祉**
此维度评估团队成员的整体幸福感和心理健康。它包括工作满意度、工作与生活平衡以及团队中感知到的压力水平等因素。一个满意的、健康的团队更有可能高效地投入工作，并最终带来更好的成果。
**P：绩效**
绩效指标侧重于工程团队的成果，例如他们生产的软件质量、交付速度以及他们的工作对业务的总体影响。此维度通常通过传统指标进行衡量，例如代码质量、部署频率和变更的交付时间。然而，SPACE 框架鼓励超越这些指标，包括衡量软件满足用户需求和业务目标的程度。
**A：活动**
此维度跟踪工程团队每天的工作，例如编码、代码审查和修复错误。它包括诸如提交次数、拉取请求次数和完成的代码审查次数等指标。虽然这些指标很有价值，但 SPACE 框架强调活动不应与生产力混淆。高活动量并不一定意味着团队高效或他们的工作质量很高。
**C：沟通与协作**
有效的沟通与协作对于工程团队的成功至关重要，尤其是在敏捷和 DevOps 环境中。此维度评估团队成员之间的协作程度、知识共享和工作协调能力。这方面的指标可能包括完成的协作任务数量、团队内部的沟通频率以及跨部门的协作程度。
**E：效率和流程**
效率指标衡量工作在开发管道中推进的流畅程度和有效程度。此维度包括诸如循环时间等指标，用于跟踪工作从一个阶段转移到下一个阶段所需的时间，以及流程效率，用于衡量花费在增值活动上的时间比例与等待或返工时间上的时间比例。目标是识别瓶颈和可以简化流程以提高整体效率的领域。
SPACE 框架提供了一种更全面的工程生产力衡量方法，强调平衡团队绩效的多个方面的重要性。通过将满意度、沟通和效率等因素与传统的绩效指标一起考虑，组织可以更深入地了解团队的表现以及可以改进的地方。这种整体方法确保团队不仅高效，而且健康、积极，能够交付满足用户需求和业务目标的高质量软件。
基于 SPACE 和 DORA 的局限性，同一批作者在 2024 年 1 月发表的一项研究中引入了 DevEx（开发者体验）。其目的是建立一种方法，专注于开发人员对其工作的满意度。从技术上讲，DevEx 并不新鲜；它一直存在，但没有得到应有的重视。
DevEx 捕捉开发人员的感受、想法以及他们对工作的价值观。在他们最初的论文中，作者确定了 25 个影响（正面或负面）开发者体验的因素，一些例子包括干扰、不切实际的截止日期、工具摩擦、任务清晰度和代码组织等。我们倾向于认为影响开发体验的是工具，但实际上远不止这些。人为因素，例如有明确的目标以及在团队中感受到心理安全感，会极大地影响绩效。
改善开发者体验不仅会影响生产力，而且明显有利于满意度、参与度和留任率。对开发者体验产生负面影响的方面会产生不同程度的影响，从公司层级到团队和个人。DevEx 对于每个开发人员来说都是不同的。有必要了解上下文，例如资历、团队和职能、过去的生活经历等等。DevEx 方法深入到特定的人和公司（流程）的层级。
**反馈循环**
经证实，通过分析价值流图和减少价值交付中的浪费来优化价值流的组织效率更高。尽早犯错，以便尽早纠正方向。这种快速循环让开发人员能够以最小的摩擦完成工作。缓慢的循环会导致沮丧、暂停、连续的任务切换、放弃任务以及必须在一段时间后返回任务。
为了改善 DevEx，必须通过以下几种方法缩短这些循环:
**认知负荷**
越来越多的工具和技术增加了开发人员面临的认知负荷。这种负荷涵盖开发人员执行一项任务所需的脑力处理量，例如非常复杂的任务或涉及学习新框架或范式的任务。这种负荷还受到信息传递方式的影响，从语言到信息的呈现方式，再到需要解释信息以将其与自己的知识联系起来。
认知负荷阻碍了当今开发人员最重要的角色：交付价值。当由于诸如文档不足的代码或系统等问题导致这种认知负荷很高时，开发人员必须花费额外的时间和精力来完成任务并避免错误。关键在于减轻这种负担，为此需要做到：
重要的是，要投入精力为开发人员提供他们每天执行工作所需的全部文档、简洁性和工具和流程的清晰度。一个专门的 DevEx 团队必须提供这些工具。
**心流状态**
心流状态关乎专注，指一个人在执行一项活动时进入的一种精神状态，沉浸在专注、投入和快乐或享受的感觉中。作为一个开发人员，经常体验这种感觉有利于提高生产力、创新和个人成长。与第一个维度反馈循环相关的负面因素会惩罚这种心流状态。其他方面可能包括自主权、明确的团队和项目目标以及刺激性且具有挑战性的任务。第三个维度是为这种心流状态创造合适的条件，例如限制干扰、避免任务和焦点变化以及在团队中创造一个鼓励接受挑战的安全空间。
度量会推动行为朝着某个方向发展，无论你是否喜欢，这些行为最终会渗透到团队或公司的文化中。你衡量什么反映了你作为领导者的关注点。它们突出了对你来说重要的东西，因此使团队朝着那个方向看。
团队会对该指标做出反应，因为他们知道自己正在被衡量，因此会做出相应的行为来满足该指标。如果你衡量代码行数，团队会产生更多代码，但这并不意味着质量更高。最终，这些行为会渗透到团队的文化中，进而渗透到公司的文化中。
以下是一些在选择 DevOps 指标时需要考虑的最佳实践：
如果使用得当，DevOps 指标可以提升你的团队、你的产品和你的文化，但如果使用不当，也会毁掉它们。在选择 DevOps 指标时，请考虑你想要成为团队的哪种领导者。使用指标来了解在哪里采取行动以及如何在日常工作中更多地帮助/指导你的团队，但不要止步于此，用它们来帮助他们成长。
