Margaret-Anne (Peggy) Storey和Abi Noda是最近发表的ACM论文 "DevEx: What Actually Drives Productivity "的合著者。
在这一集中，我们讨论了如何使用以开发者为中心的方法更好地衡量和提高开发者的生产力。Peggy和Abi首先解释了软件开发中社会技术因素的重要性。他们还分享了他们对著名的SPACE和DORA指标的看法，并指出了误用和滥用DORA指标的危险。
随后，Peggy和Abi解释了他们最新论文中关于开发者体验的三个核心维度，即反馈回路、认知负荷和流动状态。
最后，Peggy和Abi分享了关于我们如何开始测量开发者体验的提示，包括如何正确进行开发者调查。
第一篇开发者经验论文
Peggy和我最初的论文主要是了解什么是开发者体验，并对其进行定义。在我们的调查中，我们首先研究了现有的文献，以建立一个关于什么是开发者体验的工作定义，然后我们的调查重点是了解什么会实际影响开发者体验。
我们知道有很多人为和技术因素影响着开发者的体验。但真正的问题是，哪些是影响开发者体验的最重要或相关的因素？
我们的论文的主要发现是一组社会和技术因素，这些因素影响着开发者的体验，同时也理解了为什么开发者的体验对组织很重要，以及为什么这么多组织都在努力识别他们的开发者体验中的问题并进行改进。
社会-技术因素
围绕社会技术因素的观点真的很重要，因为围绕开发者体验的一个最大的误解和神话，我称之为反模式，就是开发者体验只是关于工具。
在我们的研究和Peggy之前几十年的研究中，我们发现人的因素，如协作或心理安全，或只是团队和人之间的信息交流，对开发者体验有非常重要的影响。我个人认为，对开发者经验的影响甚至比组织所关注的典型工具问题还要大。
有一天，我读到了一个很好的说法。这就是，没有社会就没有技术，没有技术就没有社会。所有这些因素，甚至是我们提出的，你不能真的说这个只是技术性的，这个是社会性的。它们在某种程度上都是社会技术性的。它们都有两个方面。
我最近还想到了一个代码质量的例子。我们认为代码质量是一个技术问题，但事实上，代码质量的真正挑战是围绕着人类理解其他人类的代码和在其他人类的代码上工作。因此，代码质量真的是一个技术问题还是一个人的问题？
很多开发者和管理者在他们对质量的定义中提到，写代码是为了让其他人能够在我的代码之上进行构建。或者说，这样其他人甚至是我就可以在将来理解它，并对它进行进化。这不仅仅是关于它有多安全或多健壮，而是更多的考虑到更多的人必须理解它。
社会-技术因素的例子
我们有大约25个因素出现了。其中很少有你认为的技术因素。像代码库的健康状况、开发环境和摩擦性发布等等，更多的是在技术方面。
但是，很多出现的因素是，对于开发人员来说，有明确的目标，知道他们必须做的工作的范围，了解需求。他们的团队和他们的经理为他们设定了合理的最后期限。对路线图有发言权，感觉他们在所发生的事情中扮演了一个角色。还有一些人喜欢拥有自主权。对将要发生的事情有发言权。这方面的心理安全。还有一些事情，如感觉与他们团队中的其他人有联系。感觉被倾听，得到帮助和给予帮助。
这让我想起了我在GitHub的一次经历，当时领导层希望改善DORA指标。实际上，我被安排负责尝试了解如何改善我们的准备时间。而在当时，企业把前置时间看成是一个技术问题，是我们的开发工具和CI/CD流程的问题。然而，当我开始研究这个问题并与整个组织的经理和领导交谈时，最常见的反应实际上是人为因素，例如范围蠕变和糟糕的产品管理。
这又回到了前面的观点，围绕着开发人员的生产力和开发人员的经验，远不止是工具。而那些只把它看成是工具问题的组织，则错过了很多改善的机会。
空间和DORA度量
我们提出SPACE的原因是为了鼓励行业，鼓励经理和领导不要只考虑那些你可以很容易衡量的东西的生产力，例如代码行或拉动请求或代码审查完成或功能交付，而要真正扩大生产力的含义。
[生产力]是很难定义的。这是一个难以捉摸的术语，我们发现它意味着许多不同的东西。这就是为什么我们提出了SPACE框架，以表明当你考虑如何提高生产力时，你需要考虑的是这些不同的层面。
协作的重要性。因此，它不仅仅是写代码或运送功能，而是思考你如何帮助别人在工作中解脱。或者你如何帮助别人加入你的代码，或者你去写代码的努力，以便别人能够理解它并在自己的工作中利用这些代码。或者急于做一些事情，以便为别人解除障碍。
你的满意度如何。所以，我早先做的一些研究，以及其他人所做的研究，发现更快乐或更满意的开发者也会感到更有生产力，反之亦然。因此，在你的工作中感到满意、快乐和喜悦，对于提高生产力来说是很重要的。此外，那些处于流动状态、不被打断的感觉，以及真正拥有编写代码、取得进展和在工作中产生影响的快乐体验。
我们认为，如果你要定义指标，至少要使用三个方面。要更全面。不要只关注活动或结果，比如说交付功能的质量。但是要看一下开发人员的满意度、协作、以及效率和流程等其他方面。
我认为DORA所关注的内容更具体，而SPACE则非常广泛，非常全面。
我不一定同意DORA比SPACE发展得更快。DORA比SPACE有很多年的时间来发展。我个人的观察是，SPACE很复杂。
SPACE框架的重点是向人们展示开发者的生产力是复杂和多维的。而我认为这并不是人们一直想要的答案。相比之下，DORA的衡量标准很简单。有四个指标，它们都是 "经过科学验证的"。我曾听到有人怀疑地称它们是高管们试图衡量工程绩效的简单按钮。
我认为SPACE从整体上考察了开发人员的生产力，而DORA指标是你可以使用的开箱即用的指标。这就是为什么你看到许多组织在使用DORA指标，并试图弄清楚开发人员的生产力的部分原因。
DORA指标的误用和滥用
DORA过去和现在都是一项突破性的研究。所以，这并不是对DORA的批评，而是说DORA指标，或者说被称为四个关键指标的指标，已经有点脱离实际，有点失控了。而我们今天看到的是，许多领导人正在努力从这些指标中获得实际价值。
我认为被忽略的关于DORA指标的最大问题是，它们是结果而不是能力。它们并不是你应该设定的目标或试图优化其本身的真正指标。
人们经常谈论《加速》这本书。他们开玩笑说，高管们只读了第19页，然后就放下了这本书。第19页是描述四个衡量标准的地方。他们没有谈及书中谈到的广泛的能力，而这正是组织实际需要关注的。
在GitHub，问题是一旦我们有了DORA指标，接下来的问题是，那又怎样？那么我们该如何改进这些指标呢？问题是，DORA指标并没有真正捕捉到整个组织所发生的事情的背景或根本原因。因此，我所做的是在公司周围采访开发人员和团队，以了解，好吧，实际上是什么拖累了你？
新的开发人员经验文件
我们决定写这篇论文的原因是为了真正建立在我们最初的研究论文中的工作。在最初的研究论文中，我们定义了什么是开发者体验，它到底是由什么组成的，它在组织中是什么样子的，以及为什么对他们来说，实际改善它是一个挑战。
在这篇论文中，我们想创造一个更实用的资源。一些可以很容易地被组织中的领导者所应用的东西。这篇论文真正囊括了我们最初论文中的研究结果，以及我们现在与许多组织合作的经验，并与他们合作，帮助他们理解和改善开发人员的经验。
因此，本文在我们的经验和研究的基础上，希望能提供一个框架或一组框架，组织可以继续应用，以开始衡量开发人员的经验。
认知负荷
在本文中，我们将认知负荷描述或定义为开发人员执行一项任务所需的心理处理量。认知负荷有不同的类型，我们在文中简要介绍了这些类型。
认知负荷的一个方面是，它只是一项任务或学习理解一个陌生的工具或框架的内在难度或复杂性。但认知负荷的一个有趣的方面是，它还关注--当我说这个的时候，我指的是认知负荷理论，这实际上是对认知负荷本身的研究--他们也关注实际摄入或处理外部信息需要多少处理。因此，比如说，沟通。
看一下这三种不同类型的认知负荷是如何映射到开发者经验中的共同挑战的，真的很有趣。
要考虑认知负荷的一个重要部分。Hans Dockter谈到了这一点。我不知道你是否看过他关于认知疲劳的谈话。当你努力理解某些东西或努力学习一个新的工具或让某些东西工作时，你所经历的疲劳。当你在等待别人的时候，或者你不知道为什么某些东西会以这样的方式工作，这真的会让你疲惫不堪。而且你知道这对开发者来说真的很累人。
如果你非常努力地工作，并且一直在快速发送你的功能，你永远没有机会放松和休息。因为你在不断地部署新的功能。
这些东西的相互作用方式对于开发者的经验来说真的很重要。还有像代码、技术债务和缺乏文档等，这些也是增加认知负荷的事情。
心流状态
绝对的，结构化的时间块。能够从事这种深入的工作真的很重要。但这并不只是做这些那么简单。
我们谈到了开发人员陷入等待。他们不能移动。他们需要帮助。他们需要有人向他们解释一些事情。或者，他们需要他们完成这个变化，这样他们就可以解除障碍，继续工作了。因此，在拥有这些个人心流经验和团队经验之间存在着这种紧张关系。
有这些大块的时间是很好的。如果你问开发人员，是什么让他们感到富有成效，是什么让他们感到度过了美好的一天，那将是他们有大量的时间不受干扰地进行编码。因此，支持和认识到这一点是很重要的，开发人员有这些大块的时间来处理他们的代码是很关键的。
另一方面，也有一个平衡。因为你需要人们之间的会议，以便能够确保整个团队有那种能够共同前进的经验。
在软件开发中，不幸的是，你不可能看到整个过程。你不能看到每个人的手在做这件事。你可以对他们正在做的事情有一些了解。但是，为了获得这种情景意识，你确实需要举行会议。因此，你确实需要人们走到一起，有那些站立，说他们正在做什么，并有能力能够说，"你能帮助我吗？我被卡住了。"
消除障碍和干扰对于促进开发人员的流动状态真的很重要。但我也认为一个被忽视的方面是我称之为流动状态的动机层面。这不仅仅是为了消除人们的路障，使他们能够进入那个区域状态。这也是为了让他们在一个环境中工作，让他们受到刺激，获得能量，并有动力进入这种状态，在流动中完成他们的工作。
心流的一个真正重要的部分是学习和支持开发人员的学习。如果你没有时间学习如何有效地使用一个工具，或者学习一个新的技术，或者学习一个你可以使用的新的API，那么你就会感到沮丧了。
我注意到，在与许多不同组织的开发人员交谈时，这些组织不一定重视花时间学习。在很多小公司，人们从来没有认识到，你知道吗，我们需要把刹车放在这里，花一些时间来做一些学习。我们不打算发送任何代码。然后，如果你花时间学习，我们就能获得那些心流体验，增加反馈，减少以后的认知负荷。所以，学习真的很重要。
领导者总是想知道我们如何让我们的开发人员更努力地工作。懒惰，他们工作得不够努力。但实际上，我认为处于流动状态的开发人员是那些在晚上熬夜工作的人，因为他们处于这种高度愉快的、激动的、刺激的、创造性的状态。
当人们谈论我们如何让我们的开发人员工作得更快时？或者我们如何从我们的员工身上获得更多，这是目前我们所处的宏观环境的一个问题。你不能只是鞭策人们更快地工作和打字。但是你可以激励他们并激发他们在工作中的积极性，从而更加努力地工作并为你的组织创造更多。
通常，开发人员最有创意的见解是在他们处于这种心流状态时。所以只是提一下，这不仅仅是关于输出。软件开发就是这样一种创造性活动。因此，授权并为您的开发人员提供进入这种心流和创造性状态的机会非常重要。
文化的重要性
当然，在我们之前关于开发者经验的论文中，我们呼吁心理安全也许是最重要的因素，它超越了所有其他的因素。如果你看一下像DORA这样的研究，他们说的也完全一样。文化总是作为最重要的因素出现，是创建有效团队和组织的赌注。
我们确实非常关注那些能够捕捉到诸如满意度或感知到的完成高质量工作的能力以及诸如此类事情的衡量标准。因此，我认为我们确实在开发人员经验的三个维度上捕捉文化。虽然，我们并没有在我们的例子中特别把心理安全作为一个衡量标准。
它们是如此重要。如果你没有这些，其他的事情就无所谓了。一切都会崩溃。
我认为这三个方面是对软件开发非常具体的东西。因此，从软件开发的角度来看，文化、协作和沟通，这些对每一种工作或每一种关系都很重要。因此，我们试图强调哪些是可操作的东西，你可能能够衡量，然后改变和改善软件开发的环境。
衡量开发人员的经验
我们在一开始就说，我们希望本文能够为这个永恒的问题或难以捉摸的问题提供一个相当有力的解决方案和答案，即我们应该衡量和关注什么来提高生产力。
在这篇论文中，我们提供了一组跨越我们刚刚谈到的开发者体验的三个维度的例子指标。在这些维度中，我们关注或建议测量这些维度中的两个不同方面。
一个方面是我们所说的感知。这些是一些人所说的主观指标或感知或态度的指标。这些是只能通过询问人们或进行调查来衡量的东西。
此外，我们也推荐衡量工作流程的例子指标。而这些可以通过调查或系统或通过观察来衡量。但这些都是实际的、我们称之为客观指标的东西，或某件事情需要多少时间或需要多少步骤。
在理解开发人员的经验时，同时拥有这些感知和工作流程的衡量标准是很重要的，因为这两者真的是相互制衡的。如果你只测量开发人员的情绪或看法，你可能会错过在他们工作流程中表现出来的机会。另一方面，如果你只关注工作流程，例如DORA指标，你可能会错过更大的画面，而这只有通过实际询问开发者的经验才能发现。
我不认为任何组织会拿着这个表格，拿着这里的例子去衡量它们。至少我希望他们不会这样做。因为他们首先必须决定我们要实现的是什么。然后根据这六个单元来决定我们应该使用哪些衡量标准。
正如阿比所说，沿着感知和工作流程或更客观的那种衡量标准来思考，这真的很重要。但也要考虑到三个反馈回路、认知负荷和认知流。因为你可以欺骗自己去想，我正在使用这个新的工具，看看一切是多么的好。与此同时，开发人员就像完全不开心，他们都离开了。因此，你必须全面地看待这个问题，这是我们的尝试。
这不是一个解决方案。同样，它很复杂。它不像DORA的四个指标那样容易，你可以采取它们并找到一种方法来操作它们。这仍然需要一些工作。
正如我们在DORA中看到的那样，正如我们在SPACE中看到的那样，正如我们在技术领域的许多其他事情中看到的那样，有这样一种趋势，就是盲目地复制和粘贴其他人已经想出的解决方案。而这个框架就是，这就是为什么我们称它们为例子，就像你在《空间》中做的那样。
这只是一个出发点，为组织思考如何测量开发者体验以实现他们希望推动的结果提供参考。
进行调查
我们确实谈到了调查是开始测量开发者经验的好方法。然而，我现在犹豫不决，不知道该如何形容它的简单。设计有效和可靠的调查实际上是一项相当艰巨的任务。
当你设计调查时，很容易设计出不能真正产生准确或可靠数据的调查。因为当你考虑到调查的真正作用时，你所做的基本上是把人的思想作为一个工具，为你提供关于你试图测量的事物的数据。你在使用人类的思想作为测量工具。为了做到这一点，你需要有精确性，就像我们在软件和计算机程序中需要精确性和确定性的算法一样。我们希望设计的调查和调查项目的行为符合我们设计的方式。
当设计调查时，你会听到谈论的两件事是有效性，它指的是你是否真的在测量你认为你正在测量的东西。还有就是所谓的可靠性，也就是你的测量工具是否真的能在不同时间和不同地区的人口中产生你想要的测量结果？
开始做调查很容易，但要在规模上产生准确和可靠的测量是相当困难的。
调查的设计和正确性实际上要比编写代码来分析和刮取GitHub存储库的数据难得多。我认为，这其实更容易分析系统数据。
调查设计真的很难。有时候，你可以使用已经存在的量表。其中一些的问题是它们可能不完全用于你的环境。或者它们可能太复杂，问的问题太多，以至于开发人员不会回答。
当然，你可以做一些事情，当然也有一些方法来检查你的调查回应是否可靠。但在一天结束的时候，拥有这两种数据，然后在没有反思和讨论的情况下不盲目地接受任何一种数据都是很愚蠢的。你需要回到回答你调查的人那里，问他们，这是我发现的。这是否与你产生了共鸣？为什么我们会看到这个？要求解释，以及为什么我们在数据和调查回答中看到这个。然后它们就会成为指导下一步工作的有力依据。
通常情况下，我看到行业中的很多仪表盘被用来测量生产力，他们测量它，它就完成了。但是，现在艰苦的工作开始了，知道下一步该做什么。
你也可以使用调查来收集开放式的答案。这些洞察力，可操作性，关于不仅是为什么东西坏了，而且如何修复它的洞察力，是黄金。这是你永远无法从系统数据中得到的。
三个技术领导的智慧
不要只把软件看成是代码。把软件看作是人和他们头脑中的理论。
通常人们把软件看作是代码或交付给终端用户的功能。
我认为把代码或软件看作是人们头脑中的理论，是一种更好的思考代码的方式。因此，没有一个人在一个项目上工作，即使他们在自己的项目上工作，也不会理解所有的事情是如何运作的。他们会有关于代码如何工作的不完整模型。
因此，思考团队中不同的人或与他们合作的其他团队的理论真的很重要，思考这些关于代码如何工作的理论，为什么它以这样的方式工作。
更重要的是，这些代码有什么可能被改变。因为任何有用的软件都会有变化。
因此，把代码看作是人们头脑中的那些理论。因此，把人作为软件的一部分来思考是至关重要的。思考协作，人们如何协作，如何沟通，如何分享知识，如何相互帮助，如何交流思想和建立新的想法。这绝对是至关重要的。
多说说你的意思。对这些事情进行更多的反思。
生产力。质量。这些术语，我们使用了很多术语，但我们没有给它们下定义。我们没有定义生产力意味着什么，也没有定义质量意味着什么。
我做了一项研究，询问开发人员和管理人员如何定义生产力和质量。我们问开发者，他们认为管理者如何定义生产力，而管理者认为开发者如何定义生产力？
我们发现，管理者知道开发者的想法，但开发者不知道他们的管理者是怎么想的。特别是开发人员，他们确实重视合作，他们确实重视帮助别人，但他们不一定认为他们的经理认为这很有价值。但他们并不真正知道。也许它可以通过一些方式浮出水面，所以它变得很重要。
开发人员的经验，很多都是，我们是人。我们希望有一个影响。
我们所做的事情，我们想感觉到我们所做的工作是有价值的，它为我们的队友或我们的最终用户带来了价值。因此，认识到这一点，使这种影响可见，真的很重要。很多开发者往往被不必要地屏蔽了他们的工具所带来的影响。
还有就是支持学习。认识到学习对开发者来说也是有影响的事情。