14 Friends of Pair Programming

Beim Pair Programming sitzt man also mit einem Paar (gewöhnlich 2) Programmierern an einem Rechner und bearbeitet den gleichen Code. Und das soll sinnvoll sein? … Wir Programmierer im Shopoffice-Team finden: Jawohl! Wir schreiben besseren Code, produzieren weniger Bugs, sind konzentrierter bei der Arbeit und am allerwichtigsten: Wir haben mehr Spaß bei der Arbeit. Klar verwenden wir Pair Programming hier im Team schon sehr ausgiebig – aber es gibt immer etwas zu verbessern. Warum also nicht mal jemanden ins Team holen, der über mehr Praxis in diesem Bereich verfügt und Erfahrungen mit Pairing in verschiedenen Projekten gemacht hat? Wir haben uns für Thomas Much entschieden, der uns für einen Sprint lang bei der Arbeit begleiten sollte. Thomas war als Java- und Pair Programming-Coach schon in zahlreichen Projekten unterwegs und genau davon wollten wir profitieren.

Jedes Teammitglied hatte hier sicher seine eigene Vorstellung, wie Thomas sich in das Team integrieren kann, um uns zu besseren Pair-Programmierern zu machen. Darum haben wir zu Beginn des Coachings unsere Vorstellungen zusammengetragen und überlegt, wie die Zusammenarbeit funktionieren kann. Jedes Teammitglied hatte die Möglichkeit zu sagen:

  1. Wann wird das Pair-Programming-Projekt ein Erfolg?
  2. Was wünsche ich mir?
  3. Was möchte ich nicht?

pairing1pairing2

Wir kamen zu dem Ergebnis, dass Thomas nicht ausschließlich auf unser Pairing-Verhalten achten soll. Er soll vielmehr auf alles achten, was ihm bei unserer täglichen Arbeit auffällt – also Scrum-Methodik, Programmier-Methodik und potentielle „Broken-Windows“ im Code.

Anschließend sind wir in den Sprint gestartet. Thomas hat sich dann jeden Tag durch das Team „gepaired“ und dabei unsere Arbeitsweise und das Gesamtsystem kennengelernt. Zu Beginn eines Tages haben wir pragmatisch im Daily entschieden, welche Paare zusammen an einer Aufgabe arbeiten. Bereits nach einem Tag konnte Thomas sich orientieren und damit beginnen, uns Tipps zu geben und Verbesserungsvorschläge zu unterbreiten.

pairing4 pairing5

Wie im Kick-Off besprochen, haben wir uns in der Mitte des Sprints für Coach-Feedback Zeit genommen. Es fanden sich einige Vorschläge zur Verbesserung in einer Präsentation wieder. Das Feedback war erfreulicherweise weitestgehend positiv. Gelobt wurde unser Pairing-Verhalten, die testgetriebene Arbeit, das Code-Design. Aber auch viele Kleinigkeiten, für die wir einfach zu betriebsblind geworden sind, waren hier als Verbesserungsvorschläge zu finden:

  1. Namenskonventionen einführen
  2. Klassen-,Methoden- und Variablennamen sind nicht immer eindeutig und konsistent im Projekt benannt. So sind beispielsweise Oberklassen mal mit Abstract und mal mit Base geprefixt. Eine Methode zum Laden einer Entität beginnt mal mit get, load oder find. Konsistente und einheitliche Benennung und damit eine einheitliche Sprache im gesamten Projekt hilft beim Verständnis.

  3. Abhängigkeiten zwischen Tests vermeiden
  4. Kent Beck beschreibt, dass gute Tests: 1. isolated, 2. automated, 3. quick to write, 4. quick to run und 5. unique sind. Abhängigkeiten zwischen Tests sollten somit vermieden werden. Isoliert von weiteren Tests soll jeder Unit-Test nur genau einen Aspekt testen.

  5. Nebenläufigkeitsprobleme bei Tests beseitigen
  6. Auch hier kann man sich wieder auf die Hinweise von Kent Beck stützen. Sofern jeder Test isoliert funktioniert, können alle Tests parallel ausgeführt werden. Es dürfen somit keine gemeinsam genutzten, nicht-thread-safen Ressourcen in den Tests verwendet werden.

  7. Tests für equals(Object obj) und hashCode() ergänzen
  8. Beim Überschreiben von equals(Object obj) und hashCode() wird häufig beim erneuten Anpassen der Klasse vergessen, auf die überschriebenen Methoden zu achten. Tests helfen diese Fehler aufzudecken.

  9. Pair-Programming mit sinnvollen Pausen unterbrechen
  10. Pair-Programming wird häufig als anstrengender und kraftraubender als eigenständiges Programmieren empfunden. Um die Konzentration über den ganzen Tag hoch zu halten, gibt es die Empfehlung, über den Tag hinweg, häufiger kleinere Pausen einzulegen.

Das Coaching endete zusammen mit dem Sprintende. Damit hatten wir auch gleich ein gutes Thema für die Retrospektive, um das Coaching zu bewerten. Was hat es uns als Team gebracht? Was hat es mir persönlich gebracht?

pairing6

Hier mal die Kernaussagen der Ergebnisse:

  • Gute Hinweise zur Architektur und zur Programmier-Methodik
  • Bessere Tests
  • gesteigerte Codequalität
  • leider zu wenig zum Thema Pairing
  • Bier (!)

Am Ende hat uns das Coaching zwar keinen enormen Gewinn gebracht, was aber bleibt, ist ein gutes Gefühl, dass wir auf dem richtigen Weg sind. Viele Hinweise waren hilfreich und helfen uns, in den kommenden Sprints noch besser und effektiver zu werden. Wir haben auch gleich begonnen, die Tipps umzusetzen. Na gut, Triples mögen ja vielleicht ineffektiv sein. Aber frei nach dem Motto „Viel hilft viel!“ programmieren wir nun im Sextuple ;-).

pairing7

Robert Breetzmann ist seit seinem Studium der Informatik an der Entwicklung von freier Software und der Verwendung neuer Technologien interessiert. Seit 2007 entwickelt er große E-Commerce-Systeme und ist seit 2011 als Softwareentwickler bei Otto tätig.

Tagged with: , , ,
Veröffentlicht in Development, Grundlagen
6 comments on “14 Friends of Pair Programming
  1. José Stiller sagt:

    Super Sache! Man sollte hier vielleicht auch einfach mal erwähnen, dass Pair Programming zwar schon lange an Universitäten gelehrt werden aber bei weitem noch nicht die Verbreitung in Unternehmen finden, wie es eigentlich sein sollte.

    Während des lesens des Artikels kam mir gerade eine Idee. Diese ist vielleicht zu hoch gegriffen oder Absurd aber darf man auch als Mitarbeiter im Zuge des PP mal für ein Tag bei euch mitmachen. Klar meine Aufgaben sind hier im Unternehmen eigentlich andere, aber man würde so vielleicht auch einfach die Leute sowie und vor allem die Arbeit kennen lernen. In wie fern ich da nun ein Vorteile draus ziehen kann, weiß ich gerade nicht. Aber ich finde den Gedanken sehr interessant.

    • Hi José, schön, dass dir der Artikel gefällt. Wegen deines Vorschlags: Schick mir doch einfach eine kurze Mail, dann schauen wir, was wir hinbekommen!

    • Guido Steinacker sagt:

      Hallo José,
      in unserem Team (Entdecken aka FT3) hatten wir gelegentlich schon mal einen Interessenten, der für einen Tag mit uns zusammen im Pair gearbeitet hat. Wir können gerne über Stefan oder mich einen Tag vereinbaren.
      VG, Guido

  2. Dirk sagt:

    Interessanter Beitrag.

    Wir bei aixigo (www.aixigo.de) sind mittlerweile auch vermehrt mit Pairprogramming unterwegs. Nach meinem eigenen Erfahrungen ändert sich die Arbeitsweise aber ziemlich stark und einige Dinge fallen irgendwie unter den Tisch, wenn man den ganzen Tag „paired“.

    Wie macht ihr das? „Paired“ ihr den ganzen Tag oder nur stundenweise?

    Das ganze Projekt durch, oder nur am Anfang bis jeder im Thema und mit den Entwicklungswerkzeugen firm ist?

    Wann wechselt ihr eure Paringpartner?

    Welche Erfahrungen habt ihr mit der Codeverantwortung gemacht? Wenn jeder alles macht, kann man sich ja ganz gut in der Gruppe verstecken. 😉

    Coding-Conventions machen sicherlich auch Sinn oder kann bei Euch jeder nach eigenem Gutdünken kodieren.

    Gruß,
    Dirk

    • Robert Breetzmann sagt:

      Hallo Dirk,

      vielen Dank für deinen Kommentar. Beim Pairen versuchen wir, wie bei allen anderen Dingen übrigens auch, gesunden Menschenverstand walten zu lassen. Es gibt also keinen Zwang dazu. Beim Daily wird meist entschieden, welche Paare zusammen an den Tasks arbeiten. Dabei versuchen wir immer neue Kombinationen zu finden. Um herauszubekommen ob Konstellationen zu häufig vorkommen, hilft eine Pairing-Matrix in der man festhält, wer mit wem gepaired hat.

      Wenn es sich einrichten lässt, dann pairen wir den ganzen Tag, unabhängig davon ob jemand eingearbeitet werden muss oder das Thema neu ist. Somit ist niemand allein für den Code verantwortlich (Stichwort: Collective Code Ownership). Coding-Conventions haben wir, sind aber nicht mehr so wichtig. Es entsteht schnell ein gemeinsames Verständnis von gutem Code. Das Team lernt somit viel voneinander und das ist gut für die Qualität!

      Viele Grüße,
      Robert Breetzmann

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: