此刻，在某个地方，一位软件开发者正从项目待办列表中打开一张任务卡，期待着开始处理一项新工作。就在他准备阅读任务描述时，笔记本电脑突然被团队生产错误追踪系统弹出的警报淹没，专注被迫中断。

好不容易回到手头任务后，他开始仔细阅读任务卡中的需求说明，却发现任务缺少必要上下文，描述也不够清晰。于是，他发起求助，但这个问题可能需要几天时间才能得到解决。与此同时，他又查看了之前提交的一项任务，这项任务已经在审批队列里等待了好几天。测试和构建反复失败，每当审查者试图验证变更时，流程都会被阻塞。

这位开发者只能在多个任务之间来回切换，期待自己终于能进入某种深度工作状态。但他很快意识到，今天的工作环境并不理想，根本无法让他发挥出最佳水平。

对于许多专业软件开发者来说，这段描述与他们的日常经历非常相似。摩擦无处不在，开发生命周期中充斥着流程负担，代码成功交付到生产环境也变得越来越困难。更糟糕的是，问题还在持续恶化。开发者眼看着高层管理者没有及时介入，最终导致开发速度停滞不前，优秀工程师陆续离开。

组织为什么会陷入这种困境？更重要的是，开发者体验究竟会如何影响开发者生产力、团队交付效率和组织层面的研发效能？

如今，在预算收紧和人工智能等变革性技术快速发展的背景下，越来越多软件组织开始关注开发者体验（Developer Experience，简称 DevEx）。技术领导者普遍认为，良好的开发者体验能够提高软件交付效率，并提升开发者满意度。

然而，在许多组织中，旨在改善开发者体验的举措和投入仍然很难获得支持，因为业务利益相关者会质疑这些改进的价值：“什么是开发者体验？它为什么如此重要？”

DevEx 为什么重要？

DevEx 涵盖开发者对自身工作的感受、思考和评价。11

这为什么重要？

首先，开发者每天都在构建软件，也在使用工程系统。因此，他们能够提供关于系统和流程运行状况的关键洞察。例如，编写代码并将其交付给客户的过程，是简单直观的，还是繁琐复杂、充满手动步骤，并且容易出错？当然，无论是哪种情况，开发者都在编写代码并交付软件；但两种环境和条件完全不同，而这些因素恰恰可以作为衡量系统质量、可靠性、可维护性乃至安全性的重要信号。

DevEx 之所以重要，还在于它会直接影响开发工作本身。

这似乎显而易见。世界各地的许多组织，从初创公司到非营利组织，再到大型企业，都会雇佣开发者来为客户编写软件、改进内部工具，或自动化复杂流程。但是，“编写代码”和“在为编写代码而优化的环境中编写代码”之间，存在巨大差异。

一个真正针对软件开发进行优化的环境，应当高效、有效，并有利于员工身心健康。它依赖工具、实践、流程和社会结构的合理组合。这样的环境可以帮助开发者：

• 进入工作状态，尽量减少干扰，从而专注解决复杂任务。
• 促进彼此之间的连接与协作，使开发者及其团队能够在关键时刻发挥创造力。
• 获得高质量反馈，从而持续推进工作。

从这个角度看，DevEx 会让我们意识到：软件开发远不只是编写代码。它是一个社会技术过程，不仅支持开发者完成工作，也会提升团队整体绩效，并促进组织使命和文化的实现。

目前，关于 DevEx 影响的实证研究仍然有限。因此，我们有必要研究开发者的工作成果，以及支撑这些成果的工作设计。

本文所述研究的目标，就是回答以下问题：开发者体验如何影响开发者个人、团队和组织？

先透露结论：改善开发者体验会带来积极成果，而且受益者并不只有开发者本人。更好的 DevEx 也有助于提升团队和组织绩效。例如，我们发现，更好的开发者体验可以提升生产力、学习效率、创新能力和盈利能力等多项结果。

将 DevEx 视为工作设计

我们的研究基于工作设计理论（Work Design Theory，简称 WDT）。原因有两个。

首先，工作设计理论从多个维度考察工作成果。相关研究发现，工作成果会对个人贡献者、团队、组织和社会产生重要影响。我们此前的研究也发现，通过改善开发者的工作环境和工作设计，可以提升个人层面的成果，例如减少职业倦怠；也可以提升团队层面的成果，例如提高软件交付效率；还可以提升组织层面的成果，例如改善客户和组织指标。7

其次，我们之所以采用工作设计理论，是因为它对“工作”的理解足够复杂，能够解释当今软件开发者的真实工作实践。WDT 将工作视为两类内容的组合：一类是被分配的任务，也就是正式交给个人完成的一组任务；另一类是“涌现的、社会性的、有时是自发性的活动”。23

软件开发者的工作既包括被分配的任务，例如迭代周期中安排的开发任务；也包括涌现出来的活动，例如被动修复缺陷、自发开展创造性工作，以及与他人协作、改进流程的社会性活动。

本研究运用工作设计理论来实现两个目标：第一，扩展我们此前的研究，从个人、团队和组织层面考察更广泛的成果；第二，探索哪些开发者工作设计因素，尤其是与 DevEx 实践相关的因素，能够积极影响这些成果。

DevEx 会带来哪些结果？

在讨论开发工作成果或开发者体验时，许多研究人员和从业者首先想到的是生产力。8,21 然而，根据我们多年的经验，改善开发者工作所带来的结果，远不止个人贡献者生产力的提升。16 它还包括团队和组织层面的成果。7,11

在工作设计理论的支持下，本研究从开发者、团队和组织三个层面考察相关成果。23

开发者成果

开发者成果是指对开发者个人有益的结果。具体而言，以往关于工作设计理论的研究表明，改进工作设计能够积极影响工作绩效、创造力和学习能力。22,5 这三项成果正是本研究的调查对象。

团队成果

团队成果是指那些虽然也可能使单个开发者受益，但更可能在团队层面产生影响的结果，因此也应在团队层面进行操作化和研究。

工作设计理论表明，质量等成果会使团队受益。22 在 DevEx 语境下，我们希望了解工作设计如何影响团队所使用系统的质量，因此将团队成果具体体现为代码质量和技术债务。

组织成果

组织成果最终会惠及雇佣开发者的组织。虽然开发者和团队成果很可能最终也会传导到组织层面，但单独研究工作改进对组织的具体影响仍然非常重要。

这是因为，组织成果有助于展现 DevEx 与组织使命之间的联系，说明 DevEx 对组织的价值，并为支持 DevEx 计划和相关投入提供证据。事实上，以往关于工作设计理论的研究表明，改进工作设计会对组织产生影响。其中许多成果也是企业领导者最关注的，例如员工留任率和创新能力。22

此前研究还表明，开发者工作的改进会对组织盈利能力及其目标实现能力产生积极影响。7 因此，本研究将衡量这些组织成果：员工留任率、创新能力、盈利能力和目标实现能力。

开发者体验的三个关键维度

基于我们此前的研究，本文提出了一个通过三个维度来理解和衡量开发者体验的模型。这三个维度已被证明会影响开发者体验：心流状态、反馈循环和认知负荷。21

本节将定义每个维度，并说明它们如何受到工作设计理论的支持。后文中的 Hn 表示研究假设，其中 n 对应假设编号，例如假设 1、假设 2 或假设 3。

心流状态：影响开发者生产力的重要体验

心流状态通常被描述为“进入状态”。这是一种心理状态，在这种状态下，人会完全沉浸于工作之中，感到精力充沛、专注投入，并从工作中获得乐趣。4

实现和支持心流状态，可以通过多种方式完成。例如，通过环境设置创造安静空间，通过工具提供专注模式，或者通过个人和团队实践安排专门的深度工作时段。

类似地，工作设计理论领域此前的研究发现，新颖的工作，以及有助于集中注意力的工作环境因素，例如灵活的日程安排和无噪声的工作区域，会影响工作相关结果。5

在本研究中，我们从以下几个方面衡量心流状态：对深度工作时间的满意度、被打断的频率，以及任务是否能够吸引开发者兴趣。

基于此前的开发者研究和工作设计理论，我们认为，心流状态会在开发者工作环境中产生积极影响，并且这种影响会体现在三个层面：开发者、团队和组织。具体来说：

H1：心流状态对开发者、团队和组织成果有积极影响。

为了更清晰地说明，我们可以将其展开为：

• 假设 1a：心流状态对开发者成果有积极影响。
• 假设 1b：心流状态对团队成果有积极影响。
• 假设 1c：心流状态对组织成果有积极影响。

后续假设也采用相同结构。

反馈循环：影响软件交付效率的关键因素

当系统的一部分被用作系统另一部分的输入时，就会形成反馈循环。6 在工作和软件开发中，反馈循环中信息返回的速度和质量同样至关重要。21

此前关于工作设计理论的研究发现，准确、及时的反馈有助于提升个人绩效、发现错误等工作结果。5,1 在本研究中，我们用代码变更获得批准所需时间，以及问题得到快速解答的频率，来衡量反馈循环。

因此，我们假设反馈循环会在三个层面支持相关结果：开发者、团队和组织。

H2：反馈循环对开发者、团队和组织成果有积极影响。

认知负荷：开发者体验中的隐性成本

认知负荷是指工作记忆一次能够处理的信息量，它会影响问题解决和学习。25 在 DevEx 语境下，认知负荷是指开发者完成任务所需的心理处理量。21

认知负荷理论提出了三类认知负荷：

• 内在认知负荷：完成任务本身所需的努力或难度。
• 外在认知负荷：信息的呈现方式带来的负担，这种呈现方式可以被设计得更直观，也可能更不直观。
• 相关认知负荷：与认知图式和长期知识结构形成有关的负荷。25

以往关于工作设计理论的研究，考察了与认知负荷密切相关、且会影响工作结果的环境和工作特征。例如，一项研究发现，易于理解的任务和设计良好的信息流，有助于改善工作结果。5 另一项大型元分析研究发现，工作复杂性和支持信息处理的因素，都会影响工作结果。15

在本研究中，我们通过以下方式衡量认知负荷：部署变更的难易程度、理解代码的难易程度，以及流程和开发者工具是否直观易用。

正式表述为：

H3：较低的认知负荷对开发者、团队和组织成果有积极影响。

研究方法：测量与数据

本研究采用横断面调查问卷。问卷中的一部分条目已经在已有文献中得到验证，另一部分条目则是在领域专家参与下，经过较长时间不断完善形成的。

这些经过完善的条目由领域专家参与开发，历时三年，包括试点数据收集、后续条目迭代和分析，以及根据专家反馈和统计分析结果进行的定期改进。所有调查条目的来源均列于表 1。表中还列出了每个构念的条目。条目层面的详细信息包括均值和标准差；构念层面的详细信息包括组合信度和平均方差提取值。表格底部列出了回答选项及其来源。

数据收集通过在线问卷进行。问卷由一家海外开发者体验平台公司管理。参与者来自该平台客户公司的开发者。这些客户公司的开发者会定期接受关于其开发者体验的调查，以下简称“常规调查”。完成常规调查后，开发者会立即受邀参与我们的研究调查。

完成这两项调查均为自愿，但只有完成常规调查的开发者，才会被邀请填写研究调查。两项调查中的问题没有重复。在该平台的所有项目中，常规调查完成率超过 90%，平均完成时间为 10 分钟。

在为期五周的数据收集期间，我们邀请了 2213 名参与者填写研究调查问卷，其中 219 人完成了问卷，回复率为 9.9%。在打开过调查问卷的参与者中，完成率为 87%。完成研究调查的中位时间为 2.5 分钟。

由于该调查问卷是在常规调查之后进行的，且属于自愿参与，因此较低的回复率可能与时间限制有关，这在企业环境中的开发者群体中很常见。

在完成调查问卷的参与者中，170 人，即 77.6%，来自一家以技术为主要业务的公司；200 人，即 91.3%，就职于员工人数超过 500 人的公司，我们以此作为中型或大型公司的界定标准。出于隐私考虑，研究团队没有收集参与者的性别、年龄或工作年限等人口统计信息。

分析与模型结果

本研究采用偏最小二乘法（Partial Least Squares，简称 PLS）分析来检验所提出的研究模型。选择 PLS 的原因有三个：2,3

第一，它非常适合探索性分析和理论构建。第二，PLS 不要求数据满足多元正态性假设。第三，PLS 适用于中小样本量。

与基于协方差的结构方程模型相比，PLS 更强调预测能力，因此特别适用于预测模型。3 这对于考察现实世界中的结果非常适合。此外，我们提出的模型包含 9 个自变量、9 个因变量，以及 2 个控制变量，这使它成为一个相当复杂的模型。相比之下，基于协方差的结构方程模型可能会因为模型复杂度较高而出现拟合较差的问题。3

在进行 PLS 分析时，确定合适样本量的一个经验法则是最大结构方程路径数量的 10 倍。9 在本研究中，最大的结构方程涉及开发者体验构念，每个构念都有三条通往结果的路径。我们的样本量为 219，远高于最小样本量 30。

我们使用某结构方程建模软件进行了分析。24 与此前采用 PLS 技术的研究一致，模型分析包括两个阶段：第一，评估测量模型；第二，评估结构模型。3

在测量模型评估中，我们使用三个标准来验证收敛效度：10

第一，每个条目在其对应构念上的载荷均高于 0.50，这适用于探索性研究。12 第二，所有构念的组合信度均高于 0.70，证实了信度。2 第三，所有构念的平均方差提取值均大于 0.50。

我们通过异质性—同质性相关比率来验证区分效度。13 因此，我们的测量工具展现出良好的心理测量学特性。

与线性回归类似，PLS 会评估构念之间关系的显著性，并提供 R² 值。这些值表示因变量方差中可以由自变量解释的比例。此外，路径系数及其显著性可用于评估构念之间关系的强度和重要性。R² 值和路径系数共同反映了数据对假设模型的支持程度。

在模型检验中，我们纳入了两个控制变量：组织规模和行业。根据样本中公司的类型，我们将这两个变量简化为二元值，并作为虚拟变量纳入模型。组织规模被编码为小型，即员工人数少于 500 人；或非小型，即员工人数 500 人及以上。行业被编码为主要科技行业或非主要科技行业。分析结果表明，控制变量并不显著。

假设检验结果总结如下：

• H1 提出，心流状态对开发者、团队和组织成果有积极影响。该假设得到充分支持。
• H2 提出，反馈循环对开发者、团队和组织成果有积极影响。该假设得到部分支持。反馈循环确实会影响团队成果，但没有显著影响开发者成果或组织成果。后文将对此发现进行更详细讨论。
• H3 提出，较低认知负荷对开发者、团队和组织成果有积极影响。该假设得到充分支持。

IPMA 分析：识别最具影响力的 DevEx 因素

由于 PLS 侧重于最大化对因变量的预测能力，它可以进一步揭示哪些因素可能产生更大影响。我们对研究模型进行了重要性—绩效图分析（Importance-Performance Map Analysis，简称 IPMA），以识别能够为团队和组织提供额外洞察的因素。

总体而言，该分析能够识别出相对于特定因变量而言，既重要又表现较好的因素。

为了提升开发者成果，深度工作和投入感强的工作具有最大的潜在影响。为了提升组织成果，以下几个因素具有较大潜在影响：深度工作、投入感强的工作、直观的流程，以及直观的开发者工具。由于模型本身存在限制，我们没有对团队成果进行同样分析。

需要注意的是，这些结果基于我们的研究背景，但它们仍然为团队和组织提供了可操作洞察。

例如，如果希望提升开发者生产力、学习能力和创造力等成果，就可以思考如何为开发者创造深度工作的机会。这些策略包括鼓励开发者个人专注工作，以及在团队之间协调专注工作时间，例如安排少开会或不开会的日子。组织也可以寻找创造更具吸引力的工作和学习机会，例如设置黑客马拉松日。

分析表明，深度且令人投入的工作，能够极大促进组织成果，例如创新、人才保留、盈利能力，以及更广泛的组织目标实现。直观的流程和工具也有助于实现这些目标。组织可以寻找简化和明确流程的方法，其他研究也已经证实这类做法有效；或者提供更直观易用的开发者工具。

此前研究发现，低效工作流是开发者面临的主要挑战之一，14 而流程和工具改进则是提升成果的关键驱动因素。7

替代模型

我们也考虑过另一种由工作设计理论支持的模型。根据该理论的一种解读，团队成果中的项目，例如技术债务和代码质量，可以被重新定义为调节开发者成果和组织成果的环境因素。22 也就是说，它们既可能削弱，也可能增强 DevEx 因素对成果的影响。

对该模型的检验发现，“作为环境调节因素的团队成果”，具体而言是我们对技术债务和代码质量的操作化定义，并不显著。因此，我们没有列出详细结果。其他环境因素可能仍然相关。另需注意，控制变量在这一分析中也并不显著。

DevEx 影响的另一种视角：可能性分析

为了更好地理解这些结果，我们进一步考察了在实施特定 DevEx 干预措施后，可能出现哪些结果。以下是本次可能性分析中观察到的统计结果，并按 DevEx 的三个维度划分：心流状态、认知负荷和反馈循环。

心流状态

能够抽出大量时间进行深度工作的开发者，其工作效率比缺少专门深度工作时间的开发者高出 50%。当然，对于开发者而言，在日历上预留大块时间并不容易，尤其是在跨时区团队协作的情况下。但为深度工作留出时间，对于提升开发者生产力而言，无疑是一项高回报实践。鼓励开发者和团队安排专注工作时间至关重要，而他们的工作环境也需要通过最大限度减少干扰来支持这种做法。

与认为工作枯燥乏味的开发者相比，认为自己工作充满乐趣的开发者，工作效率高出 30%。这提示组织可以重新思考团队成员或组织内不同团队之间的任务分配方式。是否总有一些开发者长期从事他们并不喜欢的项目和任务，从而增加职业倦怠风险？某些团队是否经常被安排处理他们觉得枯燥、乏味，或与公司使命和客户价值关联不强的工作？

认知负荷

对所编写代码理解程度高的开发者，其工作效率比那些理解程度较低甚至完全不理解代码的开发者高出 42%。当团队为了快速迭代而忽视代码清晰度、简洁性和文档完善度时，这种情况十分常见。虽然有时这种取舍是必要的，但它会严重阻碍团队的长期生产力。能够帮助团队内部以及跨团队理解代码的工具和规范，有助于保障未来生产力。

与使用晦涩难懂工具或复杂流程的开发者相比，认为工具和工作流直观易用的开发者，其创新能力高出 50%。不直观的工具和流程既浪费时间，也令人沮丧。无论是哪种情况，都会严重阻碍个人和团队的创造力。

反馈循环

与代码审查周期较长的开发者相比，代码审查周期较短的开发者认为自己更具创新力，这种感受高出 20%。快速完成的代码审查，能够让开发者和团队更快投入下一个想法，为创造下一个优秀产品奠定基础。

紧密的反馈循环还有另一个积极作用。能够快速响应开发者问题的团队，其技术债务比响应缓慢的团队少 50%。记录开发者反复提出的问题，或者部署相应工具，让开发者能够轻松、快速找到所需答案，并在编写代码时融入良好的编码实践和解决方案，可以有效减少技术债务。这是一项值得投入的工作。

讨论：为什么 DevEx 值得投入？

这项研究最重要的贡献在于，它提供了证据，证明改进 DevEx 可以为个人、团队和组织带来积极结果。

据我们所知，这是首个从个人、团队和组织层面，分析 DevEx 因素与结果之间统计关系的研究。虽然此前研究已经暗示了这些关系，但尚未进行量化。本文报告的结果提供了有力证据，可以帮助开发团队和领导者更有力地倡导对 DevEx 进行投资。

如何倡导对 DevEx 进行投资？

大多数开发者都知道，良好的开发者体验是他们发挥最佳水平的必要条件。此外，如今许多公司都是软件驱动型企业，其盈利能力取决于开发者的生产力和创造力，也取决于开发者编写和维护高质量软件、降低技术债务的能力。甚至公司的创新能力和盈利能力也取决于开发者体验——因为如果日常工作都难以顺利完成，创新自然无从谈起。

然而，仅凭直觉认识到 DevEx 的重要性，并不总能说服高层管理者。当管理层合理地询问 DevEx 是否会对业务产生影响时，本研究可以提供答案：DevEx 确实会影响开发者个人、团队和组织绩效。此外，我们的分析还清楚指出了团队应优先关注哪些因素，才能取得积极结果。

这些证据不仅可以为 DevEx 计划提供论证，也可以为指导 DevEx 干预措施提供切实可行的洞察。

既然你已经认同改善 DevEx 的重要性，那么如何说服组织也接受这一理念？以下五个步骤可以帮助你以数据为依据，倡导持续改进。

1. 获取当前开发者体验数据

首先，需要了解公司当前 DevEx 的现状。

对于刚开始 DevEx 之旅的组织而言，这意味着需要收集新数据，以揭示最大的痛点，并了解组织当前的变革能力。你可以直接使用或调整本研究中使用的调查问卷，也可以采用专门的 DevEx 解决方案。

如果希望把 DevEx 数据和实际研发流程结合起来，团队也可以借助 PingCode 这类智能化研发管理工具，将目标、需求、任务、开发、测试、发布和 Wiki 知识沉淀等环节连接起来，并打通研发过程中使用的其他工具。这样不仅有助于建立开发者体验的基准，也能帮助团队从完整的软件交付上下文中识别反馈循环、认知负荷和心流状态中的真实摩擦。

如果这是首次收集 DevEx 数据，那么这些数据将成为后续衡量的基准。如果已经开展了一些 DevEx 工作，则可以整合现有数据，并更新相关指标。

2. 基于 DevEx 数据设定目标

利用 DevEx 数据来指导目标和投资。目标可以基于当前业务优先级、DevEx 数据，以及本文中的研究发现。

例如，假设你的组织上个月刚刚收集了 DevEx 数据。这是一项探索性研究，因此提出了两个问题：一个是内部开发工具的 NPS，即净推荐值，采用 1 到 10 分制，询问受访者是否愿意向他人推荐该工具；另一个是开放式文本问题，用于收集关于开发工具的反馈。

利用这些数据，你可能会发现关键挑战，也是机会，集中在构建时间、测试不稳定以及监控不足上。与此同时，在审查业务优先级时，你发现组织一直在持续投资监控、缩短构建时间和改进 PR 流程。结合本文研究，你又可以看到，DevEx 的三个类别都会产生影响，其中深度工作和投入感强的工作影响尤其显著。

这将帮助你更好地设定目标。上一段列出的任何项目都可以成为投资方向。为了更具战略性，你可以找出重叠点。一个战略重叠点是构建时间，它同时出现在 DevEx 数据和现有业务优先级中，并且与反馈循环相关。另一个可能的战略重叠点是监控，它同样出现在 DevEx 数据和现有业务优先级中，也可以支持团队的反馈循环。

3. 为团队成功创造条件

在审阅数据并设定目标后，需要利用公司现有机制，确保你和团队能够取得成功。

这可能意味着设定团队 OKR，或者与其他团队共同设定 OKR，以建立共同责任机制。还需要与团队和组织沟通目标，并定期回顾、检查进展。

4. 分享进展并验证投入

与开发者、DevEx 团队和业务领导者分享结果，以评估和讨论相关投入的价值。

反思哪些投入产生了影响，哪些结果出乎意料，以及从中学到了什么。分享意外发现尤其有价值，因为它能够凸显拥有数据、基于数据采取行动，以及快速修正方向的价值。通过定期重新评估 DevEx 现状并强调改进成果，你可以增强组织对投入效果的信心。

5. 重复上述过程

回到第一步，继续收集更多数据。

在此过程中，回顾上一次的经验，更新并完善数据收集和干预措施。需要注意的是，除非是为了纠正错误，否则数据收集方式的调整通常应保持较小幅度，以便进行长期比较。一般来说，组织可以每三到六个月重复一次数据收集和目标设定过程，或检查大目标的进展情况。

研究的局限性与机会

尽管这项研究的结果令人鼓舞，但所有研究都存在局限性。

首先，本研究对象是已经与一家开发者体验平台公司合作的企业中的开发者。这可能表明这些公司已经致力于改善开发者体验，因此与那些没有类似承诺或文化的企业相比，研究结果可能存在一定偏差。此外，我们邀请的是已经参与过开发者体验调查的开发者，这意味着我们可能接触到了一群本身就更关注开发者体验的人。不过，我们认为这也可以被视为一个优势，因为这些开发者可能更愿意反思自己的体验。

其次，我们的衡量指标基于一个侧重流程、反馈循环和认知负荷的 DevEx 模型。可能还存在其他 DevEx 维度或定义，值得进一步研究。此外，我们对反馈循环的衡量仅关注开发者工作的一小部分：问题解答和代码审查。这些确实是开发团队协作中的关键方面，也可能解释了为什么反馈循环只显著影响团队成果。未来研究需要探索开发者体验中的其他反馈循环，例如完全来自人的反馈，如对话或讨论；完全来自系统的反馈，如自动化构建或测试；以及由人通过系统传递的反馈，如代码审查。

第三，本研究是一项横断面研究。DevEx 是一个复杂过程，需要时间积累，并涉及多个相互促进的过程。未来研究应重点探讨 DevEx 构成要素及其结果之间的纵向关系。

我们的研究有力表明，改善 DevEx 是值得投入的，而且它的影响可以被衡量。我们也期待更多组织分享自己如何通过改进和衡量 DevEx 因素来提升绩效。