1. Startseite
  2. Wissen kompakt
  3. Pair Programming

Pair Programming

Inhaltsverzeichnis: DefinitionEine Praktik aus Extreme ProgrammingAblaufVorteileTippsDownload – Hinweise

Wissen kompakt: Pair Programming ist ein Ansatz der Softwareentwicklung, bei dem zwei Programmierer gemeinsam an einem Computer eine Aufgabe lösen.

Pair Programming – Software im Tandem entwickeln

„Gemeinsam besser Software entwickeln“ – so könnte das Motto von Pair Programming lauten. Beim Pair Programming entwickeln zwei Programmierer mit unterschiedlichen Rollen gemeinsam an einem Computer.

  • Einer der beiden schreibt den Code und nimmt dabei die Rolle des Drivers bzw. Pilots ein.
  • Der andere denkt über die Problemstellung und Lösung nach, kontrolliert den geschriebenen Code und spricht Dinge an, die ihm auffallen. Er übernimmt somit die Rolle des Navigators bzw. Observers (der englische Begriff steht für Beobachter, Betrachter oder Beisitzer).

Gemeinsam bilden die beiden Entwickler ein Paar bzw. ein Tandem; daher auch der Name Pair Programming bzw. alternativ Tandem Programming oder Paarprogrammierung.

Pair Programming - Software im Tandem entwickeln

Pair Programming als Praktik aus Extreme Programming

Pair Programming wird gerne als Bestandteil von Extreme Programming deklariert. Tatsächlich gehört es neben

  • Refactoring,
  • dem Arbeiten in kurzen Iterationen,
  • der Aufwandsschätzung per Planning Poker,
  • einer kontinuierlichen Integration,
  • der testgetriebenen Entwicklung etc.

zu den 12 sogenannten traditionellen Praktiken aus Extreme Programming. Da Extreme Programming als agile Methode gilt, wird die Paarprogrammierung häufig als agile Vorgehensweise beschrieben. Das ist einerseits richtig, andererseits kann Pair Programming auch in klassischen Entwicklungen – bspw. nach dem V-Modell XT – zum Einsatz kommen.

Interessanterweise wurde Pair Programming schon in den 1950er Jahren verwendet, lange bevor es seinen Namen erhielt. Fred Brooks berichtete 1975 in seinem Buch “The Mythical Man-Month”, wie er als Doktorand gemeinsam mit seinem Studienkollegen William Wright die Paarprogrammierung zwischen 1953 und 1956 ausprobierte: “We produced 1,500 lines of defect-free code; it ran correctly first try.

1995 schrieb Larry Constantine, ein US-amerikanischer Software Engineer und Professor, dass er in den frühen 1980er Jahren “Dynamic Duos” bei Whitesmiths, Ltd. beobachtet hatte. Und 1993 beschrieb James O. Coplien über Organisationsmuster und den Ansatz, Probleme gemeinsam zu lösen, indem “kompatible Designer miteinander als Paar arbeiteten“. 1995 veröffentlichte Coplien das Buch “Developing in Pairs”.

Im Oktober 1999 veröffentlichte Kent Beck das Buch “Extreme Programming Explained”.

Der Ablauf beim Pair Programming

Der Ablauf beim Pair Programming ist relativ einfach:

  • Es gibt zwei Rollen: den Driver bzw. Piloten und den Navigator bzw. Observer. Der Driver bedient den Computer und schreibt den Code. Er kommentiert, was er tut, so dass der Navigator die zugrunde liegenden Gedanken nachvollziehen kann. Der Navigator beobachtet, gibt Feedback zur Implementierung und versucht Ideen zu entwickeln, um die Aufgabe noch besser zu lösen. Ziel der Rollenteilung ist es, zwei verschiedene Perspektiven auf den Code zu haben: Der Driver soll eher taktisch denken, er soll über die Details, über die vorhandenen Codezeilen nachdenken. Der Navigator kann in seiner beobachtenden Rolle strategischer denken. Er hat das Gesamtbild im Blick.
  • Die Rollen wechseln regelmäßig zwischen den Entwicklern, so dass jeder im Wechsel Driver oder Navigator ist.
  • Idealerweise entwickelt das Paar einen Teamgeist, kommuniziert kontinuierlich und klärt Unklarheiten zum Vorgehen, zur Programmierung, zum Testen so schnell wie möglich.
  • Es ist durchaus üblich, dass einer der beiden Entwickler nach einer Weile (2-3 Tage oder eine Woche) das Team verlässt und Platz für einen anderen Kollegen macht. Es kommt zu einer Paar-Rotation bzw. Pair Rotation. In manchen Publikationen wir die Person, die bleibt, als anchor bzw. Anker bezeichnet. Die Absicht dahinter (sofern es sich nicht um eine Rotation bedingt durch Urlaub oder Krankheit handelt): eine frische Perspektive, neue Energie und das Vermeiden von Silos. Natürlich sollte hier jede Organisation individuell entscheiden, ob und wann ein Wechsel sinnvoll ist.

In der Praxis variieren die Meinungen, ob sich die Entwickler wirklich einen Computer teilen oder ob jeder seinen eigenen Computer hat und man auf einem gemeinsamen Stand arbeitet. In Verbindung mit einem heute üblichen Versionsmanagement ist auch die Arbeit mit zwei parallelen Rechnern keine sonderliche Herausforderung.

Die Vorteile beim Pair Programming

Es gibt eine Reihe von Vorteilen, die häufig im Kontext von Pair Programming genannt werden:

  • Wissensvermittlung: Das Wissen zwischen beiden Teilnehmern wird geteilt und vermehrt. Andere Perspektiven erweitern den individuellen Horizont.
  • Freude an der Arbeit: Oftmals nimmt steigt zumindest vorübergehend die Freude am Austausch und der Interaktion.
  • Verbesserte Zusammenarbeit im Tandem und durch die Pair Rotation auch im gesamten Entwicklungsteam.

Oftmals wird auch von

  • besserem Code,
  • weniger Fehlern,
  • geringerem Risiko,
  • verbesserter Disziplin oder
  • höherer Effizienz

gesprochen. Diese Vorteile können, müssen aber nicht zutreffen. Nur weil zwei Entwickler eine gemeinsame Idee zur Lösung einer Aufgabe umsetzen, könnte eine andere Idee immer noch besser sein. Die Umsetzung der Idee mag zwar effizient sein, aber wird eine “falsche” Idee umgesetzt, leidet die Effektivität. Es ist also wichtig, nicht nur “die Dinge richtig zu tun”, sondern auch “die richtigen Dinge zu tun”.

Gerne wird auch auf ein “integriertes” Code Review hingewiesen. Da vier Augen bekanntlich mehr sehen als nur zwei, ist davon auszugehen, dass während der Implementierung mehr Fehler gefunden werden als bei einem Selbsttest durch einen einzelnen Entwickler. Aber auch hier gilt: ist das wirklich effektiver und/oder effizienter als wenn es durch einen separaten Entwickler durchgeführt wird? Klar ist auf jeden Fall, dass auch dieser Vorteil im Einzelfall geprüft werden sollte.

Zwei Vorteile für Pair Programming werden aber meistens in der Praxis übersehen:

  1. Mentoring: Es eignet sich sehr gut, um ein Mentoren-Verhältnis mit einem erfahrenen und einem weniger erfahrenen Entwickler aufzubauen. Ein Reverse Mentoring könnte ebenso etabliert werden wie die Einarbeitung von neuen Entwickler-Kollegen.
  2. Zusammenarbeit zwischen Auftragnehmer und Auftraggeber, zwischen Lieferant und Kunde. Gerade in Zeiten, in denen Feedback und direkte Kommunikation immer wichtiger werden, und sich Unternehmen temporär zusätzliche Dienstleister als Ergänzung zu vorhandenen Entwicklungskapazitäten wünschen, ergibt das Pair Programming auch über Unternehmensgrenzen hinweg viel Sinn.

 

Tipps zum Pair Programming

Es gibt einige Aspekte und Empfehlungen, mit denen sich Organisationen und/oder die Paare das Leben etwas leichter machen können. Hier finden Sie einige Tipps:

  • Klären Sie den generellen Umfang der Paarprogrammierung. Ist es eine temporäre Sache, ein erster Test oder eine auf Dauer angelegte Form der Zusammenarbeit.
  • Klären Sie die konkrete Zusammenarbeit, also bspw. wann beginnen Sie morgens, wann hören Sie auf, wann gibt es planmäßige Pausen, an welchem Arbeitsplatz wird gearbeitet etc.
  • Bearbeiten Sie stets nur eine Aufgabe. Eine Aufgabe, ein Ziel, ein Vorgehen.
  • Idealerweise gibt es in der Organisation Coding Conventions und Coding Styles. Der Navigator sollte auf die Einhaltung achten bzw. den Driver auf etwaige Verletzungen hinweisen.
  • Diskussionen gehören zum Pair Programming, allerdings findet die Zusammenarbeit häufig auch in Großraumbüros statt, so dass die Lautstärke “angemessen” sein sollte.
  • Nutzen Sie Zeilennummern, um konkrete Codezeilen leichter identifizieren zu können.
  • Spielen Sie “Ping Pong”, bspw. im Zuge von Test -Driven Development. Entwickler A scheibt einen Test (Ping), Entwickler B die Implementierung, um den Test zu bestehen (Pong). Entwickler A erweitert den Test (Ping) und Entwickler B erweitert die Implementierung (Pong).
  • Es kann nützlich sein, einen Timer zu verwenden, um so zu festen Zeiten – bspw. alle 20 Minuten – die Rollen zu wechseln. Je eingespielter ein Tandem ist, desto weniger wichtig wird die Verwendung eines Timers.
  • Tandem Programmierung ist auch eine Frage der Haltung. Anstelle von “Ich habe eine Idee, gib mir mal die Tastatur” wäre ein “Ich habe eine Idee. Nimm Du mal die Tastatur.” wünschenswert.
  • Und zu guter Letzt: vereinbaren Sie Lessons Learned bzw. Retrospektiven, um voneinander und miteinander zu lernen.

 

Pair Programming Guide Download

Wollen Sie den Pair Programming Guide kostenlos downloaden?

Alles Wichtige über Pair Programming auf einen Blick.

  • Definition und Ursprung
  • Ablauf
  • Vorteile
  • Tipps

Wissen auf 7 Seiten zum Mitnehmen.

Impuls zum Diskutieren:

Gibt es eine Möglichkeit, den finanziellen Nutzen eines Pair Programmings zu berechnen?

Hinweise:

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

Hier finden Sie den Text von The Mythical Man-Month.

Wir suchen übrigens Softwareentwickler. Berufseinsteigerinnen, Entwickler mit einigen und Expertinnen mit vielen Jahren Erfahrung. Melden Sie sich bei Interesse.

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

Wissen kompakt: Was ist Refactoring?

Was ist Refactoring?

Wissen kompakt: Was ist Mob Programming?

Was ist Mob Programming?

Wissen kompakt: Was ist Clean Code?

Was ist Clean Code?