Pair Programming

Pair Programming bedeutet, dass zwei Entwickler gemeinsam an einer Workstation arbeiten. Einer tippt (der Driver); der andere beobachtet, denkt und navigiert (der Navigator).

Das scheint ineffizient. Sie bezahlen zwei Personen für die Arbeit einer Person. Aber die Rechnung geht anders auf, als Sie erwarten würden:

• Weniger Bugs erreichen die Produktion (der Navigator fängt Fehler in Echtzeit ab)
• Wissen verteilt sich im Team (keine Wissenssilos)
• Codequalität verbessert sich (Echtzeit-Code-Review)
• Junior-Entwickler entwickeln sich schneller (lernen von Seniors)
• Fokus verbessert sich (es ist schwieriger, Twitter zu checken, wenn jemand zuschaut)

Studien zeigen, dass Paare Code mit 15 % weniger Defekten produzieren und dabei nur 15 % mehr Zeit benötigen. Das sind nicht doppelte Kosten für bessere Qualität – es ist eine 15%ige Investition für dramatisch bessere Ergebnisse.

Das klassische Pairing-Modell hat zwei Rollen:

Der Driver hat die Tastatur. Er:

• Tippt den Code
• Konzentriert sich auf die unmittelbare Aufgabe (Syntax, diese Zeile, dieser Test)
• Denkt taktisch über die Implementierung
• Spricht durch, was er tut

Der Navigator beobachtet und denkt. Er:

• Überprüft Code, während er geschrieben wird
• Denkt strategisch (ergibt dieses Design Sinn?)
• Behält das große Ganze im Blick
• Fängt Tippfehler, Logikfehler und Designprobleme ab
• Schlägt Dinge nach, wenn nötig

Wechseln Sie regelmäßig die Rollen. Alle 15-30 Minuten tauschen. Das hält beide Partner engagiert und verhindert, dass eine Person dominiert.

Der Navigator ist nicht passiv. Wenn Sie navigieren und etwas Falsches sehen, sprechen Sie sofort an. Warten Sie nicht. Der Wert des Pairings kommt von kontinuierlichem Feedback.

Es gibt mehrere effektive Pairing-Stile:

Ping-Pong-Pairing (funktioniert großartig mit TDD):

1. Person A schreibt einen fehlschlagenden Test
2. Person B bringt ihn zum Laufen und schreibt den nächsten fehlschlagenden Test
3. Person A bringt ihn zum Laufen und schreibt den nächsten fehlschlagenden Test
4. Weiter abwechseln

Das hält beide Personen aktiv beim Coden und erhält die TDD-Disziplin.

Strong-Style Pairing: „Damit eine Idee von Ihrem Kopf in den Computer gelangt, muss sie durch die Hände einer anderen Person gehen."

Der Navigator sagt dem Driver, was er tippen soll. Der Driver tippt nur; er trifft keine Entscheidungen. Das ist großartig zum Lehren – der Junior tippt, während der Senior navigiert, was Wissenstransfer erzwingt.

Tour-Guide-Pairing: Eine Person kennt die Codebasis; die andere lernt. Der Experte fährt und erklärt, gibt eine Tour durch den Code. Dann tauschen sie, wobei der Lernende Aufgaben unter Anleitung versucht.

Wählen Sie den Stil, der zur Situation passt. Ping-Pong für TDD. Strong-Style für Mentoring. Tour-Guide für Onboarding.

Pairing funktioniert auch remote. Sie brauchen:

• Screen Sharing mit niedriger Latenz (VS Code Live Share, JetBrains Code With Me oder Screen Share mit Fernsteuerung)
• Sprachkommunikation (konstante Audioverbindung)
• Kamera optional, aber hilfreich (Reaktionen und Körpersprache sehen)

Remote-Pairing-Tipps:

• Verwenden Sie ein Tool, das beiden Personen das Tippen ermöglicht (nicht nur Screen Share)
• Machen Sie häufigere Pausen – Remote-Pairing ist anstrengender
• Kommunizieren Sie verbal mehr (Sie können Körpersprache nicht so gut lesen)
• Einigen Sie sich auf Editor-Einstellungen und Tastenkombinationen, bevor Sie beginnen

Einige Teams finden, dass Remote-Pairing sogar besser funktioniert als persönlich, weil es keine „Lehnen Sie sich vor und nehmen Sie die Tastatur"-Versuchung gibt. Jede Person bleibt in ihrer Rolle.

Pairen bei:

• Komplexen Problemen, wo zwei Perspektiven helfen
• Kritischen Codepfaden (Authentifizierung, Zahlungen, Datenintegrität)
• Unbekanntem Code (eine Person kennt ihn, eine lernt)
• Wenn Sie feststecken (frische Perspektive löst Blockaden)
• Onboarding neuer Teammitglieder

Erwägen Sie Einzelarbeit für:

• Einfache, routinemäßige Aufgaben (Konfiguration aktualisieren, Dinge umbenennen)
• Explorative Spikes (wenn Sie allein nachdenken müssen)
• Wenn eine Person tiefe Expertise hat, zu der die andere nicht beitragen kann

XP schreibt nicht 100 % Pairing vor, trotz verbreiteter Annahme. Das ursprüngliche XP spezifizierte Pairing für Produktionscode, aber modernes XP erkennt an, dass effektive Teams Solo- und Paararbeit basierend auf dem Kontext mischen.

Der Schlüssel: Lassen Sie niemals Code ohne Review in die Produktion gehen. Wenn Sie nicht darauf pairen, reviewen Sie ihn. Pairing ist einfach Echtzeit-Code-Review.

„Unsere Entwickler wollen nicht pairen." Beginnen Sie langsam. Pairen Sie nur bei schwierigen Problemen. Lassen Sie die Leute die Vorteile erleben. Erzwingen Sie nicht 100 % Pairing am ersten Tag.

„Wir können uns nicht zwei Personen für eine Aufgabe leisten." Sie können sich auch keine Produktionsbugs leisten. Die Wirtschaftlichkeit spricht für Pairing, wenn Sie reduzierte Bugs, geteiltes Wissen und verbesserte Codequalität berücksichtigen.

„Senior-Entwickler werden verlangsamt." Manchmal. Aber Seniors, die mit Juniors pairen, beschleunigen das ganze Team. Das Wissen des Seniors verbreitet sich. Der Junior entwickelt sich. Es ist eine Investition in die Teamkapazität.

„Introvertierte hassen Pairing." Einige Introvertierte lieben Pairing, weil es strukturierte Interaktion mit einem klaren Zweck ist. Andere brauchen Einzelzeit zum Aufladen. Respektieren Sie individuelle Bedürfnisse, aber gehen Sie nicht davon aus, dass Introversion Anti-Pairing bedeutet.

„Pair Programming ist erschöpfend." Es ist intensiver als Einzelarbeit. Machen Sie Pausen. Pairen Sie nicht 8 Stunden am Stück. Mischen Sie Pairing mit Einzelarbeit, Code-Review oder Designarbeit.