Suche
Zwei Köpfe sind besser als einer

Die Zukunft des Pair Programming

Steve Northover

© Shutterstock.com / wavebreakmedia

Warum steigert Pair Programming die Produktivität? Das könnte daran liegen, dass es gleich zwei Menschen dazu zwingt, den Code während des Schreibens zu verstehen. Steve Northover, Senior Technical Staff Member bei IBM, erklärt, wie Pair Programming die gemeinschaftliche Programmiererfahrung vereinfachen und erweitern kann.

Pair Programming ist eines der Grundprinzipien der agilen Softwareentwicklung, bei dem sich zwei Programmierer gleichzeitig auf eine Codebasis konzentrieren. Für gewöhnlich gibt es einen Driver, der schreibt, während ein Navigator oder Beobachter die Änderungen überprüft. Befürworter behaupten, dass die Produktivität dadurch verbessert würde, während Kritiker argumentieren, dass Pair Programming unter dem „Watch the Master“-Phänomen leide, bei dem einer nur zuguckt und wenig lernt.

Pair Programming zwingt zwei Menschen zeitgleich dazu, den Code während des Schreibens zu verstehen. Das ist ein Grund dafür, dass Pair Programming dabei helfen kann, die Produktivität zu erhöhen. Jeder kennt das ja: Wenn man jemand anderem eine Idee erklärt, hilft das beiden Beteiligten dabei, das Verständnis dieser Idee zu vertiefen und zu verbessern. Ein Konzept zu erklären kann Fehler und Inkonsistenzen aufdecken.

„Lass mich mal machen…“

Es gibt noch einen weiteren Vorteil: Wenn zwei Personen für eine Lösung verantwortlich sind und einer davon noch Anfänger ist, ist derjenige während der gemeinsamen Arbeit möglicherweise entspannter. Dadurch, dass der Experte den Anfänger betreut, hat dieser das Gefühl, alles richtig zu machen. So kann der Wissenstransfer vom Experten zum Anfänger ganz natürlich, ohne expliziten Unterricht stattfinden.

Normalerweise setzen sich Programmier-Paare gemeinsam an einen Arbeitsplatz und wechseln sich regelmäßig mit der Übernahme der Rollen ab. Dazu können sie die Tastatur übergeben oder die Plätze tauschen. Da der zu bearbeitende Code meistens auf dem Desktop des Entwicklers gespeichert ist, wäre es für einen Wechsel des Rechners nötig, einen Commit durchzuführen oder die aktuelle Version aller veränderten Dateien zu transferieren. Dann ist es einfacher die Tastatur zu übergeben.

Remote Pair Programming

Wenn eine Person des Zweierteams allerdings nicht vor Ort ist, werden direkte Interaktionen durch Telefonate, Screen-Sharing, Chatprogramme und Sprach- oder Video-Sharing ersetzt. Das kann jedoch die Arbeitsgeschwindigkeit beeinträchtigen und zu Verwirrungen und Unstimmigkeiten hinsichtlich der Frage führen, wer denn eigentlich gerade an der Tastatur sitzen sollte. Inzwischen existieren einige Tools für die Zusammenarbeit, die das Remote Pairing erleichtern sollen. Meistens arbeiten diese Tools mit gemeinsamen Screens und Dokumenten.

Screen-Sharing impliziert jedoch fast automatisch eine Driver-Observer-Beziehung und fällt in sich zusammen, wenn diese Rollen getauscht werden sollen. Die aktuelle Version des Codes befindet sich auf dem Desktop des Drivers, sodass zum Rollentausch die Dateien übermittelt und der Screen-Share übergeben werden müssen. Programme wie Screen Hero oder VNC verbessern diese Situation, indem sie ein interaktives Screen-Sharing für beide Parteien auf einem Computer erlauben.

Lesen Sie auch: Vom Pair Programming zum Mob Programming – Programmiertechniken im Wandel

„Nein, nein … beweg die Maus … nach links rüber!”

Mit Screen Hero können sich zwei Personen einen Screen teilen und haben jeweils einen eigenen Mauszeiger, wodurch der Rollentausch vereinfacht wird. So haben nämlich beide Partner die Möglichkeit zu tippen und etwas auf dem Bildschirm zu zeigen. Der Computer des Drivers dient als geteilte Ressource und arbeitet für den Driver ganz normal. Der Observer ist jedoch Nutzer zweiter Klasse, mit einer schlechten Bildschirmauflösung und geringen Performance auf seiner Seite. Wenn die Verbindung unterbrochen wird, kann er außerdem nicht weiterarbeiten.

Daneben ist es so, dass zwar beide Entwickler gleichzeitig tippen und klicken können, allerdings nur ein Fokus für Maus und Tastatur existiert. Wenn also gleichzeitig getippt wird, können Zeichen vermischt werden, Fenster können um den Fokus konkurrieren. Das Duo muss aktiv miteinander kooperieren und der Driver muss die Finger von der Tastatur lassen, wenn der Observer etwas eingibt.

„Ich sehe, was du da machst…“

Dienste zum Teilen von Dokumenten wie Google Docs und Box Notes ermöglichen einen geteilten Fokus innerhalb desselben Dokuments. Jeder Nutzer hat dort während der Bearbeitung einer Datei einen eigenen Eingabepunkt und kann gleichzeitig mit Anderen schreiben, ohne jemanden zu stören. Genau wie das Screen-Sharing zeigen auch geteilte Dokumente an, wer gerade an einer Datei arbeitet. Wichtiger ist aber, dass hier sichtbar ist, an welcher Zeile jemand gerade arbeitet. Oberflächlich betrachtet scheint das die Probleme mit dem interaktiven Screen-Sharing zu lösen. Die Dateiversion wird über die Cloud geteilt, Programmierer-Paare können zusammenarbeiten und ganz einfach die Rollen tauschen. Manchmal, vor allem beim Debuggen, geht es jedoch nicht nur um ein einzelnes Dokument, sondern darum, dass beide genau die gleichen Fenster sehen.

Das Ziel: eine gemeinsamen Entwickler-Wahrnehmung

Man stelle sich nun einmal eine Umgebung vor, innerhalb der jeder an seinem eigenen  Platz arbeitet und zugleich jederzeit mit anderen zusammen arbeiten und Versionen ganz leicht teilen kann. Hier ist ein Vorschlag, wie das gelingen könnte:

Im Zentrum der gemeinsamen Arbeitsumgebung für das Pair Programming der Zukunft mit gemeinsamer Entwickler-Wahrnehmung stehen das nahtlose Teilen von Dokumenten und die unmittelbare Zusammenarbeit auf dem Bildschirm. Funktionen wie Voice-, Chat- und Video-Kommunikation sind die Grundpfeiler. In dieser neuen Umgebung gelingt die Zusammenarbeit allerdings nahtlos. Um mit anderen zusammen zu arbeiten, muss die eigene Arbeit nicht mehr unterbrochen werden, um ein Tool für das Screen-Sharing zu starten oder eine URL für die Zusammenarbeit per Instant Messenger zu teilen. Jeder befindet sich jederzeit in dieser Arbeitsumgebung und arbeitet dort einfach.

Im Arbeitsalltag werden die meisten Leute einfach in ihrem eigenen Bereich arbeiten. Nominell wissen jedoch alle Teammitglieder jederzeit, wo und woran ihre Kollegen arbeiten. Das User Interface, das dazu genutzt wird, ist so subtil, dass es nicht bei der Arbeit stört. Wenn jemand in dieser neuen Umgebung Zugang zum Code eines Teamkollegen braucht, öffnet er ihn einfach. Jeder kann ganz leicht sehen, in welchem Verzeichnis sich ein Teammitglied befindet, welche Dateien derjenige geöffnet hat und welche Tests er durchführt. Auch wenn jemand nicht im eigenen Bereich arbeitet, ist sein Fortschritt jederzeit jedem zugänglich. Natürlich gibt es aber auch Zugriffsrechte, um einzuschränken, was andere sehen können. Der Standard ist jedoch der offene Zugriff für eine vertrauensvolle gemeinsame Umgebung.

Keine Unterbrechungen mehr nötig

Wenn man an einer Datei arbeitet und eine Frage hat oder Hilfe braucht, kann man einen Kollegen unmittelbar aus der Datei heraus ansprechen und weiter coden. Sobald die Frage beantwortet wurde, wird eine Benachrichtigung angezeigt. Das kann sofort passieren, falls der Andere gerade da ist und sich sofort einklinkt, um bei der Bearbeitung der Datei zu helfen. Manche Fragen sind allerdings nicht so dringend. Deshalb kann die Frage mit einer Dringlichkeitsstufe versehen werden. Jedem Mitarbeiter ist jederzeit bewusst, ob er noch offene Fragen beantworten muss. Weiß der angefragte Kollege keine Antwort, kann er die Frage außerdem an jemand anderen weitergeben oder weitere Personen zur Diskussion hinzufügen. Die Umgebung merkt sich, wer die Frage beantwortet hat und lernt daraus, wer die Experten sind. All das passiert nahtlos im Kontext der Quelldatei, während das Team Code schreibt.

Große Diskussionen und ein langes Hin und Her per Mail, Chat, Commits oder Pull Requests sind unnötig, wenn sich Ideen herausbilden und Code geschrieben wird. Teammitglieder kommunizieren direkt innerhalb der Umgebung miteinander. Experten können ganz leicht überblicken, ob ein Kollege sich auf dem richtigen Weg befindet oder gerade verläuft. Wenn mehr als eine Person an einem Verzeichnis arbeitet, lässt sich leicht nachverfolgen, was ein bestimmtes Teammitglied gerade daran macht. Ein Anfänger kann einem Experten folgen – oder anders herum – und dieselben Dateien interaktiv mitbearbeiten. So lässt sich sicherstellen, dass es während einer formalen Code-Review keine großen Überraschungen gibt. Kleine und große Probleme werden früh gefunden und lassen sich schnell lösen.

Hackathons in der Cloud-Umgebung?

Die Zusammenarbeit ist nicht auf eine einzelne Datei beschränkt. Stellen Sie sich einen Hackathon vor, bei dem ein Teammitglied den Server-Code schreibt, ein anderes das Frontend und eine dritte Person die Datenbank untersucht. Natürlich kommunizieren alle drei während der Programmierung per Voice- und Video-Chat aktiv miteinander. Das verhindert, dass sie sich gegenseitig auf die Füße treten. Allerdings kann zugleich auch jeder dabei zusehen wie Code geschrieben wird, inklusive Teammitgliedern, die gerade nicht aktiv programmieren. Verzeichnisse und Dateien entstehen als Lösungen auf dem Weg vom Nichts zum arbeitenden Code.

Man könnte sich auch eine Situation vorstellen, in der ein Programmierer-Paar an einer Aufgabe arbeitet und der nächste Schritt vollkommen klar ist. Es müssen dafür allerdings Änderungen an vielen verschiedenen Dateien vorgenommen werden. Das Duo könnten nun entscheiden die Aufgabe aufzuteilen – „Du machst die File-Referenzen; ich die im Code“. Oder einer kümmert sich um die Änderungen, während der andere zu einem neuen Thema recherchiert oder an ganz anderem Code arbeitet. Sobald das Duo wieder zusammenarbeiten will, ist alles bereits auf dem gleichen Stand, weil die Versionen im gemeinsamen Raum gespeichert werden.

Dezentrales Mentoring

Manchmal brauchen weniger erfahrene Personen auch Führung. Was wurde bereits ausprobiert, woran hängt es? Derjenige könnte währenddessen sogar in einer anderen Zeitzone sein. Ein Experte kann auf einen Blick sehen was gemacht wurde, welche Dateien geändert wurden und daraufhin Vorschläge machen, um den Anfänger zurück auf den richtigen Weg zu bringen. Beim Pairing klickt der erfahrenere Entwickler einfach auf den „Let me drive“-Button und der Anfänger kann automatisch verfolgen, wie der Experte den Code untersucht und verändert. Diese Interaktion ist nicht auf eine einzige Datei beschränkt. Die Umgebung zeichnet alle Arbeitsschritte auf, sodass jeder, inklusive dem Autor des Codes, in der Zeit zurückgehen und sehen kann, was passiert ist. Audio-Input wird automatisch zu Text konvertiert, sodass er durchsuchbar ist und synchronisiert werden  kann, während sich der Code ändert.

Der Unterschied zwischen produktiven Programmieren und Superstars ist erstaunlich. Produktive Programmierer, die mit Begeisterung dazu lernen, saugen allen Input auf und werden so zu den Superstars von morgen. Manche Fähigkeiten werden explizit erlernt, oft reicht es allerdings auch, mit jemandem zusammen zu arbeiten, der besser ist als man selbst, um selbst klüger zu werden. Wie genau das Wissen dabei vermittelt wird, ist vielleicht nicht ganz klar. Diese Art des impliziten Lernens ist allerdings durchaus verbreitet in der Musik und in anderen Disziplinen.

Bereits seit Jahren arbeiten Programmierer zusammen. Es wird Zeit, dass wir in einer Umgebung arbeiten können, die spontanes Lernen und Teilen fördert. Die verbesserte Umgebung für das Pair Programming der Zukunft wird die gemeinsame Programmier-Erfahrung sowohl vereinfachen als auch erweitern. Eclipse Orion wird in den kommenden Monaten das Pair Programming in der Cloud und die geteilte Entwicklungs-Erfahrung erforschen. Stay tuned!

eclipseorb_color

Dieser Artikel wurde ursprünglich in der December 2016 Ausgabe des Eclipse Newsletters: Ready, Set… 2017! veröffentlicht

Mehr Informationen bekommen Sie im Eclipse Newsletter.

Verwandte Themen:

Geschrieben von
Steve Northover
Steve Northover
Steve Northover is STSM (Senior Technical Staff Member) at IBM. He has almost 30 years of experience in software development with a focus on leadership, architecture, API design, implementation, optimization, testing and maintenance. Steve is a recognized expert in open source development, widget toolkits and the principal architect of SWT (The Standard Widget Toolkit) which is the user-interface component for the Eclipse open source project. In 2011, Steve was a recipient of the prestigious ACM System Software Award. As a well-respected leader at IBM, in 2007 he was awarded the designation of STSM (Senior Technical Staff Member). He is a frequent presenter at conferences, published author (“Inside SWT”) and long-time advocate of agile development.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.