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!
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.
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.
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.
„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!
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.
Rufen Sie uns an: 030 – 555 74 70 0
