space是哪个键盘(space)

DevEx：来自 SPACE 作者的一种全新的度量框架

作者 | Abi Noda

译者 | 杨振涛

策划 | 丁晓昀

关键要点研究人员 Abi Noda、Nicole Forsgren 博士、Margaret-Anne Storey 博士和 Michaela Greiler 博士发表了一篇论文，为提高生产力提供了一种切实可行的途径，其重点聚焦在开发者体验 (DevEx)。开发者体验聚焦于开发者的真实体验及其在日常工作中遇到的摩擦点。作者断言，关注开发者体验是最大化工程效率的关键，并介绍了一个用于衡量和改进的 DevEx 框架。组织可以通过识别开发人员遇到的最大摩擦点来改善开发者体验，然后在可提高开发人员能力或满意度的可改进领域进行大力投入。DevEx 框架将影响开发者体验的因素提炼为三个维度：反馈回路、认知负荷和心流状态。领导者可以在这三个维度中选择指标，以衡量和确定需要关注的领域，最终推动生产力的提高。调查为获得一套全面的衡量标准提供了一个实践性的起点，以便充分了解开发者体验。有效的调查计划需要注重调查设计，以及按角色和团队分解结果并将结果与​内部和外部基准进行比较的能力。

近期发布的一篇研究论文揭示了度量和提升开发者生产力的一种全新框架。

该框架称作 DevEx框架 ，作者为 Abi Noda、Margaret-Anne Storey 博士、Nicole Forsgren 博士、和 Michaela Greiler 博士。

领导者长期以来一直在寻求提升其工程团队的生产力，以便帮助业务更快发展、开发新产品及利用新兴趋势。

然而，尽管近来也涌现出了 DORA 和 SPACE 这类方法，但要重点关注什么才能实现这一目标，想知道这一点仍然难以捉摸；而新的框架旨在解决这一差距。

作者凭借广泛的研究和经验，断言关注开发者体验是最大限度提高工程效率的关键。

他们的论文提出了框架，将开发者体验提炼为三个核心维度，并提供了衡量它的方法。

本文包含论文要点摘要以及主要作者 Abi Noda 的评论。这里还有全文的链接。

度量生产力有难度

谷歌研究员 Ciera Jaspan 和 Collin Green 在最近的一篇文章中提出了衡量开发人员生产力很有挑战性的两大原因：软件工程的不可重复性，以及开发人员的生产力受到外部力量的严重影响。

对于后者，外部力量可能是工作的复杂性（以及是否一定有那么复杂）、完成工作时与他人的互动或组织设计。还有一些具体影响开发人员的因素，包括不稳定的测试、构建速度和技术债务。

衡量生产力困难的另一个原因是，软件开发是一项创造性的工作：它并不是在生产统一通用的产出物。"试图通过借用操作机器的方法来量化生产力，并不适合软件工程"。

我们必须记住，我们正在与一个本质上是人类的系统合作。为了了解如何改进该系统，我们需要从人类那里了解他们当前的体验如何。

开发者体验提供了新视角

开发者体验提供了一种了解开发人员生产力的新方式：从开发人员本身的角度。开发者体验包括开发人员如何“感受、思考和重视他们的工作”，并关注开发人员在执行工作时面临的日常现实和摩擦。

先前的研究已经确定了许多影响开发者体验的因素：例如，中断、不切实际的截止日期以及开发工具的摩擦，都会对开发人员对其工作的感受产生负面影响。明确的任务、组织良好的代码和轻松的发布可以改善开发者体验。

组织可以通过确定开发人员遇到的最大摩擦点来改善开发者体验，然后投资于可提高开发人员能力或满意度的可改进领域。例如，组织可以专注于减少开发工具中的摩擦，以便让开发人员更无缝地完成任务。即使是减少了浪费的一小部分时间，如果在整个工程组织中是倍增的，那么对生产力的影响也会比雇用更多工程师更大。

越来越多的企业开始关注开发者体验

Gartner 最近的一项研究显示，78% 的受访组织已经制定或计划了正式的开发者体验倡议，而 Forrester 的一项类似研究表明，75% 的企业领导者认为开发者体验对于执行业务战略至关重要。这些发现表明，人们越来越认识到投资开发者体验计划可以带来的实质性好处。

麦肯锡和 Stripe的相关研究进一步验证了优化开发人员工作环境的业务影响，因此越来越多的组织围绕开发者体验制定了 C 级倡议举措。

开发者体验的三大维度

在论文中，作者将之前确定的影响开发者体验的因素提炼为三个核心维度：反馈回路、认知负荷和心流状态。

此框架是根据我们之前的研究和经验得出的，并了解了组织在提高开发人员生产力和体验方面的差距。我们的目标是创建一个实用的框架，易于人们理解和应用，并获得开发者体验最重要的方面。

总结一下每个维度。

反馈回路是指相对于所执行的操作的响应速度和质量。快速的反馈回路是高效开发流程的关键组成部分，因为它们使开发人员能够以最小的摩擦快速完成工作。另一方面，缓慢的反馈回路可能会导致开发周期中断，导致开发人员感到沮丧并发生延迟。因此，组织必须努力缩短反馈回路，找出可以加速的开发工具和可以优化的人工交接流程的领域（例如构建和测试流程或开发环境设置）。

认知负荷包括开发人员执行任务所需的心智处理量。高认知负荷可能是由于代码或系统文档记录不完善等挑战造成的，迫使开发人员投入额外的时间和精力来完成工作并避免错误。为了改善开发者体验，团队和组织应致力于通过消除开发过程中任何不必要的障碍来减轻认知负荷。

心流状态是指在从事某项活动时全神贯注、精力充沛的精神状态，其特点是高度专注和享受。这通常被称为“如入无人之境”。在工作中经常体验心流状态可以带来更高生产力、创新和员工发展。同样，研究表明，从工作中获得满足感的开发人员往往会生产出更高质量的产品。因此，团队和组织应致力于创造促进心流状态的最佳条件，以促进员工的福祉和绩效。

总的来说，这三个维度概括了开发人员遇到的所有摩擦类型。尽管开发者体验复杂且微妙，但团队和组织可以通过关注这三个关键领域来采取措施进行改进。领导者可以通过选择三个维度内的指标来发现提高生产力的机会。

DevEx 框架提供了一种以系统化和以开发者为中心的方式来提高开发人员生产力的方法。我们鼓励读者抓住三个维度中每个维度的指标，以阐明存在摩擦的领域，并有效地优先考虑对组织的预期结果影响最大的领域。

度量什么

对于希望改善开发者体验的组织来说，首要任务是度量前文描述的三个维度中存在哪些摩擦。作者建议在每个维度中选择要度量的主题，针对每个主题抓住感知和工作流程指标，同时抓住关键的 KPI ，以便与预期的更高层次的结果保持一致。

从三个维度度量主题。例如，组织可以选择度量测试效率（反馈回路）、代码库复杂性（认知负荷）、技术债务平衡（认知负荷）和深度工作时间（心流状态）。一些主题可能映射到多个维度。

我们主张领导者选择的指标可以全面覆盖三个维度，以全面了解开发者体验。例如，可以在反馈回路维度中评估的主题是测试效率，而代码库复杂性可以在认知负荷维度。

抓住每个主题的感知和工作流度量。除了有关工程系统和流程的客观数据之外，衡量开发者体验还需要抓住开发人员的看法（他们的态度、感受和意见）。这是因为单独的感知和工作流度量都无法讲述完整的故事。

例如，看似快速的构建过程如果经常打断开发人员的工作进度，可能会给开发人员带来干扰。相反，即使开发人员对他们的构建过程感到满意，使用构建时间等客观衡量标准也可能会发现反馈回路比应有的速度要慢，并且开发工作流程的简化程度也比应有的要低。因此，分析感知和工作流度量对于全面了解开发人员在日常工作中遇到的摩擦点是必要的。

度量 KPI，以聚焦推动重要的业务成果。 KPI 充当 DevEx 计划的北极星指标。精心设计的 KPI 应度量企业寻求推动的成果，包括生产力、满意度、参与度和保留率的提高。

如何度量

作者建议从调查开始来捕获上述指标。调查的优点是能够捕获开发者体验的各个方面，包括 KPI、感知度量和工作流度量。

谷歌、微软和 Spotify 等公司多年来一直依赖基于调查的开发者生产力指标。然而，设计和管理调查可能很困难，因此我们希望我们的框架为领导者提供一个不错的起点。

鉴于调查的重要性，作者概述了调查计划成功的几个重要考虑因素。

精心设计调查。设计不当的调查问题会导致结果不准确且不可靠。作者表示，至少，调查问题应基于明确定义的结构，并在访谈中经过严格测试，以获得一致的解释。按团队和角色细分结果。组织领导者常犯的一个错误是关注公司范围内的结果，而不是按团队和角色（例如角色、任期、资历）细分的数据。仅关注总体结果可能会导致忽视影响公司内少数但重要群体的问题。将结果与基准进行比较。比较分析有助于将数据置于情境中并帮助推动行动。例如，开发商对科技债务的情绪通常是负面的，这使得识别问题或衡量其规模变得困难。基准使领导者能够了解团队的情绪得分何时低于同行，以及组织的得分何时低于行业竞争对手。这些信号标志着显着的改进机会。混入事务调查。除了定期调查之外，组织还可以使用事务调查来收集基于特定接触点的反馈。例如，当 CLI 工具安装过程中发生特定错误时，平台团队可以使用事务调查来提示开发人员提供反馈。事务调查提供持续的反馈流，并且由于提出问题的及时性，可以产生更高质量的答复。注意调查疲劳。随着时间的推移，许多组织都在努力维持调查的高参与率。缺乏后续行动通常会导致开发人员觉得重复回应调查不值得。因此，领导者和团队跟进调查至关重要。

结论

DevEx 框架提供了一个用于了解开发者体验的实用框架，其配套的度量方法能系统地帮助指导改进。组织应该立即开始度量开发者体验，即使他们尚未建立或计划正式的 DevEx 投入。

作者简介

Abi Noda 是 DX的创始人兼首席执行官，负责领导公司的战略方向和研发工作。他的工作重点是开发衡量方法，以帮助组织提高开发者体验和生产力。在 DX 之前，Abi 在多家公司担任工程领导职务，并创立了 Pull Panda，该公司于 2019 年被 GitHub 收购。有关更多信息，请访问他的网站。

原文链接：

https://wwwq/articles/devex-metrics-framework/

相关阅读：

AI 时代背景下的平台工程之路 | 极客有约

通用电气在平台工程上浪费70亿美元的教训

一个价值70亿美元的教训！如何避免平台工程变成“大灾难”？

DevEx：来自 SPACE 作者的一种全新的度量框架

作者 | Abi Noda

译者 | 杨振涛

策划 | 丁晓昀

关键要点研究人员 Abi Noda、Nicole Forsgren 博士、Margaret-Anne Storey 博士和 Michaela Greiler 博士发表了一篇论文，为提高生产力提供了一种切实可行的途径，其重点聚焦在开发者体验 (DevEx)。开发者体验聚焦于开发者的真实体验及其在日常工作中遇到的摩擦点。作者断言，关注开发者体验是最大化工程效率的关键，并介绍了一个用于衡量和改进的 DevEx 框架。组织可以通过识别开发人员遇到的最大摩擦点来改善开发者体验，然后在可提高开发人员能力或满意度的可改进领域进行大力投入。DevEx 框架将影响开发者体验的因素提炼为三个维度：反馈回路、认知负荷和心流状态。领导者可以在这三个维度中选择指标，以衡量和确定需要关注的领域，最终推动生产力的提高。调查为获得一套全面的衡量标准提供了一个实践性的起点，以便充分了解开发者体验。有效的调查计划需要注重调查设计，以及按角色和团队分解结果并将结果与​内部和外部基准进行比较的能力。

近期发布的一篇研究论文揭示了度量和提升开发者生产力的一种全新框架。

该框架称作 DevEx框架 ，作者为 Abi Noda、Margaret-Anne Storey 博士、Nicole Forsgren 博士、和 Michaela Greiler 博士。

领导者长期以来一直在寻求提升其工程团队的生产力，以便帮助业务更快发展、开发新产品及利用新兴趋势。

然而，尽管近来也涌现出了 DORA 和 SPACE 这类方法，但要重点关注什么才能实现这一目标，想知道这一点仍然难以捉摸；而新的框架旨在解决这一差距。

作者凭借广泛的研究和经验，断言关注开发者体验是最大限度提高工程效率的关键。

他们的论文提出了框架，将开发者体验提炼为三个核心维度，并提供了衡量它的方法。

本文包含论文要点摘要以及主要作者 Abi Noda 的评论。这里还有全文的链接。

度量生产力有难度

谷歌研究员 Ciera Jaspan 和 Collin Green 在最近的一篇文章中提出了衡量开发人员生产力很有挑战性的两大原因：软件工程的不可重复性，以及开发人员的生产力受到外部力量的严重影响。

对于后者，外部力量可能是工作的复杂性（以及是否一定有那么复杂）、完成工作时与他人的互动或组织设计。还有一些具体影响开发人员的因素，包括不稳定的测试、构建速度和技术债务。

衡量生产力困难的另一个原因是，软件开发是一项创造性的工作：它并不是在生产统一通用的产出物。"试图通过借用操作机器的方法来量化生产力，并不适合软件工程"。

我们必须记住，我们正在与一个本质上是人类的系统合作。为了了解如何改进该系统，我们需要从人类那里了解他们当前的体验如何。

开发者体验提供了新视角

开发者体验提供了一种了解开发人员生产力的新方式：从开发人员本身的角度。开发者体验包括开发人员如何“感受、思考和重视他们的工作”，并关注开发人员在执行工作时面临的日常现实和摩擦。

先前的研究已经确定了许多影响开发者体验的因素：例如，中断、不切实际的截止日期以及开发工具的摩擦，都会对开发人员对其工作的感受产生负面影响。明确的任务、组织良好的代码和轻松的发布可以改善开发者体验。

组织可以通过确定开发人员遇到的最大摩擦点来改善开发者体验，然后投资于可提高开发人员能力或满意度的可改进领域。例如，组织可以专注于减少开发工具中的摩擦，以便让开发人员更无缝地完成任务。即使是减少了浪费的一小部分时间，如果在整个工程组织中是倍增的，那么对生产力的影响也会比雇用更多工程师更大。

越来越多的企业开始关注开发者体验

Gartner 最近的一项研究显示，78% 的受访组织已经制定或计划了正式的开发者体验倡议，而 Forrester 的一项类似研究表明，75% 的企业领导者认为开发者体验对于执行业务战略至关重要。这些发现表明，人们越来越认识到投资开发者体验计划可以带来的实质性好处。

麦肯锡和 Stripe的相关研究进一步验证了优化开发人员工作环境的业务影响，因此越来越多的组织围绕开发者体验制定了 C 级倡议举措。

开发者体验的三大维度

在论文中，作者将之前确定的影响开发者体验的因素提炼为三个核心维度：反馈回路、认知负荷和心流状态。

此框架是根据我们之前的研究和经验得出的，并了解了组织在提高开发人员生产力和体验方面的差距。我们的目标是创建一个实用的框架，易于人们理解和应用，并获得开发者体验最重要的方面。

总结一下每个维度。

反馈回路是指相对于所执行的操作的响应速度和质量。快速的反馈回路是高效开发流程的关键组成部分，因为它们使开发人员能够以最小的摩擦快速完成工作。另一方面，缓慢的反馈回路可能会导致开发周期中断，导致开发人员感到沮丧并发生延迟。因此，组织必须努力缩短反馈回路，找出可以加速的开发工具和可以优化的人工交接流程的领域（例如构建和测试流程或开发环境设置）。

认知负荷包括开发人员执行任务所需的心智处理量。高认知负荷可能是由于代码或系统文档记录不完善等挑战造成的，迫使开发人员投入额外的时间和精力来完成工作并避免错误。为了改善开发者体验，团队和组织应致力于通过消除开发过程中任何不必要的障碍来减轻认知负荷。

心流状态是指在从事某项活动时全神贯注、精力充沛的精神状态，其特点是高度专注和享受。这通常被称为“如入无人之境”。在工作中经常体验心流状态可以带来更高生产力、创新和员工发展。同样，研究表明，从工作中获得满足感的开发人员往往会生产出更高质量的产品。因此，团队和组织应致力于创造促进心流状态的最佳条件，以促进员工的福祉和绩效。

总的来说，这三个维度概括了开发人员遇到的所有摩擦类型。尽管开发者体验复杂且微妙，但团队和组织可以通过关注这三个关键领域来采取措施进行改进。领导者可以通过选择三个维度内的指标来发现提高生产力的机会。

DevEx 框架提供了一种以系统化和以开发者为中心的方式来提高开发人员生产力的方法。我们鼓励读者抓住三个维度中每个维度的指标，以阐明存在摩擦的领域，并有效地优先考虑对组织的预期结果影响最大的领域。

度量什么

对于希望改善开发者体验的组织来说，首要任务是度量前文描述的三个维度中存在哪些摩擦。作者建议在每个维度中选择要度量的主题，针对每个主题抓住感知和工作流程指标，同时抓住关键的 KPI ，以便与预期的更高层次的结果保持一致。

从三个维度度量主题。例如，组织可以选择度量测试效率（反馈回路）、代码库复杂性（认知负荷）、技术债务平衡（认知负荷）和深度工作时间（心流状态）。一些主题可能映射到多个维度。

我们主张领导者选择的指标可以全面覆盖三个维度，以全面了解开发者体验。例如，可以在反馈回路维度中评估的主题是测试效率，而代码库复杂性可以在认知负荷维度。

抓住每个主题的感知和工作流度量。除了有关工程系统和流程的客观数据之外，衡量开发者体验还需要抓住开发人员的看法（他们的态度、感受和意见）。这是因为单独的感知和工作流度量都无法讲述完整的故事。

例如，看似快速的构建过程如果经常打断开发人员的工作进度，可能会给开发人员带来干扰。相反，即使开发人员对他们的构建过程感到满意，使用构建时间等客观衡量标准也可能会发现反馈回路比应有的速度要慢，并且开发工作流程的简化程度也比应有的要低。因此，分析感知和工作流度量对于全面了解开发人员在日常工作中遇到的摩擦点是必要的。

度量 KPI，以聚焦推动重要的业务成果。 KPI 充当 DevEx 计划的北极星指标。精心设计的 KPI 应度量企业寻求推动的成果，包括生产力、满意度、参与度和保留率的提高。

如何度量

作者建议从调查开始来捕获上述指标。调查的优点是能够捕获开发者体验的各个方面，包括 KPI、感知度量和工作流度量。

谷歌、微软和 Spotify 等公司多年来一直依赖基于调查的开发者生产力指标。然而，设计和管理调查可能很困难，因此我们希望我们的框架为领导者提供一个不错的起点。

鉴于调查的重要性，作者概述了调查计划成功的几个重要考虑因素。

精心设计调查。设计不当的调查问题会导致结果不准确且不可靠。作者表示，至少，调查问题应基于明确定义的结构，并在访谈中经过严格测试，以获得一致的解释。按团队和角色细分结果。组织领导者常犯的一个错误是关注公司范围内的结果，而不是按团队和角色（例如角色、任期、资历）细分的数据。仅关注总体结果可能会导致忽视影响公司内少数但重要群体的问题。将结果与基准进行比较。比较分析有助于将数据置于情境中并帮助推动行动。例如，开发商对科技债务的情绪通常是负面的，这使得识别问题或衡量其规模变得困难。基准使领导者能够了解团队的情绪得分何时低于同行，以及组织的得分何时低于行业竞争对手。这些信号标志着显着的改进机会。混入事务调查。除了定期调查之外，组织还可以使用事务调查来收集基于特定接触点的反馈。例如，当 CLI 工具安装过程中发生特定错误时，平台团队可以使用事务调查来提示开发人员提供反馈。事务调查提供持续的反馈流，并且由于提出问题的及时性，可以产生更高质量的答复。注意调查疲劳。随着时间的推移，许多组织都在努力维持调查的高参与率。缺乏后续行动通常会导致开发人员觉得重复回应调查不值得。因此，领导者和团队跟进调查至关重要。

结论

DevEx 框架提供了一个用于了解开发者体验的实用框架，其配套的度量方法能系统地帮助指导改进。组织应该立即开始度量开发者体验，即使他们尚未建立或计划正式的 DevEx 投入。

作者简介

Abi Noda 是 DX的创始人兼首席执行官，负责领导公司的战略方向和研发工作。他的工作重点是开发衡量方法，以帮助组织提高开发者体验和生产力。在 DX 之前，Abi 在多家公司担任工程领导职务，并创立了 Pull Panda，该公司于 2019 年被 GitHub 收购。有关更多信息，请访问他的网站。

原文链接：

https://wwwq/articles/devex-metrics-framework/

相关阅读：

AI 时代背景下的平台工程之路 | 极客有约

通用电气在平台工程上浪费70亿美元的教训

一个价值70亿美元的教训！如何避免平台工程变成“大灾难”？