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