Agile Arbeitsmethoden haben sich als fester Bestandteil in der Softwareentwicklung etabliert. Eine beliebte Verfahrensweise hierbei ist das sogenannte Pair Programming. In unserem Beitrag erfahrt ihr, was es damit auf sich hat.
1. Pair Programming: Definition und Vorgehensweise
Pair Programming (zum Teil auch als Paarprogrammierung oder Tandemprogrammierung bezeichnet) ist Teil der agilen Softwareentwicklung und findet insbesondere im Extreme Programming (oder eXtreme Programming, XP) Anwendung. Dabei sitzen zwei Programmierer zusammen an einem Arbeitsplatz und entwickeln gemeinsam Software.
Rollen und Aufgaben
Im Pair Programming gibt es zwei Rollen, die zunächst aufgeteilt werden:
- Ein Programmierer ist der Pilot (englisch „driver“). Er schreibt den Code und kommentiert seine Vorgehensweise und seinen Gedankengang dabei idealerweise laut, damit sein Partner diese nachvollziehen kann.
- Der zweite fungiert als Navigator (englisch „navigator“ oder „observer“). Er überprüft den Code direkt bei der Eingabe auf Fehler, möglicherweise auftretende Probleme sowie einfachere Lösungswege und behält dabei das Gesamtproblem im Hinterkopf. Er achtet sozusagen darauf, den Code so gut und simpel wie möglich aufzubauen.
Bei der sogenannten verteilten Paarprogrammierung sitzen die beiden Entwickler an verschiedenen Schreibtischen oder sogar Orten und programmieren mithilfe spezieller Software am gleichen Projekt. Hierbei kommen beispielsweise Webcams zum Einsatz, um den Partner sehen und hören zu können.
Ablauf und wichtige Aspekte
Zwar werden die Rollen anfangs fest zugewiesen. Beim Pair Programming ist der regelmäßige Rollentausch jedoch ebenfalls fester Bestandteil. Die Zeitspanne sollte zu Beginn festgelegt werden; auch die strikte Einhaltung sollte – mit Ausnahmen, in denen Programmierabschnitte noch beendet werden – als Ziel gesetzt sein. Neben der Verteilung der Rollen ist auch die Zusammensetzung der Paare stets zu variieren.
Nicht nur der Rollentausch, sondern auch regelmäßige Pausen müssen eingehalten werden: Da die Programmiermethode über lange Phasen hinweg hohe Konzentration erfordert, ist sie entsprechend anstrengend. Um einen klaren Blick zu bewahren und den Kopf zwischendurch frei zu kriegen, sind Pausen essenziell.
Ein weiterer wichtiger Aspekt bei der Umsetzung ist es, Pair Programming nicht als eine Form von Kontrolle oder Überwachung, sondern als gemeinschaftliches Entwickeln zu verstehen, das auf die optimale Lösung abzielt. Dementsprechend sind beide Partner gleichberechtigt und angesprochene Probleme, die der Navigator bemerkt, werden diskutiert und auf diese Weise gelöst. Dies gelingt jedoch nur, wenn im gesamten Team ein einheitlicher Programmierstil vorherrscht.
Pair Programming sollte in einem Unternehmen als feste Methode implementiert werden. Dabei ist es nicht nötig, ständig im Paar zu arbeiten; wird dies jedoch zu selten und nur bei wenigen Projekten getan, gehen einige positive Aspekte verloren:
- Gewöhnung an die Zusammenarbeit im Paar
- Norming (gleiche Vorgehensweisen im gesamten Team)
- Überraschender positiver Outcome (obwohl Methode ursprünglich als ungeeignet erachtet wurde)
Mögliche Paarungen
Wie bereits beschrieben, sollten sich die Paare regelmäßig neu finden. Dabei sind hinsichtlich der Mitarbeitererfahrung grundlegend drei Konstellationen möglich, die unterschiedliche Vor- und Nachteile bieten:
- Experte-Experte
- Experte-Neuling
- Neuling-Neuling
Arbeiten zwei Experten als Paar zusammen, verspricht dies zunächst schnelle Ergebnisse mit einem hochwertigen Output. Allerdings kann es vorkommen, dass beide in den bestehenden Strukturen „festgefahren“ sind und diese entsprechend nicht hinterfragen, wodurch mögliche andere Lösungsansätze gar nicht erst in Erwägung gezogen werden.
Bei der Zusammensetzung von einem Experten mit einem Neuling ergibt sich die Möglichkeit, die Einarbeitung und das Onboarding im laufenden Tagesgeschäft vorzunehmen. Dabei können zugleich neue Ideen geschaffen werden, da der Anfänger aktuelle Vorgehensweisen und Methoden gegebenenfalls hinterfragt und der bereits länger im Unternehmen angestellte Mitarbeiter diese zur Erklärung selbst reflektieren muss. Allerdings kann es auch sein, dass ein neuer Angestellter sich nicht direkt traut, sich kritisch zu äußern. Gleichzeitig kann er in eine passive Rolle fallen und dem Experten lediglich zuschauen beziehungsweise beim Coden das umsetzen, was dieser sagt. Hinzu kommt, dass der Experte dazu tendieren könnte, Anmerkungen des Neulings zu ignorieren. Daher sollte ein entsprechender Rahmen des Vertrauens geschaffen und dafür gesorgt werden, dass auch bei dieser Konstellation Gleichberechtigung herrscht.
Die Paarung Neuling-Neuling birgt ein gewisses Risiko, da beide Programmierer sich nicht oder nur wenig mit den unternehmensinternen Vorgehensweisen und der Codebasis auskennen. Gleichzeitig mindert die Teamarbeit hierbei das Fehlerpotenzial gegenüber der Einzelarbeit jedes neuen Mitarbeiters, der bisher wenig Erfahrung hat, da durch den Partner zugleich eine Kontrollinstanz vorhanden ist, die eventuelle Fehler bemerken kann.
Extreme Programming beschreibt eine Methode der Softwareprogrammierung. Ihre zentralen Elemente sind Agilität und kurze Entwicklungszyklen von einem Tag bis zu einer Woche. In jedem Zyklus werden dabei diese Themeninhalte umgesetzt und in den weiteren Prozess eingebettet:
- Analyse der Anforderungen
- Produktdesign
- Implementierung
- Testphasen
Nach Kent Beck, einem der Entwickler von Extreme Programming, stellen Werte (values), Prinzipien (principles) und Praktiken (practices) die drei Säulen des Konzepts dar.
2. Ziele und Outcome der Paarprogrammierung
Durch den Einsatz von Pair Programming verspricht man sich verschiedene positive Effekte:
Die Zusammenarbeit von zwei Entwicklern ermöglicht, dass (die meisten) Fehler unmittelbar auffallen und dementsprechend behoben werden können. Zudem fließen mehrere Überlegungen gleichzeitig in die Programmierarbeit mit ein, wodurch verschiedene Ansätze miteinander verglichen werden und der beste gewählt wird. Auf diese Weise erhöht sich die Qualität der Software und des Codes.
Der Austausch während der Arbeit sorgt zudem für die Verteilung des im Team oder Unternehmen vorhandenen Wissens: Dies verhindert, dass es lediglich einen oder wenige Experten (sogenannte Wissensinseln) im Team gibt, die den kompletten Code oder Großteile davon kennen, während sich andere nur in einzelnen Bereichen auskennen und entsprechend eingeschränkt bei der Arbeit sind. Die Kompetenzsteigerung sorgt im Idealfall dafür, dass jeder Programmierer alle Bereiche des Projektes kennt und den Code an jeder beliebigen Stelle bearbeiten kann. Somit wird das Projektrisiko durch Ausfälle (Krankheit, Urlaub, Fluktuation) minimiert. Dieses wird durch die sogenannte Truck Number beziffert.
Die Truck Number wurde wie Extreme Programming von Kent Beck erfunden. Sie gibt an, wie hoch das Projektrisiko beim Ausfall von (einem) Mitarbeiter(n) ist und liegt im Bereich zwischen 0 und 1:
- 0: bester Wert, der Ausfall jedes Teammitglieds (aller gleichzeitig) kann aufgefangen werden
- 1: schlechtester Wert, fällt nur ein einziges, beliebiges (!) Teammitglied aus, scheitert das Projekt
Die Truck Number wird auch als Bus-Faktor oder Lotto-Faktor bezeichnet.
Insbesondere in der IT beziehungsweise der Softwareentwicklung sind in der Regel lange Einarbeitungsphasen notwendig:
- Neulinge verfügen über allgemeine Programmierkenntnisse (General Knowledge)
- Die gesamte Codebasis muss vorgestellt/verstanden/gelernt werden
Ein erfahrener Mitarbeiter kann einem neuen die unternehmensinterne Arbeitsmethodik sowie typische Vorgehensweisen nicht nur theoretisch vermitteln, sondern gleich praktisch zeigen. Somit erlangt dieser zeitnah projektspezifisches Wissen (Specific Codebase Knowledge), was die Einarbeitung verkürzt und den Einsteiger in die Lage versetzt, bereits vergleichsweise schnell mitzuarbeiten und einen Beitrag zu leisten.
3. Vor- und Nachteile der Methode
In der nachfolgenden Tabelle sind einige grundlegende Vor- und Nachteile des Pair Programming aufgelistet. Dabei ist zu beachten, dass sich einige von ihnen gegenüberstehen beziehungsweise ausgleichen oder aufheben: So kostet die Maßnahme einerseits mehr, da zwei Entwickler an einem Codeabschnitt arbeiten, spart jedoch gleichzeitig Geld, da die meisten Fehler direkt behoben werden können und eine nachgelagerte Fehleranalyse so vermieden werden kann. Generell lässt sich festhalten, dass die meisten positiven Aspekte von Pair Programming direkt oder indirekt in den ROI (Return on Investment) einzahlen.
Vorteile von Pair Programming
- Arbeitsreduktion: Fehler, die sofort auffallen, lassen sich schneller und günstiger beheben. Zudem fallen Code-Reviews weg und Dokumentationen werden unnötig, da Wissen direkt geteilt wird.
- Arbeitsmotivation: Durch das gemeinschaftliche Programmieren macht die Arbeit mehr Freude, woraus eine höhere Motivation resultiert. Auch die Mitarbeiterfluktuation kann daher sinken.
- Teambuilding: Pair Programming stärkt das Team und führt zu besserem Zusammenhalt.
- Flow: Durch die Partnerarbeit kommt es zu einem besseren Flow; Unterbrechungen werden umgangen – sitzt jemand allein am PC, wird er eher angesprochen als ein Paar. Dies steigert dementsprechend auch die Effizienz.
Nachteile von Pair Programming
- Zeitaufwand: Die Zusammenstellung der Teams (Paare) sowie die Eingewöhnung in die Zusammenarbeit kosten Zeit. Generell benötigt man für die gleichen Aufgaben bis zu 100 % mehr Zeit.
- Sozialer Aspekt: Bei Paarungen aus zwei Kollegen, die sich nicht mögen, kann es zu Streit kommen – Arbeit und Ergebnis können darunter leiden.
- Rechte & Pflichten: Das Urheberrecht für ein im Team entstandenes Programm kann nicht einem einzigen Programmierer übertragen werden. Ebenso fraglich ist die Haftbarkeit bei Fehlern im Code oder Urheberrechtsverletzungen.
- Arbeitsrhythmus: Gerade bei Vertrauensarbeitszeit und Gleitzeit müssen sich die Partner darauf einstellen, zur gleichen Zeit anwesend zu sein und sich dahingehend absprechen.
4. Tipps für die erfolgreiche Umsetzung
Um ein maximal positives Ergebnis durch die Paarprogrammierung zu erzielen, solltet ihr die folgenden Tipps berücksichtigen. Diese lassen sich in zwei Kategorien einteilen:
- Anforderungen auf persönlicher beziehungsweise Personalebene
- Anforderungen an die Umgebung und das Arbeitsmaterial
Die Mitarbeiter
Es ist von großer Bedeutung, dass sowohl der Pilot als auch der Navigator ihre Ideen und Gedanken jederzeit verständlich sowie nachvollziehbar formulieren und bei Unklarheiten unmittelbar nachfragen. Zudem sollte man stets versuchen, kritikfähig und dementsprechend bereit sein, Kompromisse einzugehen.
Essenziell ist auch die Einhaltung der Pausen und der Rollenwechsel: Diese ermöglichen es, bei der mental anstrengenden Arbeit die Konzentration möglichst lang auf einem hohen Niveau zu halten. Hierbei kann es sinnvoll sein, einen Timer zu setzen – einzelne Teilabschnitte können vor der Pause/dem Rollenwechsel zu Ende gebracht werden, generell sollten sich die Paare jedoch konsequent an die Zeitfenster halten.
Darüber hinaus sollte überlegt werden, welche Aufgaben und Abschnitte sich für das Pair Programming eignen und welche nicht. Grundsätzlich ist es ratsam, die Methode als festen Bestandteil der agilen Entwicklung zu etablieren; man sollte jedoch nicht ununterbrochen auf das Konzept setzen, ohne die Sinnhaftigkeit zu hinterfragen. So kann es von Vorteil sein, einige Aufgaben allein umzusetzen.
Des Weiteren sollte in regelmäßigen Abständen – beispielsweise bei der Neuzusammensetzung der Paare – eine Nachbereitung stattfinden. Dadurch können insbesondere die zentralen Aspekte der Wissensvermittlung sowie die Lerneffekte überprüft werden. Hierzu sollten sich die Partner gegenseitig befragen, was sie in der Session gelernt haben, und entsprechend reflektieren.
Das Arbeitsumfeld
Hinsichtlich der Umgebung sind kleine Büros empfehlenswert, da durch das Kommentieren andernfalls ein hoher Lautstärkepegel erreicht wird, wodurch die Paare sich gegenseitig stören würden. Zudem sollte generell ein ruhiges Umfeld geschaffen werden, indem man zum Beispiel sein Handy ausschaltet.
Damit beide Partner immer einen guten Blick auf den Code haben, sollten zwei Monitore zur Verfügung stehen. Diese sollten nicht „erweitert“, sondern auf dupliziert eingestellt sein: Somit haben sowohl der Pilot als auch der Navigator ideale Sicht auf die Arbeitsfläche. Zusätzlich empfiehlt es sich, zwei Tastaturen und Mäuse anzuschließen – damit können die Rollen getauscht werden und jeder Partner kann unmittelbar auf das Coding einwirken. Dies ermöglicht eine direkte Interaktion.
Für den Ideenaustausch und zum Aufschreiben von Notizen für spätere Nachfragen und Co. sollte zudem Schreibmaterial am Arbeitsplatz bereit liegen. Neben Papier und Stift eignen sich auch Whiteboards und Flipcharts.
5. Pair Programming versus Mob Programming
Das Mob Programming ist sozusagen der große Bruder des Pair Programming, da hierbei nicht in Zweierteams, sondern in einer ganzen Gruppe (= Mob) gemeinsam gecodet wird. Die Zusammensetzung ist eine andere, da als Teil des Teams auch Scrum Master, Designer sowie beispielsweise der Product Owner als überwachende Instanz anwesend sein können. Je nach Teamgröße kann sich der Einsatz eines Beamers als hilfreich erweisen, damit alle Beteiligten stets einen guten Blick auf die aktuellen Eingaben haben.
Mob Programming eignet sich besonders für komplexe Probleme, die nur in der Gruppe gelöst werden können, da der Input von verschiedenen Instanzen nötig ist. Dementsprechend ist es – im Gegensatz zum Pair Programming, das als ganzheitliches Konzept umgesetzt werden sollte, – eher für den punktuellen beziehungsweise kurzfristigen Einsatz vorgesehen. Zudem eignet sich diese Agility-Methode nicht nur für den reinen Programmiervorgang an sich, sondern für den gesamten Prozess der Softwareentwicklung, der auch das Designing, Testing und Deploying einschließt.
Die Vorteile des Mob Programmings gehen über die des Pair Programmings hinaus und umfassen zusätzlich:
- Reduzierung von Notlösungen/Workarounds: Wenn alle oder viele Beteiligte mit einem Lösungsansatz unzufrieden sind, wird dieser in der Regel verworfen und eine zufriedenstellende Alternative gesucht. Somit steigt die Softwarequalität.
- Vermeidung von Wartezeiten: Aufgrund der Anwesenheit aller Stakeholder können Nachfragen unmittelbar geklärt werden und Teammeetings werden zum Teil unnötig. Dadurch entsteht gleichzeitig ein optimaler Informationsfluss.
Aber auch die Nachteile bestehen – insbesondere hinsichtlich der Kosten und Arbeitszeit, zumal Diskussionen durch die Gruppengröße ausarten können.
6. Fazit
Pair Programming ist gelebte Agilität. Das Konzept kann als tatsächliche Teamarbeit verstanden werden und bietet sowohl den einzelnen Mitarbeitern als auch dem Team und dem ganzen Unternehmen zahlreiche Vorteile. Durch den Einsatz können beispielsweise Kosten gesenkt, die Effizienz gesteigert und deutlich bessere Ergebnisse erzielt werden.
Meist kann die Einführung der Methode sowohl Zeit als auch Geld kosten – bei dauerhaftem Einsatz, der bei Pair Programming ohnehin vorgesehen ist, überwiegen in der Regel jedoch die positiven Aspekte, die sich auch finanziell auszahlen.
Darüber hinaus ist die Paarprogrammierung beziehungsweise das zugrunde liegende Konzept der Paararbeit nicht nur im Bereich der Softwareentwicklung sinnvoll: Es lässt sich auch auf zahlreiche andere Unternehmenszweige ausweiten und übertragen, sodass insbesondere komplexe Aufgaben in Zweierarbeit besser gelöst werden können.