Zusammen programmiert man weniger allein

Pair Programming: Vorteile und Voraussetzungen

Oliver Welte

© Shutterstock / Spectral-Design

Programmieren im Team gilt als effektiv und agil. Zugleich ist es aber auch anstrengend und bisweilen frustrierend, wenn das Team in Meinungsverschiedenheiten festhängt. In der Praxis haben sich einige Regeln bewährt, mit denen alle Beteiligten Nutzen aus dem Pair Programming ziehen.

Software entsteht typischerweise in einem iterativen Prozess. Developer entwickeln zumeist allein an verschiedenen Einzelfunktionen, andere Entwickler überprüfen den Code und machen Änderungsvorschläge, die dann wieder beim eigentlichen Developer landen. Pair Programming führt diese Prozesse mit dem Ziel zusammen, effektiven und hochwertig(er)en Code zu erzeugen. Beim Pair Programming sitzen demnach zwei Entwickler vor einem Rechner mit zwei Monitoren an derselben Aufgabe. Doch sie programmieren nicht nur gleichzeitig, sondern zusammen. Während des Programmierens wird gesprochen, kritisiert, diskutiert und es werden laufend neue Optionen eingebracht. Pair Programming ist kommunikationsintensiv.

Doch warum soll das effektiver sein? Sowohl Code Review als auch Refactoring finden bereits während des Development-Prozesses statt. Das spart die Reviewing-Runden, die bei klassischen Entwicklungsprojekten einen erheblichen Aufwand ausmachen. Und auch die Zeiten werden eingespart, in denen die Entwickler jeweils darauf warten, bis der andere seinen Teil erledigt hat. Die Praxis zeigt, dass beim Pair Programming zudem weniger Fehler auftauchen und weniger Sackgassen entstehen – vier Augen sehen mehr als zwei und zwei Entwickler haben mehr Ideen als einer. Durch die enge Zusammenarbeit entsteht spontanes Brainstorming, Informationen werden auf direktem Weg ausgetauscht. In manchen Fällen kann es sogar sinnvoll sein, statt zwei spezialisierten Entwicklern, einen Developer zusammen mit einem Designer oder Product Manager arbeiten zu lassen. Letztere haben noch mal eine andere Sicht auf das Produkt und bringen so ihren Input frühzeitig mit ein.

Pair Programming braucht Regeln

Nach jeder Beschreibung der Vorteile des Pair Programming folgt ein „aber“. Und das zu Recht. Denn wenn jeder Schritt gerechtfertigt und auch kleinste Unstimmigkeiten ausdiskutiert werden, ist das für die Beteiligten teilweise eben auch anstrengend. Es gibt deshalb einige Grundvoraussetzungen und Regeln, die dem Pair Programming zugrunde gelegt werden sollten. Die wichtigste: Die Team-Mitglieder sollten sich grundsätzlich sympathisch sein, kommunikativ auftreten und vor allem auch offen dafür sein, Verbesserungsvorschläge zu besprechen und voneinander zu lernen. Für Befindlichkeiten und Kritikunfähigkeit ist kein Platz. Empathie, Vertrauen und Hilfsbereitschaft helfen jedem Team besser und effektiver zu werden.

Beim Pair Programming ist es besonders wichtig, die Ziele und Erwartungen an das Projekt und die Zusammenarbeit vorab zu definieren. Dabei sollte auch die Development-Partnerschaft selbst hinterfragt werden: Geht es darum, Wissen auszutauschen oder darum, neue Techniken einzubringen? Handelt es sich um die Zusammenarbeit zweier erfahrener Entwickler oder sollen andere Fachkenntnisse einfließen? Diese Vorarbeit lohnt sich, verhindert sie doch Missverständnisse und Umwege.

Soll das Pair Programming effektiv bleiben, sind fest eingeplante Pausen wichtig. Neben Zeiträumen zur Erholung gilt es, andere Verpflichtungen ausserhalb des Zweier-Teams einzuplanen und nachzugehen. Zudem sollten die Team-Mitglieder vorab diskutieren, welche Ablenkungen zulässig sind: Können beide während der Zusammenarbeit darauf verzichten, E-Mails oder Push-Nachrichten zu checken? Welche Ereignisse sind wichtiger als das Programmier-Projekt und könnten jederzeit mittendrin auftreten und den Entwicklungsprozess unterbrechen? Ein detaillierter Tages- oder Wochenplan hilft, die Developing-Sessions gut anzupassen und genug Raum für Flexibilität zu schaffen.

Pair Programming / Quelle: Pivotal

Feste Strukturen für Pair Programmer

Manchen Teams fällt die Zusammenarbeit leichter, wenn sie nach einem bestimmten Muster zusammenarbeiten. Das heißt, dass jeder Partner mehr oder weniger eine Rolle innehat. Zum Beispiel funktionieren Fahrer-Navigator-Teams in der Praxis sehr gut. Der „Fahrer“ ist derjenige, der die Ideen und Vorgaben des „Navigators“ umsetzt, sprich programmiert. Der Navigator gibt keine direkten Anweisungen, sondern führt eher abstrakt in die gewünschte Richtung. So entsteht aus einem eher übergeordneten Ansatz des einen, die praktische Umsetzung des anderen. Perfekt, um Ideen auf Umsetzbarkeit und Praxistauglichkeit zu prüfen. Die Rollen sollten in kurzen, regelmäßigen Abständen immer wieder getauscht werden.

Ebenso sinnvoll kann es sein, sich quasi als „Ping-Pong-Team“ den Ball immer hin und her zu werfen. Etwa im Bereich Test-driven Development (TDD) funktioniert das gut: Ein Entwickler schreibt einen fehlerhaften Test und übergibt an seinen Partner. Dieser implementiert das Minimum dessen, was notwendig ist, um den Test zu bestehen. Anschließend ergänzt er seinerseits neuen Code, den der erste Partner wiederum Test tauglich macht. Manche Teams arbeiten aber auch unstrukturiert am besten, gerade dann, wenn sich beide bereits kennen und die Fähigkeiten des anderen schätzen.

Dass das Arbeiten mit Pair Programming funktioniert, zeigt zum Beispiel das Digital Lab von Volkswagen. Bereits im Jahr 2015 startete VW in Zusammenarbeit mit Pivotal hier sein IT Lab in Berlin. Heute arbeiten knapp 60 Mitarbeiter aus über 25 verschiedenen Nationen zusammen an Software-Lösungen. Das Konzept rund um agile Arbeitsmethoden und Pair Programming hat sich bei Volkswagen über die vergangenen vier Jahre derart etabliert, dass es mittlerweile konzernintern sechs weitere Standorte für IT Labs gibt.

Pair Programming ist keine Technik, mit der Developer acht Stunden täglich am Stück arbeiten können. Dafür ist es schlicht zu anstrengend und bietet zu wenig Zeit, Sachverhalte gründlich zu durchdenken. Aber: Pair Programming ist eine sinnvolle Erweiterung, da gleichzeitig mehrere Sichtweisen in die Arbeit einfließen und durch offene Kommunikation besserer Code entsteht. Grundvoraussetzung ist, dem Pair-Programming-Partner als Mensch mit Empfindungen und Launen zu akzeptieren.

Geschrieben von
Oliver Welte

Oliver Welte ist Sales Manager CEMEA – Manufacturing bei Pivotal. Das Unternehmen aus San Francisco bietet eine Plattform, Entwickler-Tools sowie eine einzigartige Methodik, um den weltweit größten Unternehmen dabei zu helfen, die Art und Weise zu optimieren, wie sie ihre wichtigsten Anwendungen entwickeln und betreiben. Unter den Kunden von Pivotal in Deutschland sind unter anderem Allianz, Bosch, VW und Mercedes.

Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Pair Programming: Vorteile und Voraussetzungen"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Det
Gast

Nachdem der gesamte Artikel für mich eher nach dem üblichen Blahblah klang, mit dem wieder ein Konzept als der Gral angepriesen und den Entwicklern an“befohlen“ soll, kommt der letzte Absatz quasi im Rausgehen auf den Punkt.

Pair Programming macht zu bestimmten Zeiten für bestimmte Aufgaben Sinn.
Zu glauben, dass es für ein Entwicklungsprojekt effektiv oder überhaupt dienlich sei, wenn Entwickler morgens kommen, pair-programmen und abends nach Hause gehen, und das jeden Tag, ist eine Illusion.
Somit ist PP eine gelegentlich einzusetzende Arbeitstechnik und kein Team Entwicklungskonzept.
Wäre gut, wenn das endlich mal rüberkäme.