PDFDevEx：真正驱动生产力的因素
以开发者为中心的方法来衡量和提高生产力。
Abi Noda，DX
Margaret-Anne Storey，维多利亚大学
Nicole Forsgren，微软研究院
Michaela Greiler，DX
工程领导者长期以来一直寻求提高开发者的生产力，但如何衡量甚至定义开发者生产力仍然难以捉摸。5 过去的各种方法，例如衡量开发者的产出或完成任务所需的时间，都未能考虑到开发者执行的复杂和多样化的活动。因此，问题仍然存在：领导者应该衡量和关注什么来提高开发者生产力？
如今，许多旨在提高开发者生产力的组织发现，一种以开发者为中心的新方法，专注于开发者体验（也称为 DevEx），可以解锁有价值的见解和机会。Gartner 公司报告称，78% 的受访组织已经建立或计划了正式的 DevEx 计划。7 因此，为了帮助改善组织内部的开发者体验，专门的 DevEx 和平台团队持续增加。
开发者体验侧重于开发者的实际体验以及他们在日常工作中遇到的摩擦点。除了提高生产力外，DevEx 还通过提高效率、产品质量和员工保留率来推动业务绩效。麦肯锡 2020 年的一项研究发现，为开发者提供更好工作环境的公司，其收入增长是竞争对手的四到五倍。13
本文提供了一个实用的框架，用于理解 DevEx，并提出了一个衡量框架，该框架将来自开发者的反馈与他们与之交互的工程系统的数据相结合。这两个框架为领导者提供了清晰、可操作的见解，了解应该衡量什么以及应该关注哪些方面，以提高开发者生产力。
什么是 DevEx？
开发者体验涵盖了开发者对其工作的感受、思考和重视程度。9 在之前的研究中，我们确定了 25 多个影响 DevEx 的社会技术因素。例如，干扰、不切实际的截止日期以及开发工具中的摩擦会对 DevEx 产生负面影响，而拥有明确的任务、组织良好的代码和无痛发布则可以改善 DevEx。
一个常见的误解是，DevEx 主要受工具的影响。然而，我们的研究表明，诸如拥有明确的项目目标和在团队中感到心理安全等人为因素对开发者的绩效有重大影响。9 改善 DevEx 不仅可以提高生产力，还可以提高满意度、敬业度和员工保留率。9
摩擦点可能会对所有组织级别的开发者体验产生不利影响。诸如过长的构建时间和困难的基础设施等基础性问题通常会贯穿整个组织，需要领导者或专门团队的关注。相比之下，更局部的问题，例如最大限度地减少干扰或明确定义工作，可能需要针对团队或个人的需求量身定制具体的改进措施。
个别开发者的体验具有高度的个人性和情境依赖性。开发者的团队、角色和职责以及资历都会影响他们的实际体验。理解 DevEx 的最佳方式是仔细关注特定的角色，以及一般的组织模式。本文稍后将推荐具体的方法。
DevEx 的三个维度
我们的框架将开发者体验提炼为三个核心维度：反馈循环、认知负荷和心流状态（如图 1 所示）。这些维度源于我们先前研究在现实世界中的应用，该研究确定了 25 个影响 DevEx 的社会技术因素。9 这三个关键维度贯穿了这 25 个因素，为理解 DevEx 提供了一个实用的模型。
反馈循环、认知负荷和心流状态共同概括了开发者遇到的所有摩擦类型。尽管 DevEx 复杂且细致入微，但团队和组织可以通过关注这三个关键领域来采取措施进行改进。
反馈循环
软件组织通常会寻找方法来优化其价值流，通过减少或消除软件交付中的延迟。这可以实现更快的反馈和了解正在构建的内容，从而实现更快速的路线纠正。研究一致表明，部署频率更高且保持更短交付周期的组织，其绩效目标超出竞争对手的可能性是其两倍。3
缩短反馈循环——对执行的操作的响应速度和质量——对于改善 DevEx 同样重要。典型的开发者一天的工作由许多任务组成，这些任务依赖于来自工具和人员的反馈。例如，开发者可能会花费大量时间等待代码重新编译或测试运行。之后，他们可能需要等待代码审查人员的批准，这会阻碍他们取得进展。
快速的反馈循环使开发者能够以最小的摩擦快速完成工作。相比之下，缓慢的反馈循环会中断开发过程，导致开发者在等待或决定切换任务时感到沮丧和延迟。当来自系统（例如集成测试运行）或人员（例如审查注释）的反馈返回并需要立即关注时，缓慢的反馈循环会导致额外的中断。为了改善 DevEx，组织应通过识别可以加速开发工具的领域（例如，构建和测试流程、开发环境设置）或改进人工交接流程来缩短反馈循环。还应优化组织结构，以促进精简的团队互动，从而最大限度地减少延迟。
认知负荷
软件开发本质上是复杂的，而且不断增长的工具和技术数量进一步增加了开发者面临的认知负荷。认知负荷 涵盖了开发者执行任务所需的心理处理量。14 例如，当开发者处理本身就困难或复杂的任务，或者学习理解不熟悉的开发框架时，认知负荷通常会增加。认知负荷还根据外部信息的呈现方式而变化，当需要心理处理将信息转化为长期领域知识和模型时，认知负荷会增加。
认知负荷阻碍了开发者最重要的职责：为客户交付价值。当认知负荷因代码或系统文档不佳等问题而持续保持在高水平时，开发者需要投入额外的时间和精力来完成任务并避免错误。
为了改善开发者体验，团队和组织应致力于通过寻找方法来消除开发过程中不必要的障碍，从而降低认知负荷。应重点创建组织良好的代码和文档，既要方便开发者理解他们使用的系统，又要减少完成项目所需的上下文或任务切换量。专门的 DevEx 和平台团队应提供易于使用的自助式工具，以帮助开发者简化开发和发布步骤。
心流状态
开发者经常谈到“进入心流”或“进入状态”。这些说法通俗地描述了心流状态的概念，这是一种心理状态，在这种状态下，进行活动的人完全沉浸在充满活力的专注、全身心投入和享受的感觉中。1
在工作中频繁体验心流状态可以提高生产力、创新能力和员工发展。2 同样，研究表明，喜欢自己工作的开发者表现更好，并生产出更高质量的产品。8 中断和延迟——与反馈循环维度相关——是阻碍开发者体验心流状态的重要因素。10 其他因素包括保持对工作结构的自主权、拥有清晰的团队和项目目标，以及参与刺激和具有挑战性的任务。12
为了改善 DevEx，团队和组织应专注于为心流状态创造最佳条件。应通过集中安排会议、避免计划外工作和批量处理帮助请求来最大限度地减少干扰。领导者还应认识到，心流状态取决于创建积极的团队文化，为开发者提供自主权和从事有意义挑战的机会。
衡量 DevEx
想要改善 DevEx 的组织不可避免地面临着确定衡量什么以及如何衡量的挑战。衡量 DevEx 对于识别改进机会、检测趋势以及了解投资的影响至关重要。
衡量 DevEx 的关键是关注开发者及其在交付软件方面的实际体验。这包括工程系统的性能，以及使用和与这些系统交互的开发者的感知。协作和文化等社会因素也很重要。
与开发者生产力一样，开发者体验也不能简化为一个单一的指标或维度。5 通过认识到并使用多个维度来衡量 DevEx，团队和组织可以更好地了解人员和团队的工作方式，然后才能做出更好的决策。本节介绍了一个确定衡量内容的框架，然后提出了关于如何在组织中捕获 DevEx 指标的建议。
衡量什么
DevEx 的这三个维度为识别潜在的衡量领域提供了一个框架。准确衡量全面的开发者体验不仅需要捕捉开发者在这些维度上的感知和工作流程，还需要捕捉总体 KPI（关键绩效指标）或“北极星指标”，以把握全局。表 1 说明了这种方法，通过将全面的 KPI 指标与三个维度上的感知和工作流程指标的具体示例配对。接下来的两节将详细阐述感知指标和工作流程指标之间的差异，以及跟踪总体 KPI 的重要性。
感知指标与工作流程
衡量 DevEx 除了需要工程系统和流程的客观数据外，还需要捕捉开发者的感知——他们的态度、感受和意见。“开发者的声音”通过开发者自我报告的感知和体验，在 DevEx 的三个维度上提供直接信号。关于系统和流程的客观数据也提供了对摩擦领域的见解，以及关于如何改进的建议。
对感知指标和工作流程进行比较分析是必要的，因为两者都无法单独说明问题的全貌。例如，看似快速的代码审查周转时间，如果代码审查经常中断开发者的工作进度，仍然可能让开发者感觉具有破坏性。反例是，即使开发者对他们的构建流程感到满意，使用构建时间等客观指标也可能表明反馈循环比他们可能达到的速度更慢，开发工作流程的效率更低。
开发者通常担心领导者会误用或误解指标。衡量开发者的感知可以帮助领导者平衡围绕自上而下的开发者工作视图设计的指标。专注于开发者的实际体验可以确保领导者始终密切关注开发者面临的真正挑战。
KPI 的重要性
如前所述，开发者体验的三个维度受我们先前研究中确定的 25 个社会技术因素的影响。在捕捉这些维度时，应衡量各个方面，以识别开发者体验中可以采取行动和改进的具体领域（有关示例，请参见表 1）。
然而，仅关注各个因素，组织可能会失去对全局的把握，并在错误的领域进行投资。因此，组织还必须衡量更高层级的开发者体验 KPI，这些 KPI 可以作为 DevEx 计划的北极星指标。精心设计的 KPI 应衡量 DevEx 改进所关联并力求驱动的结果，包括生产力、满意度、敬业度和保留率。9
KPI 帮助组织设定战略重点，并了解其努力的全部影响。例如，减少团队会议可以改善与深度工作相关的开发者体验的各个因素。然而，减少会议也可能使同事之间的协作更加困难，从而损害总体满意度的 KPI。在本例中，关注 KPI 可能会引导团队采取策略来改善深度工作的时间，而不会同时降低满意度。
如何衡量
DevEx 应该通过捕捉开发者在各种系统和流程中的感知以及他们的工作流程来衡量，这些系统和流程涉及到他们的工作。为此，组织应收集来自人员和系统的数据，以便全面了解其软件交付流程。4
特别是调查，是衡量 DevEx 和捕捉开发者关于软件交付过程中摩擦点反馈的关键工具。调查数据可以快速收集（通常在几周内），并且如果设计正确，可以提供快速准确的衡量结果，以建立基线并指导改进工作。4
为了补充调查，组织还应收集来自系统的数据。然而，获取端到端系统数据可能很困难，需要跨不同的工具和团队进行工具化和数据规范化。11 在没有完全工具化的系统的情况下，组织可以使用调查来捕捉关于系统的自我报告信息（尽管精度和频率较低）。
鉴于调查在衡量过程中的重要性，本节的其余部分概述了组织进行调查的建议。这些建议来自我们在与数百家组织合作设计和实施 DevEx 调查方面的集体经验。
精心设计调查
设计不当的调查问题会导致结果不准确且不可靠。至少，调查问题应基于明确定义的结构，并在访谈中进行严格测试，以确保解释的一致性。6 如果可能，请咨询在调查开发方面具有丰富经验的专家。
按团队和角色细分结果
组织领导者常犯的一个错误是关注全公司范围的结果，而不是按团队和角色（例如，角色、任期、资历）细分的数据。如前所述，开发者体验具有高度的情境性，并且在不同的团队或角色之间可能差异很大。仅关注汇总结果可能会导致忽略影响公司内部小而重要的群体的问题，例如移动开发者。
将结果与基准进行比较
比较分析可以帮助情境化数据并帮助推动行动。例如，开发者对技术债务的情绪通常是负面的，这使得难以识别问题或衡量其规模。然而，情绪得分低于同行团队的团队以及得分低于行业竞争对手的组织，则标志着值得注意的改进机会。
混合使用事务性调查
事务性调查在开发者工作流程中的特定接触点或互动期间捕捉反馈。例如，平台团队可以使用事务性调查来提示开发者在安装 CLI（命令行界面）工具期间发生特定错误时提供反馈。事务性调查还可以通过产生更高频率的反馈和更细粒度的见解来补充定期调查的数据。
避免调查疲劳
许多组织努力维持调查的长期高参与率。缺乏后续行动通常会导致开发者认为反复回复调查并非值得的练习。因此，领导者和团队跟进调查至关重要。虽然季度或半年一次的调查频率对于大多数组织来说是最佳的，但对于某些组织来说，更频繁地进行调查可能会带来好处。
真实案例
eBay 和 Pfizer 这两家公司说明了他们在组织中对 DevEx 的关注如何在生产力方面产生影响。
eBay：加速开发者速度
作为全球电子商务领导者，eBay 一直在寻求新的方法，使软件交付成为其业务的竞争优势。
该公司正在开展一项为期多年的“速度计划”，重点是提高开发者生产力和体验。改善反馈循环和认知负荷是 eBay 的关键关注领域，其内部平台和 DevEx 组织负责收集问题领域的见解，以推动改进。
DevEx 团队通过季度调查来衡量开发者体验，这些调查捕捉总体开发者满意度和开发便利性等 KPI。他们的调查还捕捉开发者在日常工作不同领域的感知和工作流程。这些数据通过来自工程系统的实时见解和焦点小组讨论进行补充，以确定和实施具体的改进措施。
凭借这些见解，DevEx 团队领导了诸如修复组织中工具和文档差距、消除开发和发布的繁琐步骤和流程以及简化跨领域团队互动等举措。为了协助推广，DevEx 团队与特性团队紧密合作，并定期进行回顾、演示和培训课程。
eBay 在 DevEx 方面的投资继续推动开发者速度，并进一步加速在将软件交付确立为竞争优势方面取得进展。在过去一年中，改进使开发者能够以两倍的频率发布，并将部署交付周期缩短了六倍。
最重要的是，eBay 旨在确保开发者每天都对上班感到兴奋，并拥有他们需要的工具来产生出色的客户成果。
Pfizer：以光速实现突破
自从 Pfizer 在九个月内突破性开发出新冠病毒疫苗以来，该公司已开始走上改善 DevEx 的道路，以赋能开发者“以光速实现突破”。
Pfizer 的工程组织从 2018 年到 2022 年增长了近十倍，同时通过开源和云原生技术实现了软件交付能力的现代化。如今，Pfizer 的 DevEx 团队专注于寻找更多方法，通过改善开发者体验来帮助团队更快地交付。
尽管在高度监管的环境中运营，但 Pfizer 的领导者相信小型团队的好处，并赋能开发者成为富有创造力的组织力量。为了支持这一目标，DevEx 团队主要关注开发者体验的两个维度：反馈循环和心流状态。季度调查捕捉总体满意度和敬业度等 KPI，以及更具体的因素，如代码库质量和团队自主性。DevEx 团队不仅分析汇总结果以规划自己的计划，还为各个团队提供定制化的见解。
Pfizer 通过提供专门的时间和资源，赋能各个团队进行本地改进。为团队提供机会在其自身影响范围内解决改进问题，使 Pfizer 能够以比仅靠自上而下的努力快得多的速度进行转型。这种创新方法使 DevEx 团队能够管理企业范围内的计划，例如创建统一的开发者门户、减少跨团队代码重复以及改进源代码管理工具。
开始行动
这些框架为领导者提供了清晰的视角，了解应该衡量和关注什么来提高开发者生产力。DevEx 的三个维度——反馈循环、认知负荷和心流状态——共同构成了一个理解开发者体验的实用框架，而随附的衡量方法系统地指导改进。
组织应立即开始衡量开发者体验，即使他们尚未建立或计划正式的 DevEx 投资。衡量可以帮助成长中的组织发现和理解趋势，确定开始进行投资的正确时机，并驾驭宏观转变，例如远程工作和人工智能驱动的编程。
对于较小的组织和初创公司而言，DevEx 对于快速创新和寻找市场契合点至关重要。随着组织的发展，DevEx 通过提高工程效率、产品质量和员工保留率来推动业务绩效。虽然全面的开发者生产力仍然难以捕捉，但衡量和关注开发者体验提供了一条经过验证的途径，可以构建高性能的组织。
参考文献
1. Csikszentmihalyi, M. 2008. 心流：最优体验心理学。Harper Perennial Modern Classics。
2. Feldman, D. H., Csikszentmihalyi, M., Gardner, H. 1994. 改变世界：创造力研究框架。 Praeger Publishers/Greenwood Publishing Group。
3. Forsgren, N., Humble, J., Kim, G. 2018. 加速：精益软件和 DevOps 的科学：构建和扩展高性能技术组织。 IT Revolution Press。
4. Forsgren, N., Kersten, M. 2018. DevOps 指标。 通讯 61(4), 44-48; https://dl.acm.org/doi/10.1145/3159169。
5. Forsgren, N., Storey, M., Maddila, C., Zimmermann, T., Houck, B., Butler, J. 2021. 开发者生产力的 SPACE：比您想象的要多。 通讯 19(1), 20-48; https://dl.acm.org/doi/10.1145/3454122.3454124。
6. Fowler, F. 1995. 改进调查问卷：设计与评估。Sage Publications。
7. Gartner, Inc. 2022. IT 领导者技术采用路线图调查。
8. Graziotin, D., Fagerholm, F., Wang, X., Abrahamsson, P. 2018. 当软件开发者（不）快乐时会发生什么。系统与软件杂志 140, 32–47; https://www.sciencedirect.com/science/article/pii/S0164121218300323?via%3Dihub。
9. Greiler, M., Storey, M., Noda, A. 2022. 理解和改善开发者体验的可行框架。IEEE 软件工程汇刊; https://ieeexplore.ieee.org/document/9785882。
10. Janssens, S., Zaytsev, V. 2022. 进入心流：软件工程师与干扰。在第 25 届模型驱动工程语言和系统国际会议论文集：配套论文集, 934–38; https://dl.acm.org/doi/10.1145/3550356.3559101。
11. Jaspan, C., et al. 2020. 通过跨工具日志实现软件开发行为研究。IEEE 软件 37(6), 44–51; https://ieeexplore.ieee.org/document/9159122。
12. Nakamura, J., Csikszentmihalyi, M. 2009. 心流理论与研究。在 积极心理学牛津手册, ed. S. J. Lopez and C. R. Snider, 194–206; https://academic.oup.com/edited-volume/28153/chapter-abstract/212941827?redirectedFrom=fulltext。
13. Srivastava, S., Trehan, K., Wagle, D., Wang, J. 2020. 开发者速度：软件卓越性如何推动业务绩效。麦肯锡公司; https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance。
14. Sweller, J. 1988. 解决问题过程中的认知负荷：对学习的影响。认知科学 12(2), 257–85; https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1202_4。
Abi Noda 是 DX 的创始人兼首席执行官，他在那里领导公司的战略方向和研发工作。他的工作重点是开发衡量方法，以帮助组织改善开发者体验和生产力。在加入 DX 之前，Noda 曾在多家公司担任工程领导职务，并创立了 Pull Panda，该公司于 2019 年被 GitHub 收购。有关更多信息，请访问他的网站 abinoda.com。
Margaret-Anne Storey 是维多利亚大学计算机科学教授，并担任加拿大软件工程人文与社会方面研究主席。她的研究重点是改进软件工程中的流程、工具、沟通和协作。她担任 DX 的首席科学家，并为微软提供咨询，以提高开发者生产力。
Nicole Forsgren 是微软研究院的合伙人，她在那里领导 开发者速度实验室。她是获得 Shingo 出版奖的书籍 加速：精益软件和 DevOps 的科学 的主要作者。她在技术实践和开发方面的工作已在行业和学术期刊上发表，并用于指导全球范围内的组织转型。有关更多信息，请访问她的网站 nicolefv.com。
Michaela Greiler 是 DX 的研究主管，她的研究重点是开发者生产力和体验。她之前是苏黎世大学和微软研究院的研究员，在那里她专注于使用工程数据来帮助提高开发者生产力。她定期为公司提供关于如何改进其工程团队开发实践的咨询。
版权所有 © 2023 归所有者/作者所有。出版权已许可给 。
最初发表于 Queue 第 21 卷，第 2 期—
在 数字图书馆 中评论本文
更多相关文章
João Varajão, António Trigo - 评估 IT 项目成功：感知与现实
本研究通过提供关于 IT 项目成功的新见解，对实践、研究和教育具有重大意义。它通过报告项目成功（而不仅仅是项目管理成功），基于几个客观标准，例如项目后期阶段客户对可交付成果的使用情况、客户聘请项目相关的支持/维护服务、客户签订新项目以及客户向潜在客户推荐供应商，扩展了项目管理知识体系。研究人员可以找到一组标准，他们可以在研究和报告 IT 项目的成功时使用这些标准，从而扩展当前对评估的看法，并有助于得出更准确的结论。
Jenna Butler, Catherine Yeh - 设身处地为他人着想
新冠疫情改变了人们的许多工作方式，但许多结果本质上是自相矛盾的。对一个人有效的方法可能对另一个人无效（甚至对同一个人在第二天也无效），我们尚未弄清楚如何准确预测什么对每个人都有效。正如您在本文描述的复合角色中所看到的，有些人 struggle 与隔离和孤独作斗争，很难与他们的团队进行社交联系，或者发现混合工作与远程团队的时间压力令人难以承受。其他人则享受这种新发现的工作方式，享受更多与家人共处的时间、更大的白天锻炼灵活性、更好的工作/生活平衡以及为世界做出更大贡献的愿望。
Bridget Kromhout - 容器无法修复您支离破碎的文化（以及其他残酷的真相）
我们经常关注技术反模式，却忽略了我们社会结构内部的类似问题。剧透警告：许多看似技术难题的解决方案可以通过检查我们与他人的互动来找到。让我们来谈谈在与那些被称为人类的讨厌生物一起工作时，您需要了解的五件事。
© 保留所有权利。