PDF开发者生产力的 SPACE
其中包含的内容远超你想象。
Nicole Forsgren，GitHub
Margaret-Anne Storey，维多利亚大学
Chandra Maddila、Thomas Zimmermann、Brian Houck 和 Jenna Butler，微软研究院
开发者生产力是复杂且细致入微的，对软件开发团队具有重要的意义。清晰地理解开发者生产力的定义、衡量和预测，可以为组织、管理者和开发者提供能力，以更高效地创造更高质量的软件。
开发者生产力已被广泛研究。不幸的是，经过数十年的研究和实践开发经验，如何衡量生产力，甚至如何定义开发者生产力仍然难以捉摸，而关于这个话题的误解却很常见。团队或管理者常常试图用简单的指标来衡量开发者生产力，试图用“一个重要的指标”来概括一切。
一个重要的生产力衡量标准是个人感知；1 这可能与那些声称在高效的日子里处于“心流”状态的人产生共鸣。
人们也普遍认为，开发者生产力不仅对于改进工程成果是必要的，而且对于确保开发者的福祉和满意度也是必要的，因为生产力和满意度是错综复杂地联系在一起的。12,20
确保软件系统的有效开发和开发者的福祉从未像现在这样重要，因为 Covid-19 疫情已迫使全球大多数软件开发者在家工作， 17 使开发者和管理者与他们通常的工作场所和团队脱节。尽管这是出乎意料且不幸的，但这种变化构成了一种罕见的“自然实验”，统计学家可以利用它来研究、比较和理解不同背景下的开发者生产力。这种被迫的中断以及未来向混合远程/协作工作的过渡，加速了理解开发者生产力和福祉的需求，人们普遍认为，以高效和公平的方式做到这一点至关重要。
本文阐述了关于开发者生产力的几个常见误解和错误观念。揭示这些误解最重要的意义在于，生产力不能简化为一个单一的维度（或指标！）。 这些误解的普遍存在以及消除这些误解的必要性，促使我们开发了一个实用的多维度框架，因为只有通过审视一系列紧张关系中的指标，我们才能理解和影响开发者生产力。这个名为 SPACE 的框架捕捉了开发者生产力最重要的维度：满意度和福祉；绩效；活动；沟通和协作；以及效率和心流。通过认识到并使用多个维度而不仅仅是一个维度来衡量生产力，团队和组织可以更好地理解人员和团队的工作方式，并且可以做出更好的决策。
本文演示了如何使用此框架在实践中理解生产力，以及为什么使用它可以帮助团队更好地理解开发者生产力，创建更好的衡量标准来指导他们的工作和团队，并可能对工程成果和开发者福祉产生积极影响。
关于开发者生产力的误解和错误观念
多年来，积累了许多关于开发者生产力的误解。意识到这些错误观念有助于更好地理解如何衡量生产力。
误解：生产力完全取决于开发者的活动
这是最常见的误解之一，它可能导致不良结果和开发者不满。有时，活动量增加是由于多种原因造成的：工作时间延长可能表明开发者不得不“蛮力”工作以克服糟糕的系统或糟糕的计划，从而赶上预定义的发布时间表。另一方面，活动增加可能反映出更好的工程系统，为开发者提供了有效完成工作所需的工具，或者与团队成员更好的协作和沟通，以解除他们的变更和代码审查的阻塞。
仅凭活动指标无法揭示是哪种情况，因此绝不应单独使用它们来奖励或惩罚开发者。即使是诸如拉取请求数、提交数或代码审查数等简单的指标也容易因数据和测量误差而出现差距，并且报告这些指标的系统将错过结对编程或头脑风暴中所见的协作益处。最后，开发者经常会灵活调整工作时间以赶上截止日期，这使得某些活动指标难以依赖来评估生产力。
误解：生产力只关乎个人绩效
虽然个人绩效很重要，但为团队的成功做出贡献对于衡量生产力也至关重要。平衡开发者、团队和组织的绩效衡量标准非常重要。与团队运动类似，成功既要根据运动员的个人表现来判断，也要根据他们团队的成功来判断。一位只为自己的个人生产力优化的开发者可能会损害团队的生产力。更多以团队为中心的活动，如代码审查、随叫随到轮换以及开发和管理工程系统，有助于维护代码库和产品/服务的质量。在优化个人、团队和组织生产力方面找到正确的平衡，以及理解可能的权衡，是关键。
误解：一个生产力指标可以告诉我们一切
关于开发者生产力的一个常见误解是，它产生了一个通用的指标，并且这个“一个重要的指标”可以用来对团队的整体工作进行评分，并比较组织甚至行业内的团队。这不是真的。生产力代表了工作的几个重要维度，并且在很大程度上受到工作完成环境的影响。
误解：生产力指标仅对管理者有用
开发者经常说生产力指标没有用。这可能源于领导者或管理者对指标的误用，而且确实，当生产力衡量不当且实施不当时，可能会导致组织中的不当使用。生产力以这种方式被利用令人失望，但重要的是要注意到，开发者已经发现跟踪自己的生产力是有价值的——无论是出于个人原因还是为了与他人沟通。
通过记住开发者生产力是个人的，7 开发者可以利用它来深入了解他们的工作，以便他们可以掌控自己的时间、精力和日子。例如，研究表明，高生产力与对工作感到满意和快乐高度相关。12,20 寻找提高生产力的方法也是寻找在开发者的一天中引入更多乐趣并减少挫败感的方法。
误解：生产力只关乎工程系统和开发者工具
虽然开发者工具和工作流程对开发者生产力有很大影响，但诸如环境和工作文化等人为因素也具有重大影响。通常，保持环境和文化健康所需的关键工作对于组织中的许多成员或传统上用于衡量生产力的指标来说可能是“不可见的”。诸如士气建设、指导和知识共享等工作对于支持生产性的工作环境至关重要，但通常未被衡量。有益于团队整体生产力的“隐形”工作与其他更常衡量的维度同样重要。21
SPACE：理解开发者生产力的框架
生产力不仅仅关乎个人或工程系统；它不能仅通过单一指标或活动数据来衡量；而且它不仅仅是管理者关心的事情。开发 SPACE 框架是为了捕捉生产力的不同维度，因为没有它，前面提出的误解将继续存在。该框架提供了一种在更大的空间中理性思考生产力的方式，并以一种不仅揭示这些指标的含义，而且揭示它们单独使用或在错误的环境中使用时的局限性的方式来仔细选择指标。
满意度和福祉
满意度 是开发者对其工作、团队、工具或文化的满意程度；福祉 是他们的健康和快乐程度，以及他们的工作如何影响它。衡量满意度和福祉可能有利于理解生产力20，甚至可能预测生产力。15 例如，生产力和满意度是相关的，并且满意度有可能作为生产力的领先指标；满意度和敬业度的下降可能预示着即将到来的倦怠和生产力下降。13
例如，当许多地方在疫情期间转向强制居家办公时，某些生产力指标（例如，代码提交和合并拉取请求的速度）有所上升。8 然而，定性数据表明，有些人正在与他们的福祉作斗争。3 这突出了平衡衡量标准的重要性，这些标准捕捉了生产力的几个方面：虽然一些活动指标看起来是积极的，但额外的满意度衡量标准描绘了更全面的图景，表明生产力是个人化的，并且一些开发者正接近倦怠。为了应对这种情况，大型组织中的一些软件团队实施了“心理健康”日——本质上是免费的休息日，以帮助人们避免倦怠并改善福祉。
很明显，满意度和福祉是生产力的重要维度。这些品质通常最好通过调查来捕捉。为了评估满意度维度，您可以衡量以下内容
• 员工满意度。员工的满意程度，以及他们是否会向他人推荐他们的团队。
• 开发者效能。开发者是否拥有完成工作所需的工具和资源。
• 倦怠。由过度和长期的工作场所压力引起的精疲力竭。
绩效
绩效 是系统或过程的结果。软件开发者的绩效很难量化，因为很难将个人贡献直接与产品成果联系起来。产生大量代码的开发者可能没有生产高质量的代码。高质量的代码可能无法交付客户价值。令客户满意的功能可能并不总是能带来积极的业务成果。即使特定开发者的贡献可以与业务成果联系起来，但这也不总是绩效的反映，因为开发者可能被分配了影响力较小的任务，而不是有权选择更具影响力的工作。此外，软件通常是许多开发者贡献的总和，这加剧了评估任何个人开发者绩效的难度。在许多公司和组织中，软件是由团队而不是个人编写的。
由于这些原因，绩效通常最好评估为成果 而不是 产出。 软件开发者绩效最简化的观点可能是，开发者编写的代码是否可靠地完成了它应该做的事情？捕捉绩效维度的示例指标包括
• 质量。可靠性、无错误、持续的服务健康状况。
• 影响。客户满意度、客户采用率和留存率、功能使用率、成本降低。
活动
活动 是在执行工作过程中完成的行动或产出的计数。如果测量得当，开发者活动可以提供关于开发者生产力、工程系统和团队效率的有价值但有限的见解。由于开发者执行的活动复杂多样，他们的活动不易衡量或量化。事实上，几乎不可能全面衡量和量化工程系统和环境中的所有开发者活动方面。然而，一个精心设计的工程系统将有助于捕捉软件开发生命周期不同阶段的活动指标，并大规模量化开发者活动。一些相对容易测量和量化的开发者活动是
• 设计和编码。设计文档和规范、工作项、拉取请求、提交和代码审查的数量或计数。
• 持续集成和部署。构建、测试、部署/发布和基础设施利用率的计数。
• 运营活动。事件/问题的计数或数量以及基于其严重程度的分布、随叫随到参与和事件缓解。
这些指标可以用作衡量某些易于处理的开发者活动的航点，但由于其已知的局限性，绝不应单独使用它们来对个人或团队生产力做出决策。它们充当起点的模板，应根据组织需求和开发环境进行定制。如前所述，许多对于开发软件至关重要的活动是难以处理的（例如，参加团队会议、参与头脑风暴、在团队成员遇到问题时帮助他们以及提供架构指导，仅举几例）。
沟通和协作
沟通和协作 捕捉了人员和团队如何沟通和协同工作。软件开发是一项协作和创造性的任务，它依赖于团队内部和团队之间广泛而有效的沟通、协调和协作。11 成功地贡献和整合彼此工作的有效团队依赖于团队成员活动和任务优先级的 高透明度5 和意识6 。此外，信息在团队内部和团队之间如何流动会影响有效对齐和整合工作所需的文档的可用性和可发现性。多元化和包容性的团队表现更高。22 更有效的团队处理正确的问题，更有可能成功地集思广益新想法，并将从所有备选方案中选择更好的解决方案。
有助于团队成果或支持其他团队成员生产力的工作可能会以牺牲个人的生产力以及他们进入心流状态的能力为代价，从而可能降低动力和满意度。然而，有效的协作可以减少对某些个人活动的需求（例如，不必要的代码审查和返工），提高系统性能（更快的拉取请求合并可以通过避免错误来提高质量），并有助于维持生产力并避免（或者相反，如果做得不好，则会增加）倦怠。
然而，理解和衡量团队生产力和团队成员期望是复杂的，因为存在难以衡量的项目，例如隐形工作21 和用于协调和计划团队任务的阐述工作18 。也就是说，以下是一些可用作衡量沟通、协作和协调的代理指标的示例
• 文档和专业知识的可发现性。
• 工作整合的速度。
• 对团队成员贡献的工作的审查质量。
• 显示谁与谁以及如何连接的网络指标。
• 新成员的入职时间和体验。
效率和心流
最后，效率 和 心流 捕捉了以最少的中断或延迟完成工作或取得进展的能力，无论是个人还是通过系统。这可以包括团队内部和团队之间的活动如何协调，以及是否正在取得持续进展。
一些研究将生产力与以最少的干扰或中断完成复杂任务的能力联系起来。2 当许多开发者谈论在工作中“进入心流”时，或者在寻找和优化心流时遇到的困难时，都会呼应这种生产力概念——许多书籍和讨论都在探讨如何在可控的方式下实现这种积极状态。4 对于个人效率（心流），重要的是设置界限以变得高效并保持高效——例如，通过为专注时段划分时间。个人效率通常通过不间断的专注时间或在创造价值的应用程序中的时间来衡量（例如，开发者在集成开发环境中花费的时间很可能被认为是“生产性”时间）。
在团队和系统层面，效率与价值流映射相关，价值流映射捕捉了将软件从想法和创建到交付给最终客户所需的步骤。为了优化价值流中的流动，重要的是最大限度地减少延迟和交接。DORA（DevOps 研究和评估）框架引入了几个指标来监控团队内部的流动9——例如，部署频率衡量组织成功发布到生产环境的频率，而变更前导时间衡量提交进入生产环境所需的时间。
除了系统中的变更流动之外，知识和信息的流动也很重要。效率和心流的某些方面可能难以衡量，但通常可以发现并消除价值流中的低效率。对客户或用户没有产生价值的活动通常被称为软件开发浪费19——例如，重复工作、因工作未正确完成而导致的返工或耗时的重复性活动。
一些捕捉效率和心流维度的示例指标是
• 流程中的交接次数；流程中跨不同团队的交接次数。
• 感知到的保持心流和完成工作的能力。
• 中断：数量、时间、间隔、对开发工作和心流的影响。
• 通过系统的时间衡量：总时间、增值时间、等待时间。
效率与 SPACE 的所有维度相关。 已发现个人、团队和系统层面的效率与满意度提高呈正相关。然而，更高的效率也可能对其他因素产生负面影响。例如，最大化流动和速度可能会降低系统质量并增加客户可见的错误数量（绩效）。通过减少中断来优化个人效率可能会降低协作能力，阻碍他人的工作，并降低团队集思广益的能力。
框架的应用
为了说明 SPACE 框架，图 1 列出了属于五个维度中每个维度的具体指标。该图提供了个人、团队或小组以及系统层面衡量标准的示例。以下是关于这些指标的三个简短讨论：首先，展示了一组关于代码审查的指标示例，根据它们的定义和代理方式，涵盖了 SPACE 框架的所有维度。接下来，为框架的两个选定维度提供了更多示例：活动以及效率和心流。本节以关于如何使用框架的讨论结尾：结合指标以全面理解开发者生产力，以及注意事项。随附的侧边栏展示了如何使用该框架来理解事件管理中的生产力。
让我们从代码审查开始，作为一个示例场景，它展示了一组指标，这些指标可以根据其框架方式和使用的指标，涵盖 SPACE 框架的所有五个维度
• 满意度。关于代码审查的感知衡量标准可以揭示开发者是否以好的或坏的角度看待这项工作——例如，如果它们代表学习、指导或塑造代码库的机会。这很重要，因为每个开发者的代码审查数量可能表明不满，如果一些开发者觉得他们一直被分配不成比例的代码审查量，从而减少了他们用于其他工作的时间。
• 绩效。代码审查速度捕捉了审查的速度；因为这既可以反映个人完成审查的速度，也可以反映团队的约束，所以它既是个人层面又是团队层面的指标。（例如，个人可以在被分配审查后一小时内完成审查，但团队可能会制定一项政策，将所有审查开放 24 小时，以便所有团队成员都能看到建议的更改。）
• 活动。已完成的代码审查数量是一个个人指标，捕捉了在给定时间范围内已完成的审查数量，并为最终产品做出了贡献。
• 沟通和协作。代码审查本身是开发者通过代码进行协作的一种方式，而代码审查的质量或周全性的衡量或评分是对协作和沟通的极佳定性衡量标准。
• 效率和心流。代码审查很重要，但如果它中断工作流程或延迟导致系统受限，则可能会造成挑战。同样，必须等待代码审查可能会延迟开发者继续工作的能力。批量处理代码审查，使其不会中断开发者的编码时间（这将影响个人衡量标准），同时也不会导致系统吞吐量延迟（这将影响系统衡量标准），这使得团队能够高效地交付代码（团队层面衡量标准）。因此，衡量代码审查时间对个人、团队和系统的效率和心流的影响非常重要——这可以通过捕捉完成审查的时间和中断特征（如时间和频率）的感知或遥测措施来完成。
让我们通过进一步研究（1）活动和（2）效率和心流的维度来更深入地研究 SPACE 框架。在本例中，活动衡量标准是个人层面指标：提交数量、编码时间（总花费时间或一天中的时间）以及已完成的代码审查数量。这些最好地描述了直接为最终产品做出贡献的工作，并理解工作模式和行为受开发者工作的团队和环境的影响。
效率和心流具有更广泛的指标组合。自我报告的生产力衡量标准最好在个人层面捕捉：询问开发者团队是否高效可能会有盲点，而询问该成员是否感到高效或是否能够在最少干扰的情况下完成工作是一个有用的信号。您还可以衡量工作流——无论是代码、文档还是其他项目——通过系统的流动，并捕捉诸如所需时间或软件交付管道中的交接次数、延迟和错误等指标。这些将构成系统层面指标，因为它们的值将捕捉工作项通过整个工作流程或系统的旅程。
如何使用框架
为了衡量开发者生产力，团队和领导者（甚至个人）应捕捉框架多个维度中的几个指标——建议至少三个。例如，如果您已经衡量了提交（活动衡量标准），请不要简单地将拉取请求数量和编码时间添加到您的指标仪表板，因为这些都是活动指标。添加这些可以帮助完善您捕捉生产力的活动维度的方式，但要真正理解生产力，请至少添加来自两个不同维度的指标：也许是生产力的感知和拉取请求合并时间。
另一个建议是，至少有一个指标包括诸如调查数据之类的感知衡量标准。通过纳入关于人们生活经历的看法，可以构建更完整的生产力图景。很多时候，感知数据可能提供比仅从仪器化系统行为中观察到的更准确和完整的信息。10
纳入来自多个维度和测量类型的指标通常会产生紧张关系中的指标；这是故意的，因为平衡的观点提供了对您的工作和系统中正在发生的事情的更真实的描述。这种更平衡的观点应有助于加强团队成员之间更明智的决策和权衡，否则团队成员可能会理所当然地专注于工作的某一方面，而损害整个系统。
一个例子是故事点，这是一个在敏捷开发过程中常用的指标，用于评估团队层面的进展。如果一个团队仅根据故事点进行评级，则成员将专注于优化自己的点数，从而损害完成可能对其他开发者的进步和公司重要的隐形工作，如果这意味着与其他团队合作或指导未来的开发者。如果领导者在不询问开发者快速工作能力的情况下使用故事点来衡量进度，他们将无法识别是否有任何问题，团队是否在进行变通和倦怠，或者一项新的创新是否特别有效，并且可以用来帮助可能正在挣扎的其他团队。
这引出了关于指标及其对团队和组织的影响的一个重要观点：它们表明什么是重要的。间接了解组织中什么重要的一种方法是查看衡量了什么，因为这通常传达了什么是有价值的，并影响人们的行为和反应方式。例如，关心员工健康、福祉和留任率的公司很可能会在其生产力衡量标准中纳入满意度和福祉维度。作为推论，添加或删除指标可以引导行为，因为这也传达了什么是重要的。
例如，一个“生产力 = 代码行数”的团队与一个“生产力 = 代码行数 AND 代码审查质量 AND 客户满意度”的团队截然不同。在这种情况下，您保留了一个关于生产力和产出的（有问题的，但可能已嵌入的）指标，但将关于生产力的看法引导到也重视团队合作（通过重视周到的代码审查）和最终用户（通过重视客户满意度）的方向。
指标塑造行为，因此，通过添加和重视仅仅两个指标，您就帮助塑造了团队和组织的变化。这就是为什么务必从框架的多个维度中提取指标如此重要的原因：它将在团队和系统层面带来更好的结果。在本例中，随着团队继续改进和迭代，他们可以将活动指标代码行数 替换为提交数量 之类的指标。
注意事项
指标过多也可能导致困惑和动力降低；并非所有维度都需要包含在内，框架才能发挥作用。例如，如果向开发者和团队展示一个广泛的指标和改进目标列表，那么实现这些目标可能会让人感到遥不可及。考虑到这一点，请注意，良好的生产力衡量标准由至少三个维度中的少量指标组成；这些指标可以促进全面的视角，并且它们足以引发改进。
任何测量范式都应谨慎使用，因为没有哪个指标可以永远是完美的代理。有些指标是糟糕的衡量标准，因为它们是嘈杂的近似值（图 1 中注明了一些示例）。留任率通常用于衡量员工满意度；然而，这可以捕捉到比满意度更多的东西——它可以反映薪酬、晋升机会、团队问题，甚至是伴侣的搬迁。在团队层面，一些管理者可能会阻止调动以保护自己的留任率评级。即使留任率确实反映了满意度，它也是一个滞后指标，团队在为时已晚时才看到转变。我们已经在其他地方写过关于故事点使用中固有的局限性，9 这可能会激励团队专注于自己的工作，而牺牲在重要项目上进行协作。
团队和组织应意识到开发者隐私，并且仅报告团队或小组层面的匿名化汇总结果。（在某些国家/地区，报告个人生产力是不合法的。）然而，个人层面的生产力分析可能对开发者有启发意义。例如，之前的研究表明，典型的开发者工作转变取决于开发阶段，并且开发者可能在一天中的某些时间更有效率。14 开发者可以选择参与这些类型的分析，从而获得有价值的见解来优化他们的一天并管理他们的精力。
最后，任何测量范式都应检查偏差和规范。这些是可能改变或影响衡量标准的外部影响。此处包含一些示例，但它们并非详尽无遗，因此鼓励所有团队寻找并思考可能存在于其数据中的外部影响
• 同行评审和性别。研究表明，女性在代码审查中更可能收到负面评论，而不太可能收到正面评论。16 对审查过程满意度的任何分析都应在您的环境中检查这一点。理解开发者很可能受到更广泛的科技行业的影响，即使这些模式不在您的组织或团队中。考虑这些影响。
• 跨时间标准化衡量标准。团队应谨慎对待任何用于标准化时间的方法，尤其是在较长时期内。例如，查看一年以上的指标会偏向于休育儿假的人。
• 感知度量。团队和组织应注意文化规范，并拥抱这些规范。有些文化自然倾向于报告较高值，而有些则倾向于报告较低值。这并不意味着感知度量不可信；这仅仅意味着来自不同文化的度量将具有不同的基线，不应彼此比较。
SPACE 和 SRE：事件管理中的框架
SPACE 框架与 SRE（站点可靠性工程师）及其在 IM（事件管理）中的工作相关。当服务不可用或未按 SLA（服务级别协议）中的定义执行时，就会发生事件。事件可能由网络问题、基础设施问题、硬件故障、代码错误或配置问题等引起，仅举几例。
根据事件造成的影响程度，通常会为其分配严重级别（sev-1 为最高级别）。对整个组织的面向客户的系统的中断与一小部分内部用户在电子邮件传递中遇到延迟的处理方式不同。
以下是一些与 IM 相关的常见误解
• 误解：个人解决的事件数量是唯一重要的。与 SDLC（软件开发生命周期）中的许多其他活动一样，IM 是一项团队活动。导致大量中断并需要更多时间恢复的服务，会给开发和维护该服务的整个团队带来负面影响。更侧重于团队的活动，例如知识共享、准备故障排除指南以帮助其他团队成员、指导初级和新团队成员、做好交接和分配/重新分配，都是 IM 的重要方面。
• 误解：孤立地查看一个指标会告诉你一切。重要的是要理解指标的背景：事件的数量、解决它们所花费的时间——sev-1 事件与 sev-4 事件的数量和解决时间，以及其他与理解事件以及如何改进系统和团队响应相关的因素。因此，不存在“唯一重要的指标”。
• 误解：只有管理层关心事件量和满足 SLA。随着 DevOps 的兴起，开发人员现在也在进行运维工作。如果事件的数量和严重性很高，IM（运维的一部分）可能会占用开发人员大量的时间和精力。对于管理层和高管而言，保证 SLA 以及减少事件量和解决时间非常重要，对于参与 IM 流程的个别开发人员而言，同样重要。
• 误解：有效的 IM 仅仅是改进系统和工具。更好的监控系统、工单系统、案例路由系统、日志分析系统等将有助于提高开发人员的生产力。虽然工具、指南和工作流程对生产力有很大影响，但环境和工作文化的人为因素也具有重大影响。指导团队新成员和鼓舞士气非常重要。如果开发人员在 Covid-19 期间在家工作时，经常在晚上因 sev-1 事件而被呼叫，那么这些“隐形”因素对于提高他们的生产力尤其有帮助。
事件管理是一个复杂的过程，涉及各种利益相关者执行多项个人和团队活动，并且需要来自不同工具和系统的支持，因此，识别可以捕捉生产力各个维度的指标至关重要
• Satisfaction（满意度）：SRE 对 IM 流程、升级和路由以及轮班安排的满意度是需要捕捉的关键指标，尤其是在 SRE 中倦怠是一个重要问题的情况下。
• Performance（绩效）：这些度量侧重于系统可靠性；监控系统更快地检测和标记问题的能力，在问题影响客户并成为事件之前。MTTR（平均修复时间）总体而言，以及按严重程度划分。
• Activity（活动）：监控系统捕获的问题数量、创建的事件数量、已解决的事件数量——以及它们的严重程度分布。
• Communication and collaboration（沟通与协作）：参与解决事件的人员、这些人来自多少个团队，以及他们在事件期间如何沟通。事件解决文档概述了解决事件所涉及的步骤；这可以通过完整性（检查是否输入了任何解决数据）或快速质量评分（例如，赞/踩）来衡量。团队还可以包含一个指标，用于衡量引用这些指南和文档解决的事件的百分比。
• Efficiency and flow（效率和流程）：事件交接、事件分配/重新分配、事件在分配给正确个人或团队之前必须经历的跳数。
为何现在至关重要
开发人员的生产力不仅仅关乎个人的活动水平或依赖于交付软件的工程系统的效率，它不能用单一指标或维度来衡量。我们开发了 SPACE 框架来捕捉生产力的不同维度，因为没有它，关于生产力的普遍存在且可能有害的误解可能会持续存在。
SPACE 框架提供了一种逻辑且系统地思考更大空间中的生产力的方式，并仔细选择与目标相关的平衡指标——以及如果单独使用或在错误的上下文中使用，它们可能受到的限制。该框架有助于阐明可能不立即显现的权衡，并考虑到隐形工作和变更的连锁反应，例如，如果以牺牲不满意的开发人员或中断整体流程和效率为代价来衡量活动，则工作量会增加。
全面理解和衡量生产力的需求从未如此迫切。随着 Covid-19 大流行扰乱了工作，并突然转向在家工作，许多人质疑它对生产力的影响，并提出了关于如何理解和衡量这种变化的问题。随着世界缓慢恢复到“新常态”，SPACE 框架捕捉了在提出和进行未来变更时需要考虑的生产力维度。该框架旨在帮助个人、团队和组织识别相关的指标，这些指标可以全面地呈现生产力状况；这将促成关于生产力的更周全的讨论，并促成更具影响力的解决方案的设计。
致谢
我们感谢审稿人的周到审阅和深刻见解的评论，并确信纳入他们的注释和回应已加强了本文。我们很高兴它能在 acmqueue 上发表。
参考文献
1. Beller, M., Orgovan, V., Buja, S., Zimmermann, T. 2020. Mind the gap: on the relationship between automatically measured and self-reported productivity. IEEE Software; https://arxiv.org/abs/2012.07428.
2. Brumby, D. P., Janssen, C. P., Mark, G. 2019. How do interruptions affect productivity? In Rethinking Productivity in Software Engineering, ed. C. Sadowski and T. Zimmermann, 85-107. Berkeley, CA: Apress; https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_9.
3. Butler, J. L., Jaffe, S. 2020. Challenges and gratitude: a diary study of software engineers working from home during Covid-19 pandemic (August). Microsoft; https://www.microsoft.com/en-us/research/publication/challenges-and-gratitude-a-diary-study-of-software-engineers-working-from-home-during-covid-19-pandemic/.
4. Csikszentmihalyi, M. 2008. Flow: The Psychology of Optimal Experience. Harper Perennial Modern Classics.
5. Dabbish, L., Stuart, C., Tsay, J., Herbsleb, J. 2012. Social coding in GitHub: transparency and collaboration in an open software repository. In Proceedings of the 2012 Conference on Computer-supported Cooperative Work (February), 1277-1286; https://dl.acm.org/doi/10.1145/2145204.2145396.
6. Dourish, P., Bellotti, V. 1992. Awareness and coordination in shared workspaces. In Proceedings of the 1992 Conference on Computer-supported Cooperative Work (December), 107-114; https://dl.acm.org/doi/10.1145/143457.143468.
7. Ford, D., Storey, M. A., Zimmermann, T., Bird, C., Jaffe, S., Maddila, C., Butler, J. L., Houck, B., Nagappan, N. 2020. A tale of two cities: software developers working from home during the Covid-19 pandemic; https://arxiv.org/abs/2008.11147.
8. Forsgren, N. 2020. Finding balance between work and play. The 2020 State of the Octoverse . GitHub; https://octoverse.github.com/static/github-octoverse-2020-productivity-report.pdf.
9. Forsgren, N., Humble, J. Kim, G. 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press.
10. Forsgren, N., Kersten, M. 2018. DevOps metrics. Communications of the 61(4), 44-48; https://dl.acm.org/doi/10.1145/3159169.
11. Fuks, H., Raposo, A., Gerosa, M. A., Pimental, M. 2008. The 3C collaboration model. In Encyclopedia of E-Collaboration, ed. Ned Kock, 637-644. IGI Global; https://www.researchgate.net/publication/292220266_The_3C_collaboration_model.
12. Graziotin, D., Fagerholm, F. 2019. Happiness and the productivity of software engineers. In Rethinking Productivity in Software Engineering, ed. C. Sadowski and T. Zimmermann, 109-124. Berkeley, CA: Apress; https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_10.
13. Maslach, C., Leiter, M. P. 2008. Early predictors of job burnout and engagement. Journal of Applied Psychology 93(3), 498-512; https://doi.apa.org/doiLanding?doi=10.1037%2F0021-9010.93.3.498.
14. Meyer, A. N., Barton, L. E., Murphy, G. C., Zimmermann, T., Fritz, T. 2017. The work life of developers: activities, switches and perceived productivity. IEEE Transactions on Software Engineering 43(12), 1178-1193; https://dl.acm.org/doi/10.1109/TSE.2017.2656886.
15. Murphy-Hill, E., Jaspan, C., Sadowski, C., Shepherd, D., Phillips, M., Winter, C., Knight, A., Smith, E., Jorde, M. 2019. What predicts software developers' productivity? IEEE Transactions on Software Engineering; https://ieeexplore.ieee.org/document/8643844/.
16. Paul, R., Bosu, A., Sultana, K. Z. 2019. Expressions of sentiments during code reviews: male vs. female. In IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER) , 26-37; https://ieeexplore.ieee.org/document/8667987.
17. Ralph, P., et al. 2020. Pandemic programming: How Covid-19 affects software developers and how their organizations can help. Empirical Software Engineering 25(6), 4927-4961; https://www.researchgate.net/publication/344342621_Pandemic_programming_How_COVID-19_affects_software_developers_and_how_their_organizations_can_help.
18. Schmidt, K., Bannon, L. 1992. Taking CSCW seriously: supporting articulation work. Computer Supported Cooperative Work 1(1), 7-40; https://link.springer.com/article/10.1007/BF00752449 .
19. Sedano, T., Ralph, P., Péraire, C. 2017. Software development waste. In Proceedings of the 39th International Conference on Software Engineering , 130-140; https://dl.acm.org/doi/10.1109/ICSE.2017.20.
20. Storey, M. A., Zimmermann, T., Bird, C., Czerwonka, J., Murphy, B., Kalliamvakou, E. 2019. Towards a theory of software developer job satisfaction and perceived productivity. IEEE Transactions on Software Engineering; https://ieeexplore.ieee.org/document/8851296.
21. Suchman, L. 1995. Making work visible. Communications of the 38(9), 56-64; https://dl.acm.org/doi/10.1145/223248.223263.
22. Vasilescu, B., Posnett, D., Ray, B., van den Brand, M. G. J., Serebrenik, A., Devanbu, P., Filkov, V. 2015. Gender and tenure diversity in GitHub teams. In Proceedings of the 33rd Annual Conference on Human Factors in Computing Systems (April), 3789-3798; https://dl.acm.org/doi/abs/10.1145/2702123.2702549.
Nicole Forsgren 是 GitHub 的研究与战略副总裁。她是 DevOps 领域的专家，也是获得新乡出版奖的书籍 Accelerate: The Science of Lean Software and DevOps 的作者。她在技术实践和开发方面的工作已在行业和学术期刊上发表，并被用于指导全球范围内的组织转型。
Margaret-Anne Storey 是维多利亚大学计算机科学教授，也是加拿大软件工程人文与社会方面研究主席。她的研究重点是改进软件工程流程、工具、软件工程中的沟通与协作。她与微软合作，以提高开发人员的生产力。
Chandra Maddila 是微软研究院的高级研究工程师。他的研究重点是利用机器学习和 AI 改进开发人员的生产力和软件工程流程。他开发的工具和技术已在整个微软组织范围内使用，并在 USENIX OSDI 获得了最佳论文奖，并已在 VentureBeat 等科技期刊上发表。
Thomas Zimmermann 是微软研究院的首席研究员。他的研究使用定量和定性方法来提高软件生产力，并调查和克服软件工程挑战。他以其在软件仓库挖掘和软件工程中的数据科学方面的工作而闻名，并获得了多项最具影响力的论文奖。
Brian Houck 是微软 Azure 工程系统部门的首席项目经理。他的工作重点是通过改进开发人员工具、开发流程和团队文化，来提高 Azure 组织内工程师的开发人员生产力和满意度。
Jenna Butler 拥有计算机科学博士学位，专攻生物信息学。她是贝尔维尤学院放射治疗系的兼职教授，也是微软的高级软件工程师。最近，Jenna 一直与 MSR 的生产力与智能 (P+I) 团队合作，研究对齐和决策制定；在服务部门工作；以及在此期间远程工作的影响。Jenna 最喜欢可以造福福祉和健康，同时最大限度地提高生产力的多学科工作。
相关文章
衡量什么得到什么 在项目管理中使用软件指标的四个常见陷阱。Eric Bouwers、Joost Visser 和 Arie van Deursen https://queue.org.cn/detail.cfm?id=2229115
DevOps 指标 您最大的错误可能是收集了错误的数据。Nicole Forsgren 和 Mik Kersten https://queue.org.cn/detail.cfm?id=3182626
超越“修复”的跑步机 高绩效组织中事件后工件的使用。J. Paul Reed https://queue.org.cn/detail.cfm?id=3380780
人员和流程 最大限度地减少业务流程变更的痛苦。James Champy https://queue.org.cn/detail.cfm?id=1122687
版权 © 2021 由所有者/作者持有。出版权已许可给 。
本作品根据 Creative Commons Attribution-ShareAlike International 4.0 许可协议获得许可。
最初发表于 Queue vol. 19, no. 1—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。加密哈希存在许多由各种安全需求驱动的标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx in Action
DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者在财政紧缩和人工智能等变革性技术的背景下寻求优化软件交付。技术领导者凭直觉接受，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议计划和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的步伐中，它容易受到时尚潮流的影响，并且可能会忘记或忽略已证实的解决其面临的一些永恒问题的解决方案。用例于 1986 年首次引入，后来普及开来，就是这些经过验证的解决方案之一。
© 保留所有权利。