Pair Programming

Bild: Flickr/WOCinTech Chat - CC BY 2.0

Eine der Techniken die ich häufig empfehle ist das Pair Programming. Es sitzt nicht mehr ein Entwickler vor einem Rechner sondern zwei, die gemeinsam am Code arbeiten. Auf den ersten Blick erscheint das vielen Managern und Programmierern widersinnig, sie befürchten, dass die Teams dadurch weniger produktiv werden. Tatsächlich ist es auch so, dass Umsetzung zunächst länger zu dauern scheint, allerdings wird das durch andere Faktoren mehr als ausgeglichen:

• Pair Programming sorgt dafür, dass zum frühestmöglichen Zeitpunkt eine Qualitätssicherung stattfindet. Viele Fehler können direkt bei der Entstehung entdeckt und beseitigt werden, statt in nachgelagerten Bugfixing-Phasen.
• Der entstehende Code hat meistens eine hohe Qualität, da die Erfahrungen von mehreren Personen in ihn einfließen und nicht nur von einer.
• Dadurch dass sie durchgehend erklären was sie tun und warum verbessern die Beteiligten ihre kommunikativen Fähigkeiten.
• Es wird ein permanenter Wissenstransfer gefördert, der dadurch verstärkt wird, dass nicht bloss Theorie vermittelt wird sondern das Gelernte direkt in der Praxis Anwendung findet.

Je nach Betrachtung kommen noch weitere Faktoren dazu, die aber nicht unumstritten sind, z.B. dass Pair Programming mehr Spass macht, einen stabileren Arbeitsrhythmus erzeugt oder zu mehr Disziplin führt.

Herausgreifen würde ich speziell die Dimension des "Spass habens", da sie essentiell wichtig ist. Wenn Entwickler Pair Programming als belastend empfinden wird es sich nicht durchsetzen, wenn sie ihm neutral oder ambivalent gegenüberstehen besteht das Risiko, dass es mit der Zeit einschläft. Nur wenn sie diese Tätigkeit gerne durchführen kann man sicher sein, dass sie regelmässig stattfindet. Aus diesem Grund macht es Sinn Rahmenbedingungen zu schaffen, die diese Arbeitsweise möglichst angenehm machen. Dazu gehören z.B. passende Arbeitsplätze mit großen Tischen und Bildschirmen und separate Räume in denen man sich unterhalten kann ohne andere Leute zu stören. Genauso wichtig ist aber eine Einigung auf bestimmte Abläufe:

• Es sollte nach Möglichkeit nicht zu einer Aufteilung in "Vorführer" und "Zuschauer" kommen. Diese Konstellation führt zu oft dazu, dass der Zuschauer schnell das Interesse verliert und der Vorführer kein Feedback erhält.
• Wesentlich besser funktioniert die Aufteilung in "Navigator" (schlägt die jeweils nächsten Arbeitsschritte vor) und "Driver" (gibt Feedback und setzt um). Durch diese Arbeitsteilung wird verhindert, dass einer der Beteiligten inaktiv wird.
• Um beiden Beteiligten die Möglichkeit zu geben beide Rollen auszuführen sollte gegelmässig getauscht werden (von alle 10 Minuten bis einmal pro Tag habe ich schon alles gesehen).
• Zumindest in der Anfangsphase macht ausserdem ein Timeboxing Sinn, da diese sehr intensive Art der Zusammenarbeit sonst schnell überfordernd wirken kann.

Selbst wenn Pair Programming sich zu Beginn komisch anfühlt - auf Dauer ist es ein guter Weg zu höherer Qualität und früherer Qualitätssicherung, der daher jedem Team zu empfehlen ist.

A: "But if all of our programmers are pairing, won't they write half as much code?"
B: "No, hopefully they'll write even less than that"

— Ben Rady (@benrady) 6. Januar 2017