In agilen Software-Projekten ist es selbstverständlich, dass Entwickler zusammenarbeiten. Das Konzept des Pair Programmings sieht vor, dass sich zwei Programmierer zusammensetzen und gemeinsam an einer Aufgabe arbeiten. Die Entwickler wechseln sich dabei an der Tastatur ab.
Paarprogrammierung: Pilot und Navigator
Das Hauptziel der Paarprogrammierung ist die Verbesserung der Code-Qualität. Pair Programming ist eine agile Entwicklungsmethode, die sich zunächst im Rahmen des Xtreme Programmings etabliert hat und heute auch bei der Anwendung anderer agiler Frameworks zum Einsatz kommt.
Man kann Pair Programming sehr schön mit einer Autofahrt durch eine unbekannte Stadt mit einem komplizierten Straßensystem vergleichen. Hier kann sich ein geübter Fahrer sicherlich selbst ans Ziel mühen. Doch auf diesem Weg biegt er höchstwahrscheinlich da und dort falsch ab, dreht ein paar Ehrenrunden und/oder übersieht mal ein Verkehrszeichen.
Besser funktioniert es in aller Regel, wenn eine Person am Steuer sitzt und ein Beifahrer mit einer Straßenkarte arbeitet. Und im Optimalfall ist diese Person ein ebenso fähiger, vorausschauender Kraftfahrer wie der Fahrzeugführer und kann auch komplexe Verkehrssituationen überblicken.
Hier setzt Pair Programming an. (Todsichere Navigationsgeräte gibt es in der Software-Entwicklung und in individuellen Software-Projekten leider nicht.) Der “Fahrer” – im diesem Zusammenhang oft auch Pilotgenannt – schreibt den Code und die Tests für diesen. Der “Beifahrer” oder Navigator achtet darauf, was der Kollege tut, kontrolliert die Korrektheit des Codes, weist auf potenzielle Irrwege und Schwierigkeiten hin und macht Vorschläge zur Verbesserung. Nach ein paar Minuten wechseln Pilot und Navigator die Rollen.
Weniger Bugs und weniger Zusatzkosten durch spät entdeckte Fehler
In der Software-Entwicklung gilt das 1-10-100-Prinzip. Nach dieser Regel potenzieren sich Aufwand und Kosten für die Fehlerbeseitigung je nach Entdeckungszeitpunkt. Fehler, die Entwickler direkt während der Programmierarbeit finden, lassen sich zumeist rasch und ohne größeren Mehraufwand beheben (Faktor 1). Wenn ein Tester einen Fehler in einem Testsystem entdeckt, ist der Aufwand schon höher: Er muss den Fehler dokumentieren, ihn dem Entwickler übergeben und das Testsystem nach der Behebung aktualisieren und erneut testen (Faktor 10). Fehler, die im Live-System gefunden werden, sind noch schwerer wiegend, da zusätzlich die Live-Instanz aktualisiert werden muss. Dazu kommen Folgen wie verärgerte User, Umsatzeinbußen durch nicht nutzbare Features, Imageverlust (Faktor 100). Die Fehlerbehebung wird umso teurer, je später ein Bug gefunden wird.
Dank des Vier-Augen-Prinzips hilft Pair Programming, mehr Fehler schon beim Coden zu vermeiden bzw. zu entdecken und leicht zu beheben. Viele Bugs lassen sich also abfangen und schaffen es nicht in Test- oder gar Live-Systeme – was auch statistisch messbar ist.
Vermeidung von Wissensinseln – zugunsten des Projekts
Ein erfahrender Entwickler kann alleine hochproduktiv sein. Aber eine einzige schlechte Entscheidung dieses Entwicklers kann verheerende Auswirkungen haben. Er ist der einzige Kollege im Team, der an dem entsprechenden Modul programmiert hat, und damit auch als einziger wirklich in der Materie.
Pair Programming vermeidet das Problem, dass nur einzelne Entwickler spezielle Bereiche des Systems kennen. Das Team steht nicht plötzlich vor großen Problemen, wenn der spezifische Entwickler das Team wechselt, krank wird oder das Unternehmen kurzfristig verlässt. Pair Programming beugt also gefährlichen Wissensinseln vor und fördert den Wissensaustausch – zugunsten reibungs- und verlustärmerer Projektabläufe.
Auch aus diesen Gründen bilden nicht immer dieselben Entwickler Paare, sondern es wird rotiert, sodass jeder Entwickler mal mit jedem anderen Programmierer im Team zusammen vor dem Bildschirm sitzt. Durch die ständige Kommunikation und den kombinierten Erfahrungsschatz kommt das Team schneller zu besseren Ergebnissen als ein einzelner Entwickler, der für sich allein an einer Problemlösung arbeitet.
Bessere Software durch ständige Plausibilitätsprüfungen von Ideen
Die Idee hinter der Paarprogrammierung ist die, durch kontinuierliche “Sanity Checks” schlechte Ideen und Entscheidungen als solche zu identifizieren und gute Ideen zu verbessern und zu optimieren und somit besseren Code zu produzieren und letztlich die Produktivität insgesamt zu steigern. Erfahrungsgemäß führt Pair Programming durch das gemeinsame Arbeiten in der Regel zu mehr Konzentration bzw. weniger (Selbst-)Ablenkung und zu einem insgesamt noch intensiveren Arbeiten.
(Die Folge ist allerdings, dass die Entwickler die Paarprogrammierung oft als sehr anstrengend empfinden. In der Praxis wird daher empfohlen, regelmäßig Pausen zu machen, in denen man auseinandergeht, und das Pair Programming nicht unbedingt ununterbrochen den ganzen Tag zu betreiben – zumal es auch Aufgaben gibt, für die das Vier-Augen-Prinzip nicht unbedingt nötig oder besonders wertvoll ist.)
In jedem Fall generiert das Teilen von Wissen in den Paaren und durch die Rotation über das gesamte Team hinweg tatsächlich ein besseres Software-Design und zudem kürzeren (und damit besser wartbaren) Code. Und nicht zuletzt erweitert Pair Programming die technischen Fähigkeiten aller beteiligten Entwickler, wovon sowohl die Effizienz des Teams als auch die Qualität der Ergebnisse profitieren.
Fazit: Geringer Mehraufwand, der sich auszahlt
Es lohnt sich gerade auch für den Kunden, sich mit den Potenzialen der Paarprogrammierung auseinanderzusetzen und das Konzept zu verstehen. Pair Programming bietet die Voraussetzungen für die Entwicklung bestmöglicher Software, sorgt für größtmögliche Produktivität des Entwicklungsteams und reduziert später anfallende Zusatz- und Reparaturarbeiten signifikant.
Dabei ist der Mehraufwand gar nicht so dramatisch, wie man meinen möchte. Im Vergleich zum klassischen Development beläuft er sich nicht etwa auf das Doppelte, sondern auf gerade mal 15%. Das haben Alistair Cockburn und Laurie Williams im Rahmen einer kontrollierten Studie belegt.