Menü
Ein Beitrag von Adacor

Pair Programming – Zu zweit zum Erfolg

Codebeispiel Pair ProgrammingPair Programming ist eine Arbeitstechnik, die helfen soll, die Programmierungs- bzw. Softwarequalität zu steigern.
Das Verfahren stützt sich maßgeblich auf das Prinzip „Vier Augen sehen mehr als zwei“. In meinem Text möchte ich über die Programmierpraxis des Pair Programming informieren und darüber hinaus die bei uns im Unternehmen gesammelten eigenen Erfahrungen teilen.

Was ist Pair Programming?

Unter Pair Programming oder Paarprogrammierung versteht man eine Methode der Programmierung, die zumeist bei der agilen Softwareentwicklung eingesetzt wird. Klassisch schreiben dabei zwei Programmierer den Quellcode während sie gemeinsam an einem Rechner sitzen. Daraus ergibt sich aus die Aufteilung in einen aktiven und einen passiven Part. Der aktive Part wird häufig mit einem Fahrer verglichen, da er das Steuer also die Tastatur bedient. Der Beifahrer hat den passiven Part und sitzt unterstützend daneben.

Weitere Formen des Pair Programming sind etwa Distributed Pair Programming (DPP) oder Remote Pair Programming (RPP). Beim DPP wird – unterstützt von Kollaborationswerkzeugen – gemeinsam an zwei Rechnern am gleichen Quellcode gearbeitet. Werden dabei größere Distanzen überbrückt, handelt es sich um RPP.

Pair Programming bei der ADACOR

Mit dem Pair Programming wird bei uns in der Entwicklungsabteilung erst seit Kurzem experimentiert. Versprochen haben wir uns davon vor allem eine Reduzierung der typischen Flüchtigkeitsfehler und eine bessere Wissensverteilung. Den Anfang hat die Entwicklung des Cloudbase-Projekts gemacht. Aufgrund der hohen Komplexität und dem Einsatz von neuen Technologien erschien eine Paarprogrammierung sinnvoll. Durch die positiven Effekte, die sich in diesem Projekt zeigten, wurde das Pair Programming überall dort übernommen, wo die Komplexität es verlangt oder Fehler besonders kritisch sind.

Erfahrungen aus der Anwendung des Pair Programmings

Pilot und Copilot beim Pairprogramming

Im Rahmen des Cloudbase-Projekts wird bei der ADACOR Hosting ein Reverse-Proxy von Grund auf neu entwickelt. Dabei wurde auf Technologien gesetzt, mit denen zu Beginn des Projekts keiner der Entwickler weitgehende Erfahrung hatte. Hinzu kommen eine komplexe, skalierbare Architektur und die zur Selbstorganisation nötigen Kommunikationswege. Gerade in den Anfängen des Projekts fanden wir Entwickler uns häufig in Arbeitssituationen wieder, die dem Pair Programming entsprechen. Oftmals waren typische Hilfestellungen oder Implementierungs-Absprachen der Auslöser, um zu zweit vor einem Rechner zu sitzen. Schnell zeigte sich, dass das Pair Programming gerade zum Erlernen neuer Technologien vorteilhaft ist, da sich auf diese Weise neues Wissen schneller verteilt. Bei komplexeren Aufgabenstellungen ist es sinnvoll, weil man zu jeder Zeit eine zweite Meinung einholen kann. Bevor man immer wieder seinen Kollegen unterbrechen muss und ihn aus seiner Arbeit reißt, bietet es sich an, komplexe oder kritische Aufgaben gemeinsam zu bearbeiten. Mit der Zeit ergab sich eine Pilot-/Copilot-Rollenverteilung, aus deren Perspektive nun persönliche Erfahrungen aufgezeigt werden.

Pilot

Als Pilot übernehme ich das Steuer selbst, im Fall der Softwareentwicklung also Tastatur und Maus. Ein Stück weit übernimmt man somit auch die Verantwortung für den entstehenden Quellcode. Je nach Copilot kann man sich schnell kontrolliert beziehungsweise bewertet fühlen. Ein guter Copilot sollte sich jedoch nicht nur auf das Aufzeigen von Tippfehlern und das Bemängeln des Programmierstils beschränken, sondern konstruktiv mitdenken, Ideen einbringen und Alternativen bereithalten. Nicht zuletzt durch diesen Druck empfinden die meisten die Rolle des Piloten anstrengender als die des Copiloten. Mit der Zeit spielt sich die Rollenverteilung jedoch sehr gut ein und man lernt die positiven Effekte eines Copiloten zu schätzen. Es entsteht qualitativ besserer Quellcode, der weniger Fehler aufweist, die sonst zu einem späteren Zeitpunkt aufwendig gefunden und behoben werden müssten. Hinzu kommt, dass man zu jedem eigenen Gedankengang eine zweite Meinung einholen kann, wodurch oft Quellcode entsteht, der wartbarer und überschaubarer ist.

Copilot

Der Copilot kann schnell mal als untätig missverstanden werden, da er zumeist kein Eingabegerät bedient. Dass es sich dabei um ein Missverständnis handelt, wird einem erst klar, wenn man diese Aufgabe selbst einmal übernommen hat. Als guter Copilot habe ich nicht nur stets ein Auge auf die Syntax und das Einhalten von Programmierstandards, sondern biete auch immer wieder Implementierungsalternativen an oder diene dem Piloten als Gedächtnisstütze für Dokumentation, Referenzen und dergleichen. Es kommt auch vor, dass sich der Copilot zu langweilen beginnt, da beim Piloten soweit alles gut ausschaut und es nichts zu klären gibt. Aber das ist ein gutes Zeichen dafür, wieder parallel weiterzuarbeiten oder die kommenden Aufgaben schon gedanklich anzugehen und Lösungsvorschläge vorzubereiten. Hat man einen wortkargen Piloten an der Seite, kann es schwerfallen, gedanklich zu folgen und seinen Pflichten entsprechend nachzukommen. In dieser Situation verfällt man schnell in das reine Aufzeigen von Tippfehlern, was die Produktivität des Pair Programming erheblich reduzieren kann.

Tipps für produktives Pair Programming

Aus den Perspektivenbeschreibungen von Pilot und Copilot lässt sich schon erahnen, dass es sinnvoll ist, die Rollen regelmäßig zu tauschen. Auch die Pair-Programming-Partner sollten häufiger wechseln, erst recht, wenn man das Ziel der besseren Wissensverteilung anstrebt. Man sollte nicht versuchen, alles mit Pair Programming zu erschlagen und dann erwarten, dass im Quellcode keine Fehler mehr auftreten. Es empfiehlt sich, das Pair Programming nur dort einzusetzen, wo neues Wissen erarbeitet werden muss, eine komplexe Aufgabenstellung vorliegt oder etwa bei sehr fehlerkritischen Aufgaben. Die Wahl der Pair-Programming-Partner ist ebenfalls von großer Bedeutung. Annähernd gleicher Kenntnisstand und eine gewisse persönliche Kompatibilität sind ein Muss, da sonst das Pair Programming in Summe unproduktiver ist als die klassische Softwareentwicklung.

, ,

Sie möchten keinen Beitrag verpassen?

Es gibt einen Newsletter. Hier können Sie ihn abonnieren.

Datenschutzhinweise


Weitere Artikel zum Thema lesen

Der Docmanager – Einblicke ins Intranet

IT-News

Der Docmanager – Einblicke ins Intranet

Mit dem Docmanager bieten wir euch Einblick in unser Intranet. Falls ihr gerade ein Dokument der ADACOR in euren Händen haltet, ist die Wahrscheinlichkeit...

weiter lesen

Unterschied zwischen Radio-Frequency Identification und Near-Field-Communication

IT-News

Unterschied zwischen Radio-Frequency Identification und Near-Field-Communication

Im Zusammenhang mit M2M-Kommunikation fallen immer oft Begriffe wie RFID und NFC. Während die Radio-Frequency Identification (RFID) eine mögliche Datenübertragungsform im Zusammenhang mit M2M-Kommunikation...

weiter lesen

In der Akronymecke heute das Triple-A-System

IT-News

In der Akronymecke heute das Triple-A-System

Die drei A im Triple-A-System stehen für Authentication, Authorization und Accounting.

weiter lesen


Neueste Nachrichten von Adacor

IT Security

Risikomanagement als Mehrwert für Unternehmen sehen

Wie Sie das Zusammenspiel von ISMS und IKS für sich nutzen können.

weiter lesen

Cloud

AWS, Azure und Co.: Brauchen Sie wirklich eine große Public-Cloud?

Das Angebot großer Public Clouds klingt für viele Unternehmen verlockend. Eine Private Cloud kann jedoch die ökonomisch sinnvollere Lösung sein.

weiter lesen

Biz & Trends

Was ist eigentlich Digitalisierung?

Der Begriff „ Digitalisierung“ weist viele Facetten auf. Die Aufteilung in Bereiche bringt jedoch Klarheit.

weiter lesen