ACM通信
实践
开发者生产力的空间
图片来源:Nattakorn Maneerat
开发人员的生产力是复杂而微妙的，对软件开发团队有着重要的影响。对定义、度量和预测开发人员生产力的清晰理解，可以为组织、管理人员和开发人员提供制作更高质量软件的能力——并使其更有效。
开发人员生产力已经得到了广泛的研究。不幸的是，经过几十年的研究和实际开发经验，知道如何度量生产力甚至定义开发人员的生产力仍然是难以捉摸的，而关于这个主题的神话是常见的。团队或管理人员常常试图用简单的度量标准来衡量开发人员的生产力，试图用“一个重要的度量标准”来捕获它。
衡量生产力的一个重要指标是个人感知;1这可能与那些声称在高效的日子里处于“流动”状态的人产生共鸣。
还有一个共识是，开发人员的生产力不仅是提高工程成果的必要条件，而且是确保开发人员的福祉和满意度的必要条件，因为生产力和满意度是复杂地联系在一起的。12，20.
确保软件系统的高效开发和开发人员的福祉从未像现在这样重要，因为Covid-19大流行迫使全球大多数软件开发人员在家工作，17将开发人员和管理人员从他们通常的工作场所和团队中分离出来。尽管这是意料之外和不幸的，但这个变化构成了一个罕见的“自然实验”，统计学家可以利用它来研究、比较和理解许多不同环境下的开发人员生产力。这种强制的中断和未来向混合远程/协同工作的过渡加快了了解开发人员生产力和健康状况的需要，人们普遍认为，以高效和公平的方式这样做是至关重要的。
本文阐述了关于开发人员生产力的几个常见误区和误解。从揭露这些神话中得到的最重要的收获是，生产力不能被简化为单一维度(或度量!)这些神话的流行和打破它们的需要激励我们开发一个实际的多维框架，因为只有通过检查一系列紧张的度量，我们才能理解和影响开发人员的生产力。这个名为SPACE的框架捕获了开发人员生产力的最重要维度:满意度和福祉;性能;活动;沟通与协作;效率和流程。通过用不仅仅是一个维度来识别和度量生产力，团队和组织可以更好地理解人和团队是如何工作的，并且他们可以做出更好的决策。
本文演示了该框架如何在实践中用于理解生产力，以及为什么使用它将帮助团队更好地理解开发人员的生产力，创建更好的度量来通知他们的工作和团队，并可能积极地影响工程结果和开发人员的福祉。
关于开发人员生产力的神话和误解
多年来积累了许多关于开发人员生产力的神话。认识到这些错误观念会使我们更好地理解衡量生产力的方法。
误解:生产力是开发人员活动的全部。这是最常见的误区之一，它会导致不希望的结果和开发人员的不满。有时，更高的活动量是由于各种原因而出现的:工作时间更长可能意味着开发人员不得不“强行”工作以克服糟糕的系统或糟糕的计划，以满足预定义的发布计划。另一方面，增加的活动可能反映了更好的工程系统，为开发人员提供了他们需要的工具，以有效地完成他们的工作，或者更好地与团队成员进行协作和交流，以解除他们的更改和代码评审的障碍。
单独的活动指标并不能揭示这些情况，所以它们不应该被孤立地用于奖励或惩罚开发者。即使是直接的指标，如拉请求、提交或代码审查的数量，也容易出现错误，因为数据和测量错误存在差距，而报告这些指标的系统将错过在对等编程或头脑风暴中看到的协作的好处。最后，开发人员经常调整他们的工作时间以满足最后期限，使得某些活动度量在评估生产力时难以依赖。
谬论:生产力只与个人表现有关。虽然个人表现很重要，但团队的成功与否也是衡量生产力的关键。平衡开发人员、团队和组织的性能度量非常重要。与团队运动类似，比赛的成功既取决于运动员的个人表现，也取决于团队的成功。一个只为自己的生产力优化的开发人员可能会损害团队的生产力。更多以团队为中心的活动，如代码评审、随叫随到的轮换，以及开发和管理工程系统，有助于维护代码库和产品/服务的质量。在优化个人、团队和组织的生产力中找到正确的平衡，以及理解可能的权衡，这是关键。
谬论:一个生产力指标可以告诉我们一切。关于开发人员生产力的一个常见误解是，它产生了一个通用的度量标准，并且这个“重要的度量标准”可以用于对团队的整体工作进行评分，并在整个组织甚至整个行业中比较团队。这不是真的。生产力代表了工作的几个重要方面，并且在很大程度上受到工作环境的影响。
误区:生产力测量方法只对管理者有用。开发人员经常说生产力度量是没有用的。这可能来自领导者或管理者对措施的滥用，当生产力没有得到很好的衡量和执行时，它可能会导致组织中不恰当的使用。以这种方式采用生产力是令人失望的，但重要的是要注意，开发人员已经发现跟踪他们自己的生产力的价值——出于个人原因和与他人的交流。
记住开发人员的生产力是个人的，7开发人员可以利用它来了解他们的工作，这样他们就可以控制自己的时间、精力和天数。例如，研究表明，高效率与工作的满足感和幸福感高度相关。12，20.找到提高生产力的方法，也就是找到在开发人员的一天中引入更多快乐和减少挫折的方法。
误区:生产力只与工程系统和开发人员工具有关。虽然开发人员工具和工作流对开发人员的生产力有很大的影响，但环境和工作文化等人为因素也有很大的影响。通常，保持环境和文化健康所需的关键工作对于组织的许多成员或传统上用于衡量生产力的指标来说是“看不见的”。诸如士气建设、指导和知识分享等工作对于支持一个高效的工作环境都是至关重要的，但往往没有被衡量。有益于团队整体生产力的“无形”工作与其他更常见的度量维度一样重要。21
空间:理解开发者生产力的框架
生产力不仅仅关乎个人或工程系统;它不能仅通过单一指标或活动数据来衡量;这并不是只有管理者才关心的事情。开发SPACE框架是为了捕捉生产力的不同维度，因为没有它，刚才提出的神话将继续存在。该框架提供了一种在更大的空间中理性思考生产力的方法，并以一种不仅揭示这些度量的含义，而且在单独使用或在错误的上下文中显示它们的局限性的方式仔细选择度量。
满足和幸福。满意度是开发人员对他们的工作、团队、工具或文化的满足感;幸福就是他们的健康和快乐程度，以及他们的工作对健康和快乐的影响。测量满意度和幸福感有助于理解生产力20.甚至可以用来预测。15例如，生产力和满意度是相关的，满意度有可能作为生产力的领先指标;满意度和敬业度的下降可能预示着即将到来的精疲力竭和工作效率的降低。13
例如，当许多地方在大流行期间被迫在家工作时，一些生产率指标(例如，代码提交和合并拉请求的速度)出现了上升。8然而，定性数据显示，有些人正在为幸福而挣扎。3.这突出了捕捉生产力的几个方面的平衡度量的重要性:虽然一些活动度量看起来是积极的，但是额外的满意度度量描绘了一个更全面的画面，显示生产力是个人的，一些开发人员正在接近精疲力竭。为了解决这个问题，一些大型组织的软件团队实施了“心理健康”日——本质上是免费的休息日，帮助人们避免倦怠，提高幸福感。
很明显，满意度和幸福感是生产力的重要方面。调查往往能最好地捕捉到这些品质。为了评估满意度维度，你可以测量以下内容:
- 员工的满意度。员工之间的满意度，以及他们是否会将自己的团队推荐给其他人。
- 开发人员的功效。开发人员是否拥有完成工作所需的工具和资源。
- 倦怠。过度和长期的工作压力造成的疲劳。
性能是一个系统或过程的结果。软件开发人员的表现很难量化，因为很难将个人贡献直接与产品结果联系起来。一个生成大量代码的开发人员可能不会生成高质量的代码。高质量的代码可能不能交付客户价值。取悦客户的功能不一定会带来积极的业务结果。即使特定开发人员的贡献可以与业务结果挂钩，它也不总是绩效的反映，因为开发人员可能被分配到影响较小的任务，而不是有代理选择更有影响的工作。此外，软件通常是许多开发人员贡献的总和，这加剧了评估任何单个开发人员的性能的困难。在许多公司和组织中，软件是由团队而不是个人编写的。
由于这些原因，性能的最佳评估通常是结果而不是输出。对软件开发人员性能最简单的看法可能是，开发人员编写的代码是否可靠地完成了它应该做的事情?捕获性能维度的示例度量包括:
- 质量。可靠性、无bug、持续的服务运行状况。
- 的影响。客户满意度，客户采用和保留，特性使用，成本降低。
活动是在执行工作过程中完成的动作或输出的计数。开发人员活动，如果测量正确，可以提供有价值但有限的关于开发人员生产力、工程系统和团队效率的见解。由于开发人员执行的活动复杂而多样，他们的活动不容易测量或量化。事实上，的确如此几乎不可能全面地度量和量化跨工程系统和环境的开发人员活动的所有方面。然而，一个设计良好的工程系统将有助于沿着软件开发生命周期的不同阶段捕获活动度量，并在规模上量化开发人员的活动。一些相对容易测量和量化的开发人员活动是:
- 设计和编码。设计文档和规范、工作项、拉请求、提交和代码审查的数量或计数。
- 持续集成和部署。构建、测试、部署/发布和基础设施利用率的计数。
- 运营活动。根据事件/问题的严重程度、随叫随到的参与程度和事件缓解情况，统计或统计事件/问题的数量和分发情况。
这些指标可以用作度量一些可处理的开发人员活动的路径点，但由于它们的已知局限性，它们不应该单独用于对个人或团队的生产力做出决策。它们作为模板开始使用，应该根据组织的需要和开发环境进行定制。如前所述，许多对软件开发至关重要的活动是难以处理的(例如参加团队会议、参与头脑风暴、在其他团队成员遇到问题时帮助他们，以及提供体系结构指导，等等)。
沟通与协作。沟通与协作捕捉人和团队如何沟通和一起工作。软件开发是一项协作性和创造性的任务，它依赖于团队内部和团队之间广泛而有效的沟通、协调和协作。11有效的团队成功地贡献并有效地整合彼此的工作依赖于高透明度5和意识6团队成员的活动和任务优先级。此外，信息在团队内部和团队之间的流动如何影响文档的可用性和可发现性，而这些文档是有效对齐和集成工作所需的。多元化和包容性的团队绩效更高。22更高效的团队会在正确的问题上工作，更有可能在头脑风暴中获得成功，并从所有备选方案中选择更好的解决方案。
有助于团队成果或支持其他团队成员生产力的工作可能以个人生产力和他们自己进入心流状态的能力为代价，潜在地降低动力和满意度。然而，有效的协作可以降低对某些单独活动的需求(例如，不必要的代码检查和返工)，提高系统性能(更快的拉请求合并可以通过避免错误来提高质量)，并帮助维持生产力和避免(或者相反，如果做得不好，会增加)耗尽。
生产力和满意度是相关的，而且满意度有可能作为生产力的领先指标。
然而，理解和度量团队生产力和团队成员的期望是复杂的，因为有些项目很难度量，比如无形的工作21协调和计划团队任务的表达工作。18也就是说，以下是一些度量指标的例子，可以用作度量沟通、协作和协调的代理:
- 文档和专业知识的可发现性。
- 功的整合速度有多快。
- 对团队成员贡献的工作进行质量评审。
- 显示谁与谁以及如何连接的网络度量。
- 新成员的入职时间和经验。
效率和流程。最后,效率而且流获取在最小的中断或延迟下完成工作或取得进展的能力，无论是单独的还是通过一个系统。这可以包括团队内部和团队之间的活动安排得如何，以及是否取得了持续的进展。
一些研究将生产力与在最少干扰或干扰的情况下完成复杂任务的能力联系起来。2当许多开发人员谈到工作时“进入流”时，他们对生产力的这种概念化得到了回应——或者是寻找和优化它的难度，许多书籍和讨论都在讨论如何以可控的方式实现这种积极状态。4对于个人效率(心流)来说，设定效率和保持效率的边界是很重要的——例如，为一个专注的时间段屏蔽时间。个人效率通常通过不间断的专注时间或在创造价值的应用程序中的时间来衡量(例如，开发人员在集成开发环境中花费的时间可能被认为是“高效”的时间)。
在团队和系统级别，效率与价值流映射相关，它捕获了从想法和创建到将软件交付给最终客户所需的步骤。要优化价值流中的流，重要的是要最小化延迟和传递。DORA (DevOps研究和评估)框架引入了几个指标来监控团队内部的流程9-例如，部署频率度量组织成功发布到生产环境的频率，变更前置时间度量提交到生产环境所需的时间。
除了通过系统进行变更的流动，知识和信息的流动也很重要。效率和流程的某些方面可能很难度量，但通常可以发现并消除价值流中的低效。对客户或用户没有产生价值的活动通常被称为软件开发浪费19例如，重复工作，因为工作没有正确完成而返工，或耗时的死记硬背活动。
表格指标的例子。
捕获效率和流程维度的一些例子是:
- 一个过程中转换的数量;流程中不同团队之间的交接数量。
- 保持工作状态并完成工作的能力。
- 中断:数量、时间、间隔、对开发工作和流程的影响。
- 时间通过系统度量:总时间、增值时间、等待时间。
效率与所有SPACE维度相关。个人、团队和系统层面的效率已被发现与满意度的增加呈正相关。然而，更高的效率也可能对其他因素产生负面影响。例如，最大化流程和速度可能会降低系统的质量，并增加对客户可见的bug数量(性能)。通过减少干扰来优化个人效率可能会降低合作能力，阻碍其他人的工作，并降低团队头脑风暴的能力。
行动纲领
为了说明SPACE框架，图1列出了属于五个维度中的每个维度的具体指标。该图提供了个人、团队或组和系统级度量的示例。下面是关于这些度量的三个简短讨论:首先，展示了一组与代码审查有关的度量示例，它涵盖了SPACE框架的所有维度，具体取决于它们是如何定义和代理的。接下来，为框架的两个选择维度提供了额外的例子:活动、效率和流程。本节最后讨论了如何使用该框架:结合指标以全面理解开发人员的生产力，以及注意事项。伴随侧边栏展示如何使用该框架来理解事件管理中的生产力。
让我们从代码评审开始，作为一个示例场景，它展示了一组可以覆盖SPACE框架的所有五个维度的指标，这取决于如何框架以及使用哪种指标:
- 的满意度。这是很重要的，因为如果一些开发人员认为他们总是被分配了不成比例的代码审查数量，使得他们在其他工作上的时间更少，那么每个开发人员的代码审查数量可能表明他们的不满。
- 的性能。代码评审速度捕获了评审的速度;因为这既可以反映一个人完成评审的速度，也可以反映团队的约束条件，所以它既是一个个人的指标，也是一个团队的指标。(例如，一个人可以在被分配的一个小时内完成一个评审，但是一个团队可以有一个政策，让所有评审开放24小时，以允许所有团队成员看到提议的更改。)
- 活动。完成的代码评审数量是一个单独的度量，它捕获了在给定的时间框架内完成的评审数量，并对最终产品做出贡献。
- 沟通与协作。代码评审本身是开发人员通过代码进行协作的一种方式，对代码评审的质量或深思熟虑的度量或评分是协作和沟通的一个很好的定性度量。
- 效率和流程。代码审查很重要，但如果它中断工作流或延迟导致系统中的约束，则会带来挑战。类似地，必须等待代码评审会延迟开发人员继续工作的能力。批处理代码检查，这样它们就不会中断开发人员的编码时间(这会影响单个度量)，同时也不会导致系统吞吐量的延迟(这会影响系统度量)，允许团队有效地交付代码(团队级度量)。因此，测量代码评审时间对个人、团队和系统的效率和流程的影响是很重要的——这可以通过感知或遥测测量来完成，这些测量捕获完成评审的时间和中断的特征(例如时间和频率)。
让我们通过进一步观察活动、效率和流程的维度来更深入地研究SPACE框架。在本例中，活动度量是个体级别的度量:提交的数量、编码时间(花费的总时间或一天的时间)和完成的代码评审的数量。这些最好地描述了直接有助于最终产品的工作，理解了工作模式和行为受到开发人员工作的团队和环境的影响。
效率和流程有更广泛的指标组合。自我报告的生产力测量最好是在个人层面上捕捉:询问开发人员团队是否高效容易出现盲点，而询问成员是否感觉高效或能够在最少的干扰下完成工作是一个有用的信号。您还可以通过系统度量工作流——代码、文档或其他项目，并捕获诸如它所花费的时间或软件交付管道中的移交、延迟和错误的数量等度量。这些将构成系统级的度量，因为它们的值将捕获工作项在整个工作流或系统中的过程。
如何使用框架
为了衡量开发人员的生产力，团队和领导者(甚至个人)应该跨框架的多个维度获取几个度量标准—建议至少有三个。例如，如果您已经在度量提交(一种活动度量)，就不要简单地将拉请求的数量和编码时间添加到度量仪表板中，因为这些都是活动度量。添加这些可以帮助您更好地捕捉生产力的活动维度，但要真正理解生产力，至少要从两个不同的维度添加一个指标:可能是生产力的感知和拉请求合并时间。
另一个建议是，至少有一个指标包含感性度量，如调查数据。通过把人们的生活经历包括在内，我们可以构建一个更完整的生产力图景。很多时候，感知数据可能提供比仅通过测量系统行为所观察到的更准确和更完整的信息。10
包含来自多个维度和类型的度量常常会造成度量紧张;这是经过设计的，因为平衡的视图提供了工作和系统中正在发生的事情的更真实的图像。这种更平衡的观点应该有助于加强团队成员之间更明智的决策和权衡，否则，团队成员可能会以损害整个系统的方式专注于工作的一个方面。
一个例子是故事点，这是敏捷开发过程中常用的度量标准，用于评估团队级别的进度。如果一个团队只根据故事点数进行评级，那么成员将专注于优化自己的点数，从而损害完成对其他开发人员的进展和公司非常重要的潜在无形工作(如果这意味着与其他团队或招聘未来开发人员的话)。如果领导者用故事点来衡量进度，而不询问开发人员的快速工作能力，他们就无法确定是否有什么东西无法工作，团队正在采取变通措施并耗尽精力，或者一个新的创新是否特别有效，可以用来帮助其他可能正在挣扎的团队。
这引出了一个关于度量及其对团队和组织的影响的重要观点:它们表明了什么是重要的。要间接了解组织中什么是重要的，一种方法是看什么是被衡量的，因为这通常传达了什么是有价值的，并影响人们的行为和反应方式。例如，关心员工健康、福利和留任的公司可能会将满意度和福利维度包括在他们的生产力测量中。作为一个推论，添加或删除指标可以推动行为，因为这也传达了什么是重要的。
例如，一个“生产力=代码行”的团队与一个“生产力=代码行和代码评审质量和客户满意度”的团队是非常不同的。在这种情况下，您保留了一个关于生产力和输出的度量(有问题，但可能是嵌入的)，但是将对生产力的看法推向了一个同样重视团队合作(通过重视深思熟虑的代码评审)和最终用户(通过重视客户满意度)的方向。
指标塑造行为，所以通过添加和评估两个指标，您已经帮助塑造了团队和组织的变化。这就是为什么一定要从框架的多个维度中获取信息是如此重要:这将在团队和系统级别上带来更好的结果。在本例中，随着团队继续改进和迭代，他们可以交换活动度量代码行数比如提交的数量。
要注意什么
拥有过多的指标也可能导致困惑和低动机;并不是所有的维度都需要包含在框架中才能发挥作用。例如，如果向开发人员和团队提供了大量的度量标准和改进目标，达到它们可能会感觉像是一个无法实现的目标。考虑到这一点，请注意，一个好的生产力度量包含至少三个维度的少量指标;这些可以促使一个整体的观点，它们足以唤起改进。
任何度量范式都应该谨慎使用，因为没有任何度量可能是完美的代理。有些指标是糟糕的衡量标准，因为它们是嘈杂的近似值(图1中指出了一些例子)。留存率通常用于衡量员工满意度;然而，这不仅仅是满足——它可以反映薪酬、晋升机会、团队问题，甚至是合伙人的调动。在团队层面，一些经理可能会阻止调动，以保护自己的留任评级。即使留存率确实反映了满意度，但这是一种滞后的衡量标准，团队在发现变化时已经太晚了。我们在其他地方写过关于使用故事点的内在限制，9这可能会激励团队专注于自己的工作，而放弃在重要项目上的合作。
团队和组织应该意识到开发人员的隐私，只报告匿名的、团队或小组级别的汇总结果。(在一些国家，报告个人生产率是不合法的。)然而，对开发人员来说，个人级别的生产力分析可能是有见地的。例如，以前的研究表明，典型的开发人员工作轮班取决于开发阶段，开发人员可能有更高效的时间。14开发人员可以选择这些类型的分析，获得有价值的见解，以优化他们的日子和管理他们的精力。
最后，任何度量范式都应该检查偏差和规范。这些是可能改变或影响度量的外部影响。这里包含了一些例子，但它们并不是详尽的，因此鼓励所有团队寻找和思考可能出现在他们的数据中的外部影响:
- 同行评议和性别。研究表明，在代码评审中，女性更容易收到负面的评论，而较少收到正面的评论。16任何对评审过程的满意度分析都应该在您的环境中检查这一点。要知道开发人员可能会受到更广泛的技术行业的影响，即使这些模式并不在您的组织或团队中。考虑到这些影响。
- 跨时间的标准化度量。团队应该谨慎使用任何用于规范化时间的方法，特别是跨长时间的方法。例如，观察一年以上的指标会对休产假的员工产生偏见。
- 感性的措施。团队和组织应该注意文化规范，并欣然接受。有些文化的报告自然更高，而有些则更低。这并不意味着感知测量是不可信的;这只是意味着来自不同文化的衡量标准会有不同的基线，不应该相互比较。
为什么现在这么重要
开发人员的生产力不仅仅是一个人的活动水平或交付软件所依赖的工程系统的效率，而且它不能通过单一的度量或维度来度量。我们开发了SPACE框架来捕捉生产力的不同维度，因为没有它，关于生产力的普遍和潜在有害的神话可能会持续存在。
SPACE框架提供了一种方法，可以在更大的空间中逻辑地、系统地思考生产力，并谨慎地选择与目标相关联的平衡指标，以及如果单独使用或在错误的环境中使用它们会如何受到限制。该框架有助于阐明可能不是立即明显的权衡，并解释无形的工作和变化的连锁效应，如如果以未完成的开发人员或对整体流程和效率的破坏为代价来衡量活动，则会增加工作。
从整体上理解和衡量生产力的必要性从未像现在这样大。由于Covid-19大流行中断了工作，导致人们突然转向在家办公，许多人质疑其对生产率的影响，并就如何理解和衡量这种变化提出了问题。随着世界慢慢回到“新常态”，SPACE框架抓住了生产力的各个维度，这些维度在提出和做出未来变革时非常重要。该框架旨在帮助个人、团队和组织识别相关的度量标准，以呈现生产力的整体图景;这将导致对生产力进行更深思熟虑的讨论，并设计出更有影响力的解决方案。
致谢我们非常感谢我们的审稿人的深思熟虑的审查和有见地的评论，我们相信，纳入他们的注释和回应加强了文章。
相关文章
在queue.acm.org
得到你衡量的东西
埃里克·鲍尔斯，乔斯特·维瑟，阿里·范·德尔森
https://queue.acm.org/detail.cfm?id=2229115
DevOps指标
妮可·福斯格伦和米克·克斯滕
https://queue.acm.org/detail.cfm?id=3182626
超越“修理”的跑步机
保罗·里德
https://queue.acm.org/detail.cfm?id=3380780
人员与流程
詹姆斯•钱皮
https://queue.acm.org/detail.cfm?id=1122687
参考文献
1.Beller M.， Orgovan V.， Buja S.， Zimmermann T.注意差距:关于自动测量和自我报告生产力之间的关系。IEEE软件(2020);https://arxiv.org/abs/2012.07428。
2.Brumby, d.p.， Janssen, c.p.， Mark, G.中断是如何影响生产力的?重新思考软件工程中的生产力。萨多夫斯基和齐默尔曼编。加州伯克利，Apress, 2019, 85-107;https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_9。
3.挑战和感激:一项关于新冠肺炎大流行期间在家工作的软件工程师的日记研究(2020年8月)。微软;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.奇凯岑特米哈伊,M。心流:最佳体验的心理学。哈珀多年生现代经典，2008年。
5.达比什，L.， Stuart, C.， Tsay, J.， Herbsleb, J. GitHub中的社交编码:开放软件仓库中的透明度和协作。在ACM 2012年会论文集。计算机支持的协同工作(2012年2月)，1277-1286;https://dl.acm.org/doi/10.1145/2145204.2145396。
6.杜里什，P，贝洛蒂，V.共享工作空间的意识和协调。在1992年ACM会议论文集。计算机支持的协同工作(1992年12月)，107-114;https://dl.acm.org/doi/10.1145/143457.143468。
7.福特等人。双城记:2020年2019冠状病毒病大流行期间，软件开发人员在家工作;https://arxiv.org/abs/2008.11147。
8.在工作和娱乐之间找到平衡。2020年的章鱼宇宙状态。GitHub;https://octoverse.github.com/static/github-octoverse-2020-productivity-report.pdf。
9.福斯格伦，N.;加速:精益软件和DevOps的科学:建立和扩展高效技术组织。IT革命出版社，2018。
10.Forsgren, N.， Kersten, M. DevOps度量。Commun。ACM 61， 4 (2018)， 44-48;https://dl.acm.org/doi/10.1145/3159169。
11.H.福克斯，A.拉波索，M.杰罗萨，M. Pimental . 3C合作模式。电子协作百科全书。内德·科克(Ned Kock)主编。IGI Global, 2008, 637-644。https://www.researchgate.net/publication/292220266_The_3C_collaboration_model。
12.软件工程师的幸福感与生产力。重新思考软件工程中的生产力。萨多夫斯基和齐默尔曼编。加州伯克利，Apress, 2019, 109-124;https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_10。
13.马斯拉奇，C.莱特，M.P.。工作倦怠和敬业度的早期预测因素。J.应用心理学93， 3 (2008)， 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.开发人员的工作生活:活动，切换和感知生产力。IEEE反式。软件工程43， 12 (2017)， 1178-1193;https://dl.acm.org/doi/10.1109/TSE.2017.2656886。
15.墨菲-希尔，E.等。什么可以预测软件开发人员的生产力?IEEE反式。软件工程, 2019;https://ieeexplore.ieee.org/document/8643844/。
16.Paul, R.， Bosu, A.， Sultana, k.z。在代码评审期间情感的表达:男性与女性。在IEEE 26th实习生。软件分析、演进与再工程， 2019, 26-37;https://ieeexplore.ieee.org/document/8667987。
17.拉尔夫，p等人。大流行编程:Covid-19如何影响软件开发人员以及他们的组织如何提供帮助。经验软件工程25， 6 (2020)， 4927-4961;https://www.researchgate.net/publication/344342621_Pandemic_programming_How_COVID-19_affects_software_developers_and_how_their_organizations_can_help。
18.施密特，K，班农，L.认真对待CSCW:支持发音工作。计算机支持的协同工作， 1 (1992)， 7-40;https://link.springer.com/article/10.1007/BF00752449。
19.Sedano, T.， Ralph, P.， Péraire, C.软件开发浪费。在三十九人会议记录th国际米兰。软件工程， 2017, 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.软件开发人员工作满意度和感知生产力的理论。IEEE反式。软件工程, 2019;https://ieeexplore.ieee.org/document/8851296。
21.让工作变得可见。Commun。ACM 38， 9(1995年9月)，56-64;https://dl.acm.org/doi/10.1145/223248.223263。
22.Vasilescu, B.等人，Filkov, V. GitHub团队中的性别和任期多样性。在33人会议记录理查德·道金斯ACM年会:计算系统中的人为因素(2015年4月)，3789-3798;https://dl.acm.org/doi/abs/10.1145/2702123.2702549。
数字图书馆是由计算机协会出版的。版权所有©2021 ACM, Inc.
没有找到条目