reports

Pair Programming - Driver, Navigator oder Tour Guide?

von Stefan Scheidt
24.06.2019

Viele unserer Teams bei REWE digital praktizieren Pair Programming. Das bedeutet, dass zwei Entwicklerinnen oder Entwickler gemeinsam an einem Rechner arbeiten. 

Pair Programming bietet viele Vorteile:

  • Pair Programming ist eine Form von “Extreme Code Review”.

  • Es fördert den Konsens über die entstandene Lösung und “Collective Code Ownership”.

  • Genauso unterstützt es die Wissensverteilung im Team.

  • Es limitiert “Work in Progress”.

  • Es öffnet Türen für Arbeitsweisen wie beispielsweise Trunk Based Development ohne Pull Requests, die wiederum ihre eigenen Vorteile mit sich bringen.
     

Pair Programming birgt aber auch einige Herausforderungen:

  • Die Pairing Partner präferieren eventuell unterschiedliche Betriebssysteme, Tastatur-Layouts, IDEs und Key Bindings.

  • Die Arbeitsplatzergonomie muss die gemeinsame Arbeit an einem Computer ermöglichen.

  • Effizientes Pair Programming ist nur möglich, wenn es genügend unterbrechungsfreie Zeiten im Arbeitstag gibt, in denen ein Pair zusammen arbeiten kann.

  • Pair Programming ist anstrengend. Häufig macht ein Pair nicht rechtzeitig und nicht oft genug Pausen.

  • Durch Pair Programming kann nur dann Collective Code Ownership entstehen, wenn die Pairing Partner oft genug wechseln. Dazu müssen alle Team-Mitglieder einen Modus finden, in dem sie gut als Pairs zusammen arbeiten können.

 

Diverse Studien belegen, dass Pair Programming keinen negativen Einfluss auf die Entwicklungsgeschwindigkeit eines Teams hat. Unsere Erfahrungen bestätigen das.

 

Im Rahmen der Auseinandersetzung mit den Herausforderungen haben wir haben uns unter anderem etwas intensiver mit möglichen Modi der Zusammenarbeit beschäftigt.

Rollenverteilung

Neben der unstrukturierten Zusammenarbeit, bei der zwei Menschen “einfach so” zusammen arbeiten, gibt es beim Pair Programming mindestens folgende gängige Rollenverteilungen:

  • Tour Guide & Tourist

  • Driver & Backseat Navigator

  • Driver & Navigator

Tour Guide & Tourist
 

Bei dieser Rollenverteilung fungiert der Pairing Partner an der Tastatur als “Tour Guide”, der andere Partner oder die Partnerin ist der “Tourist”. Der Tour Guide erledigt die anstehende Aufgabe und erläutert dabei alles, was sie tut, und weist auf “interessante Sehenswürdigkeiten” hin. Der Tourist verfolgt das gezeigte und stellt bei Bedarf Rückfragen.

Diese Rollenverteilung ist geeignet, um “neue” Kollegen in ein Thema - fachlich oder technisch - einzuführen. Der Tourist ist dabei aber oft passiv und muss aktiv darauf achten, “dabei zu bleiben”. Der Tour Guide kann dies durch Fragen an die Partnerin (“Ich würde das jetzt so einchecken. OK?”, “Ich glaube, wir brauchen noch einen Test. Was meinst Du?”, ...) unterstützen.

Driver & Backseat Navigator
 

In dieser Rollenverteilung diktiert die Partnerin, der nicht an der Tastatur sitzt, dem Partner, was genau er tun soll - wie der Backseat Driver, also der “Besserwisser” beim Autofahren. Der Driver ist nur das ausführende Organ.

Auch diese Rollenverteilung eignet sich für eine “Expert - Novice”-Konstellation, der “Novice” ist aber viel stärker aktiv eingebunden als “Tourist”. Dafür muss der Backseat Navigator gut und auf einem angemessenen Abstraktionsniveau erklären können, was getan werden soll. Beachte aber auch die nachfolgenden Erläuterungen zum sogenannten “Strong-style Pairing”.

Driver & Navigator
 

Dies ist die Rollenverteilung, die bei Paring Partnern mit vergleichbarem Kenntnisstand (fachlich wie technisch) meist angestrebt wird. Es spielt auf die Teamarbeit von Fahrer und Beifahrer bei einer Rallye an. Der Driver konzentriert sich gänzlich auf die Details des Kodierens, der Navigator behält den größeren Überblick und stellt Rückfragen.

Der Driver unterstützt diese Rollenverteilung, indem sie beispielsweise

  • einen Ausblick gibt, wohin sie “fahren” möchte (“Lass uns zunächst den Datenbankzugriff implementieren.”),

  • ausspricht, was sie denkt (“Ich implementiere zunächst A. Dann kann ich dies später bei B benutzen.”),

  • Erwartungen formuliert (“Dieser Test sollte jetzt fehlschlagen.”) und

  • Offensichtliches erfragt (“Können wir das so committen?”).

Der Navigator kann unterstützen, indem er

  • der Handlung “der Geschichte” folgt,

  • Annahmen bestätigt oder zurückweist,

  • Begründungen erfragt, wenn der Fahrer überraschende oder unerwartete Wege einschlägt,

  • vorausschaut und sich Gedanken über die nachfolgenden Aufgaben macht

  • nach einem Ausweg ausschau hält, wenn er das gefühl hat, das Pair steuert auf eine Sackgasse zu.

Rollentausch
 

Bei der Driver-Navigator-Rollenverteilung sollten regelmäßig die Rollen getauscht werden. Dies kann beispielsweise durch einen Timer geschehen, der alle 10 Minuten an das Tauschen erinnert. Praktiziert das Team testgetriebene Entwicklung, kann auch Ping-Pong-Pairing verwendet werden: Pairing-Partner A beginnt das Pairing damit, einen fehlschlagenden Test zu schreiben. Pairing-Partner B macht den Test grün und refaktorisiert in der Rolle des Drivers. Anschließend wird getauscht: B schreibt einen fehlschlagenden Test und A macht ihn als Driver grün.

Bei den anderen Rollenverteilungen gestaltet sich der Wechsel inhaltlich schwieriger, wenn er bei einer “Expert - Novice”-Konstellation eingesetzt wird. Ein “Novice” kann zum Beispiel meist nur eingeschränkt die Rolle des Tour Guide übernehmen. Möglich ist aber, bei einem Rollentausch auch die Rollenverteilung zu wechseln: Der Expert wird von Tour Guide zum Backseat Navigator, der Novice wird vom Tourist zum Driver.

Strong-style Pairing

Eine interessante Variante des Driver-Navigator-Pairing kann das Strong-style Pairing sein. Aufgebracht wurde diese Idee von Llewellyn Falco. Die goldene Regel dieses Stils lautet: “For an idea to go from your head into the computer it MUST go through someone else's hands”. Damit kombiniert es Elemente von Driver & Navigator und Driver & Backseat Navigator. Es adressiert beispielsweise Situationen, in denen der klassische Driver zu dominant ist oder der klassische Navigator nur noch zuschaut. Es etabliert also eine Art von Gewaltenteilung zwischen Driver und Navigator und bezieht den Navigator aktiver in das Geschehen ein.

Abschließend bleibt zu sagen, dass Pair Programming natürlich nur möglich und sinnvoll ist, wenn es das entsprechende “Buy In” der Beteiligten gibt. Nicht alle Menschen fühlen sich in Pairing-Situationen wohl, und das muss man respektieren. In solchen Situationen kann es interessant sein, nicht einen Schritt zurück, sondern Schritt nach vorne zu machen und statt Pair Programming einmal eine Mob Programming Session auszuprobieren.

Nächste Story von Stefan Scheidt

Softwerkskammer Köln

Stefan Scheidt

Suche hier nach Stories, Jobs und Themen…

question mark
Hoppla!
Leider konnten wir unter dem von Dir gewünschten Suchbegriff keine Ergebnisse finden.