Remote Pair Programming mit Eclipse Saros

Pair Programming gehört zu den empfohlenen agilen Vorgehensweisen, es ist insbesondere ein wichtiger Bestandteil des Extreme Programming (XP). Die anfängliche Skepsis, dass dieses Vorgehen durch doppelte Ressourcen viel zu teurer ist, sollte mittlerweile gewichen sein. Die folgenden Vorteile klingen auch erstmal sehr vielversprechend:

  • schneller als Soloentwicklung
  • weniger Bugs
  • sauberer Softwareentwurf
  • konzentrierteres Arbeiten
  • immerhin zwei Entwickler, die den Code wirklich kennen
  • Wissenstransfer und schnelleres Lernen
  • mehr Spaß bei der Arbeit


Natürlich stehen dem gegenüber auch Nachteile:

  • mehr Ressourcen benötigt
  • manche Programmierer mögen diese Vorgehensweise nicht

In der Wirtschaft wird Pair Programming aber immer noch sehr zögerlich eingesetzt, obwohl die Unternehmen dadurch einiges gewinnen:

  • schnellere Produkteinführungszeiten
  • höhere Design- und Codequalität
  • Verringerung von Flaschenhälsen durch Strong Code Ownership
  • ständiger Wissenstransfer zwischen den Kollegen

Eine Hauptursache dafür ist sicherlich die oft örtliche Verteilung der Teammitglieder. Selten sitzen wirklich alle Mitarbeiter am selben Standort, im selben Raum und sind vor allem auch immer im Büro. Sei es nun durch Outsourcing/Offshoring oder einfach nur banale Homeoffice-Arbeitsplätze bzw. die Verteilung auf mehrere Standorte, diese geographischen Grenzen verhindern natürlich das tagtägliche Zusammensetzen vor einem Rechner.

Screensharing ist nur sehr bedingt eine Alternative, da das eine Paar-Mitglied zum Nichtstun verurteilt ist. Außerdem ist durch die Netzwerklatenz und schwache Internet-Infrastruktur das Zuschauen dann mehr eine Qual.

Das Projekt Saros verspricht hier Abhilfe: Real-Time Distributed Software Development. Es handelt sich um einen Forschungsprototypen der Freien Universität Berlin, der seit 2006 als Eclipse Plugin entwickelt wird. Ein IntelliJ IDEA Plugin soll in Kürze folgen. Die Idee ist, daß bis zu 5 Leute in einer Session arbeiten können. Einzelne Änderungen werden in Echtzeit zu den anderen Session-Teilnehmern synchronisiert. Dabei ist man nicht gezwungen, mit den anderen Partnern genau auf der gleichen Ressource zu arbeiten, theoretisch könnte auch jeder andere Dateien anschauen und editieren. Es gibt aber auch einen Follower-Modus, wo ein Programmierer den Ton angibt und die anderen die Änderungen und auch mögliche Markierungen im Dateibaum und im Editor in Echtzeit nachverfolgen können.

Die Einsatzszenarien für Saros sind vielseitig:

  • Remote Code Reviews
  • Einarbeiten von entfernt sitzenden Anfängern
  • Verteiltes Pair Programming
  • Distributed Party Programming (unabhängiges Arbeiten von zwei oder mehr Personen)

Bei der Zusammenarbeit von verteilt sitzenden Team-Mitgliedern gibt es natürlich neben den technischen Problemen, die Saros versucht zu lösen, noch organisatorische und soziale Problemstellungen, die z. B. die Einführung von Remote Pair Programming komplizierter machen:

  • Zeitzonen-Unterschiede
  • technische Infrastruktur (Internetverbindung, Audio-/Video-Telefonie-Equipment, gemeinsame Code-Repositories, …)
  • Großraumbüro ist bei vielen parallelen Remote-Sitzungen ungünstig
  • Entwickler müssen es überhaupt wollen
  • es muß ein eingespieltes und stabiles Team sein
  • Entwicklungsprozess muß kompatibel sein
  • gute Kenntnisse der gemeinsamen Sprache der Paar-Partner (Deutsch, Englisch, …)

Daraus ergibt sich, daß man niemanden zu diesem Glück der Paar Programmierung zwingen, sondern auf Freiwillige und den Sog aufgrund der guten Erfahrungen setzen sollte.

Short URL for this post: http://wp.me/p4nxik-1Q2
This entry was posted in Agile Methods and development, Eclipse Universe, Java and Quality and tagged , , , , . Bookmark the permalink.

Leave a Reply