Noch immer hält sich selbst in Entwickler-Kreisen das Vorurteil, Pair Programming würde die Entwicklungsgeschwindigkeit reduzieren.

Klar, wenn zwei Entwickler an einem Rechner sitzen kann immer nur einer Tippen. Doch ist Programmieren wirklich nur das Abtippen von Code? Und wenn dem so ist, warum schafft es auch der beste Programmierer nicht am Tag mehr Zeilen zu schreiben, als eine durchschnittliche Rechtsanwaltsgehilfin in einer Stunde?

Ich habe selbst schon Pair-Programming-Sessions erlebt, bei denen zwei Entwickler vor dem Rechner reine Verschwendung waren. Dabei kann man mit einem motivierten und disziplinierten Paar sowie einer Hand voll best practices, die Velocity mit Hilfe von Pair Programming durchaus verdreifachen.

Vorbereitungen

Folgendes sollte beim Pair Programming zur Verfügung stehen:

• Zwei motivierte und gut gelaunte Entwickler.
• Ein aufgeräumter Schreibtisch, an dem beide Entwickler genug Platz haben um sich auszubreiten.
• Einen fertig eingerichteten Entwickler-Rechner für den Driver.
• Ein Notebook oder ein Tablet für den Navigator
• Ein Notizblock und Stift für den Navigator
• Eine Stoppuhr

Gerade als Stoppuhr eignet sich auch eine App auf dem Navigator-Rechner sehr gut. Insbesondere da hier die Möglichkeit besteht mehrere Stoppuhren zu starten, was für „Ping Pong“, eine spezielle Pair-Programming-Methode beim Test Driven Development, sehr nützlich ist. Zu beachten ist jedoch, dass die Stoppuhr auch für den Driver immer einsehbar sein sollte und darum immer im Vordergrund ist.

Auch für Notizen kann sich das Notebook oder Tablet des Navigators sehr gut eignen. Insbesondere wenn man seine Notizen gleich ins Ticketsystem eintragen will. Verzichten sollte man auf den Notizblock allerdings nur, wenn ein Whiteboard oder eine entsprechende App mit Stift zur Verfügung steht. Nichts unterstützt die Kommunikation zwischen Entwicklern besser als ein schnell gezeichnetes Diagramm.

Der Driver

Für den Driver ändert sich im Pair Programming kaum etwas im Vergleich zum Single-Programmieren. Der größte Unterschied besteht für ihn nur darin, dass er sich mehr auf den Code konzentriert, den er gerade schreibt und weniger zwischendurch in irgendwelchen Dokumentationen nach Antworten zu Fragen zu suchen, die gerade nicht relevant sind.

Zudem muss sich der Driver an die vorgegebene Timebox halten und die Tastatur auf das Signal der Stoppuhr hin, dem Navigator übergeben. Die positiven Effekte des Pair Programmings  werden sich nicht einstellen, wenn der Driver nach dem Ablauf von 20 Minuten „nur noch schnell“ eine Funktion fertig schreiben will und dann noch 1,5 Stunden in die Tasten haut.

Der Navigator

Der Navigator unterstützt den Driver bei der Entwicklung, indem er ihm all die Dinge abnimmt, die ihn aus dem Fluss bringen könnte.

Er sucht im Internet nach einer Funktion, notiert sich Dinge die man noch verbessern könnte und beantwortet Fragen seines Drivers. Wichtig ist: Der Driver führt und der Navigator beobachtet und unterstützt.

Man sollte sich als Navigator immer bewußt sein, dass der Driver die Führung hat. Kaum etwas ist schlimmer als ein Navigator, der einem Driver die ganze Zeit ungefragt vorschreibt, was er zu tippen hat.

Natürlich soll der Navigator den Driver auf Fehler hinweisen. Darum ist es wichtig, dass jedes Paar sich ein Gespür dafür erarbeitet, wann ein Fehler es Wert ist den Driver in seiner Konzentration zu stören und  wann man den Driver den Fehler selbst finden lässt oder sich eine Notiz macht.

Der Ablauf

Jeder, der etwas mit agiler Softwareentwicklung zutun hat weiß sicher dass alle 20 Minuten die Rollen getauscht werden und der Driver zum Navigator und der Navigator zum Driver wird. Meiner Erfahrung nach ist für ein erfolgreiches auch entscheidend, was zwischen den Wechseln passiert:

• Bei jedem Wechsel sollte der Navigator den Driver darüber informieren, was ihm in der letzten Session aufgefallen ist und was er notiert hat.
• Jede Stunde (also nach 3 Sessions) sollte ein kurzes 5 minütiges Retro stattfinden, in dem die beiden Entwickler reflektieren, wie die letzte Stunde gelaufen ist und was man verbessern kann.
• Alle zwei Stunden (also nach 6 Sessions) sollte dieses Retro mit einem Spaziergang verbunden werden.

Gerade der letzte Punkt wirkt auf die meisten Entwickler etwas befremdlich. Wer aber wirklich einmal 8 Stunden am Tag Pair Programming gemacht hat wird feststellen, wie erschöpfend dieses hochkonzentrierte Arbeiten ist. Die kurze Bewegung alle zwei Stunden ist also essentiell um die Leistungsfähigkeit aufrecht zu erhalten. Insbesondere dann, wenn der Arbeitstag einmal länger als 8 Stunden werden sollte.

Ping Pong

Beim Test Driven Development (TDD) bietet sich „Ping Pong“ an. Der Ablauf ist folgendermaßen:

• Entwickler A schreibt einen Unit-Test
• Entwickler B implementiert die Funktionalität bis der Test grün ist
• Entwickler A refaktorisiert sowohl die Funktionalität, als auch den Test, bis A und B zufrieden sind.
• Nun schreibt Entwickler B einen Test
• …

Ein Ziel von TDD ist es, möglichst kleine Tests zu schreiben, die genau ein einziges Verhalten einer Klasse abtesten (auch bei Tests gilt wie überall „Single Responsibility“). Dies erreicht man mit Ping Pong sehr gut. Insbesondere, wenn man zwei Stoppuhren einsetzt, die jeweils die Gesamtzeit messen in der ein Entwickler der Driver ist. Diese, aus dem Blitzschach entlehnte Methode,  führt zu einem kleinen Wettkampf zwischen den Entwicklern, der sehr kurze Iterationen fördert. Iterationen von 20 Minuten sollten beim Ping Pong nicht vorkommen. Falls doch, ist es vielleicht ratsam zum konventionellen Pair Programming mit fester Timebox zu wechseln.

In keinem Fall sollten auch beim Ping Pong die regelmäßigen Pausen und Retrospektiven vergessen werden.