Pair Programming wird als zentrales Werkzeug der agilen Softwareentwicklung gesehen. Immer wieder begegnen mir in der Praxis Teams, die es für sich zum Standard erklärt haben. Als Begründung wird oftmals schlichtweg angeführt, dass es Best Practice und Kernbestandteil von agiler Entwicklung und Extreme Programming sei. Dabei sehe ich sehr häufig folgendes Schema:
Zwei Entwickler sitzen gemeinsam am Rechner und arbeiten gemeinsam an einer Aufgabe. Dabei übernimmt einer die tatsächliche Programmierarbeit an der Tastatur. Der andere hat währenddessen ein Auge auf die Korrektheit und den Lösungsansatz. Er macht Designverbesserungen und gibt Feedback. Nach einem gewissen Zeitintervall werden die Aufgaben gewechselt.
Was ich dabei oftmals vermisse, ist eine Reflexion innerhalb der Teams hinsichtlich dieses Vorgehens. Dabei sollte es gemäß dem 12. Prinzip des agilen Manifest wie alle anderen Werkzeuge und Methoden durchaus auch einer Reflexion unterzogen werden.
Teams sollten sich grundsätzlich immer wieder die Frage stellen, ob die von ihnen angewandte Art des Pair Programmings tatsächlich die erhoffte Produktivitäts- oder Qualitätssteigerung bringt.
Gibt es mögliche Variationen, die es für das Team effektiver machen können?
Ja, die gibt es! Und ich möchte nachfolgend einige davon ganz kurz vorstellen, um einen Anreiz zu schaffen, eingefahrene Arbeitsweisen zu variieren.
Soloing
Was hat Soloing mit Pair Programming zu tun? Berechtigte Frage!
Ich möchte an dieser Stelle zunächst einmal darauf hinweisen, dass es für manche Teams oder zumindest einzelne Entwickler durchaus sinnvoller sein kann, nicht (immer) im Pair zu arbeiten. Hier kann ich aus eigener Erfahrung sagen, dass insbesondere introvertiertere Entwickler diesen Freiraum benötigen, da für sie oftmals dauerhaftes Pairing sehr anstrengend sein kann. Der Artikel „Agile for the Introvert“ liefert hier interessante Einblicke.
Für alle Leser, die „Alleinarbeit“ grundlegend verteufeln, sei in diesem Zusammenhang nochmal auf das agile Manifest hingewiesen:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Supported Soloing
Beim Supported Soloing arbeiten zwei Entwickler Seite an Seite. Dabei bearbeiten sie unterschiedlichen Aufgaben, unterstützen sich aber gegenseitig in regelmäßigen Abständen.
Örtliche Nähe ist hierbei sehr wichtig. Durch sie wird sichergestellt, dass Unterstützung sofort gegeben ist, wenn sie benötigt wird. Zudem sollten Entwickler mehrmals täglich ihren Source Code einchecken. Anhand der Checkins kann der Fortschritt mit dem Partner diskutiert werden. Außerdem ermöglichen diese Zwischenstände effektive Code Reviews durch den Partner. Sie bilden die Basis auf derer der Partner Ratschläge geben kann.
Divide and Conquer
Im Gegensatz zum Supported Soloing arbeiten beim Divide and Conquer zwei Entwickler gemeinsam an einer Aufgabe. Diese wird in kleinere unabhängige Teile zwischen den Partnern aufgeteilt. Jeder kann so unabhängig vom anderen zur Implementierung der Gesamtaufgabe beitragen.
Auch hierbei ist eine örtliche Nähe der Partner hilfreich. Sie ermöglicht eine direkte Kommunikation zwischen den Partnern bei Rückfragen, Abstimmungen oder ad hoc Code Reviews. Sobald alle Teile fertig gestellt sind, können die Partner gemeinsam das Ergebnis reviewen.
Diese Methode erlaubt es übrigens jederzeit in den Modus des klassischen Pair Programmings zu wechseln. Beide Entwickler kennen die Aufgabe genau, so dass
Mob Programming
Das Mob Programming ist eine extreme Art des Pair Programmings. Hierbei arbeitet ein gesamtes Team zur gleichen Zeit an der gleichen Aufgabe. Ein Projektor, eine Tastatur – ein Entwickler entwickelt und die anderen „navigieren“. Dabei rotiert die aktive Rolle zwischen allen Teammitgliedern. Es geht dabei vor allem um kontinuierliche Zusammenarbeit und nicht um ein einzelnes Meeting. Die Zusammenarbeit dauert daher den ganzen Tag, jeden Tag! So sollen Kommunikationsbarrieren verhindert und personelle Veränderungen im Team besser aufgefangen werden. Für neue Teammitglieder und unerfahrene Entwickler steht außerdem der Lerneffekt im Vordergrund. Zusätzlich wird eine gemeinsame Entscheidungsfindung gefördert.
Wem das zu extrem ist, der kann vielleicht zunächst einmal mit einem Randori starten. Hierzu eignen sich vor allem aktivitätsspezifische Aufgaben wie z.B. ein Refactoring oder ein größeres Code Review.
Quintessenz
Pair Programming ist ein anerkanntes Werkzeug der agilen Softwareentwicklung! Allerdings bedarf der Einsatz wie jedes andere Werkzeug auch einer Reflexion und darf nicht dogmatisch angewendet werden. Ich empfehle allen Teams immer wieder mit den vorgestellten Variationen zu experimentieren, um für sich letztlich den größtmöglichen Nutzen daraus ziehen zu können.
Happy Pairing!
