Unser Learning-Friday-Projekt MEGA befasst sich damit, die für den Monatsabschluss notwendigen Prozesse durch eine Softwarelösung zu vereinfachen. Die Projektmitglieder für die aktuelle Iteration des Projektes setzen sich aus einem vom Erfahrungsgrad sehr gemischten Entwicklerteam zusammen. Ebenso sind die fachlichen Kenntnisse der Entwickler ungleichmäßig verteilt. Ziel des Projektes ist die technische und fachliche Wissensverteilung und die Einhaltung der Release-Deadline.
Um die Jagd nach neuem Wissen und Features weiter voranzutreiben, haben sich acht Geparden zusammengeschlossen und jagen für die Projektlaufzeit in Paaren. Dabei erwarten wir uns, dass erfahrene Geparden ihr Wissen an Junggeparden weitergeben, ohne dabei an Geschwindigkeit zu verlieren. Im Zuge dessen steht auch die Evaluierung des “Code With Me”-Plugins für IntelliJ auf der Agenda. Dieses Plugin bietet eine gute Möglichkeit ohne Verwendung eines Versionierungstools zeitgleich an derselben Codebasis zu entwickeln.
Eine Möglichkeit des Pair-Programmings ist es, sich gemeinsam mit einem:r Entwickler:in an einen (Remote-)Tisch zu setzen und ein Feature miteinander zu entwickeln. Die beiden überlegen sich wie die Arbeit am besten aufgeteilt werden kann, definieren bei Bedarf die benötigten Schnittstellen und entwickeln anschließend unabhängig voneinander auf das gemeinsame Ziel hin. Für diese Technik bietet sich das IntelliJ-Plugin “Code With Me” hervorragend an, da es den Programmierer:innen ermöglicht, gemeinsam in einer Entwicklungsumgebung zu arbeiten.
So kann Entwickler:in A direkt auf die Funktionalität zugreifen, die Entwickler:in B parallel programmiert, ohne dabei auf ein Versionsverwaltungstool zurückgreifen zu müssen. Ausreichende Kommunikation ist dabei äußerst hilfreich, um späteren (Schnittstellen-)Konflikten proaktiv entgegenzuwirken.
Eine Vorgangsweise, um etwas Struktur ins Pair-Programming zu bekommen, ist die Driver-Navigator-Methode. Zwei oder mehr Entwickler:innen wechseln sich in ihren Rollen nach einem festgelegten Zeitintervall oder nach einem fertigen Feature/Test ab. Der Driver übernimmt das Steuer und schreibt den Code, spricht seine Gedanken während dem Coden laut aus und stellt offene Fragen in den Raum. Der Navigator füttert den Driver mit Ideen, schlägt Lösungsansätze vor und versucht einen Überblick über die Gesamtaufgabe zu behalten. Neben den zwei Hauptrollen gibt es auch noch den Tourist. Dieser kann Verbesserungsvorschläge einbringen, soll sich aber so gut wie möglich passiv verhalten.
Einen sehr interessanten Ansatz für Pair Programming beschreibt Llewellyn Falco als “strong-style pair programming” [1]. Er definiert “strong-style pair programming” wie folgt: “In order for an idea to go from your head into the computer, it must go through someone else’s hands.” Der Navigator ist also bei diesem Ansatz viel erfahrener und vertrauter mit dem Setup oder der Aufgabe.
Der Driver hingegen ist ein Anfänger (hinsichtlich Programmiersprache, Tool, Code-Basis, …) . Die Rollen werden nicht gewechselt und der Navigator übernimmt nur das Anleiten des Drivers, schreibt aber selbst keinen Code. Hierbei ist es besonders wichtig, dass der Driver ausreichend Fragen stellt und auch selbstständig arbeitet. Der Navigator sollte keine Schritt-für-Schritt-Anleitung bereitstellen. Stark empfehlenswert ist im Anschluss an die gemeinsame Session die Gründe für die jeweilige Lösung intensiv zu diskutieren. Oft werden dadurch neue Lösungswege aufgezeigt und der Driver lernt andere Herangehensweisen kennen.
Bevor wir mit der Entwicklung begannen, definierten wir gewisse Spielregeln, um die Zusammenarbeit von Grund auf zu fördern. Dazu zählten unter anderem folgende Punkte:
Die Aufgaben in Gruppen zu bewältigen, wirkte sich im Großen und Ganzen sehr positiv auf unseren Fortschritt und die Teamdynamik aus. Eine Voraussetzung für sinnvolles Pair-Programming ist eine gewisse Komplexität der Aufgabe. Bei Routineaufgaben ist es nämlich meist effizienter nur eine Person auszulasten. Wenn sich der Navigator gelangweilt fühlt, kann der Grund sein, dass entweder die Komplexität der Aufgabe nicht gegeben ist oder der Driver zu stark agiert und eventuell die Rollen gewechselt werden sollten.
Ideal ist Pair-Programming gerade dann, wenn erfahrene Entwickler:innen weniger erfahrene Entwickler:innen beim Lernen von neuen Technologien unterstützen können. Der:die erfahrene Entwickler:in zeigt dabei die Techniken vor und der:die neue Entwickler:in kann danach sofort selbst Hand anlegen. Da in unserem Projekt ein guter Mix aus erfahrenen und neuen Entwickler:innen teilnahmen, eignete sich diese Technik gut, um die neuen Entwickler:innen mit ins Boot zu holen. Unabhängig von der gewählten Pair-Programming-Technik ist es vorab wichtig, dass beide Entwickler:innen ein gemeinsames Ziel vor Augen haben. Ist der rote Faden nicht gegeben, verlieren sich die Entwickler:innen meist in Details, anstatt den Überblick zu bewahren.
Die Zeitersparnis beim Pair-Programming kommt oft auch dadurch, dass beide Entwickler:innen gemeinsam über den Code und die Implementierung sprechen und es beiden einfacher fällt den Code zu verstehen. Dadurch ist nach der Entwicklung auch kein Code-Review mehr notwendig. Vier Augen sehen mehr als zwei – Fehler werden oft schon während der Entwicklung gefunden und behoben. Das steigert wiederum die Softwarequalität stark. Zu Beginn wurde das IntelliJ-Plugin “Code With Me” sehr intensiv genutzt. Die parallele Entwicklung ohne dabei auf ein Versionierungstool zurückgreifen zu müssen, war dafür ein ausschlaggebender Punkt. Das Plugin funktioniert out-of-the-box und eine “Code With Me”-Session ist schnell eingerichtet.
Gegen Ende des Projekts flachte die Nutzung des Plugins sehr ab, weil oft eine reine Meeting-Session komfortabler ist und Pop-Ups und Einstellungen bei anderen Entwickler:innen nicht sichtbar sind. Oft bedarf es nur einer oder zweier Tastenkombinationen und die gesamte Struktur einer Klasse oder eines Packages ändert sich, was zu einer leichten Verwirrung der Teilnehmer:innen führt. Teilnehmer:innen haben zudem nur eine eingeschränkte Funktionalität in der IDE.
Oft waren nicht die Pair-Programming-Sessions an sich das Problem, sondern die Terminfindung. Hin und wieder wurden wir auch von Kundenprojekten abgelenkt, schlussendlich konnten wir aber unseren Release-Termin zeitgerecht einhalten und haben alle unsere Ziele erreicht. Zurückblickend haben alle neuen Entwickler, aber auch die Erfahrenen haben in diesem Projekt viel Neues gelernt.
[1] Llewellyn’s strong-style pairing
http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html
