Mob-Programmierung - 5 Entwickler an einem einzigen Computer?!

Die Durchführung von Experimenten zur Verbesserung unserer Prozesse ist Teil unserer täglichen Arbeit. Wenn ich also von etwas höre, das uns helfen könnte, uns zu verbessern, möchte ich es erforschen. Anfang 2019 nahm ich an der Domain Driven Design Europe-Konferenz teil. In den Pausen unterhielt ich mich viel mit anderen Teilnehmern, meist Entwicklern.

In vielen dieser Gespräche kam der Workshop Mob Programming von der Convention im Jahr zuvor zur Sprache. Die Entwickler waren wirklich begeistert von der Mob-Programmierung: mehrere Entwickler arbeiten im selben Raum an einem einzigen PC. Sie erklärten, wie viel sie durch diese Sitzungen gelernt hatten und wie sehr sie als Team gewachsen waren. Das war für mich ein klares Signal, mehr darüber zu erfahren. Daraufhin beschloss ich, dass wir damit experimentieren würden.

Ein wesentlicher Bestandteil eines Experiments ist die Hypothese. Ohne sie weiß man nicht, ob das Experiment erfolgreich war. Meine Theorie war, dass die Mob-Programmierung uns helfen würde, Wissen zwischen Entwicklern auszutauschen und gleichzeitig sauberen Code zu erstellen.

Ich habe unsere erste Mob-Programmierungssitzung geplant und vorbereitet, was gar nicht so schwer war:

• Beschaffen Sie sich einen Computer, der an einen großen Bildschirm angeschlossen ist

• Stellen Sie einen Tisch vor den Bildschirm.

• Beschaffen Sie fünf Sitzplätze am Tisch.

• Stellen Sie einige Snacks und Zubehör auf den Tisch.

Und da waren wir nun, fünf Entwickler in einem Raum mit nur einem Computer:

Was geschah während unserer ersten Mob-Programmierung?

Wesley setzt sich in die Nähe der Tastatur (wir benutzen seinen PC) und wird automatisch in die Rolle des Treibers versetzt. Der Treiber ist ein intelligentes Eingabegerät: Er kann tippen, darf aber keine Entscheidungen treffen. Die anderen Entwickler bekommen die Rolle des Navigators. Sie sind diejenigen, die darüber diskutieren, was passieren soll und dem Fahrer sagen, was er tun soll.

Der Fahrer ist ein intelligentes Eingabegerät: Er kann tippen, aber er darf keine Entscheidungen treffen.

Wir beginnen mit einer einfachen Aufwärmgeschichte, bei der wir einige veraltete Inhalte in der Fußzeile der Website entfernen müssen.

Die Navigatoren sagen Wesley, dass er Docker starten soll. Wir sehen sofort eine Fehlermeldung. Wesley erklärt, dass dies manchmal vorkommt, aber mit ein paar Wiederholungsversuchen immer behoben wird. Wir versuchen es nicht noch einmal, aber die Navigatoren erklären uns, welche Einstellungen wir ändern müssen. Von nun an startet Docker immer ohne Fehler. 

Wesley schreibt auf einen Klebezettel, was er über Docker gelernt hat. Er klebt diesen Zettel auf das große Blatt Papier mit der Bezeichnung Learnings.

Ich schreibe auf einen Klebezettel, dass Docker nicht gestartet ist, was uns zurückhält. Ich leite ihn an die Waste Snake weiter, ein großes Blatt Papier mit einer darauf gezeichneten Schlange. Auf dieses Blatt klebt man Haftnotizen, die alles beschreiben, was den Mob vom eigentlichen Programmieren abhält:

Nach 12 Minuten ertönt ein Buzzer. Alle müssen nach rechts schalten. Der Fahrer wird zum Navigator, und einer der Navigatoren wird zum Fahrer. Das ist ein bisschen mühsam, und es dauert eine Weile, bis wir wieder loslegen können. Aber nach ein paar Wechseln sind wir viel besser darin geworden.

Wir beenden die Geschichte und beginnen mit der Arbeit an der nächsten: Yii2 view verursacht falsche Kommentare in HTML, was zur Ungültigkeit von HTML führt. Eine interessante Geschichte. Sie wurde bereits zweimal von verschiedenen Entwicklern aufgegriffen, aber beide blieben stecken. Jeder trägt seinen Teil zur Geschichte bei. Schließlich beheben wir das Problem auf eine Weise, mit der alle sehr zufrieden sind.

Nach zwei Stunden ist die Sitzung beendet.

Was haben wir bei unserer ersten Mob-Programmierungssitzung gelernt?

Wir besprechen in einer Retrospektive, was gut gelaufen ist und was wir verbessern können. Die wichtigste Erkenntnis dabei ist: Wir haben die Geschichte in einer Iteration besser/gründlicher gelöst, als wenn eine einzelne Person daran gearbeitet hätte.

Wir haben die Geschichte in einer Iteration besser / gründlicher gelöst, als wenn eine einzelne Person daran gearbeitet hätte.

Jeder fühlt sich während der Retrospektive angeregt. Uns allen hat das Experiment gefallen. Es wird deutlich, dass Mob-Programmierung uns tatsächlich hilft, Wissen zu teilen und gleichzeitig sauberen Code zu erstellen.

Die meisten Lektionen waren ziemlich offensichtlich, z. B. wenn eine Abkürzung dem Treiber unbekannt war, oder die Konfiguration von Werkzeugen, die Ihnen zu mehr Effizienz verhelfen. Es wurde deutlich, wie einfach es ist, den eigenen Entwicklungsprozess durch die Verwendung von Workarounds zu verkomplizieren, wenn sich ein System unerwartet verhält. Dies bestätigt die Notwendigkeit, die Verbesserungskata zu übernehmen.

Andere Erkenntnisse waren eher subtiler Natur. Zum Beispiel, wie man ein schwieriges Problem in kleinere Probleme aufteilen kann. Oder die Vorschläge, wie man wirklich testgetrieben arbeiten kann, indem man zuerst einen fehlgeschlagenen Test erstellt, anstatt erst danach einen Test hinzuzufügen.

Das Experiment ist gelungen! Die nächste Sitzung ist sofort geplant

Eine der größeren Herausforderungen war die Kommunikation zwischen den Navigatoren und dem Fahrer. Man will nicht alles buchstabieren, vor allem nicht für die erfahreneren Entwickler. Aber man will auch nicht, dass ein jüngerer Entwickler das Gefühl hat, ins kalte Wasser geworfen zu werden. Mit der Zeit lernt die Meute, wie man die einzelnen Fahrer richtig anspricht.

Ferngesteuerte Mob-Programmierung

In den Niederlanden sind wir gerade in einer Abriegelung. Unser Büro ist geschlossen, und alle arbeiten aus der Ferne. Das macht Mob-Programmierung wie oben beschrieben unmöglich, weil wir nicht im selben Raum sein können.

Wir wollten aber trotzdem Mob-Programmierungssitzungen durchführen. Durch Versuch und Irrtum kamen wir auf die folgende Idee für eine ausgezeichnete Remote-Mob-Programmierungssitzung:

• Jeder hat eine Webcam, und jeder schaltet sie während einer Sitzung ein.

• Wir verwenden Whereby, um unsere Sitzungen zu veranstalten, weil man seinen Bildschirm freigeben und trotzdem die Kameraübertragungen der anderen sehen kann.

• Der Fahrer meldet sich über eine Remote-Desktop-Verbindung auf einem eigenen Computer an (wir haben dafür ein mob-Benutzerkonto im internen Netzwerk eingerichtet).

• Wir haben ein separates mob-Benutzerkonto für Git eingerichtet. Das macht es sehr einfach, die Rollen zu wechseln.

Wie kann ich dies in meinem eigenen Arbeitsumfeld ausprobieren?

Von allen Artikeln, Blogs und E-Books, die ich zum Thema Mob-Programmierung gelesen habe, kann ich die Lektüre dieser beiden sehr empfehlen:

• Das Mob Programming Guidebook (kürzlich umbenannt in Ensemble Programming Guidebook) von Maaret Pyhäjärvi.

• Mob Programming - A Whole Team Approach von Woody Zuill.

Wählen Sie dann einfach einen Termin mit Ihrem Team und probieren Sie es aus. Viel Spaß!