ACM通信
研究突出了
软件开发中的认知偏差
来源:盖蒂图片社
认知偏差是一种影响开发者行动的固有行为，并可能导致他们走上不正确的行动路线，并需要回溯。尽管研究人员在受控实验室研究中发现认知偏差出现在开发任务中，但我们仍然不知道这些偏差如何影响开发人员的日常行为。如果没有这样的理解，开发工具和实践仍然是不够的。为了缩小这一差距，我们进行了一项由两部分组成的实地研究，以检查认知偏差发生的程度，这些偏差对开发者行为的影响，以及开发者用来处理这些偏差的实践和工具。我们发现，大约70%的观察到的行为至少与一种认知偏差有关。即使开发人员认识到偏差经常发生，他们还是被迫用特别的过程和次优的工具支持来处理这样的问题。正如一位参与者(IP12)哀叹的那样:没有救恩!
1.简介
认知偏见系统偏离最佳推理吗17这会影响我们寻找、评估和记忆信息的方式。这些通往潜在解决方案的“捷径”可以有几种形式，并且经常出现在我们的日常行为中。例如，确认偏误(倾向于更多地关注与我们先入之见相符的信息一些人将COVID-19病毒描述为“另一个u”，这促使他们违反专家和卫生组织的建议进行社会行为。就像这个例子一样，认知偏差的发生会对社会造成重大影响。
软件开发人员也不能幸免于这种行为，并且可能会因为几个原因而表现出偏见。例如，有些偏见是试图绕过我们有限的认知能力的结果(例如，可用性偏见可能会促使开发人员基于他们容易记住的例子来选择解决方案)，而另一些则是解决方案的先前经验的结果(例如，信念坚持偏见可能会迫使开发人员更多地关注代码他们相信有bug)，或者个人解决问题的风格(例如，双曲线折扣偏差可能会鼓励开发人员选择奖励更小、更快的解决方案)。
尽管这些认知偏差往往会导致理想的解决方案，但它们也可能会造成重大的负面后果。受控实验室研究已经确定了特定的认知偏差对软件开发的几个方面的有害影响，比如缺陷密度，1需求规范,6创意的设计,18和功能设计。4Mohanani et al。9对65个这样的研究进行了调查。然而，尽管做出了这些努力，我们仍然不明白认知偏见是如何在现实世界中显现的，以及它们如何影响开发者的行动、行为和决策原位。只有通过理解现实世界的行为，我们才能开始了解如何减少这种非最优行为。
在这里，我们展示了一项由两部分组成的实地研究的结果，该研究考察了认知偏差在开发人员日常工作活动中发生的程度。我们考虑某些偏见发生的频率和时间。我们还列出了开发人员目前用来减轻偏见的一些实践和工具。
2.背景
1974年，研究人员特沃斯基和卡尼曼首次提出了认知偏见。17自1990年以来，软件工程的研究人员一直在研究这个领域中的这些偏见。16Mohanani等人总结了65篇描述软件工程中研究偏差现状的文章。9这些文章调查了37种不同的认知偏见(从心理学、社会学和管理学研究中先前确定的200多种认知偏见中)。例如，研究发现，在测试时，确认偏差会导致更高的缺陷率和更多的发布后缺陷;可用性和代表性的偏差会导致开发人员错误地描述代码特性;在执行需求分析时，过度自信会导致努力不足。
在65篇被检查的论文中，没有一篇描述了原位实地研究是他们研究方法的一部分。例如，Calikli等人。2通过用户研究，包括交互式和书面测试，评估公司文化、教育和经验对软件开发人员和测试人员确认偏差的影响。尽管实验室研究和对照实验允许对混杂因素进行控制，但它们确实牺牲了自然观察的丰富性和自发性。5我们的研究试图通过在现实环境中使用观察性研究，将这些基于实验室(或非自然环境中的研究)的发现扩展到实际的发展实践中。
3.方法
我们观察了10个开发者原位用于我们的实地研究。我们的参与者是从一家美国的软件初创公司(a公司)招募的，该公司专门从事分布式开发工具和服务领域，如程序分析、用户界面(UI)设计、基础设施支持和软件研发。由于创业公司关注领域的多样性，参与者使用了各种各样的编程语言、工具和工作风格。
表1介绍有关研究参与者的人口统计信息，如开发经验、代码编辑器使用情况和首选编程语言(软件开发经验的中位数为两年，平均值为5年9个月)。一个
表1。研究参与者的人口统计数据。
我们观察参与者在一个典型的工作日中执行他们的日常开发任务。在观察过程中，我们要求参与者大声地说出他们的想法和互动。12我们记录了他们的屏幕、音频和物理工作空间。
每次观察的总时间被限制为60分钟，以防止参与者倦怠，并尊重启动时的时间限制。
在每次实验中，一名研究人员被安排在参与者旁边，做笔记。在参与者看不到的单独房间里，另一名研究人员充当次要的现场记录员，并监控参与者的录音以确保一致性。研究小组的成员轮流担任主要和次要的笔记记录者。
在每次会议结束时，参与者被要求完成一个简短的人口统计调查(结果见表1)，尽管两位研究人员在15分钟的回顾性访谈中整理和准备了后续问题以澄清。
为了理解认知偏差是如何影响软件开发的，我们首先确定了开发人员的任务(目标)和行动-开发人员为达到目标而执行的离散步骤。3.我们使用定性编码方法识别和分类参与者的每个个体行为。
为了编码原始数据，我们首先转录所有数据，并对每个单元进行分区，以包含与时间戳一致的参与者操作的引用和描述。
为了在我们的转录数据中编码操作，我们从所有参与者的观察中创建了五组94个(4.5%，超过五组的总数为22.5%)随机实例。三个作者分别使用中描述的代码对每个操作进行编码表2．我们实现了三个编码员的内部评级可靠性(IRR)措施。然后，我们检查每一个行动，以识别任何相关的偏差，如下所述。
表2。行动准则。
3.1.互补的采访
接下来，我们对16名开发人员进行了半结构化的访谈，以从最初的实地研究中三角定位我们的发现。我们使用半结构式访谈而不是调查来:(1)确认参与者正确地理解了偏见，尽管允许他们提出澄清性的问题，(2)跟踪参与者建议解决偏见的建议/实践。
我们从三家公司招募了面试参与者，研究不同组织规模和文化背景下的去偏见做法。首先，我们采访了来自原始公司(A公司)的11名开发者;从我们观察到的10个参与者(见表1)的时候，有两名员工离开了，另外三人在我们实地考察后加入了。接下来，我们采访了来自另一家初创公司(公司B)的一名开发者;团队规模与a公司相似。最后，我们采访了来自《财富》500强公司(C公司)的4名开发者;团队规模庞大的跨国公司。这些访谈有助于证实所观察到的偏差并不局限于某一家公司。表3为所有访谈参与者提供人口统计信息。
表3。采访中参与者的人口统计数据。
在访谈中，我们定义了10个偏见类别，并根据我们在实地研究中观察到的实例提供了例子(定义见第4节)。使用这些一般化的例子，我们针对每个特定的偏见问了两个问题:(1)“从1(低)到5(高)，你认为开发者在这种偏见下的行为频率是多少?”“什么样的标准实践、指南或工具可以帮助避免这种偏见?”
访谈回答由两位作者使用模式编码进行分类8-将类别分成更小的专题集的过程。我们确定了29种开发实践(例如，头脑风暴，引用)。这些实践被抽象成五个类别，它们将特定的偏见与直接解决它们的实践联系起来(参见表6详情)。
4.偏见的分类
关于个人偏见的描述可以在我们的补充网站上找到，b它提供了用于数据分析的匿名补充构件。出于对参与者隐私的考虑，我们不能发布原始数据。
4.1.偏见的类别
我们分组28个观察到的偏见分为10类基于它们对开发人员行为的影响(参见表4）;我们没有观察到Mohanani等人报告的其余9个偏差，可能是因为我们的研究设计——一个小时的观察研究，采用自言自语的协议。
表4。认知偏见的类别。
通过协商一致的过程创建偏倚类别，确保偏倚编码的有效性。两位作者使用以下方法分别对28种偏见进行了分类:(1)软件工程环境中认知偏见的定义(根据Mohanani等人)，(2)认知科学文献中对偏见的定义，以及(3)观察到的偏见对参与者发展行为的影响(通过直接观察和参与者的言语表达)。在第一轮中，作者同意将28种偏见中的24种(85.7%的一致性)划分为11个类别。在第二轮研究中，作者对一种偏见分类意见不一致(96.4%的一致性)，并决定合并1种偏见圣和11th类别。表4展示了10个类别(CB1-CB10)的最终列表，以及它们与个人认知偏见的映射关系。
的偏见(CB1)类别是指人们倾向于根据预先设定的思维模式来选择手头任务的行动。这一类的偏差会导致开发人员不重视采取行动所需的解决方案空间探索程度。
所有权(CB2)发生在开发人员过分重视他们自己创建或已经拥有的工件时，从而减少了客观评估其他选项的可能性。对自己的工件的偏爱使开发人员无法完全探索解决方案空间。
固定(CB3)指将解决问题的努力锚定在初始假设上，而不是根据附加信息或相互矛盾的证据充分地修改该锚定。这导致对任务上下文的意识降低。
采取默认(CB4)发生在开发人员仅仅基于他们的默认状态选择现成的选项，或者不考虑适用性或适应性而倾向于选择当前条件的时候。这将导致丢失整个任务的上下文。
乐观(CB5)反映了一系列的偏见，导致错误的假设和过早的结论，有关效率或选择的解决方案的正确性。当人们过度信任自己的能力，或者高估了有利结果的可能性时，就会出现这种情况。
方便(CB6)包含了每个问题都存在简单原因的假设，以及采取看似更快或更简单的解决方法的倾向。这减少了开发人员在推理和理解信息上的投入。
潜意识的行动(CB7)指的是将评估和意义理解转移到外部资源(如ide或在线资源)，而不考虑这些信息的实际价值。
幸福的无知(CB8)指的是假设一切都是名义上的和工作的，即使面对指示相反的信息。正因为如此，开发人员不注意他们周围的环境。
肤浅的选择(CB9)表示一系列的行为和信息被基于肤浅的标准而过度重视。因此，开发人员在没有彻底推理的情况下就决定了解决方案。
记忆偏见(CB10)影响开发人员如何从一系列替代信息中记忆信息，更喜欢使用遇到的主要或最近的信息，或对记忆中最容易获得的信息做出反应。
5.结果
5.1.在开发人员的行动中存在偏见
实地研究包括2084个不同的开发商行动;在这些行为中，我们将至少包含一种偏见类别的953种行为分类。因此，大约一半的开发人员的行为(45.72%)与某种形式的偏见有关。注意，我们观察到的大量有偏见的行为(2084个中有953个)可能是由于决策行为中固有的认知偏见，这是软件开发的关键部分。
然而，并不是所有的认知偏见都必然导致消极的结果。偏见可以导致积极的影响——参与者比预期采取更少的行动。然而，在非受控环境中，我们无法区分“基线”(无偏差)或“优化”(偏差的积极结果)行动数量。因此，这里我们只关注反向行为(消极偏见)。
为了识别导致负面结果的偏见，我们使用逆转的行动。我们定义反转操作作为开发人员在以后需要撤消、重做或丢弃的操作。因此，反转动作指示了非最优解路径。
图1一个显示开发人员操作的分布(有偏见的或无偏见的)，以及它是否导致了消极的结果。有953个行为带有偏见，1131个行为没有偏见。同样，有1104个反转动作和980个非反转动作。逆转行为发生的概率为68.75%(759/1104例)，而逆转行为发生的概率为79.64%(759/953例)。
图1。偏置和反转作用存在的分布。圆圈的大小代表(a)动作的数量或(b)时间(以秒为单位)。总数显示在底部和右边的边缘，总总数显示在右下角。
为了验证这种关联，我们进行了带有Bonferroni校正的独立性卡方检验(以解释多重比较)13)．卡方检验显著(X2[4,N= 2084] = 499.35，p值≤2.2e- 16，与Bonferroni纠正)显示有偏见的行为与逆转高度相关。
为了评估这种关联的强度，我们估计了Cramer's V测度，表示偏差的存在和需要逆转的行为之间存在很强的关联(V= 0.5，当最小变量数为2时较大14)．
然而，如果花在逆转动作上的时间不多，那么仅靠逆转动作的数量并不能准确估计偏差的负面结果。我们分析了每个行动所花费的时间图1 b．每个细胞表示在每种类型的行动中所花费的时间(以秒为单位)。
总的来说，开发人员花了34.51%(7839/21407)的时间来扭转偏差行为。当只关注逆转动作花费的时间时，70.07%(7839/11187)涉及偏差。因此，有偏见的行为会导致显著的负面结果，因为参与者损失了大约25%的整个工作时间。独立性卡方检验支持这一假设，X2[4,N= 21407] = 5850.2，p值< 2.2e- 16显示时间花在扭转行动不是独立于有偏差的行动(与邦费洛尼纠正和大的效应大小与克莱默的V)。
不仅在软件开发中经常出现偏差(45.72%)，而且偏差行为也更有可能被逆转。此外，开发人员花费大量时间来扭转这些有偏见的行为。
5.2.偏差的后果
为了确定这些偏见对发展的影响，我们调查了偏见类别对参与者决策和解决问题的影响。
两位作者通过分析偏见和协商一致，将偏见类别的影响分为四个后果组。表5展示了对发展的偏见和相关类别的后果。
表5所示。偏差的后果。
我们确定了每个偏见类别对编程中四个正交问题解决活动的影响:(1)收集信息，15(2)理解信息，11(3)维护与任务和目标相关的信息(上下文)，3.(4)在必要的地方保持和集中注意力。10
不充分的探索。探索或搜集不同的信息10并评估替代方案7形成发展的关键部分。认知偏见有时会阻碍参与者投资于适当的探索。
减少探索通常会导致参与者创造出次优的解决方案。例如，P4需要来自哈希映射的数据子集，这就要求他查询哈希映射。由于他不熟悉查询接口，也不知道如何构造查询，所以他认为一个简单的解决方法(CB6)是手动收集数据。
[14:26]“最简单的做法是收集所有的输入语句，而不是使用查询，自己做这件事。”
然后P4开始实现这个功能的前提是(CB1)比手动收集数据更容易。然而，在尝试了接下来的18分钟后，他意识到实现比他预期的要困难得多，于是他决定学习如何查询hashmap。
减少意会。“意义建构”是一个通过认知信息来构建相关心智模型的过程，该模型可用于理解特定情境。11我们通过参与者表明之前的行为(和假设)是错误的言语来识别减少的意义。
例如，P10正在测试对数据管道(用于聚合和监视数据)的修改，发现在向管道添加新的输入数据文件后，她的测试失败了。她下意识地(CB7)跟随消息中建议的错误位置，没有对错误进行推理。最终，她发现她使用了较旧的输入文件，这导致了错误;更新这些文件后，她的测试工作正常。
(13:25)“……所以那个文件从一开始就不存在……”
上下文的损失。在导航和理解不同的信息集时，开发人员必须保留问题空间和相关信息的心智模型，以完成任务。3.当参与者对当前的任务或目标反复回溯或表达困惑(例如，失去当前行动的轨迹)时，可以看到语境的减弱。
当P3专注于(CB3)试图解决错误并偏离轨道，从而失去任务的更大上下文时，就显示了这一点。我们还观察到，当参与者对实现感到乐观(CB8)时，他们会暂停相关的上下文，继续执行任务。当这些参与者后来实现失败时，他们很难回忆起上下文。
错位的注意。注意力是我们认知系统的一个关键元素，它会影响开发人员认为哪些信息是相关的，开发人员如何解释错误信息，等等。偏见会导致开发人员将注意力转移到与当前任务无关的问题上。
当P4试图调试正在返回的查询函数时零，他认为问题可能是不正确的查询语法。[26:28]“这是Clojure的API，我正在寻找一些东西，告诉我如何检查列表是否包含一个vect。他变得如此专注于改变语法(CB3)，以至于他没有注意到语法高亮显示不再工作，他的环境已经失败了(CB8)。
偏见会影响开发过程中解决问题的多个方面。具体来说，偏差会影响开发人员如何充分地探索解决方案空间，他们如何彻底地参与意义构建，他们如何有效地保留环境，以及他们如何有效地投入注意力。
5.3.处理的偏见
为了进一步证明偏见在实践中经常发生，我们采访了16名开发人员，问他们:“你认为开发人员在(偏见类别)下的行为有多频繁?”
图2显示每一个偏差出现的感知频率;从“几乎从不”到“总是”。频率由红色的色调表示。深红色条表示高频率(经常，总是)，它们的百分比报告在最右边(例如，81%的受访者认为CB10是经常发生的)。浅红色条表示低频率(几乎从不，很少)，报告的百分比最左边(例如，6%发现CB10不常见)。中间的灰条反映了“有时”反应的频率，在随后的分析中被认为是中性的。
图2。从“几乎从不”到“总是”的面试中发现的偏见频率。偏差类别按频繁程度从高到低的降序排列(以%表示)。
总的来说，受访者认为偏见在软件开发中经常发生(图2)，与我们的观察结果相吻合。例如，当谈到便利偏好(CB6)时，IP12说:[32:12]“这种事经常发生!”这是技术债务发生背后的故事!三个月后，你会问为什么会失败?当你回头看，有人重写了一些东西，因为它更容易。它把一切都搞砸了!”
记忆(CB10)、便利(CB6)和偏见(CB1)的感知频率最高。这些评级至少部分地证实了我们的实证结果，因为便利(CB6)、固定(CB3)和先入为主(CB1)同样是最常见的五大偏见。然而，对于记忆偏差(CB10)和潜意识行为(CB7)，实际频率与开发者的感知频率并不匹配。
实践帮助。尽管当前的开发实践和工具并没有设计成避免认知偏差，但是开发人员可能仍然在使用它们来做到这一点。因此，在我们的采访中，我们要求参与者识别可以帮助他们/同事避免或恢复偏见的实践和工具。采访中有246条独特的建议。两位作者使用模式编码对这些建议进行了分类8-将类别分成更小的主题集的过程。出现了三个主题——开发实践，谁执行这些实践，以及何时执行这些实践。
表6显示这些类别和主题，以及这些实践可以帮助解决的偏差。最后一列列出了参与者认为对这些实践有用的工具。“类别”列指出了实践的类别，而“子类别”列描述了这个类别中有用的实践。“谁”栏表明团队(T)是否需要参与实践，或者个人(I)是否可以自己完成。“When”列指定实践是否需要在(B)、(D)或(A)任务之前完成。“偏差”一栏指出了每一种实践可以帮助解决的偏差。
表6所示。有益的实践。
五类建议如下。
退一步:从自己的开发模式中抽身出来可以帮助开发人员意识到有益的实践(如干净的代码)，这可以避免偏见，如先入为主(CB1)和记忆(CB10)。如描述的IP13文档的日子而且测试的盛会, (20:01):“在编写文档的日子里，我们会说，‘今天，我们不打算编写代码。我们将专注于检查文档，更新文档……‘你可能会遇到一些新方法……然后你下次更有可能使用它们。’”
同样地，通过集中和激励的培训来学习可以帮助形成“好的”实践，从而帮助开发人员避免像Convenience (CB6)这样的偏见。例如，IP14提到“干净的代码”研讨会是怎样的:[20:06]“真正灌输给我们所有人——哦，构建最高质量的代码真的很重要!”
不同的观点:欣赏一个不同的视角，加上相关的反馈，可以帮助避免偏见，如先入为主(CB1)，固定(CB3)和表面选择(CB9)。接触不同的方法可以帮助开发人员摆脱认知上的“引导循环”，迫使他们重新考虑、评估和证明任何后续行动。例如，结对编程可以帮助进行表面选择(CB9)，因为导航器可以在编程时指出推理中的任何错误。
系统方法:为了避免成为偏见或其他错误的受害者，个人应该系统地处理问题空间，探索可用的解决方案和工具。这种对不同任务参数的系统评估可以帮助开发者避免偏见，如先入观念(CB1)、记忆(CB10)和固定(CB3)，因为开发者可以更好地意识到潜在的陷阱，也可以提前考虑替代解决方案。正如IP7所解释的注意文档的做法:[14:49]“……(在选择工具时)我们的标准之一是(研究)它记录得如何?我认为好的文件非常重要。”
除了替代解决方案，系统探索还可以帮助开发人员牢记“大局”。换句话说，它迫使开发者更明确地欣赏和承认更大的目标，从而最大限度地减少他们分心的可能性原位。通过促进使用现有的相关代码(不一定只属于一个开发人员)，这可以防止诸如所有权(CB2)这样的偏见，这有助于保持更大的代码库向后兼容。
RTFM:在开始一项任务之前查阅文档可以避免偏见，比如，先见之见(CB1)、记忆(CB10)和所有权(CB2)，因为开发人员可以意识到解决问题的多种方法以及每种解决方案的缺陷。例如,团队日记而且剧本是开发人员记录库和包指南的日志，这些指南指定了如何使用任何代码工件和避免陷阱。
关于如何处理错误(或警告)及其严重级别的标准化的描述性文档，也可以帮助开发人员更快速地定位错误，从而克服诸如幸福无知(CB8)和乐观主义(CB5)这样的偏见。
过程:良好的软件工程实践，如尽早且频繁地设计和测试、敏捷软件开发等，可以在一定程度上帮助避免所有类别的偏见。开发人员可以通过编码标准和使用标准库来避免诸如所有权(CB2)和求助于默认(CB4)等偏见。这也有助于开发人员找到适当的代码来重用。
最后，有效的问题解决策略也可以帮助避免偏见，如固定(CB3)、便利(CB6)和潜意识行动(CB7)。例如,辐合思维训练-确定问题的具体解决方案可以帮助开发人员快速达成(具体)解决方案发散思维训练-探索问题的多种解决方案-可以帮助开发人员从一组备选方案中确定最佳解决方案。这可以防止开发人员将注意力集中在单一的解决方案上。
工具的清单。参与者觉得缺乏工具支持来帮助克服偏见，并且很难命名他们将使用的任何工具。他们推荐了以下他们希望存在的工具来帮助处理所列的每一种偏见:
固定(CB3):通过跟踪开发人员的操作并检测开发人员“专注”的情况，偏见可以被减少。然后它可以提示不同的操作。IP12解释说,[44]“ide -如果你改变[代码]，你总是得到相同的错误，它可以说，嘿，你已经做了5次相同的事情。但你总是得到相同的错误，也许可以尝试不同的东西?”
采用默认(CB4):开发者会屈服于这种偏见，因为这是一条阻力最小的道路;正如IP12所提到的，“如果有默认选项，他们就会使用它”，克服这个问题的方法将是通过工具个性化和规范。他认为工具的默认值应该更好地匹配当前的工作环境。例如，实现一个高级的“意图”向导，它允许开发人员向向导“输入他们的意图”，然后创建正确的默认值和与任务相关的参数。
乐观主义(CB5):在后台持续运行测试(和构建脚本)的工具可以通过识别开发人员可能没有验证的错误更改来消除这种偏见。IP12推荐(44)“(这个工具)会发现，‘嘿!这是[代码区]，我可以运行测试'，它会为你运行测试，而不需要你做任何事情。
然而，他警告说，如果这些工具不断地通知开发人员测试失败，它们可能会变得干扰和分散开发人员的注意力。
方便(CB6):有一种工具可以防止偏差，它可以识别出次优的代码更改，并推荐“干净”或“无异味”的代码。没有“快速修复”更改还可以帮助保持向后兼容性并减少技术债务。正如IP1所解释的，[14:36]“一些可以识别快速修复的工具……然后指出这种特定修复将导致的一些问题。”
潜意识行为(CB7):基于误导和反复出现的环境线索，可以通过注释失败、异常或不可靠测试的结果的严重性来防止。IP12提到注释不可靠的测试，[42:45]更新提示，说，好吧，这不是红色，这是血红色!因为有一个我们知道不应该失败的测试失败了。一个在过去20个版本中从未失败过的测试，现在却失败了!”
幸福的无知(CB8):可以通过突出问题的工具来避免，这些问题与开发人员以前遇到过的类似，否则会被忽略。IP15和IP12都描述了一种工具，它允许开发人员标记某些预期的失败，这样该工具就可以通知他们其他相关的失败。
内存(CB10):可以通过一个工具来避免偏差，该工具可以自动识别已弃用的方法，并推荐相关更新的API函数，而不是开发人员记住的函数。IP13提到(44):“API代码正在频繁地进化……而你不知道(更新的)方法……所以有一种方法告诉你，嘿，可能有更好的方法来做这件事。”
6.讨论
我们的研究结果表明，认知偏差经常会干扰开发，并在任务表现和投入的时间方面损害开发人员解决问题的能力。尽管开发人员目前使用标准和即兴实践的组合来处理偏差，但是缺少防止或帮助开发人员从偏差中恢复的工具。我们的发现有以下含义:
对于开发人员的含义。应该让开发人员意识到偏见对生产开发造成了重大威胁，而且可能比他们意识到的更普遍。我们综合了一系列有用的做法(表6)，有望减少认知偏差的影响。有些偏见需要组织层面的主动行动。然而，有许多开发人员可以单独使用的实践(例如，发散思维、防御性编程，等等)。受访者经常讨论这样的做法有长期的好处。
对工具制造者的影响。我们的访谈显示，开发人员认为缺乏处理偏见的工具支持。在第5.3节中，我们确定了开发人员设想的各种工具特性，它们可能有助于处理偏差。此外，由于开发人员目前依赖于标准和临时实践的组合来处理偏差，这些实践需要更好的工具来支持有效的实现。我们的研究结果为工具构建者提供了一个初始起点，以实现帮助预防和处理频繁出现的认知偏差的工具。
的局限性。如任何实地研究，在我们的研究中存在某些威胁，可能会挑战我们的发现。我们描述了其中的一些威胁以及减轻它们的步骤。
虽然我们的观察结果来自于一家软件开发公司的少数参与者，但该公司的创业性质确保了参与者在任务和工具方面的差异。我们的主要分析单位是2084名参与者的行为(与个体参与者相对)。为了支持这些观察结果，我们随后使用了一个更多样化的面试样本，包括来自大雇主和小雇主的参与者。
观察性研究容易混淆，如反应偏差，这可以影响参与者在我们的研究期间的反应。为了减轻这种威胁，我们在研究过程中只让一名研究人员直接观察参与者，但由另一名观察员在幕后支持。
7.结论
在本文中，通过对10名开发者的实地研究，我们调查了认知偏差在工作场所发生的频率，以及这些偏差如何影响发展。我们的研究结果表明，认知偏差经常会干扰开发，并损害开发人员解决问题的能力，如探索、意义构建和上下文意识。我们汇编了一套最初的实践和工具，开发人员目前使用(或希望)处理认知偏差。
目前的研究结果为未来的研究提供了一个有用的起点，未来对认知偏差的深入理解将有助于开发人员和研究人员实施更有效的预防措施，并指导工具构建者创建有策划的支持。
致谢
这项研究得到了美国国家科学基金(2008089和1815486)的部分资助。
参考文献
1.Calikli, G.， Bener, A.确认偏差影响因素的实证分析以及确认偏差对软件开发人员/测试人员性能的影响。在6th软件工程预测模型国际会议(PROMISE’10)。计算机械协会，纽约，纽约，美国，2010，第10条，1-11。DOI:https://doi.org/10.1145/1868328.1868344．
2.Calikli, G.， Bener, A.， Arslan, B.分析公司文化，教育和经验对软件开发人员和测试人员确认偏差水平的影响。在32届会议的会议记录ndACM/IEEE软件工程国际会议第2卷(ICSE’10)。计算机协会，纽约，美国，2010,187-190。DOI:https://doi.org/10.1145/1810295.1810326．
3.Chattopadhyay, S.， Nelson, N.， Gonzalez, Y.R.， Leon, a.a.， Pandita, R.， Sarma, a .活动中的潜在模式:开发者如何管理环境的实地研究。在41届立法会的议事录圣国际软件工程会议(ICSE’19)。电子学报，2019,373-383。DOI:https://doi.org/10.1109/ICSE.2019.00051．
4.Cruz, S.S.J.O, da Silva, F.Q.B, Monteiro, C.V.F.， Santos, P.， Rossilei, I.， dos Santos, M.T.软件工程中的个性:来自系统文献综述的初步发现。15th软件工程评估与评估年会(EASE 2011), 2011年1 - 10。DOI:10.1049 / ic.2011.0001
5.Easterbrook, S.， Singer, J.， Storey, m.a.， Damian, D.选择软件工程研究的经验方法。见:F. Shull, J. Singer, d.i.k Sjøberg主编。高级经验软件工程指南。施普林格,伦敦,2008年。DOI:https://doi.org/10.1007/978-1-84800-044-5_11．
6.Jorgensen, M.， Grimstad, S.软件开发评估偏差:相互依赖的角色。IEEE反式。软件Eng。38， 3(2012)， 677-693。
7.Mayer,右眼思考，解决问题，认知。心理学丛书。WH Freeman/时代图书/Henry Holt & Co, Worth Publishers，纽约，1992年。ISBN-13: 9780716722151。
8.迈尔斯，硕士，休伯曼，上午，休伯曼，硕士，休伯曼，M。定性数据分析:扩展的资料本。圣人,1994年。
9.Mohanani, R.， Salman, I.， Turhan, B.， Rodríguez, P.， Ralph, P.软件工程中的认知偏差:一个系统的映射研究。IEEE反式。软件Eng 46， 12(2020)， 1318-1339。DOI:https://doi.org/10.1109/TSE.2018.2877759．
10.在一个非常大的可浏览文本集合中信息气味跟踪的计算模型。在美国计算机学会计算系统中人为因素SIGCHI会议论文集(CHI '97)。计算机协会，纽约，美国，1997,3 - 10。DOI:https://doi.org/10.1145/258549.258558．
11.Pirolli, P.， Card, S.通过认知任务分析确定的分析师技术的意义制造过程和杠杆点。在第五卷国际情报分析会议论文集。2005年,2 - 4。
12.Runeson, P.， Höst, M.进行和报告软件工程案例研究的指南。经验软件工程， 2(2009)， 131。
13.你的卡方检验在统计上是显著的:现在呢?Pract。评估。Eval >, 20，(01 2015)， 1-10。
14.Sheskin, D.J.参数和非参数统计程序手册:第三版（3理查德·道金斯ed)。查普曼和霍尔/CRC，纽约，2003年。电子书ISBN 9780429186165。DOI:https://doi.org/10.1201/9781420036268．
15.Sillito, J.， Murphy, g.c.， De Volder, K.程序员在软件进化任务中问的问题。在14年的会议记录th软件工程基础国际学术研讨会(SIGSOFT '06/FSE-14)。计算机协会，纽约，纽约，美国，2006,23-34。DOI:https://doi.org/10.1145/1181775.1181779．
16.用知识获取系统批判人类的判断。人工智能杂志。11， 3(1990)， 60。
17.Tversky, A.， Kahneman, D.不确定性下的判断:启发式和偏差。科学185， 4157(1974)， 1124-1131。
18.温伯格,通用计算机程序设计心理学,卷932633420。Van Nostrand Reinhold，纽约，1971年。
脚注
a.我们无法研究性别是否与偏见有关，因为我们的研究中很少有女性参与者。
b。https://epiclab.github.io/ICSE20-CogBias/
要查看随附的技术观点，请访问doi.acm.org/10.1145/3517215
这篇论文的原始版本名为“一个来自战壕的故事:认知偏见和软件开发”，发表在ACM/IEEE第42届软件工程国际会议论文集(第654-665页)，2020年6月。
©2022 0001 - 0782/22/4 ACM
如果您不是为了盈利或商业利益而制作或分发本作品的部分或全部，并在第一页注明本通知和完整引用，则允许您免费制作本作品的部分或全部数字或纸质副本，供个人或课堂使用。本作品的组成部分必须由ACM以外的其他人享有版权。信用文摘是允许的。以其他方式复制、重新发布、在服务器上发布或重新分发到列表，需要事先获得特定的许可和/或费用。请求发布的权限permissions@acm.org或传真(212)869-0481。
数字图书馆是由计算机协会出版的。版权所有©2022 ACM股份有限公司
没有发现记录