Das Vier-Augen-Prinzip der Programmierung im Erfahrungsbericht

Pair Programming ist in der Softwareentwicklung seit einiger Zeit gesetzt.
Dieser Beitrag über Pair Programming ist zuerst bei Heise erschienen.
Patrick Klös, einer unserer Softwareentwickler, berichtet darin über seine Erfahrungen und die seiner Kollegen mit dieser Programmierpraktik.
Der Artikel wird bei Heise sehr ambivalent diskutiert und hat bereits annähernd 50 Kommentare erhalten.
Wir publizieren ihn bei uns im Blog, um ihn an diesem Ort ebenfalls verfügbar zu machen.

Pair Programming hat eine lange Geschichte. Bereits 1995 machte der Informatiker Larry Constantine die Beobachtung, dass Programmierer, die in Paaren zusammenarbeiteten, schneller programmierten und weniger Bugs produzierten. Auf diesen Beobachtungen aufbauend entwickelten seine Fachkollegen Ward Cunningham und Ron Jeffries 1996 ihre Methode des Extreme Programming (XP). Pair Programming macht den entscheidenden Aspekt von XP aus. Mit dieser agilen Programmiermethode lassen sich vor allem typische Flüchtigkeitsfehler reduzieren und eine bessere Wissensverteilung im Unternehmen erzielen. Integriert in agile Methoden wie Scrum und im Kontext sich selbst organisierender Teams hat das Thema seitdem an weiterer Relevanz gewonnen.

Einführung und Einsatzgebiete

Mit Beginn 2013 wurde das Konzept bei ADACOR zuerst etwa ein halbes Jahr in einem Zweierteam der Entwicklungsabteilung erprobt. Vorrangige Treiber des Projekts waren die Teamleitung und die Mitarbeiter der Abteilung Softwareentwicklung, die diese Methode im Rahmen eines Forschungs- und Entwicklungsprojekts einer Cloud-basierten Proxy-Software mit vielen neuen Techniken und Herausforderungen nutzen wollten. Die ADACOR-Geschäftsführung war eingangs skeptisch, ob es sinnvoll sei, doppelte Ressourcen für eine Aufgabe vorzuhalten. Doch das Management ließ der Softwareentwicklung letztlich weitgehend freie Hand.

Grundsätzlich ist Pair Programming vielseitig einsetzbar und unterstützt den schnellen Wissenstransfer sowie die rasche Einarbeitung neuer Projektmitarbeiter. Es hilft, die Entwicklerfähigkeiten weniger erfahrener Kollegen zu verbessern. Darüber hinaus lohnt sich die Arbeitstechnik beim Erstellen zentraler, kritischer oder fehleranfälliger Softwarekomponenten. Die auf den ersten Blick unwirtschaftlich wirkende Vorgehensweise zahlt sich dabei meist durch geringeren Wartungsaufwand, kürzere Einarbeitungszeiten und bessere Softwarequalität aus, was die Kundenzufriedenheit erhöht.

Seitdem wird Pair Programming eingesetzt, um Junior-Entwickler zur Wissensvermittlung punktuell mit Senior-Entwicklern zusammenzubringen, und zwar bei Softwarekomponenten mit vielen Abhängigkeiten oder bei Software mit niedriger Fehlertoleranz.

Sinnvoll ist Pair Programming bei

• komplizierten Aufgaben: Durch die Wissensbündelung der Programmierpartner lassen sich Probleme schneller lösen und komplizierte Sachverhalte in kürzerer Zeit erfassen. Das eigene Verständnis eines Sachverhalts wird durch die stetige Auseinandersetzung mit dem Partner konsequent überprüft.
• Tasks mit potenziell hohem Bug-Risiko: In diesem Fall helfen zwei Programmierer dabei, Fehler zu vermeiden. Arbeiten zwei Senior-Entwickler zusammen, ist von einer hohen Codequalität auszugehen, sodass sich der Code schneller in Produktion geben lässt.
• Aufgaben, die neue Techniken erfordern: Aus Managementsicht ist vor allem die Verbreitung betriebsinternen Know-hows interessant. Den Programmierern geht es dagegen vor allem um schnelle brauchbare Ergebnisse. Wenn einer der Programmierer schon mit ähnlichen Techniken vertraut ist und konstruktive Vorschläge in das Brainstorming einfließen lassen kann, wirkt das zusätzlich motivierend.

Die Paarfindung

Wie sucht man die Paare am besten aus? Grundsätzlich kann beim Pair Programming jeder mit jedem arbeiten. Die Grundchemie zwischen den Programmierpartnern sollte allerdings stimmen, damit sie die Zusammenarbeit nicht nach kurzer Zeit aufgeben oder lustlos werden. Ein ähnlicher Tagesrhythmus ist ebenfalls hilfreich: Frühaufsteher und Langschläfer miteinander zu kombinieren, kann bei Gleitzeitmodellen oder Vertrauensarbeitszeit zu Konflikten führen.

Im konkreten Projekt haben sich vor allem zwei Konstellationen bewährt:

1. Wenn es um Wissens- und Know-how-Transfer geht, empfiehlt sich die Kombination eines Junior- mit einem Senior-Programmierer, um die besten Lerneffekte zu erzielen.
2. Steht die Vermeidung von Fehlern, die Codequalität oder die Umsetzung schwieriger Aufgaben im Vordergrund, sollten möglichst zwei Senior-Programmierer miteinander arbeiten. Ihre Zusammenarbeit gewährleistet eine hohe Effizienz und geringe Fehlerquote.

Spielt die Wissensvermittlung an einen Junior keine Rolle, ist generell darauf zu achten, dass das fachliche Know-how der Programmierpartner nicht zu ungleich ist. Sonst stellt sich schnell ein Lehrmeister-Schüler-Gefühl ein, dass positive Dynamiken hemmen kann. In der Regel werden neue Herangehensweisen eher ausprobiert oder alternative Lösungen akzeptiert, wenn sie von jemandem vorgeschlagen werden, dessen Kompetenz respektiert wird. Außerdem wächst ein Paar mit der Zeit und den gemeinsam bewältigten Aufgaben zusammen. Deshalb ist es auch sinnvoll, Paaren die nötige Zeit zu geben, um sich aneinander zu gewöhnen und sich „einzuspielen“. Zu häufige Neuzusammensetzungen sind erfahrungsgemäß kontraproduktiv.

Regelung der Zusammenarbeit

Es ist wichtig, dass jeder im Pair Programming zu Wort kommt. Pilot und Copilot sollten sich regelmäßig in ihrer aktiven und passiven Rolle abwechseln. Bei ADACOR ergab sich die Aufteilung in Pilot und Copilot meist von selbst. Ersterer übernimmt die Kontrolle über die Eingabegeräte, während der Copilot gedanklich folgt, auf mögliche Fehler achtet und quasi von der Seitenlinie Ideen einbringt.

Experten empfehlen im Zusammenhang mit Pair Programming ein häufiges Abwechseln, bisweilen sogar innerhalb einer Aufgabe, oder sogar Arbeitsplätze mit zwei Tastaturen und Mäusen. Aber schon unterschiedliche Betriebssysteme auf den Rechnern oder individuelle IDE-Einstellungen machen ein effektives Arbeiten, insbesondere bei häufigem Wechsel der Eingabekontrolle, schwierig.

Im Fall des Autors kam erschwerend hinzu, dass man auf lokalen VMs arbeitetete und somit ein Arbeitsplatzwechsel auch einen Wechsel der Entwicklungsumgebung bedeutet hätte. Hier hat es sich als praktikabel erwiesen, gemeinsam an einem Arbeitsplatz zu arbeiten und von Fall zu Fall die Kontrolle über Maus und Tastatur abzugeben. Falls der Pilot nicht versteht, was genau der Copilot ausprobieren möchte, kann der dem Piloten eine Idee auch diktieren.

Die Arbeitsplatzsituation beim Pair Programming

Der Arbeitsplatz sollte für effizientes Pair Programming schallmäßig abgetrennt sein und über einen Rechner mit zwei Monitoren und Bürostühlen verfügen. So ist gewährleistet, dass niemand gestört wird und beide Entwickler produktiv miteinander arbeiten können.

Pair Programming ist besonders mental herausfordernd. Beide Programmierpartner müssen sich darauf einlassen, dass alle Aktionen direkt vom Partner hinterfragt werden. Es ist anfangs gar nicht so leicht, Gedankengänge dem Partner gegenüber direkt formulieren zu müssen, damit dieser die einzelnen Programmierschritte gut nachvollziehen kann. Das entwicklertypische „stillschweigend vor sich hin programmieren“ ist nicht mehr möglich. Schließlich muss sich der Copilot auf den Piloten einstellen und dem Workflow bei der Entwicklung folgen können. Bei Unklarheiten und Differenzen sollten entsprechend Nachfragen erfolgen und abweichende Ansätze konstruktiv eingebracht und diskutiert werden. Denn wenn der Copilot den Ansatz des Piloten still akzeptiert, obwohl er anderer Auffassung ist, wäre das Pair Programming wertlos.

Auch Geduld ist gefordert: Der Copilot kann nicht jede seiner Idee direkt ausprobieren lassen. Wichtig ist, offen für andere Lösungswege zu sein und alternative Ideen nicht direkt abzulehnen oder eigene Standpunkte ausufernd zu diskutieren.

Lohnt sich Pair Programming?

Vor der Einführung ist das geplante Ausmaß des Pair Programming zu klären: Sollte die ntwickler es durchgängig oder nur phasenweise, etwa an einem Tag praktizieren, um danach wieder parallel zu arbeiten? Einfache Arbeiten lassen sich auch außerhalb des Pair Programming erledigen. Allerdings schleichen sich gerade bei solchen Aufgaben gerne kleine Fehler ein.

Eine Herangehensweise ist, frühmorgens oft allein zu arbeiten, in der Kernzeit verstärkt Pair Programming zu betreiben und später, wenn viele Kollegen schon im Feierabend sind, wieder einzeln zu arbeiten. Der Ein- und Ausstieg beim Pair Programming erfolgt spontan und nach Bedarf. Ein eingespieltes Team ist sich schnell einig, wann es sinnvoll ist, eine Aufgabe zu zweit anzugehen, und wann einfacher Codedurchsatz wichtiger ist.

Darüber hinaus hat sich eine Task-basierte Arbeitstechnik bewährt. Wenn sich eine Programmierpartnerschaft eingespielt hat, kann ein Ein- und Ausstieg schnell erfolgen. Wer schon öfter mit dem gleichen Partner gearbeitet hat, ist ziemlich schnell wieder im Fluss und kann direkt die Vorteile ausschöpfen. Wenn neue Paarungen ausprobiert werden, ist es hingegen sinnvoll, diese gemeinsam an länger dauernden Tasks arbeiten zu lassen, damit sich das Paar einspielen kann.

Im Beispielprojekt war es etwa so, dass das grundlegende API-Framework über einen längeren Zeitraum in Paarkonstellationen entwickelt wurde. So wusste jeder, wie Schnittstellen aussehen und das Framework generell funktionieren soll. Danach wurden die API-Funktionen und Endpunkte parallel programmiert. Nur wenn Änderungen oder Erweiterungen an Schnittstellen oder am Framework benötigt wurden, ging man wieder in das Pair Programming über.

Die Methode ist auch dann effektiv, wenn die eingesetzten Entwickler zwischen parallelem und gemeinsamem Arbeiten wechseln. Im Projekt fiel bei der Entwicklung der API das gemeinsame Planen und Konzipieren des übergreifenden Frameworks leichter, und das daraus resultierende Konzept hatte Hand und Fuß. Nachdem das Framework via Pair Programming konzipiert war, ließen sich aber die eigentlichen Funktionen und Endpunkte der API schneller parallel umsetzen: Zwei qualifizierte Entwickler können schlicht und einfach mehr Code produzieren als ein einzelner.

Fazit

Mit der Arbeitstechnik des Pair Programmig ließ sich die Programmierungs- und Softwarequalität steigern. Die Eigenverantwortung bei den Mitarbeitern wurde gestärkt, Wissensverteilung intensiviert und die Teams wurden noch stärker selbstorganisiert. Mit der Zunahme alternativer Arbeitsmodelle wie Holacracy und agiler Arbeitsmethoden wird sich Pair Programming weiter etablieren.