Pair Programming: Die zweite Agile Welle kommt auch in Deutschland an

Agil, nicht agil? Diese Frage stellen sich mittlerweile viele Firmen. Und während es in Start-ups Gang und Gäbe ist, nach agiler Methodik zu arbeiten, wagen sich auch mehr und mehr Konzerne Schritte in Richtung Scrum und Co. zu machen. Eine der immer häufiger auftretenden Methoden im IT Bereich ist Pair Programming. Zusammen anstatt nur gleichzeitig ist hier die Devise. Während die Methode erst mit der großen Agile-Welle weit verbreitet wurde, existiert diese Art des Programmierens schon seit den 1990er Jahren und kann auch ausserhalb von eXtreme Programming und Agile angewendet werden.

Was ist Pair Programming überhaupt?

Bei Pair Programming handelt es sich um eine Entwicklungsmethode, bei der zwei Programmierer gleichzeitig am selben Code arbeiten. Zwei Mäuse, zwei Tastaturen, aber nur ein Bildschirm. Dieses enge Zusammensitzen soll dazu führen, über ständige Kommunikation, zu einer gemeinsamen Lösung für komplexe Probleme zu gelangen.

Meistens übernimmt hierzu einer der beiden Entwickler die Rolle des "Drivers", während der andere die Rolle des "Navigators" übernimmt. Der Driver schreibt den Code und der Navigator übernimmt eher eine überprüfende und richtungsweisende Rolle, um sicherzustellen, dass die Konformität mit Entwicklungszielen eingehalten wird.

Diese Teamarbeit kann dazu führen, dass schon verworfene Konzepte neu aufgefasst und weiterentwickelt werden und durch eine gemeinsame Expertise neue Perspektiven und Lösungen erschlossen werden.

Ein agiles Konzept im Konzern?

Während die meisten Start-ups wohl mit Agile vertraut sind, setzen viele Großkonzerne nach wie vor auf traditionelle Methoden in der Softwareentwicklung. Doch auch hier tut sich etwas. Industrieriesen wie VW schieben den (langsamen) Wandel an und erstellen sogenannte Inseln, in denen schon heute unter Agiler Methodik gearbeitet wird. So entwickelt das Digital Lab Berlin fast ausschließlich mit Pair Programming. Frank Loyd Mitarbeiter und der VW-Konzern-IT sowie Leiter Software äußerte sich gegenüber T3N, dass Pair Programming sich besonders "für Software, bei der es um maximale Entwicklungsgeschwindigkeit bei sehr hoher Qualität geht" eignet. Bei wiederum anderen Projekten "können andere Arbeitsmethoden der wirtschaftlichere Weg sein."

Eignet sich Pair Programming für Ihr Team? Und welche Risiken bringt es mit sich?

Pair Programming wirkt auf den ersten Blick nicht immer intuitiv. Softwareentwickler sind stereotypisch eher introvertiert und so gibt es viele, die mit dem Konzept wenig anfangen können oder wollen. Auch zwei Programmierer für die gleiche Arbeit zu bezahlen, wirkt auf den ersten Blick unwirtschaftlich. Doch schon Studien Mitte der neunziger Jahre zeigten, dass die positiven Aspekte der Methode - bei richtiger Anwendung - die negativen mehr als nur ausgleichen können.

Eine Studie von Laurie Williams aus dem Jahr 2000 hebt folgende Pluspunkte als besonders hervor:

Paare denken

Leute, die in Paaren als Team arbeiten, neigen dazu, sich weniger ablenken zu lassen und werden im Zweifel von ihrem Partner schnell wieder in die Prozesse eingebunden - falls eine Mail oder ein Meeting sie unterbrochen hat. Auch die Idee, einen Partner nicht enttäuschen zu wollen, ist für viele ein primärer Motivationsfaktor.

Paarweises Weiterleiten 

Zwei Köpfe sind besser als einer. Diese Grundidee hinter Pair Programming ermöglicht es effizienter und kooperativer nach Lösungen zu suchen. Verworfene Konzepte können gemeinsam neu aufgefasst und weiterentwickelt werden oder zusammen mit anderen Ansätzen neue Lösungswege erschließen.

Bewertung des Paares 

Studien zeigen immer wieder, dass Code-Reviews zu einer der unbeliebtesten Aufgaben zählt und viel zu oft nur halbherzig wahrgenommen werden. Die schon ständig während dem Entwickeln anfallende Kontrolle beim Pair Programming ist nicht nur effizienter, sondern kann gegebenenfalls auch die unbeliebte nachträgliche Kontrolle überflüssig machen.

Das Ganze spart viel Geld, immerhin kann ein Fehler nachträglich zu beheben sein über zehnmal so viel Kosten, als ihn frühzeitig zu erkennen.

Fehlersuche

Auch einzelne Programmierer kennen die Vorteile von Rubber-Ducking, dem verbalen Erklären eines Problems oder eines Vorgehens, um es besser betrachten zu können. Beim Pair Programming muss man sich nicht nach einer anderen Person oder einer Badeente umsehen, sondern kann direkt an einen anderen Programmierer weitergeben.

Paarweises Lernen

Zurecht wird Pair Programming heutzutage auch zum Einarbeiten neuer Mitarbeiter (und im Falle von VW sogar als Bewerbungsprogramm) eingesetzt. So können nicht nur Systeme, Standards und Architektur weitergegeben werden, sondern auch gegebene Methoden hinterfragt und verbessert werden. Aber auch Programmierer auf gleichem Level können voneinander lernen und regelmäßige Rotation von Pair-Partnern kann zusätzlich Wissens-Silos verhindern.

Teambildung

Pair Programming ist nicht nur sehr Teamwork abhängig, sondern auch sehr förderlich für eben dieses. Auch Standards werden durch die ständige Anwendung schneller verbreitet.

Projektrisiko

 Da für jeden Teil des Projekts zwei anstatt nur eine Person verantwortlich sind, ist ein Ausfall einer Key-Person bei weitem nicht so tragisch, da im optimalen Fall einfach der Partner weiterarbeiten und eine dritte Person einarbeiten kann. Auch werden - wie bereits erwähnt - Silos verringert und so der Risikoindex weiter Richtung 0 verschoben.

Natürlich gibt es auch mehr als eine Schwierigkeit, die mit Pair Programming verbunden ist.

Einzelgänger

Nicht jeder kann über längere Zeiträume so eng einer anderen Person ausgesetzt werden, dies zu akzeptieren ist wichtig.

Genauso arbeiten nicht alle Personen gut miteinander, Pair Programming profitiert in der Regel von einer kommunikativen Gleichstellung, daher müssen Entwickler mit einer starken Persönlichkeit oder einem sehr kleinen Ego lernen, dem Jeweils anderen in der Mitte zu begegnen bevor eine Kooperation Möglich ist.

Einlernphase

Ein Team, oder eine neue Teamkonstellation für Pair Programming vorzubereiten kann sehr zeitintensiv und daher teuer sein, Standards müssen gefunden werden, sowohl beim Programmieren als auch in der Kommunikation. Die Gewöhnung an neue Partner oder die Methodik im Allgemeinen kann anfangs sehr konfliktreich sein und so manch einer mag davor zurückschrecken, so intim zu arbeiten.

Flexible Arbeitszeiten

Fallen leider Weg, ist man darauf angewiesen, sich an seinen Partner oder bei fliegenden Rotationen sogar seinem kompletten Team anzupassen.

Intensive Arbeit

Die Arbeit im Paar und der ständige Austausch kann sehr intensiv sein. Auch gibt sie einen sehr intimen Einblick auf die eigene Arbeitsweise und Vorgehensweise, dies kann sehr abschreckend und anstrengend sein.

Nutzlos in der Routine

Es muss immer abgewogen werden, ob Pair Programming für einen Arbeitsteil überhaupt zweckmäßig ist oder ob es nicht einfacher ist, selbstständig zu arbeiten ohne Qualitätsverlust zu riskieren. Besonders bei Routineaufgaben kann dies sinnvoll sein.

Geringere Arbeitsgeschwindigkeit

Verglichen mit zwei separat arbeitenden Entwicklern ist die Arbeitsgeschwindigkeit beim Arbeiten in Paaren geringer. In der Praxis setzt ein Zweierteam eine Aufgabe im Vergleich zu einer Einzelperson nicht etwa doppelt so schnell um. Ausgeglichen wird dies durch eine höhere Arbeitsqualität und weniger Defekte, daher muss hier die Wirtschaftlichkeit für die gegebene Aufgabe abgeschätzt werden.

Wie es richtig funktioniert:

Struktur und Standards festlegen

Noch bevor das Projekt begonnen hat, ist es extrem wichtig für alle einen gemeinsamen Standard und eine klare Struktur zu setzen. Dies Hilft den einzelnen Paaren sich schneller zu finden und bei späteren Rotationen schneller in das aktuelle Modul einzuarbeiten.

Auch Standards für den Umgang können helfen Konflikte und Stress zu vermeiden.

Pairing-Konzept wählen

Je nach Ziel sollte bewusst eine der drei Optionen gewählt werden:

Neuling-Neuling

Wird am seltensten gewählt, da es keine gute "Absicherung" gegenüber Unternehmensstandards gibt. Kann aber ermöglichen, zuvor gemeinsam ausgewähltes Wissen zu festigen.

Neuling-Experte

Bietet starke Möglichkeiten, um Neulinge oder Anfänger in ein System einzuarbeiten, auszubilden oder mit Standards vertraut zu machen.
Ferner kann auch ein neuer oder unerfahrener Mitarbeiter neue Einblicke geben oder Gegebenes hinterfragen.

Experte-Experte

Personal mit vergleichbaren Fähigkeiten kann das Potential des Pair Programming vermutlich am besten ausschöpfen und Code mit einer hohen Qualität abliefern. Hier muss allerdings darauf geachtet werden, nicht in alte Gewohnheiten zurückzufallen.

Einarbeitung und richtiges Pairing

Nicht jeder Mensch hat den gleichen Charakter, die gleiche Arbeitsweise oder die gleiche Art sich den Arbeitsplatz einzurichten. So müssen sich die meisten erst an die intensive und intime Art des Pair Programming und an den Persönlichkeitstyp des Partners gewöhnen. Das Ziel hier sollte sein sich nicht mehr als einzelne Programmierer, sondern als Team zu betrachten, auch den Arbeitsplatz richtig einzurichten und Gefahrenquellen zu identifizieren sind kritische Aspekte für den Erfolg.

Pausen und Arbeitszeiten

Die intensive Arbeitsweise von Pair Programming kann sehr anstrengend sein, daher ist es wichtig nicht zu lange im Pair Modus zu arbeiten. Experten empfehlen nicht mehr als sechs Stunden am Tag und regelmäßige Pausen einzulegen.

Um das richtig managen zu können, wird oft die Pomodore-Variante genutzt und von vornherein festgelegt, was an diesem Tag oder Abschnitt erreicht werden soll, um möglichst wenige Aufgaben im Status: WIP zu haben.

Rollen und Tausch

Die meisten Pair-Programmierer benutzen die Driver-Navigator Methode, in der einer die Rolle des Drivers übernimmt und den Code aktiv schreibt und dabei ihr oder sein Vorgehen kommentiert, während der Navigator den Code mit überprüft, bei Lösungen hilft und das Projektziel im Auge behält. Hierbei ist es sehr wichtig, nicht ins Micro-Management zu verfallen und regelmäßig (zum Beispiel nach jeder Pause) die Rollen zu wechseln.

Drehung

Während einzelne Paare öfters die Rollen tauschen, kann mithilfe der Rotation (dem Partnertausch), das Risiko für Wissens-Silos und Cabin Fever, durch ständiges aufeinander Sitzen, verringert werden. Außerdem können auch Spezialisten einrotiert werden, um ihre Expertise einfließen zu lassen. Zu häufige Rotation kann allerdings schädlich für ein Projekt sein, wenn man dadurch in Gefahr läuft, in der Einarbeitungsphase liegen zu bleiben.

Wirtschaftlichkeit?

Während viele der Untersuchungen über die Effizienz von Pair Programming an Universitäten durchgeführt wurden, und daher immer wieder an ihre Relevanz für die Wirtschaft gezweifelt wird, ist es wohl unbestreitbar, dass es deutlich zeitintensiver ist, Fehler im Programm zu beheben, als sie zu verhindern. Und gerade diesen Punkt nutzt das Pair Programming für sich aus, eine bis zu 15 % geringere Defektrate soll die Methode liefern. Dennoch ist es auch selbstverständlich, dass Routineaufgaben wohl kosteneffizienter in selbstständiger Arbeit gelöst werden können.

Fazit

Pair Programming benötigt klare Strukturen, Energie und Teamwork, kann sich jedoch nach vorhergehendem Investment durchaus auszahlen. Traditionelle Arbeitsweisen wird die Methode allerdings noch lange nicht alle ersetzen. Besonders Routineaufgaben sind nur bedingt wirtschaftlich als Paar lösbar. Die Methode eignet sich jedoch durch die erhöhte Qualität ausgezeichnet für zeitkritische und komplexe Aufgaben. Denn genau dort hat sie auch außerhalb von Silicon Valley Fuß gefasst.

Quellen:
The Collaborative Software Process von Laurie Ann Williams (University of Utah, 2000)Agil im Konzern von Stefan Waschk (Jaxenter)
Hinter den Kulissen bei VW: Wie gut funktioniert Pair-Programming? (T3N)

Jetzt unten für den Newsletter anmelden und keine Taledo-Neuigkeiten verpassen!