Pair-Programming: Einblicke in unsere Arbeitswelt

Pair-Programming und SoftwareentwicklerInnen passen nicht wirklich gut zusammenpassen. Denken Sie genauso? Kennen Sie viele ProgrammiererInnen, die sich hinter ihren Bildschirmen verstecken anstatt darüber zu reden, was sie gerade schreiben? Dass es auch anders geht und welche Erfahrungen wir bei der secu-ring GmbH mit Pair-Programming machen, möchte ich Ihnen hier zeigen.

Als Paar programmieren, was heißt das überhaupt?

Pair-Programming, zu deutsch Paar-Programmierung, ist eine Methode in der agilen Softwareentwicklung, bei der sich zwei ProgrammiererInnen an einem Computer gemeinsam mit einer User-Story bzw. einem Problem beschäftigen. So formuliert es Christian Helmbold in seinem kurzen, sehr übersichtlichen Artikel (letzte Änderung: 2012-09-29). Noch deutlicher wird diese Definition im Unterschied zu der von uns bisher häufig angewendeten Partnerprogrammierung: Hier programmiere ich allein und lasse vor dem Einchecken eineN andereN ProgrammiererIn noch mal drüber schauen beziehungsweise bespreche die besonders kritischen Punkte.

Beim Pair-Programming herrscht eine klare Aufgabenteilung. Es gibt den so genannten „Fahrer“ – auch driver genannt – der den Code schreibt und es gibt den „Beifahrer“ – auch als navigator bezeichnet – der die User-Story als Ganzes im Blick behält sowie das Geschriebene auf mögliche Refactorings, bessere Kommentare und einzuhaltende Coding-Guidelines hin überprüft.

Ist Pair-Programming nicht viel zu teuer und zeitaufwendig?

In der Literatur zu Pair-Programming finden sich häufig Vorteile wie zum Beispiel schnellere Einarbeitung neuer Teammitglieder, gestiegene Zufriedenheit am Arbeitsplatz und höhere Wartbarkeit des Codes.

Interessant und für das Management nicht unbedeutend ist aber auch das Ergebnis einer Studie von Alistair Cockburn und Laurie Williams (zuletzt aufgerufen: 2013-05-21), die sich unter anderem mit der Wirtschaftlichkeit von Pair-Programming beschäftigt haben. Darin heißt es, dass 15 % mehr Zeitaufwand beim Programmieren durch 15 % weniger Fehler und die damit gesparte Zeit für Bugfixing (einen Fehler später zu beheben kostet im Vergleich zur Sofortbehebung zehn mal so viel) und zusätzliches Projektmanagement mehr als ausgeglichen wird.

Irgendwann ist immer das erste Mal

Nach der Einführung der agilen Softwareentwicklung im Team Entwicklung der secu-ring GmbH – wir haben uns für Scrum entschieden – wagten wir uns mit langsamen Schritten an das Pair-Programming. Eine kleine Umfrage im Team nach einer dreimonatigen Testphase von ca. 30 % Pair-Programming ergab folgende positive Aspekte:

  • verbesserte und schnellere Know-How-Verteilung
  • ständige Verbesserung der Codequalität als Folge der Mini-Konkurrenzkämpfe zwischen den zwei ProgrammiererInnen
  • viel Spaß
  • hoher Lerneffekt
  • Gewöhnung, dass einem jemand über die Schultern beim Programmieren schaut
  • Gefühlt wird effektiver, d.h. geringerer Zeitaufwand plus robusterer Code, gearbeitet.
  • Es wird auf einen aufgepasst. Allein gerät man eher auf Abwege, welche nichts mehr mit der eigentlichen Aufgabe zu tun haben.
  • Es wird mehr miteinander geredet.

Als negative Erfahrungen wurden folgende genannt:

  • Es gibt Phasen, wo man sich sinnlos vorkommt.
  • Gefühlt wird länger gebraucht (hier scheinen die Erfahrungen auseinander zu gehen).
  • Gefühlt bleiben andere Aufgaben liegen.
  • Probleme treten insbesondere bei unterschiedlichen Geschwindigkeiten und Wissensständen auf.

Fazit

Unser Team ist sich einig: Pair-Programming macht nicht nur Spaß sondern auch Sinn. Allerdings müssen wir etwas mehr darin investieren, typische Fehlerquellen und somit die bisher aufgetretenen Probleme zu vermindern bzw. zu vermeiden.

Wie uns das gelingt, lesen Sie im nächsten Blogartikel zum Thema Pair-Programming.

Berit Kitzing

About Berit Kitzing

Berit Kitzing ist Projektleiterin bei der secu-ring GmbH. Der agile Weg hat es ihr besonders angetan. Sie ist stolz darauf, dass die agile Denk- und Arbeitsweise mittlerweile Unternehmensweit praktiziert wird. In ihrer Projektarbeit konzentriert Berit sich auf den Bereich Requirements Engineering und Projektevaluationen und übernimmt damit den Part des Product Owners. Wenn sie nicht am Schreibtisch sitzt, bewegt sie sich am liebsten draußen und genießt die Seen und Wälder Brandenburgs.

4 responses on “Pair-Programming: Einblicke in unsere Arbeitswelt

  1. Berit KitzingBerit Kitzing Post author

    Hallo Prajit, bei uns besteht ein Projektteam immer aus mehreren MitarbeiterInnen. Wir haben den Grundsatz, dasss Wissen verteilt und geteilt wird – nur so können Projekte auch bei ungeplanten Ausfällen noch pünktlich fertig gestellt werden. Auch die Projektinformationen sind durch unsere gemeinsamen Planungstreffen für alle transparent. Somit ergibt sich die Methode Pair Programming als logische Konsequenz. Wie handhabt Ihr das bei Projekten? Sammelt Ihr gute Erfahrungen mit “Ein-Mann-Projekten”?

  2. Prajit

    Hallo, bei der Pair-Programmierung handelt es sich ja um zwei Programmierer, die zusammen an einem Projekt arbeiten. Etwas Bedenken habe ich diesbezüglich, da es für mich unvorstellbar ist, gemeinsam an einem Projekt zu arbeiten. Wie sind denn hierfür die ersten Erfahrungsberichte?

  3. Olaf Stichtenoth

    Bei Pair Programming gibt es natürlich die selben Widerstände aus dem Management mit denen man auch bei der Einführung von agiler Entwicklung zu kämpfen hat. Ich als Geschäftsführer bin gespannt, ob sich die Prozessänderungen auch in den relevanten wirtschaftlichen Kennzahlen niederschlagen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.