https://t3n.de/news/tipps-remote-pair-programming-entwicklung-1374246/
!assets/shutterstock-1681615609.jpg Private or broken link
The page you're looking for is either not available or private!
Pair-Programming im Homeoffice ist eine echte Herausforderung. (Foto: fizkes / shutterstock)
Wo Menschen eng zusammenarbeiten und kommunizieren, ist Homeoffice eine Herausforderung. Auch Pair-Programming, also die gemeinsame Arbeit an einem Quellcode, lebt vom Miteinander. Damit das auch remote funktioniert, können folgende Tipps helfen.
Gerade Entwicklerinnen können im Homeoffice gut – weil ungestörter – arbeiten, sollte man meinen. Leider ist häufig genau das Gegenteil der Fall, denn besonders der fachliche Austausch mit den Kolleginnen fehlt. Gerade agile Softwareentwicklung leidet unter der Distanz, lebt sie doch als iterativer Prozess davon, dass sich das Entwicklerteam selbst organisiert und ständig weiterentwickelt. Regelmäßige kurze Meetings oder Development-Techniken wie zum Beispiel das Pair-Programming erfordern eine enge Zusammenarbeit.
Beim Pair-Programming arbeiten zwei Entwickler*innen zur gleichen Zeit am selben Task aktiv zusammen – und zwar in der Regel auf derselben VM, nebeneinander vor zwei Monitoren sitzend. Dabei wird diskutiert, konstruktiv kritisiert, direkt korrigiert und ausprobiert. So zu entwickeln, ist extrem kommunikationsintensiv und auch anstrengend, das Team muss sich gut verstehen. Die Praxis zeigt, dass Pair-Programming in einem agilen Umfeld sehr gut funktioniert. Code-Reviews und Refactorings sind so bereits Teil des Developments selbst – das spart nicht nur Nacharbeit, sondern verhindert auch früh Sackgassen und Missverständnisse. Pair-Programming steht dabei keinesfalls allein, sondern sollte in der Software-Fabrik als Teil einer umfassenden Methodik implementiert werden, die Prozesse, Vorgehensweisen und Platform-as-a-Product mit einschließt. So lässt sich hochwertiger Code effektiver entwickeln. Doch wie kann das funktionieren, wenn jeder allein im Homeoffice arbeitet?
Pair-Programming lebt von der Kommunikation. Der Prozess des Problemlösens unterscheidet sich sehr stark von der herkömmlichen Art und Weise, wie ein fertiges Codefragment reviewt wird. Jede Aktion der Programmierer*innen steht direkt auf dem Prüfstand, wird infrage gestellt und muss begründet werden. Code entsteht aus der Diskussion heraus. Ein Pairing-Team muss darüber sprechen, was es tut, während es dies tut. Dabei sollten sich die Partner auf derselben lösungsorientierten Arbeitsebene befinden, ausschließlich fachlich und so unemotional wie möglich diskutieren.
Um strukturiert zu arbeiten, kann es helfen, die Arbeit aufzuteilen: Während ein Developer hauptsächlich programmiert und über die nächsten logischen Anweisungen nachdenkt, übernimmt der andere die strategischen Überlegungen. Er prüft, welche Auswirkungen eben erstellter Code auf andere Programmteile hat, welche funktionalen Anforderungen er erfüllt oder eben noch nicht erfüllt und wie es weitergehen muss. Die Überlegungen von beiden zusammen ergeben dann einen gut durchdachten nächsten Schritt. Werden die Rollen laufend getauscht, entsteht eine sehr produktive Dynamik.
Apropos Kommunikation: Ausführlich über Erwartungen, Ideen und Probleme zu sprechen, ist äußerst hilfreich. Ein beinahe ebenso großer Teil der Kommunikation läuft jedoch nonverbal ab. Für das Pair-Programming sind daher Videochats gut geeignet: Während Video-Plattformen bei Meetings von größeren Gruppen durch Latenzen und Priorisierung bei der Datenübertragung schnell an ihre Grenzen kommen, lässt es sich zu zweit gut damit arbeiten. Sinnvoll ist es, sowohl den Video- als auch den Audio-Kanal ständig eingeschaltet zu haben, damit der Partner auch in schweigsameren Arbeits- und Denkphasen weiß, was gerade geschieht.
Wichtig ist zudem, dass die Technik gut funktioniert und die Beteiligten mit den Tools umgehen können. Das klingt zunächst nach einer selbstverständlichen Voraussetzung, nicht immer jedoch ist das so leicht umsetzbar. Neben einem leistungsfähigen Internetzugang gehören auch gute Audiogeräte, etwa ein Headset mit Mikrofon, dazu. Hintergrundgeräusche können so besser ausgeblendet werden. Außerdem kann es sinnvoll sein, dass jeder Entwicklerin zwei Monitore zur Verfügung hat – einen für die gemeinsame Bildschirmnutzung und einen für die Videoübertragung.
Hinzu kommt die Wahl der passenden Tools. Der Markt bietet vielfältige Möglichkeiten, viele Firmen haben zudem bestimmte Lizenzen oder Vorgaben. Die meisten Video-Plattformen eignen sich grundsätzlich gut und haben die Möglichkeit zur gegenseitigen Bildschirmfreigabe inklusive. Auch hierbei kann es vorkommen, dass Latenzen bei der Datenübertragung die Programmierung erschweren. Hier können Break-out-Räume hilfreich sein. Über Instant-Messaging-Dienste kann zugleich gechattet werden, manche erlauben die Integration von anderen Tools und Apps. Auf jeden Fall sollten sich die Pair-Programmer darüber vorab austauschen, wie sie die gemeinsame Arbeit organisieren wollen.
Wenn Software agil entwickelt wird, steht zu Beginn – außer den Anforderungen, die die Software erfüllen soll – wenig fest. Developer sollten sich bewusst Zeit für den Entwurf der Software-Architektur nehmen und bereit sein, sie im Laufe des Prozesses immer wieder neu auszurichten und anzupassen. Oft gibt es verschiedene Entwurfsmuster, Bibliotheken oder Frameworks, die das Problem von unterschiedlichen Seiten aus angehen. So kann es effektiver sein, ein vorhandenes, gut dokumentiertes Framework zu nutzen, als ganz neu zu entwickeln. Zudem fließen bei der agilen Softwareentwicklung die Erfahrungen mehrerer Experten direkt in den Prozess ein, sodass etliche Ansätze diskutiert werden können. So kann man flexibel die passende Architektur zusammenstellen und sich der idealen Lösung immer weiter annähern.
Es ist eines der Hauptanliegen der agilen Softwareentwicklung und des Pair-Programmings im Besonderen, dass die Teammitglieder voneinander lernen. Der Austausch ist rege, verschiedene Erfahrungen und Skills fließen ein. Sind alle im Homeoffice, ist das im Prinzip zwar immer noch so, beschränkt sich aber doch sehr auf das Projektteam selbst. Von anderen Projekten erfährt man nur noch wenig und das informelle, unspezifische Fachgeplänkel zwischendurch findet nun kaum mehr statt. Zwei Ansätze können hier helfen: Zum einen sollten Teammitglieder jeweils aktiv fragen, ob die Programmierpartner beispielsweise mehr über den ein oder anderen Skill erfahren möchten. Und zwar auch dann, wenn es vordergründig nicht zwingend mit dem eigentlichen Projekt zu tun hat. Zum anderen sind hier die Teamleiterinnen und Verantwortlichen gefragt. Sie sollten ihren Entwicklerinnen die Zeit und die Möglichkeit geben, sich auch im Homeoffice weiterzuentwickeln. Das kann durch Online-Weiterbildungsangebote geschehen oder durch Themenrunden im Kollegenkreis.
Software-Entwicklung ist ein anspruchsvoller Job, sowohl im Büro als auch im Homeoffice. Wird agil entwickelt – und erst recht, wenn Pair-Programming-Techniken genutzt werden – kommt viel Kommunikation hinzu. Das ist bisweilen per Videocall samt Chat sogar anstrengender als der formlose Austausch im realen Meeting. Das heißt konkret: Entwickler*innen sollten ihren Homeoffice-Alltag gut strukturieren und vor allem mehr Zeit für Pausen einplanen. Auch das klingt zunächst banal – in der Praxis zeigt sich jedoch, dass viele Homeworker dazu tendieren, länger am Schreibtisch zu sitzen, Pausen nur nach gefühltem Bedarf machen und deshalb Gefahr laufen, unkonzentrierter und damit ineffizient zu arbeiten. Absprachen mit dem Team und eine entsprechende Planung können dem entgegenwirken – natürlich immer unter der Maßgabe, auch innerhalb dieser Vorgaben flexibel zu bleiben.
Homeoffice ist gekommen, um zu bleiben. Auch wenn früher oder später viele Developer in ihre realen Großraumbüros und Meetingräume zurückkehren werden, wird Homeoffice vermutlich zu einem festen und breit akzeptierten Bestandteil der Arbeitskultur werden. Mit aktiver, konstruktiver und rücksichtsvoller Kommunikation sowie geeigneter Technik und passenden Tools funktioniert agile Softwareentwicklung im Homeoffice ebenfalls gut.