Nutzen Sie Mob Programming, um Ihr Lernen zu maximieren

In jedem Scrum.org Professional Scrum Development-Kurs gehen wir sowohl auf technische Praktiken als auch auf Praktiken der Zusammenarbeit ein, um die Entwicklungsteams bei der Erkundung neuer Möglichkeiten zu unterstützen. In einem unserer letzten Kurse hatten wir zwei Teams, die nach zwei Sprints nicht in der Lage waren, ein "Done"-Inkrement zu liefern, das sie beim Sprint Review vorzeigen konnten. Sie wurden von allen möglichen Problemen geplagt, von Merge-Konflikten, schief gelaufenem Refactoring, fehlenden automatisierten Tests und allem anderen, was im echten Leben passiert. Ich beschloss, Mob Programming einzuführen, um zu sehen, ob ihnen das helfen könnte. Die erste Erfahrung mit Mob Programming ist in der Regel das totale Chaos und ich versuchte, das Team entsprechend vorzubereiten. Das Ausprobieren einer neuen Technik - alles, was außerhalb Ihrer Komfortzone liegt - kann zu einem anfänglichen Chaos führen, und es erfordert ein wenig Mut, weiterzumachen. Denjenigen unter Ihnen, die keine Ahnung haben, was Mob Programming ist, empfehle ich, unseren jüngsten Artikel im XPRT-Magazin zu lesen, der einen Überblick darüber gibt, oder sich eine Aufzeichnung der jüngsten Präsentation von Woody Zuill anzusehen .

Der erste Versuch dieser Teams hat sich für sie nicht erfolgreich angefühlt. In einer Retrospektive haben wir uns ein wenig mit den Problemen befasst, auf die sie gestoßen sind. Es ist gut zu wissen, dass diese Leute schon länger zusammenarbeiten, denn einige der Probleme, die auftauchten, waren ziemlich überraschend.

1. Uneinigkeit über den zu befolgenden Kodierungsstil/Standards. Bis zu dem Punkt, an dem einer der Entwickler sagte: "Wenn ich der nächste sein wollte, der den Fahrersitz übernimmt, hätte ich als erstes den gesamten Code des Vorgängers entfernt". Das ist ziemlich hart!
2. Sie mochten es nicht, sofortiges Feedback von den Teammitgliedern zu erhalten. Normalerweise würden sie eine Codeüberprüfung anfordern, wenn die Arbeit abgeschlossen ist. Diese Überprüfung würde nur den aktuellen Endzustand kritisieren. Nicht, wie Sie dorthin gekommen sind, welche Entscheidungen Sie auf dem Weg dorthin getroffen haben, welche "dummen" Alternativen Sie ausprobiert haben. Wenn Sie mit dem gesamten Team hinter demselben Bildschirm arbeiten, sieht das jeder, und viele haben eine Meinung dazu. Pair Programming funktioniert ähnlich, aber dann mit 4 Augen auf dem Code. Bei Mob Programming vervielfacht sich die Anzahl der Augen und damit auch das Feedback.
3. Für die Leute, die nicht an der Programmierung beteiligt waren, war das unproduktiv. Sie hatten nicht herausgefunden, wie sie am effektivsten zur Lösung des Problems beitragen konnten, ohne den Code direkt ändern zu können.

Wir haben den Teams die Rollen des Mob Programming Role Playing Game vorgestellt, nur die Rollenkarten, nicht das ganze Spiel. Und ließen sie über jede Rolle sprechen und darüber, ob einige davon Beiträge enthielten, die sie zum Entwicklungsprozess hätten leisten können. Das führte zu einer interessanten Diskussion und dem Wunsch, es noch einmal zu versuchen.

Das zweite Mal, als die Teams einen Sprint in Angriff nahmen, waren sie schließlich erfolgreich. Sie haben nicht nur Mob Programming ausprobiert, sondern auch beschlossen, diesen Sprint testgetrieben anzugehen. Es war das erste Mal, dass sie ihrer selbst auferlegten Definition von "Done" gerecht werden konnten und sie hatten eine Menge Spaß dabei. Das Team hat eine Reihe positiver Dinge über die ganze Erfahrung herausgefunden, die sie sich vor Beginn nicht vorgestellt hatten:

1. Da das gesamte Team zur gleichen Zeit am gleichen Code arbeitete, wurde keine Zeit (null Sekunden) für das Zusammenführen von Code aufgewendet.
2. Das Team hatte eine lange Liste von Tipps, Tricks, Tastenkombinationen, alternativen Ansätzen zur Codierung usw. ausgetauscht. Alle hatten das Gefühl, dass sie nicht nur Code geliefert, sondern dabei auch voneinander gelernt hatten.
3. Jedes Teammitglied fühlte sich wohl, wenn es den Code pflegen musste oder mitten in der Nacht einen Notfall-Bugfix durchführen musste. Das lag zum Teil daran, dass die Unit-Tests ein Sicherheitsnetz und eine automatisch validierte Dokumentation boten, aber auch daran, dass sie an der Erstellung des Codes beteiligt waren. Die wirkliche Zusammenarbeit hat das Gefühl der gemeinsamen Verantwortung stark verbessert.
4. Es wurde sehr wenig Zeit für "Overhead", Koordination, Meetings und Statusaustausch aufgewendet. Die Teams übten zwar immer noch ihr tägliches Scrum, aber der Schwerpunkt verlagerte sich von "was wir getan haben und was uns noch im Weg steht" auf die Auswirkungen auf das Ziel und die übergeordneten Anliegen. Kein einziger Entwickler hatte das Bedürfnis, genau zu erklären, was er getan hat und warum. Die Zeitspanne wurde also viel kürzer, aber der Wert stieg beträchtlich an.

Das endgültige Fazit des Teams: Sie wären wahrscheinlich 6-mal produktiver, aber alle wären zur Mittagszeit todmüde. Nicht schlecht für eineinhalb Stunden, in denen sie wirklich versucht haben, zusammenzuarbeiten. Haben Sie Pair Programming oder sogar Mob Programming ausprobiert? Ich würde gerne Ihre Gedanken, Frustrationen und Erfolge hören. Dieser Blog basiert auf einem Auszug aus dem Artikel, den ich zusammen mit Martijn van der Sijde geschrieben habe. Den ganzen Artikel sowie weitere interessante Artikel können Sie im XPRT Magazine #6 lesen.