PDFDevEx in Action
对其有形影响的研究
Nicole Forsgren, Microsoft Research
Eirini Kalliamvakou, Github Next
Abi Noda, DX
Michaela Greiler, DX
Brian Houck, Microsoft
Margaret-Anne Storey, University Of Victoria and DX
此时此刻，某处，一位软件开发者正在打开项目积压工作列表中的一个工单，对即将开始新的工作感到兴奋。当这位开发者开始阅读任务描述时，他们的笔记本电脑突然被来自团队生产错误跟踪系统的警报淹没，打断了开发者集中注意力的能力。最终，回到手头的任务，开发者研究了工单中描述的需求。不幸的是，该任务缺乏上下文和清晰度，因此开发者寻求帮助，这将需要几天时间才能解决。与此同时，开发者检查了之前的任务，该任务已在队列中等待审批数日。测试和构建反复失败，每次审阅者尝试验证更改时都会停止他们的进度。当开发者从一个任务跳到另一个任务，希望最终沉浸在一些深度工作中时，他们意识到今天的体验并不像它应该的那样好，无法让他们发挥最佳水平。
对于许多专业软件开发者来说，这个轶事与他们的日常体验非常相似。摩擦无处不在，开发生命周期充斥着繁文缛节，成功地将代码交付到生产环境是一件令人沮丧的罕见事件。更糟糕的是，问题还在不断累积。开发者们眼睁睁地看着高层管理人员未能介入，导致速度停滞不前，顶尖工程师纷纷离职。
组织是如何陷入这种困境的呢？
如今，DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者们寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付。技术领导者们凭直觉普遍认为，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议计划和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。“什么是开发者体验？”，他们中的许多人质疑。“为什么它很重要？”
为什么 DevEx 很重要
DevEx 涵盖了开发者如何感受、思考和重视他们的工作。11 为什么这很重要？首先，开发者每天构建软件并使用工程系统，因此他们完全有能力对系统和流程的运行状况提供关键见解。例如，编写代码并将其交付给客户是否容易且直观？还是令人困惑且充满手动步骤，容易出错和发生中断？当然，您可以争辩说，在这两种情况下，开发者都在编写代码和交付软件，但环境和情况却截然不同，它们可能是系统质量、可靠性、可维护性甚至安全性的领先指标。
DevEx 很重要也是因为它对开发的影响。
这似乎是显而易见的，因为世界各地的许多组织，从初创公司到非营利公司再到大型企业，都聘请开发者为客户编写软件、改进内部工具或自动化复杂流程。但是，仅仅编写代码和在为编写代码而优化的环境中编写代码之间存在差异。为编写代码而优化的环境是高效、有效且有益于福祉的，并且依赖于工具、实践、流程和社会结构的正确组合。这些环境帮助开发者
• 进入心流状态并最大限度地减少中断，以便他们能够集中精力并解决复杂的任务。
• 促进联系和协作，以便他们及其团队在最重要的时候能够发挥创造力。
• 获得高质量的反馈，以便他们能够取得进展。
从这个角度来看 DevEx 表明，开发不仅仅是编写代码。这是一个社会技术过程，可以帮助开发者工作，同时为更广泛的团队绩效和组织使命与文化做出贡献。我们不知道对 DevEx 的影响进行过实证调查；有必要研究开发者工作的结果以及支持它的工作设计。
因此，本文描述的研究目标是回答这个问题：DevEx 如何影响个人开发者以及他们的团队和组织？剧透警告：改进的开发者体验具有积极的结果——而且不仅仅是对开发者而言；它还有助于改善团队和组织的结果。例如，我们发现更好的开发者体验可以提高生产力、学习能力、创新能力和盈利能力等等。请继续阅读以了解详细信息，如果您现在只想知道结果，请转到“分析与讨论”部分。
作为工作设计的 DevEx
我们的研究基于 WDT（工作设计理论）22，原因有二。首先，该理论考虑了多个维度的工作成果。WDT 的研究发现，个人贡献者、团队、组织和社会都有重要的成果和影响。我们之前的研究7 还发现，通过改善开发者工作环境和工作设计，个人（例如，减少倦怠）、团队（例如，改善软件交付）和组织（例如，改善客户和组织指标）的绩效结果会更好。
其次，我们的调查基于 WDT，因为其工作概念化足够复杂，可以解释当今软件开发者的工作实践。WDT 将工作视为分配的工作（即，正式分配给个人的任务组）以及“新兴的、社会的，有时是自发的活动”。23 软件开发者工作包括分配的任务（例如，在冲刺期间分配的项目），以及新兴的活动（例如，修复错误、自发性创造性工作以及协作和改进流程的社交活动等反应性工作）。
本研究使用 WDT 做两件事：首先，它扩展了我们之前的工作，以调查个人、团队和组织层面更广泛的结果。其次，它探讨了开发者（侧重于 DevEx）的工作设计，这种设计对这些结果产生积极影响。
结果
在考虑开发工作或开发者体验的结果时，许多研究人员和人士会想到生产力。8,21 然而，在我们多年的经验中，我们看到开发者工作的改进远远超出了个人贡献者的个人生产力，16 还包括团队和组织的结果。7,11 本调查考虑了开发者、团队和组织层面的结果，这得到了 WDT 的支持。23
开发者结果
开发者结果是指使个人开发者受益的结果。特别是，之前的 WDT 研究表明，改进的工作设计对工作绩效、创造力22 和学习能力5 产生积极影响——本研究调查了这三种结果。
团队结果
团队结果是指可以使个人开发者受益，但更可能在团队工作层面累积，因此在这个层面进行操作和研究的结果。WDT 还表明，质量等结果使团队受益。22 在 DevEx 的背景下，我们希望了解工作设计如何影响团队可以工作的系统质量，因此将其捕获为代码质量和技术债务。
组织结果
组织结果使员工的雇主受益。虽然开发者和团队的结果很可能累积到组织，但调查特定于组织的工作改进的影响仍然很重要。这是因为它可以证明 DevEx 与组织使命的关系，解释 DevEx 对组织的价值，并提供证据，有助于证明和倡导对 DevEx 计划的投资。事实上，之前的 WDT 研究表明，工作设计的改进会影响组织。其中许多结果是企业领导者最关心的问题，包括员工保留率和创新。22 先前的研究还表明，开发者工作的改进对组织的盈利能力及其实现目标的能力产生积极影响。7 本研究衡量了组织结果的这些指标——员工保留率、创新、盈利能力和实现目标的能力。
开发者体验
根据我们之前的工作，我们在此提出一个模型，通过已发现影响开发者体验的三个维度来理解和衡量 DevEx：心流状态、反馈循环和认知负荷。21 本节定义了这些维度中的每一个，并描述了 WDT 如何支持它们。假设表示为 Hn，表示假设 1、2 或 3，后跟我们正在检验的假设。
心流状态
心流状态，通常被描述为“进入状态”，是一种精神状态，在这种状态下，一个人完全沉浸在工作中，并感受到精力充沛的专注、全身心的投入和享受。4 实现和支持心流状态通过环境设置（例如，安静的房间）、工具（例如，工具中的专注模式）以及个人或团队实践（例如，指定整块时间进行深度工作）来实现。同样，之前的 WDT 研究发现，新颖的工作以及支持专注的工作环境方面（例如，调度自由和无噪音的工作区域）会影响与工作相关的结果。5 我们通过以下方式衡量心流状态：对从事深度工作的时间量感到满意、中断的频率以及吸引开发者兴趣的任务。
根据先前的开发者研究和 WDT，我们假设心流状态将在开发者环境中产生积极的结果，并且这些结果将出现在三个层面：开发者、团队和组织。正式声明如下
H1 – 心流状态对 (a) 开发者、(b) 团队和 (c) 组织结果产生积极影响。
为了清晰起见，我们扩展了第一个假设陈述
假设 1a：
心流状态对开发者结果产生积极影响。
假设 1b：
心流状态对团队结果产生积极影响。
假设 1c：
心流状态对组织结果产生积极影响。
其余假设使用相同的符号，并具有相似的结构。
反馈循环
当系统的某一部分被用作系统另一部分的输入时，就会发生反馈循环。6 在工作和软件开发的背景下，反馈循环中信息的速度和质量也很重要。21 先前的 WDT 研究发现，准确及时的反馈支持个人绩效和发现错误等结果。5,1 在本研究中，我们将反馈循环衡量为代码更改获得批准的时间以及快速获得问题解答的频率。
因此，我们假设反馈循环支持三个层面的结果：开发者、团队和组织
H2 - 反馈循环对 (a) 开发者、(b) 团队和 (c) 组织结果产生积极影响。
认知负荷
认知负荷是工作记忆一次可以处理的信息量，它有助于解决问题和学习。25 在 DevEx 的背景下，认知负荷是开发者完成任务所需的心理处理量。21 认知负荷理论描述了一个框架，其中包含三种类型的认知负荷：内在是指完成任务所需的固有努力或难度；外在是指信息的呈现方式，可以对其进行修改以使其更直观或更不直观；相关与图式有关。25
之前的 WDT 研究测试了与认知负荷密切相关的环境和工作特征，这些特征有助于工作成果。例如，一项先前的研究发现，易于理解的任务（内在的）和设计良好的信息流（相关的）有助于结果。 5 另一项调查（这是一项大型荟萃分析研究）发现，工作复杂性（内在的）和支持信息处理的因素（相关的）有助于结果。15
我们的研究将认知负荷衡量为部署变更的难易程度、理解代码的难易程度以及使用流程和开发者工具的直观程度。
正式声明，我们假设低认知负荷支持开发者、开发团队及其组织获得更好的结果
H3 - 低认知负荷对 (a) 开发者、(b) 团队和 (c) 组织结果产生积极影响
拟议的研究模型如图 1 所示。用于衡量该模型的调查将在下一节中介绍。
测量和数据
我们创建了一项横断面调查，其中使用了先前在文献中验证的项目，或者是在专家投入下随着时间推移开发和完善的项目。随着时间推移完善的项目是与主题 matter 专家共同开发的，并在三年内进行了完善；这包括试点数据收集、后续项目迭代和分析，以及在收到专家反馈和统计分析后进行的定期完善。所有调查项目的来源都在表 1 中注明。该表列出了每个结构的项目。项目的详细信息包括均值和 SD（标准差，在括号中）。结构的详细信息包括 CR（组合信度）和 AVE（平均方差提取量）。响应选项和来源包含在表格底部。
数据收集是通过基于网络的调查完成的；这项调查由 DX（一家提供开发者体验平台的公司）管理。参与者是 DX 客户公司的开发者。在这些客户中，会定期对开发者进行关于他们的 DevEx 的调查（以下称为常规调查）。在完成常规调查后，开发者立即被邀请参与我们的研究（研究调查）。
完成这两项调查都是可选的，但只有完成常规调查的开发者才会被邀请完成研究调查。这两项调查之间没有重复的问题。在 DX 的产品组合中，常规调查的完成率高于 90%，完成的中位时间为 10 分钟。
在为期五周的数据收集中，2,213 名参与者被邀请参加研究调查，其中 219 人完成，回复率为 9.9%。查看研究调查的参与者的完成率为 87%。完成研究调查的中位时间为 2.5 分钟。由于研究调查是在常规调查之后进行的并且是自愿的，因此低回复率可能是时间限制的结果，这在企业环境中的开发者中通常是如此。20 在完成调查的人中，170 人（77.6%）来自主要业务为技术的公司，200 人（91.3%）为员工人数超过 500 人的公司工作（我们对中型或大型公司的划分标准）。出于隐私考虑，研究团队未收集参与者的人口统计信息，如性别、年龄或工作年限。
分析和模型结果
拟议的研究模型使用 PLS（偏最小二乘法）分析进行了测试，选择 PLS 的原因有三：2,3 (1) 它非常适合探索性分析和理论构建；(2) PLS 不需要多元正态性假设；(3) PLS 在中小样本量下效果良好。在考虑 CBSEM（基于协方差的结构方程建模）与 PLS 时，CBSEM 更关注模型拟合，而 PLS 特别适合预测模型，3 这在考虑现实世界的结果时是一个理想的应用。此外，我们提出的模型包含九个自变量和九个因变量，以及两个控制变量（在本节稍后解释），使其成为一个相当复杂的模型；相比之下，CBSEM 可能仅由于模型的复杂性而显示出较差的模型拟合度。3
在进行 PLS 分析时，确定足够样本量的经验法则是最大结构方程模型的 10 倍。9 在本研究中，最大的结构方程是开发者体验结构，其中每个结构都有三条通往结果的路径。我们的样本量 219 远大于最小样本量 30。
我们使用 SmartPLS 424 进行了分析。与先前使用 PLS 技术的研究所一致，模型分析包括两个阶段：3 评估 (1) 测量模型和 (2) 结构模型。
在测量模型的评估中，收敛效度通过三个标准建立：10 (1) 每个项目都加载到其各自的结构上，并且没有一个低于 0.50 的截止值（适用于探索性研究）；12 (2) 所有结构的组合信度均低于 0.70，证实了信度；2 (3) 所有结构的 AVE（平均方差提取量）均大于 0.50。区分效度通过异质特质-同质特质相关比率得到证实。13 因此，我们的测量结果表现出良好的心理测量特性；项目和描述性统计数据如表 1 所示。
与线性回归类似，PLS 评估结构之间关系的显着性并提供 R2 值。这些值表示可以由自变量解释的因变量方差的比例。此外，路径系数及其显着性可用于评估结构之间拟议关系的强度和重要性。R2 值和路径系数共同提供了关于数据对假设模型的支持程度的见解。
在测试模型时，我们包括了两个控制变量：组织规模和行业。根据样本中公司的类型，这些变量被简化为两个二元值，并作为虚拟变量包含在内。组织规模被编码为小型（少于 500 名员工）或非小型（500 名或更多员工）；行业被编码为主要技术或非主要技术。分析表明，控制变量不显着。假设检验的结果如图 2 所示，并在此处总结
• H1 指出心流状态对开发者、团队和组织结果产生积极影响。该假设得到完全支持。
• H2 指出反馈循环对开发者、团队和组织结果产生积极影响。该假设得到部分支持；反馈循环影响团队结果，但不影响开发者或组织结果。本文稍后将更详细地讨论这一发现。
• H3 指出认知负荷对开发者、团队和组织结果产生积极影响。该假设得到完全支持。
IPMA：产生影响
由于 PLS 专注于最大化因变量的预测，因此它可以提供对可能具有超大影响的项目的额外见解。我们对研究模型进行了 IPMA（重要性-绩效地图分析），以识别可以为团队和组织提供额外见解的项目。总之，此分析识别了相对于所考虑的因变量具有高影响和绩效的项目。为了改善开发者结果，深度工作和引人入胜的工作具有最大的潜在影响。为了改善组织结果，有几个项目具有巨大的潜在影响：深度工作、引人入胜的工作、直观的流程和直观的开发者工具。我们无法基于新兴模型对团队结果进行分析。
请注意，这些结果基于我们的研究背景，但它们提供了可以为团队和组织提供可行见解的线索。例如，如果您希望改善开发者结果（例如生产力、学习能力和创造力），请考虑您可以提供深度工作机会的方式；这些可以包括鼓励个人开发者集中时间和团队之间协调集中时间等策略，例如几乎没有或没有会议的日子。您还可以寻找创造引人入胜的工作和学习机会，例如黑客日。
分析表明，深度和引人入胜的工作为组织结果（如创新、员工保留率、盈利能力和更广泛的组织目标）提供了超乎寻常的支持。直观的流程和工具也支持这些目标。组织可以寻找方法来简化和澄清其流程（研究已发现这具有影响力），或者提供对直观、易于使用的开发者工具的访问。先前的研究发现，低效的工作流程是开发者面临的首要挑战14，流程和工具的改进是结果的驱动因素。7
替代模型
我们还考虑了 WDT 支持的替代模型。对该理论的一种解读允许将团队结果（技术债务和代码质量）中的项目重新定义为调节开发者和组织结果的环境因素。22 也就是说，它们可以减弱（减少）或放大（增加）DevEx 因素对结果的影响。对该模型的测试发现，“作为环境调节剂的团队结果”（特别是我们对技术债务和代码质量的操作化）并不显着。因此，我们不包括结果的详细信息。其他环境因素可能相关。另请注意，控制变量在此分析中不显着。
影响的另一种观点：可能性分析
为了从整体上看待这些结果，我们考虑在实施特定的 DevEx 干预措施时可能预期哪些结果。以下是在此可能性分析中观察到的统计结果，按 DevEx 的三个维度细分：心流状态、认知负荷和反馈循环。
心流状态
• 与那些缺乏专用时间的开发者相比，有大量时间用于深度工作的开发者感觉生产力提高了 50%。诚然，开发者在日历上预留整块时间并不总是那么容易，尤其是当他们在跨时区的团队中工作时。但是，投入时间进行深度工作是一种回报丰厚的实践，可以让开发者真正提高生产力。鼓励开发者和团队抽出时间集中注意力非常重要，他们的环境需要通过最大限度地减少中断来支持这种实践。
• 那些发现自己的工作引人入胜的开发者感觉生产力提高了 30%，而那些发现自己的工作枯燥乏味的开发者则不然。重新思考团队中个人或组织内团队之间的任务分配可能有所帮助。是否是相同的开发者一直在从事不太理想的项目和任务，这可能会导致倦怠？某些团队是否经常承担他们觉得枯燥乏味或与公司使命和客户脱节的活动？
认知负荷
• 那些报告对他们使用的代码有高度理解的开发者感觉生产力比那些报告理解程度低或没有理解的开发者高 42%。当团队需要快速行动并忽略使他们的代码清晰、简单或文档齐全时，这是一个非常熟悉的模式。虽然有时这是必要的，但它确实会阻碍团队的长期生产力。有助于代码在团队内部和跨团队之间易于理解的工具和约定可以为未来的生产力提供保障。
• 那些发现他们的工具和工作流程直观且易于使用的开发者感觉创新能力比那些使用不透明或难以理解的流程的开发者高 50%。不直观的工具和流程既会浪费时间，又会令人沮丧——无论哪种情况，都会严重阻碍个人和团队的创造力。
反馈循环
• 那些报告代码审查周转时间快的开发者感觉创新能力比那些报告周转时间慢的开发者高 20%。快速完成的代码审查使开发者和团队能够快速转向他们的下一个想法，为提出下一个伟大的想法奠定基础。
• 紧密的反馈循环还有另一个积极的结果。对于开发者的问题能够快速响应的团队，其技术债务比响应缓慢的团队少 50%。记录开发者重复提出的问题和/或部署工具非常值得，这样开发者就可以轻松快速地找到他们需要的响应，并在编写代码时整合良好的编码实践和解决方案，从而减少技术债务。
讨论
本研究最重要的贡献是它提供的证据表明，改进 DevEx 可以为个人、团队和组织带来积极的结果。
这是我们所知的第一个分析 DevEx 因素与个人、团队和组织层面的结果之间统计关系的研究。虽然先前的研究已经暗示了这些关系，但它们尚未被量化。此处报告的结果提供了具体证据，可以使开发团队和领导者能够倡导对 DevEx 进行投资。
如何倡导对 DevEx 的投资
大多数开发者都知道他们需要良好的 DevEx 才能做到最好。此外，由于当今如此多的公司都是软件驱动的，它们的盈利能力取决于其开发者提高生产力和创造力、编写和维护高质量、低技术债务的软件的能力。即使是公司的创新和盈利能力也取决于 DevEx——因为如果日常工作太难做，那么创新肯定会更难。
然而，凭直觉了解 DevEx 的重要性并不总是足以向上层管理人员提出令人信服的理由。当管理层合理地询问 DevEx 是否对业务产生影响时，本研究可以提供答案，表明 DevEx 会影响个人开发者、团队和组织的绩效。此外，我们的分析清楚地表明了应优先考虑哪些因素，以使团队取得积极成果。该证据可以证明 DevEx 计划的合理性，并为指导 DevEx 干预提供可操作的见解。
既然您已经确信改进 DevEx 的重要性，那么您如何说服您的组织接受它呢？首先，让他们阅读这篇文章。然后，玩笑归玩笑，以下是五个重要步骤，可以帮助您通过保持您的论点以数据为基础来倡导持续改进。
1. 获取关于当前开发者体验的数据。
了解您组织中的 DevEx 是什么样的。对于刚开始 DevEx 之旅的组织，这意味着收集新数据以揭示他们最大的痛点，并了解他们当前进行更改的能力。（您可以使用或改编本研究中使用的调查问卷，包含在表 1 中，或使用 DX 等专用解决方案。）如果这是您第一次收集关于 DevEx 的数据，这将成为您的基线。如果您已经完成了一些 DevEx 工作，则可以整合这些数据并更新您的指标。
2. 根据您的 DevEx 数据设定目标。
使用您的 DevEx 数据来指导您的目标和投资。这些可以基于当前的业务优先级、DevEx 数据以及您从本文中学到的知识。例如，假设您的组织上个月刚刚收集了 DevEx 数据。这是一项探索性研究，因此它提出了两个问题：一个是关于内部开发工具的 NPS（如果受访者会将该工具推荐给其他人，则为 1-10 分制），另一个是关于开发工具的反馈的开放式文本问题。使用这些数据，您会看到关键挑战（机会！）是构建时间、测试不稳定性以及监控方面的差距。在审查业务优先级时，您的组织一直在持续投资于监控、构建时间和改进 PR 流程。回顾这项研究，您会看到有三个类别的 DevEx 具有影响力，其中深度工作和引人入胜的工作具有很大的影响力。
这将使您处于设定目标的有利位置。上一段中列出的任何项目都将是开始进行投资的领域。为了更具战略意义，您可以识别重叠之处。一个战略重叠是构建时间（在您的 DevEx 数据和现有业务优先级中都已识别），这可能与反馈循环（本研究支持）相一致。另一个可能的战略重叠是监控（在您的 DevEx 数据和现有业务优先级中都已看到），这也可能支持团队的反馈循环（此处支持的概念）。
3. 让您的团队为成功做好准备。
一旦您审查了您的数据并设定了目标，请务必利用贵公司已有的机制来让您和您的团队为成功做好准备。这可能意味着设定团队 OKR（目标和关键结果）——或者与另一个团队设定共享 OKR 以建立共同的责任感。与您的团队和组织沟通您的目标。定期回顾并检查进度。
4. 分享进度并验证投资。
与开发者以及 DevEx 和业务领导者分享结果，以评估和讨论您的投资价值。反思哪些投资产生了影响，以及哪些是令人惊讶的，以及您学到了什么。（分享惊喜可能特别有用，因为它突出了拥有数据并根据数据采取行动的价值，以及快速纠正方向的能力。）通过定期重新评估 DevEx 的状态并突出改进之处，您可以增强对您的投资正在产生影响的信心。
5. 重复此过程。
回到步骤 1 并收集更多数据。当您这样做时，反思您上次的经验，以更新和完善您的数据收集和干预措施。（请记住，除非为了纠正错误，否则数据收集方面的调整通常应保持较小，以便随时间进行比较。）一般来说，您应该每三到六个月重复一次数据收集和设定目标（或检查大型目标的进度）的这个过程。
研究的局限性和机会
虽然这项研究的结果很有希望，但与所有研究一样，也存在一些局限性。首先，这项研究是在已经与 DevEx 公司 (DX) 合作的公司的开发者中进行的。这可能表明这些公司致力于改进 DevEx，与没有类似承诺或文化的组织相比，这可能会使结果产生偏差。我们还邀请了参与 DevEx 调查的开发者，这意味着我们可能接触到了一群关心开发者体验的人。但是，我们认为这是一个好处，因为这些开发者可能更善于反思自己的体验。
其次，我们的测量是基于 DevEx 模型进行操作的，该模型侧重于心流、反馈循环和认知负荷。可能还有其他 DevEx 的维度或定义可以保证进一步研究。此外，我们对反馈循环的操作化仅侧重于开发者工作的一小部分：问题的答案和代码审查。这些是开发者如何在团队中工作的关键方面，这可以解释为什么这只影响了团队结果；我们强调有必要探索 DevEx 的其他方面，例如仅来自人员的反馈循环（对话或讨论）、纯粹来自系统的反馈循环（自动化构建或测试）以及来自人员但通过系统介导的反馈循环（代码审查）。
第三，这项研究是横断面的。DevEx 是一个复杂的过程，它随着时间的推移而发生，并且具有相互加强的流程。未来的工作应调查 DevEx 结构及其结果之间和内部的纵向关系。我们的研究强烈表明，改进 DevEx 值得付出努力，并且这样做的影响是可以衡量的。我们邀请您分享改进和衡量 DevEx 因素如何影响您组织的结果。
参考文献
1. Campion, M. A., McClelland, C. L. 1991. Interdisciplinary examination of the costs and benefits of enlarged jobs: a job design quasi-experiment. Journal of Applied Psychology 76(2), 186-198. https://psycnet.apa.org/record/1991-25985-001.
2. Chin, W. W., Marcolin, B. L., Newsted, P. R. 2003. A partial least squares latent variable modeling approach for measuring interaction effects: results from a Monte Carlo simulation study and an electronic-mail emotion/adoption study. Information Systems Research 14(2), 189-217; https://pubsonline.informs.org/doi/10.1287/isre.14.2.189.16018.
3. Chin, W. W. 2010. How to write up and report PLS analyses. In Handbook of Partial Least Squares, eds. V. Esposito Vinzi, W. W. Chin, J. Henseler, H. Wang, 655–690. Berlin, Heidelberg: Springer; https://link.springer.com/chapter/10.1007/978-3-540-32827-8_29.
4. Csikszentmihalyi, M. 2008. 心流：最优体验心理学. Harper Perennial Modern Classics。
5. Edwards, J. R., Scully, J. A., Brtek, M. D. 1999. 工作衡量：多方法工作设计问卷的分层表示。《人事心理学》52(2), 305–334; https://psycnet.apa.org/record/1999-05792-002。
6. Ford, F. A. 1999. 环境建模：环境系统系统动力学模型导论. Island Press。
7. Forsgren, N., Smith, D., Humble, J., Frazelle, J. 2019. DevOps 现状加速报告; https://services.google.com/fh/files/misc/state-of-devops-2019.pdf。
8. Forsgren, N., Storey, M. A., Maddila, C., Zimmermann, T., Houck, B., Butler, J. 2021. 开发者生产力的 SPACE：它比你想象的更复杂。《acmqueue》19(1), 20–48; https://queue.org.cn/detail.cfm?id=3454124。
9. Gefen, D., Straub, D., Boudreau, M. 2000. 结构方程建模与回归：研究实践指南。《信息系统协会通讯》4; https://aisel.aisnet.org/cais/vol4/iss1/7/。
10. Gefen, D., Straub, D. 2005. 使用 PLS-Graph 进行因子效度的实用指南：教程和注释示例。《信息系统协会通讯》16(5); https://aisel.aisnet.org/cais/vol16/iss1/5/。
11. Greiler, M., Storey, M. A., Noda, A. 2022. 理解和改进开发者体验的可操作框架。《IEEE 软件工程汇刊》49(4), 1411–1425; https://ieeexplore.ieee.org/document/9785882。
12. Hair Jr., J., Hult, G. T. M., Ringle, C. M., Sarstedt, M. 2021. 偏最小二乘结构方程建模 (PLS-SEM) 入门. Sage Publications。
13. Henseler, J., Ringle, C.M. Sarstedt, M. 2015. 基于方差的结构方程建模中评估判别效度的新标准。《市场营销科学学会杂志》43, 115–135; https://link.springer.com/article/10.1007/s11747-014-0403-8。
14. Houck, B., Yelin, H., Butler, J., Forsgren, N., McMartin, A. 2023. 两全其美：释放混合工作模式对软件工程师的潜力。微软和 Vista Equity Partners 白皮书; https://www.microsoft.com/en-us/research/publication/the-best-of-both-worlds-unlocking-the-potential-of-hybrid-work-for-software-engineers/。
15. Humphrey, S. E., Nahrgang, J. D., Morgeson, F. P. 2007. 整合激励性、社会性和情境性工作设计特征：工作设计文献的元分析总结和理论扩展。《应用心理学杂志》92(5), 1332–1356; https://psycnet.apa.org/doiLanding?doi=10.1037%2F0021-9010.92.5.1332。
16. Kalliamvakou, E., Forsgren, N., Redford, L., Stephenson, S. 2021. 2021 年 Octoverse 焦点：美好的一天项目 – 用于改善您工作日的个人分析。GitHub 博客; https://github.blog/2021-05-25-octoverse-spotlight-good-day-project/。
17. Magyaródi, T., Nagy, H., Soltész, P., Mózes, T., Oláh, A. 2013. 新建立的心流状态问卷的心理测量特性。《幸福与福祉杂志》1(2), 89–100; https://jhwbjournal.com/uploads/files/acef39a197aeafb1b70cd2400037f869.pdf。
18. Meijer, A. 2019. 公共创新能力：开发和测试自我评估调查工具。《国际公共管理杂志》42(8), 617–627; https://www.tandfonline.com/doi/full/10.1080/01900692.2018.1498102。
19. Morrison, B. B., Dorn, B., Guzdial, M. 2014. 衡量计算机科学导论中的认知负荷：工具的改编。在第 10 届国际计算机教育研究年会论文集, 131–138; https://dl.acm.org/doi/10.1145/2632320.2632348。
20. Murphy-Hill, E., Jaspan, C., Sadowski, C., Shepherd, D., Phillips, M., Winter, C., Knight, A., Smith, E., Jorde, M. 2019. 什么预示着软件开发人员的生产力？《IEEE 软件工程汇刊》47(3), 582–594; https://ieeexplore.ieee.org/abstract/document/8643844。
21. Noda, A., Storey, M. A., Forsgren, N., Greiler, M. 2023. DevEX：是什么真正驱动了生产力？《acmqueue》21(2); https://queue.org.cn/detail.cfm?id=3595878。
22. Parker, S. K., Wall, T. D., Cordery, J. L. 2001. 未来的工作设计研究与实践：迈向精细化的工作设计模型。《职业与组织心理学杂志》74(4), 413–440; https://bpspsychub.onlinelibrary.wiley.com/doi/abs/10.1348/096317901167460。
23. Parker, S. K., Morgeson, F. P., Johns, G. 2017. 一百年的工作设计研究：回顾与展望。《应用心理学杂志》102(3), 403–420; https://psycnet.apa.org/record/2017-06118-001。
24. Ringle, C. M., Wende, S., Becker, J.-M. 2022. SmartPLS 4. 奥斯泰因贝克: SmartPLS。检索自 https://www.smartpls.com。
25. Sweller, J. 1988. 问题解决过程中的认知负荷：对学习的影响。《认知科学》12(2), 257–285; https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1202_4。
26. Theriou, N., Maditinos, D. I., Theriou, G. 2017. 管理控制系统与战略：基于资源的视角。来自希腊的证据。《国际商业与经济科学应用研究杂志》10(2), 35–47; http://ijbesar.teiemt.gr/docs/volume10_issue2/management_control_systems_strategy.pdf。
Nicole Forsgren 是微软研究院的合伙人，她在那里领导 开发者体验实验室。她是 DevEx、DevOps 和决策方面的专家，并且是 Shingo 出版奖获奖书籍《加速：精益软件和 DevOps 的科学》的主要作者。她在技术实践和开发方面的工作已发表在行业和学术期刊上，并用于指导全球范围内的组织转型。有关更多信息，请访问她的网站 nicolefv.com。
Eirini Kalliamvakou 是 GitHub Next 的一名研究人员，她在那里指导团队的战略原型设计工作，并将其扎根于以用户为中心的研究。Eirini 正在研究人工智能对开发者创建软件方式的变革性影响。此前在 GitHub，Eirini 领导了 美好的一天项目 和 2021 年 Octoverse 状态报告，并就开发者生产力和幸福感进行了广泛的演讲。
Abi Noda 是 DX 的创始人兼首席执行官，他在那里领导公司的战略方向和研发工作。他的工作重点是开发测量方法，以帮助组织改善开发者体验和生产力。在加入 DX 之前，Noda 曾在多家公司担任工程领导职务，并创立了 Pull Panda，该公司于 2019 年被 GitHub 收购。有关更多信息，请访问他的网站 abinoda.com。
Michaela Greiler 是 DX 的研究主管，专注于开发者生产力和体验。此前，她曾在苏黎世大学和微软研究院工作，以帮助利用工程数据提高开发者生产力。她还经营一家培训和咨询公司，专门为团队改进软件工程流程和实践。有关更多信息，请访问她的网站 michaelagreiler.com。
Brian Houck 是微软的首席生产力工程师，专注于提高微软内部开发者的福祉和生产力。他的工作不仅探索影响开发者生产力的技术因素，还探索影响工程师日常体验的文化、环境和组织因素。在过去的三年中，他的大部分研究都集中在向远程/混合工作模式的转变如何影响开发者。
Margaret-Anne Storey 是维多利亚大学的计算机科学教授，并担任加拿大软件工程人文与社会方面研究主席。她的研究重点是改进软件工程中的流程、工具、沟通和协作。她担任 DX 的首席科学家，并为微软提供咨询以提高开发者生产力。
版权 © 2023 由所有者/作者持有。出版权已授权给 。
最初发表于 Queue vol. 21, no. 6—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
尽管密码哈希函数和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。针对各种安全需求，密码哈希存在许多标准，但在非密码方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，研究生产力差异，从而为该主题提供新的见解。低代码技术已清晰地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的过程中，它容易受到时尚潮流的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的已被证明有效的解决方案。用例于 1986 年首次引入，并在后来得到普及，就是那些已被证明有效的解决方案之一。
Jorge A. Navas, Ashish Gehani - OCCAM-v2：结合静态和动态分析以实现有效且高效的全程序特化
OCCAM-v2 利用可扩展的指针分析、值分析和动态分析来创建一个有效且高效的工具，用于特化 LLVM 位代码。实现的代码大小缩减程度取决于特定的部署配置。每个要特化的应用程序都附带一个清单，该清单指定先验已知的具体参数，以及运行时将提供的剩余参数的计数。部分评估的最佳情况发生在参数完全具体指定时。OCCAM-v2 使用指针分析来反虚函数调用，从而可以消除任何直接调用都无法访问的函数的整个主体。
© 保留所有权利。