配对编程什么时候起作用?什么时候避免呢?


51

并非一直在刻苦地配对编程,而是在团队中选择性地使用配对编程。我认为在以下情况下效果最佳:

  • 加强项目中全新的团队成员(而不是让他们自己浏览文档或代码)。
  • 初级和高级人员一起工作(有助于显示经验丰富的开发人员的一些技能和技巧,此外,它还允许老狗有时学习新的技巧)。
  • 当某人试图查找缺陷时,通常可以帮助您与另一只眼睛配对。

什么时候使用配对程序,为什么?

什么时候避免成对编程?为什么?


11
试图在回答问题三年后,客观地明确地参考经验研究,以了解解决这个问题的价值和逻辑。在敏捷通用的所有实践中,这是研究和记录最多的实践之一。问题的措词是否需要以某种方式更改?自发布以来的三年中,期望/标准有没有改变?
2014年

Answers:


44

劳里·威廉姆斯(Laurie Williams)编制的研究表明,结对编程最适合工业团队

  • 结对执行规范,设计和复杂的编程任务 -实验表明,成对地处理简单任务不会显示质量改善,但可能会提高速度。还要注意,“编程”对通常包括编写代码以外的活动。
  • 配对中的每个人都具有大约相同的专业知识水平 -虽然配对编程非常适合训练,但是当配对大致相同时,配对就最为投入。
  • 角色定期轮换 - 定期轮换有助于保持现任副驾驶的积极性,因为个人在开车或感觉自己将要开车时往往贡献最大。
  • 配对定期轮换 -团队在了解他们所构建的系统的不同部分时表达了安慰。结对轮换有助于知识转移,从而减少了项目中的某些风险。在学术环境中,通常会分配对,但是在行业中,通常在站立时通常是自分配的。在两种情况下,当两个人都愿意在配对活动中看到有价值的参与者时配对最为有效。

根据我的亲身经历,我发现我的XP团队平均花费大约60%的开发时间对编程。其余时间用于个人开发。配对以创建初始设计,在设计上单独工作几个小时,然后再聚在一起完成代码中棘手或困难的部分,这种情况并不罕见。

我还发现,结对编程在大约1.5到2.5小时内最为有效。少得多的东西往往会要求太多的设置开销,而更多的东西会使配对变得胡思乱想和疲倦。脾气暴躁而又疲倦的人意味着您沟通不畅,并且可能会让缺陷渗入系统中。


迈克尔的好答案。从许多好的答案中接受这一点,因为它结合了个人经验和与研究的紧密联系。
Paddyslacker 2011年

具有讽刺意味的是,尽管在您发布答案时该链接有效,但现在它是404了!
Paddyslacker 2011年

我在您的答案Michael中修复了超链接,所以一切都很好。
Paddyslacker 2011年

“复杂”部分非常重要。如果您进行琐碎的打字工作,您的伴侣将很快感到无聊。
Dave O.

3
@DaveO:我只能使用结对编程来做简单的事情。对于复杂的任务,我需要考虑,而结对编程只是一种分散注意力的源泉(请参阅Will Sargent的回答)。我仍然发现与同事讨论复杂的问题非常有用,但这不同于一起编写整个代码。
Giorgio

29

结对编程在很少情况下为我工作。

配对编程对我失败的地方

简短的故事是,结对编程不适用于我开发软件的主要方式。我可以将程序配对一天或一周,特别是如果我们专注于特定问题。但是之后呢?我受够了。吐司 我不想见任何人,不与任何人交谈,而且我至少需要在山洞里待几天,直到我再次适合人陪伴。

这是一个悲伤的故事,但有趣的是,我现在对它的结局感到更加高兴。我很高兴地受雇于一份合同,可以在家中或在咖啡店工作,而且我结了新朋友,并在旧金山以外的地方进行了前所未有的探索。我有一辆自行车和一台笔记本电脑,只要我按时完成任务并定期检查代码,我的时间就是我自己的时间。

我将在前面列出配对编程遇到的主要问题,稍后再提供详细信息和轶事。

  1. 分割焦点。
  2. 没有实验。
  3. 没有高音。
  4. 对所有权不感到自豪。
  5. 无法逃避...

...我问我的同事们是否看到了我看到的东西,如果我缺少任何东西,我什么也没看到-我没有看到这怎么工作,人们如何继续做下去。他们说我做的很好,只是花了一些时间适应和调整。起初,每个人都很难。

最终,我退缩了自己。在令人头疼的头痛,失眠和无法满足的编写代码需求之间,我停止了对输入的响应。我可以凝视屏幕,什么也看不到。有人可能会意外地与我交谈,而我听不到他们的声音。我满足了工作的死记硬背的要求,但当时我不在那里。我已经用光了当天刚出现的一切。当我的另一位伙伴打字时,我开始检查iPhone。

最终-距离三个月后还不到第一次,而且这是有史以来的第一次-我因为结对编程时不适合团队而被解雇。

不孤单

我写这篇文章不仅是为了理解它,而且也是为了谈论它。有一种假设,即结对编程对大多数人都有效,并且比单独编程要容易和快捷得多。这可能是,也可能不是,但是从长远来看,结对编程对我不起作用。配对编程对许多其他人都不起作用。我们也很重要


2
我也是。仅在缺陷跟踪方面,甚至比真正的编程还要集思广益和富有思想。
hplbsh

4
+1有见地的答案。有时,结对编程倡导者会忘记我们的独来独往和内向的人。碰巧的是,许多对编程感兴趣的人也是内向的……
Andres F.

6
@AndresF .:除了独来独往的人和内向的人之外,还有一些人是独立的,只是需要自己的空间来组织思想。为了在团队成员之间传播知识,代码审查至少与结对编程一样有效。
乔治

2
@乔治同意。我实际上支持部分结对编程:成对解决一些难题。但是有些拥护者认为大多数情况下,大多数情况下都应该使用它,但我不同意。
Andres F.

4
@AndresF .:我同意你的看法。“部分对编程”或用不太时髦的词语“在需要时一起讨论一些难题”是一种非常合理的方法,不仅用于编程,还用于在学校学习时等。但是,我不考虑这种做法应当一直使用的银色子弹。
乔治

10

我的团队从成立之初就开始进行结对编程,这是我在那之前工作的很长时间,这是一家以“极限编程”风格为主的商店的一部分。配对编程是默认状态 ; 人们只会在单数奇数的情况下才真正地单身,或者偶尔进行调查,尤其是那些涉及摆弄敌对设备并试图使其工作的人。

“初级/高级”不是唯一的方法。“中级/初级”很有用;通过强迫他与他人交流,它可以帮助中级人员综合获得的知识。“中级/中级”挑战两个人一起工作以共享他们的知识,进行交流并成为团队的一部分。即使您有两个真正的资深人士,他们也有可能拥有不同的专业领域,并且可以提出不同的方法。一旦有人含糊地“加快”项目的进度,知识共享方面就不会结束。相反,结对编程是学习型组织的缩影。新技术和最佳实践迅速传播。

结对编程还有助于保持代码的质量(较少的缺陷)和代码的完整性(它不仅可以完成预期的工作,还可以完成应做的工作 ……理想情况下,无需花费数周的时间,孔做错事,或者两个不同的正确事会发生冲突)。它可以帮助程序员保持专注:在硅谷的心脏地带,每周工作80小时,我们每周只能工作40个小时,因为我们每天要进行8个小时的密集编码,因此需要切换彼此离开。(此外,如果您花更长的时间进行结对编程,则可能会退出。或者至少会疲惫。) 这对于工作/生活平衡非常有用,并且在重要的是要有快速周转(特别是低延迟周转)时,也可以为您的组织提供帮助。

并非全部是100%桃子和奶油。我发现结对编程有时会妨碍我应用直观的大脑过程,这对某些问题很有用。最近,在执行内存泄漏任务时,我花了一些时间来配对和不配对。没有一个人,我就可以随意闲逛并尝试实验,而不必真正地确切地知道如何在任何时刻解释我的所作所为。在单例中工作还具有一些优势,能够立即切线并进行某些狂野的重构(在XP方法论中很有价值)。

但总而言之,收益远远超过成本,而配对对我们而言效果显着:从创业阶段到被一家大公司收购,以及随后的整合。(说到这一点,结对编程已帮助我们通过扩展和很少的营业额来保持文化的连续性)。

(我们在Perl开发了一种软件设备,标价约4,000-40,000美元。)


4

我从来没有在“配对编程”设置中工作过,但是我可以声称这是您列出的三种情况的一部分。您提到的场景似乎更像是“常规编程”,其中包含了帮助/培训的各个阶段。在“成对编程”出现之前,我们是否没有完成所有这些工作?配对编程,我认为这需要一种更加专注的方法,即团队内部的共享过程不会在您解决眼前的任务或问题的那一刻就停止。但这就是我“思考”而不是我“知道”的东西。

对于结对编程,我个人希望与一个团队合作,让我有机会学习和分享我的知识。一个不平衡的团队,与您一起工作的每个人都在您前面几英里远,或者远低于标准水平的团队可能很快就会变得毫无兴趣。另外,我害怕与坚定信念并难以说服的人一起工作。


没错,我们可以解决我提到的情况而无需成对编程,但是我们使用成对编程技术,一个人驾驶另一个人观察并定期关闭它们。这比帮助/培训更为正式。许多XP商店所进行的配对编程要比这多得多-我想知道人们的配对“正确”数量是多少。
Paddyslacker

是的,我也很想听到与PP长期合作的人的来信。我可以理解与多个公司或团队合作的顾问如何从PP中受益,但是这些任务通常需要持续几个月。了解PP在一家通常持续超过一年的典型软件公司中的工作方式将很有趣。
Preets 2010年

2

在过去的几个月中,我们一直在我们的团队中尝试使用Pair编程。当您在开发新事物(新技术,新功能等)时,我觉得它非常有用,因为您可以与团队中的另一个人快速地提出想法并对其进行验证/验证。此外,并排的同行评审有助于防止错误发生。

另一位队友尝试使用结对编程和测试来进行ATDD,他们对结果感到非常满意(根据他的计算,开发成本增加了20%,导致测试时间减少了约50%)


1

晚安

关于极限编程和结对编程的实践,我们辩论了很多次。时光倒流,我们能够理解编程是一种单独的活动,因为程序员需要专注和孤立。当时的程序员们在,精神状态,他们可以有效地专注于代码,使漂亮的和创造性的决策。

如果您假设一个程序员互相中断,那么结对编程似乎也有风险。另一方面,打断两个程序员一起工作更困难。例如,在Solo编程中,中断会更容易,因此,一个单独的程序员几乎不可能停留在“区域”中。

当死角指日可待时,代码质量是另一个。人们总是很匆忙,无论是结对程序员还是独行程序员:他们不会采用某些最佳实践,而只会忘记单元测试。

我会坚持结对编程。因为当遇到风险时,如果一名程序员离开了,您将总是有另一个人来记录该过程并教其他所有人该过程如何工作。


1

处理任何非同寻常的复杂性往往是结对编程的一个不错的选择,因此多个人都可以理解代码,而不是只有一个开发人员知道部分代码库。另一种情况是某人想转让一些技能。这里的一个例子可能是让一个真正擅长单元测试的人与一个不太熟悉该概念的人结对,因此有助于养成某种东西的初步习惯。

至于避免配对编程的地方,请做一些简单的工作任务,最好将工作分为两组,让每个开发人员分别完成一些工作以完成工作。有些任务可能只需要键入一些内容,但规模并不大,值得花几个小时尝试找到更好的方法来完成,因为如果每个开发人员都采用蛮力的方法,那么就可以这样做小时。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.