Entwickler in der „Paarungszeit“

Ein Erfahrungsbericht über Pair-Programming

Ein neues Projekt, neue Teammitglieder, agile Entwicklung mit Scrum, Pair-Programming und das große Ziel, diesmal alles richtig und gut zu machen: das ist die Kurzzusammenfassung meines ersten Tages im neuen Projekt. Bisher war Pairing für mich eher die Ausnahme, nun sollte es zur Ausnahme werden nicht zu pairen. Ich war gespannt, ob ich es schaffen würde, den ganzen Tag mit einer anderen Person am selben Rechner zu arbeiten, die ich kaum kannte.

Was versteht man unter Pair-Programming

Pair-Programming bedeutet, dass zwei Personen am selben Rechner dasselbe Design, denselben Algorithmus bzw. dasselbe Stück Code bearbeiten. Im Pair-Programming gibt es zwei Rollen, den Driver und den Observer. Der Driver ist aktiv und in Besitz der Tastatur und Maus. Er programmiert, während der Observer aufmerksam beobachtet, mitdenkt und versucht, das große Ganze im Blick zu haben und kritisch zu hinterfragen. Somit findet ein kontinuierliches Code-Review statt. Diese Rollen sollten regelmäßig, etwa alle 30 – 60 Minuten, getauscht werden. Man lernt also gegenseitig voneinander. Vor jedem neuen Schritt wird miteinander über mögliche Lösungsansätze gesprochen. Dies führt dazu, dass in kleinen Schritten gearbeitet wird. Die Partner der Pairs sollten regelmäßig getauscht werden, beispielsweise jedes Mal wenn eine Story erfolgreich durchgeführt wurde.

Man könnte nun glauben, dass Pairing den Aufwand und damit die Kosten in die Höhe treibt. Studien [1] belegen jedoch, dass

… Pairing am Ende sogar wirtschaftlicher und effektiver ist, als kontinuierlich alleine zu arbeiten.

Wie kann das sein? Dazu später mehr.  Zunächst mal meine Erfahrungen mit Pair-Programming.

Herausforderungen

Im Team gibt es meist verschieden Erfahrungslevels, von Anfänger bis Experte, die unterschiedlich miteinander kombiniert werden können, z.B.:

• Der Experte übernimmt die Rolle des Mentors.
• Der Anfänger übernimmt häufiger die aktive Rolle des Drivers.
• Der Anfänger kann den Experten dazu bringen, über Dinge nachzudenken bzw. zu hinterfragen.

Weitere Hürden gilt es zu meistern:

• Große Büros mit vielen Arbeitsplätzen: denn schon bei zwei Pairs steigt der Geräuschpegel durch die Diskussionen
• Räumliche Trennung (verschiedene Standorte) der beiden Pairing-Partner ist anders und man benötigt eine gewisse Zeit der Eingewöhnung.
• Fluktuation im Team ist selten gut, dies gilt auch für das Pair-Programming: jeder Pairing-Partner ist anders und man benötigt eine gewisse Zeit der Eingewöhnung, verändert sich nun das Team, ändern sich damit die möglichen Partner.
• Seine Komfortzone zu verlassen ist nicht für jeden Entwickler gleichermaßen einfach:
  • sei offen für neue Methoden und Tools
  • habe keine Scheu vor der „Kontrolle“ des Pairing-Partners
• Nicht vergessen regelmäßig die Rollen zu wechseln (alle 30 – 60 Minuten).

Meine Erfahrungen

• Permanent zu zweit zu arbeiten ist ganz schön anstrengend
• Es fällt schwer konsequent die Rollen zu tauschen. Häufig ist es sogar so, dass die Rollen des Drivers und Obervers beibehalten werden, auch nach einem Tausch zwischen den Pairing-Partnern
• Als Driver habe ich das Gefühl alles dem Observer erläutern zu müssen, was nochmal anstrengender wird, wenn mehr als ein Pair im Raum ist
• Als Observer habe ich manchmal das Gefühl den Driver mit meinen Fragen auszubremsen
• Es ist mühsam wenn beide Entwickler (noch) keine Umsetzungsidee haben und erst noch recherchieren möchten. Für mich funktioniert das besser alleine
• Die Kombination zwischen Anfänger und Experte ist nochmal eine größere Herausforderung, da ich mich in die jeweilig andere Rolle noch mehr versuche hineinzudenken

• Manchmal genügt es schon, sich selbst im Gespräch laut denken zu hören, um ein Problem zu erfassen
• Brainstorming und die Suche nach Fehlern funktioniert häufig besser zu zweit
• Oft findet man gemeinsam aussagekräftigere Namen, einfachere Lösungen
• Fehler fallen früher auf, man spart sich oft die Zeit zu kompilieren und neuzuladen
• Pausen werden bewusster gemacht
• Gemeinsame Erfolgserlebnisse motivieren
• 2 Monitore, 2 Tastaturen und 2 Mäuse sind sehr nützlich
• Man lernt voneinander. Nicht nur Programmierfähigkeiten, auch neue Tools und den Umgang bekannter Tools, wie z.B. Shortcuts, die Kommunikation untereinander und die Strukturierung der Umsetzung wird gefördert
• Jeder bringt ganz unterschiedliche Stärken, Erfahrungen und Wissen mit, von denen der jeweils andere profitiert. Aristoteles würde sagen „Das Ganze ist mehr als die Summe seiner Teile“
• Es findet eine gute Verbreitung von Wissen und Erfahrung statt

Wann ist es ineffektiv?

• Aller Anfang ist schwer: beginne mit kleinen Aufgaben, die weniger als einen halben Tag dauern.
• Pair-Programming eignet sich weniger für „Fleißarbeit“ und einfache Tätigkeiten.
• Gönne dir Freiraum, um auch alleine Aufgaben zu lösen.
• Sei nicht immer ein Sturkopf.

Nun nochmal zur Frage „wie kann das sein?“

Die Qualität, sowie Design- und Architekturentscheidungen von Pairs sind meist besser, der Code ist damit leichter verständlich und einfacher erweiterbar.

Es werden weniger Fehler gemacht, die im schlimmsten Fall erst im produktiven Einsatz Schaden anrichten und damit umso aufwändiger zu beheben und um ein Vielfaches teurer sind.

Fazit

Wenn ich zurück blicke, bietet Pair-Programming in Kombination mit agilem Vorgehen wirklich viele Dinge, die sich alle Projektbeteiligten (Kunde, Stakeholder, Projektleiter, Entwickler etc.) wünschen:

Eine hohe Qualität der Software, effektive und wirtschaftliche Arbeit, motivierte Mitarbeiter mit umfassendem Überblick und Verständnis der Software, die selbstorganisiert arbeiten und gute Design- und Architekturentscheidungen treffen.

Aber auch paarungsfreie Zeiten haben ihre Berechtigung!

[1] Mehr zum Thema:  http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

Der Beitrag Entwickler in der „Paarungszeit“ erschien zuerst auf Sybit Agile.