Pair Programming in unserem Team

Eines wunderschönen, regnerischen Tages kam unser Teamleiter auf uns zu, mit der grandiosen Idee eines Blogartikels zum Thema Pair Programming, um aus unserem positiven Erfahrungsschatz zu berichten. Der Clou daran: Wir erstellen den Artikel in Pairing! :-)

Unsere Ausgangssituation

Zuerst wollen wir einmal kurz unsere Ausgangssituation beschreiben: Wir sind ein Team bestehend aus 4 Entwicklern bei Mayflower und zusätzlich 2-3 Entwicklern des Kunden.

Ursprünglich war eine feste Pairing-Rotation angedacht, wurde jedoch zugunsten einer spontanen Zusammensetzung, abhängig von Ausfällen wie Krankheit, Urlaub, Vor-Ort-Einsätzen etc., abgelöst. Trotzdem achten wir dabei darauf, dass möglichst jeder mal mit jedem pairt und wir eine regelmäßige Durchmischung erreichen.

Aktuell wechseln wir wöchentlich die Pairs und bearbeiten die Tickets je nachdem wie es gerade passend erscheint.

Unser Setup besteht dabei aus insgesamt drei verschiedenen Betriebssystemen (die wir auch durchrotieren), dabei sitzen jeweils ein Driver mit Tastatur und Maus und ein Navigator mit Witz und Köpfchen vor einem großen Bildschirm. Ein kleiner zusätzlicher Bildschirm (am Laptop) dient uns dabei meist zum Monitoren von z.B. Logausgaben.

Unsere Wechsel zwischen Driver und Navigator finden in 15-minütigem Abstand, sehr konsequent nach Uhr, statt. Damit erreichen wir auch tatsächlich den regelmäßigen Wechsel, denn keiner kommt in Versuchung zu lange auf seiner Position zu verweilen (da die Versuchung erfahrungsgemäß, gerade beim Driver, hin und wieder besteht). Nach 4 mal 15 Minuten machen wir dann immer eine 15-minütige Pause, die unser Wecker auch dafür beendet. Damit haben wir uns auch noch zusätzlich am Pomodoro-Prinzip orientiert. Da die Konzentration auf die Aufgabe meistens höher ist als bei der “Alleinentwicklung”, sind die Einheiten auch sehr anstrengend, was die Pausen dann auch notwendig und sinnvoll macht.

Je nach Projekt haben wir auch schon eine alternative Rotationsmethode angewandt, bei der Driver und Navigator test-driven arbeiten, d.h. der Wechsel findet nach dem Erstellen eines neuen Tests statt.

Das Pairing ist allerdings nicht vollständig starr, d.h. einer der Pair-Mitglieder kann früher mit der Aufgabe beginnen oder länger daran arbeiten, so dass wir die Arbeitszeiten nicht komplett teilen müssen und jeder seine Zeiteinteilung flexibler gestalten kann. Dadurch ist es dem einzelnen Teammitglied auch möglich, anderen Aufgaben wie z.B. der (E-Mail-) Kommunikation besser nachzukommen.

Gründe für das Pair Programming

Der für uns mit Sicherheit wichtigste Grund ist die kontinuierliche und umfassende Wissensverteilung. Dadurch, dass jeder mit jedem pairt, verteilen sich sowohl Methoden, Techniken sowie vorhandenes Fach- und Domänenspezifisches Wissen sehr effektiv.

Außerdem bleibt man konzentrierter bei der Aufgabe und wird weniger abgelenkt bzw. lässt sich weniger ablenken, z.B. durch E-Mails oder Chat.

Die Codequalität verbessert sich durch zwei Köpfe und vier Augen erheblich. Man spart sich z.B. Code-Reviews und jede Menge Fehler, die durch den anderen direkt entdeckt werden können. Dadurch wird natürlich auch erheblich weniger Debugging notwendig.

Des Weiteren finden sich bessere Lösungen durch Diskussionen, sowohl auf fachlicher als auch auf technischer Ebene.

Ein schöner Nebeneffekt des Pairings ist, dass dadurch die Teamarbeit und der Zusammenhalt im Team verbessert werden. Man lernt sich gegenseitig mehr zu vertrauen und kommt weniger in eine Art “Betriebsblindheit” oder auch Eigenbrötlerei hinein.

Von Vorteil kann es auch sein, dass die Verantwortung auf 2 Schultern verteilt wird. Somit ist es einfacher, mit problematischen Aufgaben zu beginnen und der Kunde hat mehr als einen Ansprechpartner, insbesondere wenn einer der beiden Entwickler nicht anwesend ist.

Eine gute Erfahrung war bei uns aktuell, dass ein neues Teammitglied schnell, d.h. gleich am ersten Tag, effizient eingearbeitet werden konnte und somit gleich zu Beginn produktiv am Projekt mitwirken konnte.

Außerdem macht Pairing einfach Spaß! :-)

Mögliche Befürchtungen

Trotz allen positiven Aspekten gibt es zu Beginn oftmals viel Skepsis, gerade von Kundenseite.

Hier wird unter anderem die Effektivität in Frage gestellt, da augenscheinlich erst einmal 2 Entwickler an demselben Problem arbeiten. Dies wird aber durch die oben genannten Gründe, gerade durch die verbesserte Codequalität und Effizienz, sehr schnell widerlegt.

Auf Entwicklerseite sind die Vorbehalte meistens in den Eigenarten der jeweiligen Personen zu finden. Oftmals existiert z.B. die Angst davor, dass der eigene Code den Ansprüchen nicht genügen könnte. Andererseits gibt es auch die Einzelkämpfer, die lieber keine “Tricks” preisgeben wollen. Hier hilft “Learning by doing”, denn die Erfahrung zeigt, dass die Zweifel oft unberechtigt sind und die Vorteile überwiegen. Diese Erfahrung muss einfach jeder einmal selbst machen. ;-)

Was auch manchmal angezweifelt wird, ist die Möglichkeit, tägliche organisatorische oder kommunikative Arbeiten zu verrichten. Wie schon oben angemerkt, lässt sich das aber prima vor und nach dem Pairing erledigen.

Hindernisse und Unterbrechungen

Trotz allem kam und kommt es auch bei uns hin und wieder zu Unterbrechungen des Pairings.

Wir haben z.B. die Erfahrung gemacht, dass man einfache “Copy und Paste”-Arbeiten nicht im Pairing umsetzen muss, sondern in dem Fall – ausnahmsweise – schneller ist, wenn man die Aufgabe parallel abarbeitet.

Ein durchaus nicht zu unterschätzendes Problem hatten wir in dem Fall, dass es Konflikte zwischen den Teammitgliedern gab. Es mangelte an gegenseitigem Vertrauen und damit gab es einen Bruch, so dass wir eine längere Pairingpause hatten. Durch die Änderung der Teamzusammensetzung stellt sich dieses Problem bei uns nun nicht mehr. In bestimmten Teamkonstellationen kann es leider trotzdem schwierig sein, ein regelmäßiges Pair Programming aufrecht erhalten zu können.

Um mögliche Konflikte zu vermeiden und den Teammitgliedern ab und zu Rückzugsmöglichkeiten einzuräumen, legen wir z.B. manchmal auch einen Tag Pause ein.

Unser Fazit

Aus unseren Erfahrungen mit Pair Programming und diesem Blogartikel, sozusagen Pair Writing, können wir sagen, dass es sich fast immer lohnt, Pairing zu betreiben.
Es empfiehlt sich daher, gerade bei anfänglichen Bedenken, einfach mal mit einer kleinen Aufgabe im Pair zu beginnen und dies dann auch konsequent mit Uhr zu betreiben.
Gerade neue Teammitglieder können so schnell und effektiv eingearbeitet werden.
Wenn die Teamkonstellation passt, hilft das Pair Programming auch beim Teambuilding. Hin und wieder vergessen wir sogar vor lauter Flow, rechtzeitig unsere Pausen zu machen.

Was wir demnächst als weiteres Experiment ausprobieren wollen, ist das Remote Pairing mit den Entwicklern des Kunden!

Dieser Blogartikel hat im Pairing jedenfalls Spaß gemacht! :-)

Diana und Benedikt

Weiterführendes Webinar

Übrigens, wer mehr über Pair Programming erfahren möchte, dem legen wir unser Webinar zu Pair Programming Mythbusters am 11. Juni nahe. Teilnahme ist kostenlos, einfach registrieren.