Home Blog Leanovate Best Practices: Pairing oder warum zwei nicht einer zu viel sind

Leanovate Best Practices: Pairing oder warum zwei nicht einer zu viel sind

Aus unserer Reihe Leanovate Best Practices wollen wir heute das Pairing oder länger: Pair Programming ein wenig beleuchten. Doch im Grunde ist es nicht nur bei uns ein Best Practice. Und zudem eigentlich auch nicht auf die Entwicklung von Software beschränkt. Sondern einfach unglaublich hilfreich.

 

Es wird leise gemurmelt im Büro. Es sind nicht viele Kollegen anwesend (der Sommer ist da, es ist Urlaubszeit), aber die sechs, die heute da sind, sitzen in Zweiergruppen vor einem Bildschirm. Vielen Managern würde nun der Gedanke durch den Kopf schießen, welche Verschwendung das sei. Der Entwickler, der nicht an der Tastatur sitzt scheine ja schließlich nichts zu tun! Langeweile und verschenkte Arbeitszeit? Weit gefehlt!

 

Nicht faul, sondern effektiv!

 

Pair Programming kommt ursprünglich aus dem Bereich des XP (Extreme Programming) und stellt Transparenz und Kommunikation zwischen allen Beteiligten in den Vordergrund.

Die beiden Entwickler sind nämlich völlig gleichberechtigt. Und der eine glänzt nicht etwa durch Faulheit, sondern die beiden schaffen Mehrwert. Und zwar mehr als einer alleine. Auch wenn nur einer tippt.

 

Wie funktioniert’s?

 

Einer von beiden ist der Driver, also der den Code schreibt, während der andere als Navigatorschon währenddessen überprüft, ob alles logisch und richtig ist und schon weiterdenken kann, was noch zu verbessern ist, Notizen für spätere Refactorings macht oder Nebenschauplätze anschaut, um weitere Informationen zu sammeln. Während der eine also das große Ganze im Blick hat, kann sich der andere auf die Syntax seines Codes konzentrieren.

 


Praktische Tipps:

  • Du fühlst dich als Driver unwohl oder beobachtet? Keine Angst, der Navigator hat auch mehr Zeit zum Denken!
  • Du möchtest als Navigator am Liebsten eingreifen? Nicht sofort unterbrechen, sondern schau erst einmal, ob der Driver nicht sich selbst korrigiert!
  • Plötzlich Fragen oder Ideen? Dann aufschreiben und sie im passenden Moment gemeinsam zu diskutieren!
  • Müde? Tauscht alle paar Minuten die Rollen!
  • Irgendwie hängt ihr? Findet euch zu neuen Paaren zusammen, eine frische Perspektive schadet nie!
  • Und immer dran denken: Kollaborieren, nicht kritisieren!

 

Denn es geht hier nicht um Kontrolle, sondern um Verbesserung. Quasi ein Live-Codereview. Mit einer minimal kurzen und permanenten Feedbackschleife. Immer wieder wird zwischen beiden Rollen gewechselt. Augenhöhe und Verbesserung – da sind wir doch gleich wieder im ganz agilen Sinne. Denn der große Vorteil dabei ist, dass beide den Code gleich gut kennen. Wenn morgen dann die Paarbesetzung eine andere ist (und das sollte sie sein, um immer wieder eine neue Perspektive einzunehmen), kennt auf diese Weise das ganze Team den Code. Wissensverteilung – auch wieder einer der zentralen agilen Ansprüche.

 

Qualität ist ein Standard

 

„Vier Augen sehen mehr.“ Das ist nicht nur uralt, sondern auch völlig richtig. Die Qualität des Codes wird nachweislich verbessert sowie Fehler früh erkannt und gleich berichtigt. Und ganz nebenbei wachsen so auch einzelne Entwickler zu einem Team zusammen. Kommunikation, Transparenz und Qualität – agiler geht’s nicht! Natürlich darf es auch Spaß machen! So steigt die Motivation, das Vertrauen in die eigene Arbeit und die Entwickler arbeiten zu zweit viel fokussierter als alleine. Mag sich am Anfang vielleicht für Einige Entwickler komisch anfühlen, aber probiert es doch einfach mal einen Monat lang aus! Experimentiert (schreibt eure Erfahrungen doch als Kommentar hier dazu, andere haben vielleicht ähnliche Herausforderungen?).

Und was sagen wir dem Manager, der vielleicht etwas schräg guckt? Spätestens mit der Finanzbrille wird er es verstehen: Wenn Fehler im Code später entdeckt werden, kosten sie viel mehr! Und wenn mal ein Mitarbeiter krank wird: Kein Problem, denn alle haben einen Einblick in das Projekt und den Code. Also keine Wissensinseln mehr! Da kann keiner mehr nein sagen!

 

PS.: Und nun für alle!

 

Man kann das noch steigern. Im sogenannten Mob Programming sitzt das ganze Team vor dem gleichen Code und arbeitet gleichzeitig daran. Das gesamte Wissen der crossfunktionalen Teams kann eingebracht werden. Mehr Qualität geht nicht! Es regt Diskussionen an, die das ganze Produkt nach vorne bringen.

Doch ist das nun nur was für Entwickler? Nö. Warum denn? Wie wäre es denn mal mit Pairing in der Buchhaltung? Mehr Feedback und höhere Qualität kann man auch hier erreichen. Also ich werde es beim nächsten Mal mit Pair Writing probieren.

 

 

Schreibe einen Kommentar

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

* Die Checkbox für die Zustimmung zur Speicherung ist nach DSGVO zwingend.

Ich stimme zu.

© by leanovate GmbH - Impressum     Datenschutz