Warum ein zweiter Blick auf den Nutzen von Pair Programming lohnt

Pair Programming: Gemeinsam weniger einsam programmieren
Keine Kommentare

Pair Programming wird bereits in vielen Entwicklungsabteilungen diskutiert, aber bei Weitem nicht überall tatsächlich gelebt. Es gibt vielfältige Vorbehalte und Bedenken, und der erhoffte Nutzen bleibt oftmals eher vage. Mit diesem Artikel wollen wir in einem oft unbeachteten Bereich weitere Nutzenpotenziale aufzeigen, um so die Motivation für Pair Programming zu stärken.

Entwickler bekommen irgendwann einen Impuls zu Pair Programming, z. B. durch einen Vortrag oder Artikel, und beschließen, das mal auszuprobieren. Die ersten Erlebnisse sind durchaus positiv, die Qualität des Ergebnisses ist höher, man hat anregende Diskussionen und kommt auf gute Lösungen, die einer allein nicht gefunden hätte. Danach wird Pair Programming zwar in Situationen angewandt, in denen der Nutzen offensichtlich ist, aber nicht oft genug, um es zur Routine werden zu lassen. Oftmals schläft Pair Programming dann wieder ein oder wird nur ganz selten genutzt. Schade, denn eigentlich passiert beim Pair Programming im Verborgenen etwas, das ein Team erst wirklich erfolgreich werden lässt. Genau darauf soll der Fokus in diesem Artikel liegen.

Was ist Pair Programming?

Pair Programming bedeutet, dass zwei Entwickler gemeinsam an einem Rechner eine Aufgabe erledigen. Dabei gibt es im Pair zwei Rollen: Der Driver bedient die Tastatur und Maus und versucht, die aktuelle Lösungsstrategie in funktionierenden Code zu überführen. Der Navigator betrachtet die aktuelle Aufgabenstellung aus einer stärker konzeptionell geprägten Perspektive und überprüft gleichzeitig die entstehende Lösung auf konzeptionelle Fehler. Diese werden dann sofort im Dialog zwischen den Pairingpartnern gelöst. Die Rollen sollten im Pair regelmäßig getauscht werden.

Was ist ein gutes Team?

Teams, die Verantwortung übernehmen, sind für jeden Chef ein Wunschbild. Noch besser, wenn alle gemeinsam diese Verantwortung übernehmen und automatisch jemand einspringt, sollte mal ein Teammitglied temporär ausfallen. Aus der Perspektive eines Teammitglieds fühlt es sich gut an, Teil einer Gemeinschaft zu sein, mit anderen gemeinsam auf ein Ziel hinzuarbeiten, an einem Strang zu ziehen und seine Stärken und Neigungen gewinnbringend für die Zielerreichung einbringen zu können.

Idealerweise agiert ein gutes Team folgendermaßen: Das Team entwickelt zunächst ein gemeinsames Problemverständnis. Auf Basis dieses Problemverständnisses können dann von verschiedenen Teammitgliedern aufgrund ihrer unterschiedlichen Erfahrungen und Kompetenzen Lösungswege vorschlagen werden. In einem konstruktiven Dialog wird aus den verschiedenen Lösungsoptionen eine gemeinsame Lösungsvision entwickelt, die das Team dann gemeinschaftlich umsetzt. Das Team erkennt selbstständig Informations- und Kompetenzlücken und reagiert entsprechend, um diese adäquat zu füllen. Für das Ergebnis fühlt sich jeder im Team verantwortlich, unabhängig davon, wer an der Umsetzung beteiligt ist. Dabei packt jeder eigenverantwortlich dort mit an, wo es notwendig ist. Das funktioniert umso erfolgreicher, je besser das Team eingespielt ist.

Wie entstehen nun solche Teams? Entscheidend sind dabei in erster Linie die Rahmenbedingungen und die Teamkultur. Im Folgenden wollen wir uns auf den Aspekt Teamkultur fokussieren und aufzeigen, welchen positiven Einfluss Pair Programming darauf haben kann. Zunächst wollen wir uns aber dem offensichtlichen Nutzen von Pair Programming zuwenden.

Der offensichtliche Nutzen von Pair Programming

Pair Programming bedeutet einen gewissen Aufwand, der unterschiedlich bewertet wird. Diesem Aufwand stehen verschiedene Nutzen entgegen: an erster Stelle eine bessere Codequalität, die eine höhere Wartbarkeit verspricht, und eine höhere Ergebnisqualität. So entstehen im Pair oftmals einfachere, schnellere und weniger komplexe Lösungen, die anwendergerechter sind, und viele potenzielle Probleme sind bereits korrekt berücksichtigt. Damit erreichen wir einen reduzierten Aufwand für das Nacharbeiten, wie z. B. Codereviews, Refactoring oder auch Fehleranalyse und -behebung.

Ein weiterer Nutzenbereich ist der Know-how-Transfer, der zwischen den Pairingpartnern erfolgt. Man wird sich immer den ein oder anderen Trick abschauen können oder auch neue Codekonstrukte lernen. Das Verständnis für unbekannte Codebereiche lässt sich am schnellsten durch gemeinsames Arbeiten im Pair entwickeln. Und wenn ein Entwickler mit einem Tester im Pair arbeitet, werden beide gemeinsam aufgrund ihrer unterschiedlichen Perspektiven den effizientesten Lösungsweg und die ideale Teststrategie finden.

Aufwand von Pair Programming

Im Kontext von Pair Programming wird sehr häufig die Frage diskutiert, ob sich das lohnt. Es wird dabei der Aufwand im Verhältnis zum Nutzen bewertet. Vor allem bezüglich des Aufwands ist die Spanne von Einschätzungen sehr groß. Während einige Entwickler den Standpunkt „Wenn ich es noch jemandem erklären muss, dauert es länger, als wenn ich es schnell alleine mache“ vertreten und so also nicht nur vom doppelten Zeiteinsatz durch zwei Personen, sondern auch von einer längeren Dauer ausgehen, behaupten andere wiederum, dass sie mithilfe von Pair Programming viel schneller eine gute, nachhaltige Lösung erstellen können und so das Ergebnis nicht nur deutlich besser ist, sondern dabei auch noch Zeit gespart wurde. Spannend ist in diesem Zusammenhang, wie Teams Pair Programming bei der Aufwandsabschätzung berücksichtigen.

Der verborgene Nutzen von Pair Programming

Dieser verborgene Nutzen von Pair Programming entsteht nicht direkt im Kontext der zu erledigenden Aufgabe. Vielmehr ist Pair Programming – wenn es richtig genutzt wird – eine hervorragende Möglichkeit, um gegenseitiges Verständnis zu entwickeln, voneinander zu lernen und so die Arbeit in einem Entwicklungsteam angenehmer und effizienter zu gestalten.

Arbeitet ein Pair gemeinsam an einer Aufgabe, können beide Partner voneinander lernen. Das funktioniert auch, wenn beide Partner unterschiedliche Wissens- und Erfahrungsstände haben. Hierzu ist allerdings ein gewisser Grad an Offenheit erforderlich. Zunächst die Offenheit, Themen zu hinterfragen oder Verbesserungsvorschläge aktiv einzubringen sowie die Offenheit, Wissenslücken zuzugeben. Auf der anderen Seite bedarf es aber auch der Offenheit, durch diese Fragen seinen eigenen Standpunkt zu hinterfragen, vor allem aber auch Verbesserungen zuzulassen und das Augenmerk auch auf Kleinigkeiten zu lenken. Diese Kleinigkeiten können ein Tastatur-Shortcut, eine elegante Implementierung oder auch das Vorgehen bei der Fehlersuche oder der Informationsrecherche sein. In der Summe machen genau diese Kleinigkeiten einen guten Entwickler aus, und wer häufig mit verschiedenen Personen Pair Programming übt, der kann sich bei diesen auch vieles abschauen. Neue Erfahrungen und neues Wissen im Team verteilen sich auf diese Weise schnell und effizient.

Neben der persönlichen Wissensvermehrung entsteht aber auch eine gemeinsame Vorstellung im Team darüber, wie bestimmte Dinge am besten gelöst werden. Das Team wird genormt, und dieses Norming ist wiederum wichtig, um efzient diskutieren und arbeiten zu können. Eine gemeinsame Basis erlaubt es, dass sich Diskussionen um die wichtigen Aspekte drehen und nicht ständig über die gleichen Themen geredet wird, bei denen jeder im Team andere Vorstellungen oder Vorlieben hat. Ein komplettes Norming ist jedoch nicht das erklärte Ziel und einem funktionierenden Team auch nicht zuträglich. Unterschiedliche Meinungen sind zwingend notwendig, um Lösungsalternativen einzubringen und zu diskutieren. Entscheidend ist, auf welche Aspekte unserer Arbeit wir diese Diskussionen fokussieren wollen, die dann von allen Teammitgliedern im Einklang umgesetzt werden. Mithilfe von Pair Programming wird sehr schnell sichtbar, wo einzelne Teammitglieder unterschiedliche Stile und Vorlieben haben, und es kann nach einer Diskussion von verschiedenen Optionen und deren Vor- und Nachteilen ein gemeinsamer „Currently Best Approach“ festgelegt werden, ein Weg, den das Team gemeinsam als den richtigen empfindet, so lange, bis es neue Erfahrungen gesammelt und eine bessere Lösung gefunden hat. Im Pair entsteht dieses Alignment wesentlich schneller als durch unabhängige Entwicklung und nachgelagerte Codereviews.

Neben diesen lösungsorientierten Ansätzen entsteht aber noch etwas weitaus Wichtigeres: Die Pairingpartner entwickeln Empathie, ein gegenseitiges Verständnis für Meinungen, Bedenken und Motive. Mit gegenseitigem Respekt für die Position und Empfindungen des Gegenübers entsteht ein tiefes Vertrauen und ein Gemeinschaftsgefühl, das die optimale Basis für motiviertes Arbeiten ist.

Das wiederum bedeutet, dass wir nicht nur mit den Mitgliedern des Teams ein Pair bilden sollten, mit denen wir uns am besten verstehen und mit denen wir schon die größten Gemeinsamkeiten haben. Gerade mit den „Quertreibern“, mit denen, die uns und unseren Standpunkt nicht richtig verstehen, die unsere Überzeugungen augenscheinlich nicht teilen, sollten wir intensiver zusammenarbeiten. Das ist anstrengend, kann uns selbst und unsere Perspektive allerdings entscheidend weiterentwickeln.

Konkrete Tipps fürs Pair Programming

Im Folgenden noch einige ganz konkrete Tipps, wie Sie mit Pair Programming schneller und besser an den Start kommen können.

Time Box für Rollenwechsel: Ein Rollenwechsel beim Pair Programming ist immens wichtig, denn nur so lernen wir voneinander. Hat immer der die „führende“ Rolle, der es am besten kann, wird der Zweite weniger Motivation empfinden, sich selbst aktiv zu beteiligen. Eine Time Box hilft dabei, den Wechsel wertfrei zu machen. Es übernimmt nicht derjenige die Umsetzung, der es am besten kann, sondern der, der an der Reihe ist. Dabei empfiehlt es sich, die Time Boxes sehr konsequent einzuhalten.

Onboarding neuer Teammitglieder: Ohne Unterstützung hat es ein Neuankömmling in einem Team sehr schwer. Häufig wird die Einarbeitungsdauer neuer Kollegen von den Teams auf mehrere Monate eingeschätzt. Das hängt damit zusammen, dass Entwickler erst ein gutes Verständnis der bestehenden Codebasis und der Anwendungsdomäne brauchen, bevor sie etwas Sinnvolles beitragen können. Im Pair mit einem erfahrenen Kollegen kann ein Neuling allerdings bereits sehr früh einen Beitrag leisten, ohne das Risiko für Fehler zu erhöhen.

Ein dedizierter Mentor ist jedoch nur die zweite Wahl, denn dieser gibt sich oft nur ein paar Tage Zeit, bevor er wieder vom Alltag aufgefressen wird. Der Neuling steht dann binnen Kurzem oft wieder allein da. Der richtige Mentor ist das Team. Wird ein neues Teammitglied jeden Tag mit einem neuen Partner gepairt, entsteht sehr schnell ein guter Gesamtüberblick.

Routine durch Übung: Pairing wird nur dann gut funktionieren, wenn alle im Team bereit sind, sich aktiv daran zu beteiligen. Damit der oben beschriebene Kollateralnutzen eintritt, muss es auch mit einer gewissen Häufigkeit geschehen. Pair Programming nur dann einzusetzen, wenn es sich anbietet, kann zu wenig sein. Vielmehr sollte das Team sich darauf einigen, einen gewissen Anteil der Arbeit im Pair zu erledigen, um sich besser kennenzulernen und das Norming aktiv voranzutreiben. Dabei können sich selbst bei Aufgaben, für die ein Pairing ursprünglich nicht für sinnvoll erachtet wurde, durchaus positive Überraschungen ergeben.

Was ist Mob Programming?

Mob Programming ist gewissermaßen die Fortführung von Pair Programming. Dabei werden Aufgaben gemeinsam in einer Gruppe (dem Mob), z. B. dem Team, an einem einzigen Rechner bearbeitet. Dafür ist ein großer Bildschirm oder ein Beamer erforderlich, damit alle Beteiligten das aktuelle Geschehen verfolgen und darauf Einfluss nehmen können. Idealerweise ist auch der Anforderungsverantwortliche (z. B. Product Owner) aktiv beteiligt und kann so direkt Fragen zur Anforderung klären und das entstehende Ergebnis aus seiner Perspektive bewerten. Es gibt durchaus Teams, die dies als ihren Standardarbeitsmodus definiert haben und berichten, dass sie noch nie so schnell und effizient zu Lösungen gekommen sind. Aber selbst wenn Teams Mob Programming nur punktuell einsetzen, ist es eine extrem effiziente Möglichkeit, das Team-Norming und ein Gemeinschaftsgefühl zu entwickeln.

Infrastruktur/Set-up/Hardware: Auch nicht unterschätzt werden sollte die Auswahl der geeigneten Hardware. Für Programmierer bedeutet das zwei Bildschirme, aber nicht erweitert, sondern dupliziert. Beide sollten gleichberechtigten Zugriff auf die Inhalte haben. Muss einer um die Ecke schauen, macht das keinen Spaß und hängt ihn schnell ab. Tastatur und Maus können weitergegeben werden. Ansonsten sollte auch ausreichend Platz vorhanden sein. Sich gegenseitig auf dem Schoß zu sitzen, ist für viele dann wohl doch etwas zu viel Nähe.

Remote Pairing: Mit modernen Kommunikationslösungen wie Skype for Business kann auch remote hervorragend gepairt werden. Im Grunde sind die Gegebenheiten dort sogar ideal. Besonderes Augenmerk sollte dabei auf das aktuelle Befinden des Pairingpartners gelegt werden. Emotionale Änderungen sind remote schwerer zu erkennen. Eine Webcam kann dabei unterstützen, es bedarf allerdings etwas mehr Aufmerksamkeit als in einer Sitzung, in der der Partner neben einem sitzt.

Organisatorischen Raum schaffen: Für Pairing müssen organisatorische Rahmenbedingungen geschaffen werden. Die wichtigste dabei ist, klar auszusprechen, dass ein solches Vorgehen erwünscht ist. Sowohl das Team als auch die Organisation sollten sich klar dazu bekennen, an die Vorteile von Pair Programming zu glauben. Danach ist eine Kosten-Nutzen-Diskussion keine Frage mehr.

Retrospektive für die Pairing Session: Wie bereits zuvor ausgeführt, besteht ein großer Teil des Nutzens beim Pair Programming darin, etwas zu lernen. Dabei hilft es, wenn sich nach dem Ende einer Pairing Session die Partner gegenseitig fragen: „Was hast du in dieser Session gelernt?“

Pair Writing

Dieser Artikel ist auch im Pair entstanden. Die Autoren haben sich bewusst dafür entschieden, dieselben Konzepte einzusetzen wie beim Pair Programming. Also zwei Personen, ein Rechner. Obwohl es im Vorfeld eine gesunde Portion Skepsis gab, ob sich eine solche Aufgabe überhaupt zum Pairing eignet, waren die Erfahrungen damit überaus positiv. Erwartet wurde, dass jeder für sich besser seine Gedanken ordnen und in Worte fassen sollte. Tatsächlich haben sich aber an unterschiedlichen Formulierungen und thematischen Schwerpunkte überaus spannende Diskussionen ergeben, die nicht nur zu einem wesentlich tieferen gemeinsamen Verständnis des Themas, sondern auch zu größerer Empathie zwischen den beiden Autoren geführt haben. Nach dieser Erfahrung gehen wir davon aus, dass es nur wenige Aufgabenstellungen gibt, bei denen Pair Programming gar keinen Sinn macht, es ist lediglich eine Frage des Willens und der Offenheit für den positiven Kollateralnutzen.

Fazit

Wer noch das Image des Softwareentwicklers als einsamer, kontaktscheuer Nerd pflegt, der wird sicher den Vorteilen des Pair Programmings eher skeptisch gegenüberstehen. Wer glaubt, dass er selbst die beste Lösung findet, wenn man ihn nur in Ruhe arbeiten lässt, der wird das Zusammenarbeiten im Pair eher als ein Ausbremsen denn als persönliche Bereicherung ansehen.

Wer aber an echte Teamarbeit glaubt, wer Spaß daran hat, mit anderen gemeinsam etwas zu erreichen, wer die Geborgenheit der Gruppe schätzt und auch bereit ist, sich am Arbeitsplatz darauf einzulassen, der braucht das richtige Team um sich herum. Teamarbeit wird zwar in sehr vielen Jobanzeigen versprochen, doch wird der Begriff sehr unterschiedlich interpretiert. Wenn eine Gruppe von Personen zusammen an etwas arbeitet, wird das schon als Team bezeichnet. Mit einer echten Teamarbeit mit Vertrauen, Empathie und gemeinsamen Zielen hat das aber oft nicht viel zu tun. Geschenkt bekommen wir ein solches Team nicht, es wird nicht von allein entstehen. Jeder hat die Möglichkeit, sein Team und somit sein Arbeitsumfeld mit zu prägen. Die meisten Teams haben ausreichend Gestaltungsspielraum, diesen Ansatz zu nutzen, um zunächst erste Erfolge unter Beweis zu stellen und damit für mehr zu werben. Pair Programming ist ein methodischer Ansatz, mit dem wir neben der Stärkung technischer insbesondere auch die sozialen Kompetenzen im Team voranbringen. Frei nach dem Motto: Pfeif auf die Weihnachtsfeier und den Hochseilgarten – es lebe der Alltag!

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -