Der Begriff des Pair Programmings ist aus dem Extreme Programming heraus in den späten 90ern entstanden. Bei Pair Programming arbeiten zwei Entwickler gleichberechtigt gemeinsam an einer Aufgabe und schauen dabei auf den gleichen Bildschirm. Pair Programming wird im Deutschen auch als Tandem-Programmierung oder wörtlich übersetzt Paarprogrammierung bezeichnet.
Rollen
Beim Pair Programming nehmen die Partner zwei unterschiedliche Rollen ein. Es gibt verschiedene Formen, allen gemeinsam ist aber, dass es keine definitive Aufgabenverteilung gibt und die Partner ihre Rollen regelmäßig tauschen.
Driver und Navigator
Diese Bezeichnungen stammen aus dem Rallye-Sport, bei dem der Fahrer durch einen Beifahrer begleitet wird. Im Rallye-Sport informiert der Beifahrer den Fahrer kontinuierlich über den weiteren Streckenverlauf, über enge, weite und lange Kurven, Kuppen, Täler und Hindernisse sowie Unfälle auf der Strecke. Dabei übernimmt er auch die Kommunikation mit der Zentrale und führt gegebenenfalls Wartungsarbeiten wie Reifenwechsel durch. Der Beifahrer übernimmt also eine strategische Rolle und hat das Gesamtbild im Blick, damit der Fahrer sich auf das Hier und Jetzt konzentrieren kann. Der Fahrer muss sich auf die aktuelle und unmittelbar folgende Situation konzentrieren, er muss die optimale Geschwindigkeit und richtige Fahrweise zum vorliegenden Streckenlauf kennen und umsetzen und nimmt damit den taktischen Gegenpart ein.
Beim Pair Programming verhält es sich ähnlich, wenn auch zum Glück deutlich weniger angespannt und gefährlich. Der Driver, manchmal auch Pilot genannt, übernimmt das Schreiben. Dabei denkt er laut und formuliert seine Gedanken so, dass der Navigator sie gut verstehen und nachvollziehen kann. Der Driver kommentiert, was er gerade tut, er berichtet, was er als nächstes vor hat, begründet seine Schritte und spricht auch Offensichtliches aus.
Der Navigator hingegen, auch als Observer bekannt, arbeitet auf einer strategischen Ebene. Er überprüft das vom Driver Umgesetzte, denkt über Verbesserungen nach, gibt dem Driver Feedback zur Implementierung, bestätigt seine Annahmen oder fragt nach Gründen für seine Entscheidungen. Der Navigator hat den Gesamtüberblick, er kennt das Ziel und stellt sicher, dass das Duo auf dieses hinarbeitet. Verrennt sich der Driver, so weist ihn der Navigator darauf hin und bietet Möglichkeiten an, wieder auf den richtigen Weg zu kommen.
Üblicherweise tauschen beide Partner regelmäßig in kurzen Abständen die Rollen, etwa alle 15 Minuten.
Erfahrungskonstellationen
Grundsätzlich kann man zwischen erfahrenen und unerfahrenen Partnern in Bezug auf die Domäne und den Tech-Stack unterscheiden. Dabei ergeben sich verschiedene Kombinationsmöglichkeiten.
erfahren / erfahren
Zwei erfahrene Entwickler liefern in der Regel schnelle und hochwertige Ergebnisse. Dabei kann es allerdings passieren, dass sie langzeitig aufgebaute Denkweisen nicht ablegen können, Bestehendes nicht hinterfragen und bestimmte Lösungsansätze gar nicht erst in Erwägung ziehen.
erfahren / unerfahren
Diese Konstellation entspricht zum Beispiel der Einarbeitung neuer Mitarbeiter, dem Onboarding, oder auch dem Mentoring weniger erfahrener Kollegen. Der unerfahrene Kollege kann durch seine Fragen und Erfahrungen Raum zur Reflektion und für innovative Ideen schaffen.
Wichtig bei dieser Konstellation ist ein vertrauensvolles und gleichberechtigtes Verhältnis, damit der Unerfahrene nicht in eine passive Zuschauerrolle verfällt, Angst hat, sich kritisch zu äußern oder seine Äußerungen vom erfahrenen Partner ignoriert werden.
In der Regel lernt der unerfahrene Entwickler bei dieser Konstellation mehr, während er die Rolle des Drivers einnimmt. Da er in der Rolle des Navigators weniger beitragen kann, steigt das Risiko, dass er gedanklich abschweift und den Anschluss verliert.
unerfahren / unerfahren
Diese Kombination ist aus meiner Sicht eher nicht zu empfehlen, da durch mangelndes Domänenwissen und Unternehmenserfahrung ein hohes Fehlerrisiko besteht.
Varianten Driver / Navigator
Strong-Style Pairing
Bei dieser Variante nimmt ein erfahrener Navigator eine deutlich dominantere Rolle ein und leitet den Driver an. Er hat dabei den gesamten Umsetzungsplan im Kopf und diktiert diesen an den Driver Schritt für Schritt. Der Driver muss dabei nicht zu jeder Zeit verstehen, warum er etwas umsetzt, sondern nur, was er umzusetzen hat.
Backseat Navigator
Diese Variante hat einen ähnlichen Hintergedanken wie das Strong-Style Pairing und wird auch synonym verwendet. Da der Driver in diesem Fall relativ unerfahren ist, greift der Navigator vermehrt taktisch ins Geschehen ein, indem er ihm erklärt, warum ein bestimmter Ansatz nicht funktioniert oder ihm präzise Anweisungen gibt, welche Objekte und Funktionen zu verwenden sind.
Tour Guide
Diese Spielart sollte nur punktuell eingesetzt werden. Der Gedanke hinter dieser Variante ist, einem unerfahrenen Kollegen eine geführte Besichtigung zu bieten. Üblicherweise wird dabei kein Code geschrieben, sondern der erfahrene Driver führt den unerfahrenen Navigator durch den bestehenden Code, erzählt ihm etwas dazu und gibt ihm die Gelegenheit, Fragen zu stellen und in bestimmte Bereiche tiefer einzutauchen. Diese Form des Pair Programmings bietet sich auch an, wenn ein Kollege längere Zeit abwesend war und sich in der Zwischenzeit viel verändert hat.
Ping-Pong
Diese Konstellation stammt aus dem Test-driven Development. Der Ping-Entwickler nimmt das Steuer in die Hand und schreibt einen Test, der fehlschlägt, weil die Implementierung dazu noch fehlt. Der Ping-Entwickler übergibt das Ruder an den Pong-Entwickler, der die Implementierung schreibt, so dass der Test durchläuft. Der andere Entwickler kann im Anschluss den Test verbessern, oder den nächsten Test schreiben. Der nicht-aktive Entwickler nimmt bei dieser Zusammenarbeit eine eher beobachtende Rolle ein. Bei dieser Vorgehensweise sollte darauf geachtet werden, dass nicht ein Entwickler alle Tests schreibt und der andere die ganze Implementierung, und dass die Aufgaben so kleinteilig sind, dass ein regelmäßiger Wechsel stattfindet.
unstrukturiert
Pair Programming muss sich nicht zwingend an die vorgestellten Spielregeln halten. Die unstrukturierte Form ist unverbindlicher, individueller und spontaner. Bei gut eingespielten erfahrenen Partnern kann dies eine gute Idee sein, in anderen Fällen kann dies auch Nachteile mit sich bringen, etwa wenn eine Person ständig den Ton angibt und die Tastatur in Beschlag nimmt, während die andere nicht gehört wird und mit der Zeit das Interesse verliert. Bei dieser Form der Zusammenarbeit ist regelmäßiges Feedback besonders wichtig.
Umfeld
Beim Pairing sollte man darauf achten, nicht von Kollegen gestört zu werden und gleichzeitig keine Kollegen zu stören. Beide Kollegen müssen die Entwicklungsumgebung gleichermaßen gut im Blick haben, dazu bietet es sich zum Beispiel an, den Bildschirm zu duplizieren. Um den Rollentausch möglichst angenehm zu machen, vor allem, wenn der Navigator mal kurz aktiv in das Geschehen eingreifen will, lohnt es sich, zwei Mäuse und Tastaturen anzuschließen.
Seit Corona hat sich Remote-Arbeit immer stärker etabliert. Tut man dies im Pairing, spricht man dabei von Distributed Pair Programming oder Remote Pair Programming. Damit stellen sich andere Herausforderungen. Braucht man nun nicht mehr einen großen gut aufgeräumten Schreibtisch mit für beide Partner gut einsehbarem oder dupliziertem Bild und doppelter Peripherie, so sind nun eine gute Kamera, ein gutes Mikrofon und eine hohe Internetbandbreite entscheidend. Da die Körpersprache in den Hintergrund tritt, ist es essenziell, dass sich beide Partner gegenseitig sehr gut verstehen. Gleichzeitig sollte das Bild klar und scharf sein und keine spürbare Latenz vorliegen. Zur Zusammenarbeit teilt der Driver seinen Bildschirm. Beim Rollenwechsel übernimmt dann entweder der Partner die Bildschirmfreigabe, oder der vorherige Driver gibt die Maus- und Tastatursteuerung für seinen Partner frei, was einer sehr geringen Latenz bedarf. Alternativ können Kollaborationswerkzeuge wie das Plugin Code With Me von IntelliJ IDEA verwendet werden.
Die verwendeten Werkzeuge sollten für beide passen. Ist der eine Partner ausschließlich mit Vim unterwegs, während der andere Partner auf Visual Studio Code besteht, kann sich die Zusammenarbeit als schwierig erweisen. Auch sehr spezielle Konfigurationen oder Plugins können der Kollaboration im Wege stehen.
Austausch
Die oberste Priorität hat aus meiner Sicht das gemeinsame Verständnis. Der Driver muss seine Gedankengänge und Vorhaben dem Navigator klar, präzise und unmissverständlich kommunizieren, während der Navigator Unklarheiten sofort klären sollte. Zum Austausch über den Code hat sich bei mir persönlich die Kommunikation über Zeilennnummern als sehr hilfreich erwiesen.
Pair Programming einführen
Bevor es mit dem Pair Programming losgeht, sollten einige Rahmenbedingungen gegeben sein. Dies ist vor allem dann entscheidend, wenn man ganz am Anfang steht und noch wenig Erfahrung im Pairing miteinander gemacht hat.
Voraussetzung
Damit man sich nicht in Diskussionen verliert, die mit der Erreichung der Aufgabe nur wenig zu tun haben, sollte das Team im Voraus einen einheitlichen Programmierstil gefunden haben. Dazu zählt die Einigung auf Code-Konventionen bzw. einen Style-Guide, der optimalerweise durch einen Linter forciert wird. Werkzeuge wie Arch Unit, Frameworks wie die Twelve-Factor App oder ausformulierte Qualitätsszenarien, auf die man sich bei seinen Entscheidungen berufen kann, können ebenfalls unterstützen, einen guten Rahmen zu schaffen.
Grundsatzdiskussionen, wie funktionale vs. objektorientierte Programmierung, statische vs. dynamische Typisierung usw. haben im Pairing nichts verloren und sollten außerhalb geklärt werden.
Klare Aufgabe
Das Pair Programming sollte eine klare Aufgabe und ein klares Ziel haben. Dabei kann es sich um die Umsetzung einer User Story handeln, für die eine Definition of Ready erfüllt wird, durch die abgesichert ist, dass ein grober Umsetzungsplan bekannt ist. Das Ziel kann durch Akzeptanzkriterien und eine Definition of Done messbar und eindeutig gemacht werden.
Die Aufgabe sollte einen überschaubaren Umfang haben, damit sie idealerweise auch von beiden Pairing-Partnern umgesetzt werden kann. Da ein Partner durch Krankheit, Notfälle oder spontane Ereignisse anderer Art immer überraschend ausfallen kann, erhöht sich das Risiko, dass die Aufgabe nicht von beiden Partnern zuende umgesetzt werden kann, mit steigendem Umfang der Aufgabe. Zwar kann ein Partner einen Teil der Aufgabe auch alleine umsetzen, jedoch gehen damit die Vorteile des Pair Programmings auch verloren. Alternativ kann ein neuer Partner hinzukommen, für den dies dann aber auch einen Kontextwechsel bedeutet und der erstmal in den aktuellen Umsetzungsstand eingearbeitet werden muss, was insgesamt zusätzlichen Aufwand impliziert.
Planung der Umsetzung
Die meisten Aufgaben, die man im Pairing umsetzen möchte, sind nicht so trivial, dass davon ausgegangen werden kann, dass beide Partner von Anfang an das gleiche Bild im Kopf haben. Auch wenn in einem agilen Umfeld das Refinement die meisten Fragezeichen beantwortet haben sollte, lohnt sich ein Austausch über das zu Erreichende, bevor man mit der Implementierung beginnt. Dabei kann man zu Visualisierungswerkzeugen greifen. Im Büro sind das Whiteboards, Flipcharts und Notizzettel. Remote sind dies Werkzeuge wie Confluence, Miro/Mural oder Diagrams.net.
Timeboxing und Pausen
Pair Programming ist anstrengend! Regelmäßige Pausen sind daher sehr wichtig. Als Unterstützung kann man sich dabei der Pomodoro-Technik bedienen. Dabei wird alle 25 Minuten eine Pause von 5 Minuten eingelegt. Nach vier solchen Intervallen wird eine längere Pause von 15 bis 20 Minuten gemacht. Die Pausen können auch unter Zuhilfenahme eines Weckers oder einer entsprechenden App durchgesetzt werden.
Befindet man sich gerade im Flow, kann eine geräuschvolle, aktive Erinnerung an die nächste Pause aber auch stören. Wer damit nicht zurecht kommt, sollte zumindest über regelmäßige Pausen sprechen und eine solche vorschlagen, wenn man sie für angebracht hält.
Pair Programming sollte nicht acht Stunden am Tag ausgeübt werden. Oftmals ist dies auch gar nicht möglich, da die Beteiligten selbst andere Termine haben. Damit das Pairing gut funktioniert, sollte man im Voraus die Zeiten festlegen – wenn es beiden passt, kann man das Pairing ja immer noch nach hinten raus verlängern. Bei einem zu vollen Terminkalender sollte man versuchen, seine Termine zu synchronisieren, so dass man gemeinsam mehr Zeit findet. Dazu kann man abgestimmte feste Pairing-Blocker im Kalender eintragen oder Vereinbaren treffen, wie bestimmte Tage, Vormittage oder Nachmittage Meeting-frei zu halten, damit unterbrechungsfreies Arbeiten möglich ist.
Unterbrechungen
Die beiden Partner sollten im Voraus darüber sprechen, welche Unterbrechungen toleriert werden und welche nicht. Besteht die Möglichkeit, dass ich wegen einer wichtigeren Angelegenheit, etwa Rufbereitschaft, spontan aus dem Pairing aussteigen muss, sollte ich im Voraus mit dem Partner darüber sprechen und mit ihm entscheiden, ob wir das Pairing ggf. verschieben oder es darauf ankommen lassen. Erwarte ich einen Rückruf, für den ich das Pairing 5-10 Minuten unterbrechen müsste, sollte ich auch darüber im Voraus sprechen und ggf. den Rückruf nicht entgegennehmen.
Ablenkende Anwendungen oder audiovisuelle Benachrichtigungen können für den Zeitraum des Pairings ggf. beendet oder deaktiviert werden. Darf ich während des Pair Programmings wichtige E-Mails lesen oder sollte ich besser den E-Mail-Client schließen? Auch dies sollte ich vor der Pairing-Session mit meinem Partner geklärt haben.
Einzelaufgaben
Nicht alle Teile einer Aufgabe müssen im Pairing erledigt werden. Routineaufgaben, deren gemeinsame Bearbeitung keinen Vorteil gegenüber der Einzelarbeit ergibt, können nach Absprache auch von einer der beiden Partner mitgenommen und bis zur nächsten Pairing-Session umgesetzt werden.
Nachbereitung
Gerade am Anfang sind Selbstreflektion und gegenseitiges Feedback sehr wichtig. Die Beteiligten sollten dafür dediziert Zeit einplanen und sich aussprechen, wie das Pairing aus ihrer Sicht verlaufen ist. Damit das Feedback auch angenommen werden kann, sollten dabei die allgemeinen guten Etiketten des Feedback-Gebens eingehalten werden, also über die eigene Wahrnehmung zu sprechen, konstruktive Vorschläge zu machen, den Partner nicht anzugreifen, Kritik auf die Sache oder das Verhalten zu beziehen und nicht auf die Person usw.
Einstellung
Für ein gut funktionierendes Pair Programming ist es wichtig, dass beide Partner kompromissbereit sind. Bestehen beide auf gegensätzlichen Standpunkten, sollte das Pairing beendet und der Streitpunkt außerhalb geklärt werden. Beide Partner müssen kritikfähig sein und sollten diese gleichzeitig nicht zu ernst nehmen. In der Software-Entwicklung werden unzählige Entscheidungen getroffen und nicht alle davon sind wirklich relevant. Oftmals sind beide Ansichten legitim und die Wahl ist eher eine Geschmackssache. Auch eine begründete Entscheidung kann zwar plausibel klingen, im gegenwärtigen Kontext aber irrelevant sein, da die genannten Vorteile oder Risiken nicht greifen bzw. ihr Eintritt äußerst unwahrscheinlich ist.
Um eine bestmögliche Zusammenarbeit zu garantieren, müssen beide Pairing-Partner sehr kommunikativ sein, um das gegenseitige Verständnis zu maximieren. Gleichzeitig sollten sie offen für die Gedanken des anderen sein und Vertrauen in ihn haben. Das gilt unabhängig davon, ob der Partner ein erfahrener oder unerfahrener Kollege ist. Ein hohes Maß an Empathie ist ebenso wichtig wie Hilfsbereitschaft und Geduld. Es gilt die Annahme, dass jeder mit dem ihm zur Verfügung stehenden Erfahrungen und Informationen das Beste erreichen will. Der Umgang miteinander sollte zu jeder Zeit wertschätzend und respektvoll ausfallen.
Beim Pair Programming wird viel geredet, umso wichtiger ist es, dass genauso viel und aktiv zugehört wird. Dies gilt sowohl für den Navigator, der die Handlungen des Drivers nachvollziehen und einordnen muss, als auch für den Driver, der das Feedback und die Vorschläge des Navigators annimmt. Als Navigator sollte man darauf achten, kein Micromanagement zu betreiben, sofern es nicht in der Rolle des Backseat Navigators explizit gewünscht wird. Für Tippfehler gilt die 5-Sekunden-Regel: Gib dem Driver mindestens fünf Sekunden Zeit Fehler selbst zu entdecken, bevor du ihn darauf aufmerksam machst.
Paar-Rotation
Um seine Vorteile richtig auszuspielen, sollten die Partner beim Pair Programming regelmäßig wechseln. So lernt jeder jeden im Team kennen und erlangt auch zumindest rudimentäres Wissen in allen Bereichen der Entwicklung, für das sich das Team verantwortlich zeichnet. Dabei entsteht Collective Code Ownership, d.h. jedes Team-Mitglied verantwortet den gesamten Code gleichermaßen.
Vorteile des Pair Programmings
Pair Programming verbessert die Qualität der Software und Fehler werden früher erkannt. Dies liegt nahe, da zwei Personen mit unterschiedlichen Wissensständen, Erfahrungen und Perspektiven ihre Gedanken konsolidieren – gemäß der Lebensweisheit „vier Augen sehen mehr als zwei“. Fehler, die schneller auffallen und behoben werden, führen zu weniger Arbeit, als solche, die erst spät bemerkt werden. Dadurch führt Pair Programming insgesamt zu weniger Arbeit.
Umfragen zufolge steigert Pair Programming bei den meisten Programmierern den Spaß an der Arbeit und eine höhere Motivation geht meist mit einer besseren Leistung einher.
Pair Programming führt zu einer Wissensverteilung im Team, wodurch das gesamte Team an Kompetenz gewinnt. Gleichzeitig werden Wissensinseln abgebaut und der sogenannte Truck-Faktor, auch Bus-Faktor oder wohlwollender Lotto-Faktor genannt, wird reduziert. Dieser beziffert das Risiko, dass ein Projekt scheitert, weil ein Wissensträger das Team verlässt. Durch Pairing lernen Entwickler schneller alle Bereiche des Projektes kennen und erlangen die Kompetenz in diesen eine User Story umzusetzen, so dass es zu weniger Verzögerungen und Engpässen durch Krankheiten und Urlaube kommt.
Es fördert die Kommunikation, die Zusammenarbeit und auch die Sozialkompetenzen der Teammitglieder und stellt damit auch eine Maßnahme des Team Buildings dar. Insgesamt fördert Pair Programming die psychologische Sicherheit des Teams und das Verständnis füreinander, so dass Entscheidungen schneller und nachhaltiger getroffen werden können und weniger Frust entsteht.
Pairing führt zu weniger Unterbrechungen als bei Einzeltätigkeiten, da durchgehende Aufmerksamkeit erforderlich ist und der Partner es spürt, wenn diese nachlässt. Durch die Zusammenarbeit gelangt man auch eher in einen Flow-Zustand, der allgemein mit einer hohen Produktivität verbunden ist. Zwei kollaborierende Personen werden im Büro weniger oft durch Dritte unterbrochen, als Kollegen, die alleine in Einzelarbeit vertieft sind. Durch auferlegte Regeln kommt es zugleich seltener zu Unterbrechungen durch eintrudelnde E-Mails, Chat-Nachrichten oder Anrufe. Gerade wenn das Pairing im vorrangigen Kommunikationsmedium des Unternehmens in einem Video-Call stattfindet, wird dies für Dritte sichtbar und reduziert die Wahrscheinlichkeit, dass eine der beiden Personen direkt angerufen wird.
Mittels Pair Programming gelingt die Einarbeitung neuer Team-Mitglieder einfacher und erfolgreicher. Pairing-Partner arbeiten disziplinierter und tendieren dazu, einfachere Lösungen zu finden als Einzelarbeiter. Gleichzeitig findet mehr spontanes Brainstorming statt, was die Kreativität erhöht. Insgesamt werden die Lösungen durch Pair Programming diverser. Durch wechselnde Sparring-Partner und die gemeinsame Lösungsfindung haben Entwickler, die im Pair Programming arbeiten, gegenüber Einzelarbeitern mehr Vertrauen in ihre fertigen Lösungen.
Ohne Pair Programming muss ein Team mehr Zeit in seine Dokumentation stecken, konsequentere Code Reviews absolvieren, sich mit der Gefahr von Wissensinseln auseinandersetzen und dediziert Zeit in Team Building investieren.
Stolpersteine und Nachteile
Pair Programming erhöht den Zeitaufwand. In einem Team aus vier Entwicklern, werden bei konsequentem Pairing nur zwei statt vier Aufgaben parallel bearbeitet. Betrachtet man die Gesamtkosten, also langfristig falsch getroffene Entscheidungen, Mehraufwände durch schlechtere Qualität und erst spät gefundene schwer zu behebende Fehler, kann der Mehraufwand von Pair Programming zwar nicht direkt beziffert werden – es ist auch nicht messbar, ob Pairing langfristig teurer ist als Einzelarbeit, wenn man den Gesamtpreis betrachtet, während der Umsetzung einer Aufgabe ist Pairing aber erstmal langsamer als Einzelarbeit, da zwei Pairing Partner die Aufgabe in der Regel nicht doppelt so schnell abschließen wie ein Entwickler, der diese alleine umsetzen würde.
Pair Programming mag das falsche Gefühl vermitteln, dass zwei Partner gemeinsam immer auf die richtige bzw. beste Lösung kommen. Das ist leider nicht immer so. Es muss das richtige Maß gefunden werden, mit dieser Herausforderung umzugehen, gerade auch in Bezug auf Code Reviews. Pair Programming wird auch als Continuous Code Reviewing bezeichnet. Auch wenn es im Mittel unzweifelhaft die Qualität gegenüber der Einzelarbeit erhöht, mag es sich anbieten, je nach Kontext und Größe der Aufgabe dennoch ein separates Code Review durch einen Dritten als Teil der Umsetzung einzuplanen.
Gerade wenn sich im Team noch keine einheitliche Kultur etabliert hat, bestehende Meinungsverschiedenheiten noch nicht ausdiskutiert wurden und eine von allen akzeptierte Lösung für das Team noch nicht gefunden wurde, bietet Pair Programming Konfliktpotenzial. Auch der Arbeitsrhytmhus, bevorzugte Arbeitszeiten, Pausenregelungen und andere Termine können zu Streits führen.
Wenn die Zusammenarbeit nicht funktioniert, weil zwei Partner nicht zusammenarbeiten und keine Sympathie füreinander entwickeln können, kann Pair Programming sehr ineffektiv werden. Im falschen Maße eingesetzt kann Pair Programming auch zu übermäßiger Erschöpfung und Burnout führen, etwa wenn Pausen und Timeboxen nicht eingehalten werden.
Herausforderungen bieten auch bestimmte Arten von Aufgaben, etwa solche, die sehr Recherche-intensiv sind, da sie auf unbekanntem Terrain stattfinden. Hier bietet es sich an, konkrete Recherche-Aufgaben zu definieren, diese zwischen den Partnern aufzuteilen und später zu konsolidieren, oder tatsächlich auf Pairing zu verzichten.
Fazit
Aus meiner Sicht sprechen die Vorteile für sich und ich möchte sie hier nicht nochmal einzeln aufführen. Ein Team sollte sich seiner Werte bewusst sein, bevor es Pair Programming einführt. Soll eine Lösung als Wegwerfprodukt quick and dirty entstehen oder herrscht ein extremer Zeitdruck, sind die anfänglichen Kosten von Pair Programming wahrscheinlich zu hoch. Die meisten Projekte und Produkte streben aber nachhaltige Lösungen an. Eine frühzeitige gut gemachte Einführung von Pair Programming zahlt sich dann meiner Meinung nach irgendwann immer aus. Wichtig ist, die Effektivität im Blick zu behalten. Dazu habe ich in diesem Beitrag zahlreiche Tipps und Beispiele gegeben. Gerade die Konsolidierung der unterschiedlichen Blickwinkel, ein gemeinsamer Stil und ein festes Rahmenwerk sind unabdingbar, damit Pair Programming nicht nach hinten losgeht.
Alle Teammitglieder sollten dafür bereit sein und auch hinter den notwendigen Werten stehen, die ich im Abschnitt „Einstellung“ beschrieben habe. Besteht Unsicherheit, kann auch erstmal nach Pairing nach Bedarf oder auf Probezeit gearbeitet und später eine Retro dazu abgehalten werden. Wichtig ist auch die Erkenntnis, dass nicht jeder Lust auf Pair Programming hat. Niemand sollte zum Pair Programming gezwungen werden. Gibt es am Ende im Team ein oder zwei Einzelpersonen, die sich nicht am Pairing beteiligen möchten, so muss individuell eine Lösung dafür gefunden werden.
- "The Costs and Benefits of Pair Programming" von Alistair Cockburn