开发商生产力的空间

3月6日，2021年第19卷，第1款Nicole Forsgren，Github Margaret-Anne Story，维多利亚大学Chandra Maddila，Thomas Zimmermann，Brian Houck和Jenna Butler，微软研究

开发人员生产力复杂，对软件开发团队具有重要意义。清楚地了解定义，测量和预测开发人员生产力可以为组织，管理者和开发人员提供能够进行更高质量的软件 - 并更有效地使其更加有效。

开发人员生产力已经广泛研究。不幸的是，经过几十年的研究和实践发展经验，了解如何衡量生产力甚至定义开发人员生产力仍然难以捉摸，而关于这个话题的神话是常见的。团队或管理人员常常尝试使用简单的指标来衡量开发人员的生产力，试图捕获所有与＆＃34;重要的一项度量。＆＃34;

生产力的一个重要衡量标准是个人看法; 1这可能与那些声称在＆＃34中的人产生共鸣;流程＆＃34;在生产的日子里。

还有一致认为，开发商生产力是必要的，而不仅仅是为了改善工程结果，而且还要确保开发人员的福祉和满足，因为生产力和满足是错综复杂的。 12,20

确保软件系统的有效开发和开发人员的福祉从未如此重要则从Covid-19 Pandemer迫使全球的大多数软件开发人员从家里工作，17名断开开发人员和管理人员从他们通常的工作场所和团队中脱颖而出。虽然这是出乎意料和不幸的，但这种变化构成了一个罕见的＆＃34;自然实验＆＃34;统计学家可以利用在许多不同背景下学习，比较和了解开发人员的生产力。这种强迫中断和未来对混合媒体的过渡到混合偏远/唱好工作的转型加快了解开发商生产力和福祉的必要性，以高效和公平的方式进行广泛的协议至关重要。

本文阐述了关于开发人员生产力的几种常见神话和误解。暴露出这些神话的最重要的外卖是生产力不能降至单个维度（或公制！）。这些神话的普遍性和破坏他们的需要激励我们开发一个实用的多维框架的工作，因为只有通过检查紧张局势的指标星座，我们可以了解和影响开发商的生产力。这个框架称为空间，捕获开发人员生产力最重要的维度：满意度和福祉;表现;活动;沟通与协作;和效率和流动。通过以不仅仅是单一维度，团队和组织的识别和衡量生产力，可以更好地了解人和团队的工作方式，他们可以做出更好的决定。

本文演示了本框架如何用于了解实践中的生产力，为什么使用它将帮助团队更好地了解开发人员的生产力，创造更好的措施，以通知其工作和团队，并可能积极影响工程结果和开发者福祉。

多年来，许多关于开发人员生产力的神话已经积累。对这些误解的认识导致更好地了解测量生产率。

这是最常见的神话之一，它可能导致不良结果和开发人员不满。有时，出于各种原因出现了更高的活动量：工作较长的时间可能会使开发人员发出＆＃34; Brute-Force＆＃34;努力克服糟糕的系统或糟糕的计划，以满足预定义的发布计划。另一方面，增加的活动可能反映了更好的工程系统，为开发人员提供他们需要有效地完成工作的工具，或者更好地与团队成员进行合作和通信，以解锁他们的更改和代码审查。

独自的活动指标不透露出种哪些情况，因此他们永远不应该被隔离使用来奖励或惩罚开发人员。即使是拉拔请求，提交或代码审查数量的简单指标也易于出现错误，因为数据和测量错误中的差距以及报告这些指标的系统将错过在对等方案或头脑风暴中看到的协作的好处。最后，开发人员经常弯曲他们的时间来满足截止日期，使某些活动措施难以评估生产力。

虽然个人表现很重要，但为衡量生产力也是至关重要的。平衡开发人员，团队和组织的性能措施很重要。与团队体育相似，成功由玩家判断出来的个人表现以及团队的成功。仅为自己的个人生产力优化的开发人员可能会损害团队的生产力。更多的团队审查，呼叫旋转和开发和管理工程系统等团队的职业活动有助于维护代码库和产品/服务的质量。在优化个人，团队和组织生产力以及理解可能的权衡时，找到合适的平衡，是关键。

关于开发人员生产力的一个常见神话是它产生了一个通用的指标，这是一个＆＃34;重要的一个公制;可用于在整体工作中获得团队，并比较组织甚至一个行业的团队。这是＆＃39; t真。生产率代表了几个重要的工作维度，并且受到完成工作的背景下的影响。

开发人员经常说生产力措施areN＆＃39; t有用。这可能来自领导或经理的滥用措施，以及它的真实，当生产力衡量和实施时，它可以导致组织中的不当使用。它令人失望的是，生产力一直在选择这种方式，但重要的是要注意，开发人员在追踪自己的生产力方面找到了价值 - 因为个人原因和与他人沟通。

通过记住开发人员的生产力是个人的，7名开发人员可以利用它来实现他们的工作中的见解，以控制他们的时间，能量和日子。例如，研究表明，高生产率与对工作感到满意和满意的高度相关。 1 2,20找到提高生产力的方法也是寻找更多的快乐方式，并减少挫折，在开发商和＃39;。

虽然开发人员工具和工作流程对开发人员生产力的影响很大，但环境和工作文化等人类因素也具有很大的影响。往往需要保持环境和文化健康的关键工作可以是＆＃34;看不见的＆＃34;对于组织的许多成员或传统上用于测量生产率的指标。士气建设，指导和知识共享等工作对于支持生产性工作环境至关重要，但通常不会被衡量。 ＆＃34;看不见的＆＃34;工作的工作使团队的整体生产力与其他更常见的尺寸同样重要。 21.

生产率大约超过个人或工程系统;它不能单独通过单个度量或活动数据来衡量;它是＆＃39;只有管理人员关心的东西。开发了空间框架以捕获生产率的不同维度，因为没有它，刚才呈现的神话将持续存在。该框架提供了一种理性地在更大的空间中思考的方式，并以一种不仅揭示这些指标意味着什么的方式仔细选择度量，还可以单独使用或在错误的上下文中使用的局限性。

满足是如何实现的开发人员对他们的工作，团队，工具或文化的感受;幸福是他们是多么健康和快乐，以及他们的工作如何影响它。测量满意度和福祉可能是有益于理解生产力20，也许是为了预测它。 15例如，生产率和满足是相关的，并且满足可能是生产率的主要指示;满足和参与的下降可能发出越来越突出的倦怠和降低的生产率。 13.

例如，当许多地方在大流行期间从家中转移到强制性工作时，在一些生产力的措施（例如，代码提交和速度以合并拉拉请求的速度）发生了一个uptick。然而，8个定性数据表明，有些人正在努力与他们幸福的努力。 3这突出了占生产效率若干方面的平衡措施的重要性：虽然一些活动措施看起来是积极的，但额外的满足措施绘制了更全面的图片，表明生产力是个人的，一些开发商正在接近倦怠。要打击这一点，在大型组织中实施了一些软件组，而且在大型组织中实现＆＃34;心理健康＆＃34;几天基本上，自由日子，帮助人们避免倦怠并改善幸福。

很明显，满意度和幸福是生产力的重要方面。这些品质通常最好捕获调查。要评估满意度维度，您可能会衡量以下内容：

•员工满意度。员工之间的满足程度，以及他们是否会向别人推荐他们的团队。

•开发人员疗效。开发人员是否有他们需要完成工作所需的工具和资源。

性能是系统或过程的结果。软件开发人员的表现难以量化，因为很难将个别贡献直接纳入产品结果。产生大量代码的开发人员可能不会产生高质量的代码。高质量代码可能无法提供客户价值。欢呼客户可能不会总是导致积极的业务成果。即使特定的开发人员＆＃39;贡献可以与业务成果相关联，它并不总是对性能的反映，因为开发人员可能被分配了一个较少的有影响力的任务，而不是有机构选择更有影响力的工作。此外，软件通常是许多开发人员和＃39的总和;贡献，加剧了评估任何个体开发人员的表现的困难。在许多公司和组织中，软件由团队，而不是个人编写。

由于这些原因，性能通常最好地评估为结果而不是输出。最简单的软件开发人员性能看法可能是，开发人员编写的代码是否可靠地执行它所应该做的事情？捕获性能维度的示例度量标准包括：

活动是在执行工作过程中完成的行动或产出的计数。开发人员活动，如果正确测量，可以为开发人员生产力，工程系统和团队效率提供有价值但有限的见解。由于开发商表现的复杂和多样化的活动，他们的活动并不容易测量或量化。事实上，几乎不可能全面测量和量化工程系统和环境的开发人员活动的所有方面。然而，一个精心设计的工程系统将有助于沿软件开发生命周期的不同阶段捕获活动指标，并按比例量化开发人员活动。可以相对容易地测量和量化的一些开发者活动是：

•设计和编码。设计文档和规格，工作项目，拉拔请求，提交和代码评论的卷或计数。

•运营活动。基于其狭义，呼叫参与和发生缓解的事件/问题和分配的计数或分配数量。

这些指标可以用作衡量一些贸易的开发人员活动的航点，但由于其已知的限制，他们永远不应该被隔离地做出关于个人或团队生产力的决定。它们作为模板开始，应根据组织需求和开发环境进行定制。如前所述，许多对开发软件至关重要的活动是棘手的（例如参加团队会议，参与头脑风暴，当遇到问题时帮助其他团队成员，并提供架构指导，以命名为数）。

沟通和协作捕获人员和团队如何共同沟通和工作。软件开发是一项合作和创造性的任务，依赖于团队内部和之间的广泛有效的沟通，协调和协作。 11个有效的团队，成功贡献并互相融合＆＃39;高效地依赖于高透明度5和团队成员活动和任务优先事项的认识6。此外，如何在团队内部流动的信息如何影响有效对准和整合工作所需的文件的可用性和可发现性。多元化和包容性的团队表现较高。 22越来越有效的团队在正确的问题上工作，更有可能在头脑风暴中成功，并将从所有替代方案中选择更好的解决方案。

为团队提供贡献的工作，或者支持另一个团队成员＆＃39;生产力可能会牺牲一个人的生产力和他们自己进入流动状态，可能减少动力和竞争的能力。满意。然而，有效的协作可以减少对某些个人活动的需求（例如，不必要的代码审查和返工），提高系统性能（通过避免错误，提高提高申请资金可能会提高质量），并帮助维持生产力并避免（或相反，如果没有正确，增加）倦怠。

然而，了解和衡量团队生产力和团队成员的期望是由于难以衡量的项目，如不可见的工作21和协调和规划团队任务的阐明工作。 18表示，以下是可以用作测量通信，协作和协调的代理的度量标准的示例：

最后，效率和流量捕获完成工作的能力或通过最小的中断或延迟进行进展，无论是单独还是通过系统。这可能包括策划团队内部和跨团队的活动以及是否正在持续进展。

有些研究将生产力与获得复杂任务的能力与最小的分心或中断相关联。 2当他们谈论＆＃34时，许多开发人员的生产率的概念化是由许多开发者的回声。进入流程＆＃34;在进行工作时 - 或者难以找到和优化它，许多书籍和讨论解决如何以受控方式实现这种正状态。 4对于单个效率（流量），它和＃39;设置边界的重要性，以使高效和保持富有成效 - 例如，通过阻止焦点期间。个人效率通常是通过不间断的焦点时间或价值创建应用程序中的时间来衡量的（例如，开发人员在综合开发环境中花费的时间可能被考虑，而＃34;生产性＆＃34;时间）。

在团队和系统级别，效率与价值流映射有关，它捕获了从想法和创建将软件拍摄到最终客户所需的步骤。要优化值流中的流量，重要的是最小化延迟和切换。 DORA（Devops Research和RessionMent）框架推出了几个指标，以监控团队内的流程9 - 例如，部署频率测量组织成功发布到生产的频率，并且更改的提前时间测量提交所需的时间进入生产。

除了通过系统的变化流动之外，知识和信息的流程也很重要。效率和流动的某些方面可能很难测量，但是通常可以点击和消除价值流中的低效率。为客户或用户提供价值的活动通常被称为软件开发废物19 - 例如重复的工作，返工，因为工作未正确完成，或耗时的死记硬背活动。

•过程中的切换次数;过程中不同团队的切换次数。

效率与所有空间尺寸有关。已经发现个人，团队和系统级别的效率与增加的满意度积极相关。然而，更高的效率也可能对其他因素产生负面影响。例如，最大化流量和速度可能会降低系统的质量并增加客户可见的错误数（性能）。通过减少中断优化个体效率可能会降低协作的能力，阻止其他＆＃39;工作，并降低团队集体风暴的能力。

为了说明空间框架，图1列出了落入五个维度中的每一个的具体度量。该图提供了个人，团队或团体和系统级别措施的示例。关于这些指标的三个简短讨论遵循：首先，示出了关于代码审查的示例集指标，涵盖了空间框架的所有维度，具体取决于它们的定义和代理方式。接下来，为框架的两个选择尺寸提供其他示例：活动和效率和流量。该部分结束了如何使用该框架的讨论：将度量与开发人员生产力的整体理解相结合，以及注意事项。伴随的侧边栏显示框架如何用于了解事件管理中的生产力。

Let＆＃39;首先，代码审查开始作为一个示例方案，它呈现了一组可以涵盖空间框架的所有五个维度的度量，具体取决于它是如何构建的，并且使用了哪些度量：

• 满意。关于代码审查的感知措施可以揭示开发人员是否在良好或糟糕的灯光中查看工作 - 例如，如果他们呈现学习，指导或塑造码比的机会。这很重要，因为每名开发人员的代码审查数量可能会发出不满意，如果某些开发人员觉得它们持续分配不成比例的代码审查，则将其留下更少的时间进行其他工作。

• 表现。代码审查速度捕获评论的速度;因为这可以反映个人如何完成审查的速度和团队的约束，它既是个人和团队级度量。 （例如，个人可以在分配一小时内完成审查，但团队可能会有一项留下所有录用的政策24小时，以允许所有团队成员查看拟议的变更。）

• 活动。代码审查数量已完成是一个单独的指标捕获给定的时间范围内完成了多少评论，并为最终产品贡献。

•沟通和协作。 代码审查自己是开发人员通过代码协作的方式，以及代码审查的质量或周边的措施或分数是合作和沟通的巨大定性衡量标准。 •效率和流量。 代码审查很重要，但如果它中断工作流程或延迟导致系统中的约束，则可能导致挑战。 同样，必须等待代码审查可以延迟开发人员＆＃39;我们继续工作的能力。 批处理 ......