Coding Dojo @Zühlke: Programmieren als Mob

29 April 2014
| |

Am 16. April fand bei Zühlke das Oster-Coding-Dojo statt. Das Thema diesmal: Mob-Programming. Statt dem gängigen Pair-Programming, bei dem immer zwei Entwickler gemeinsam programmieren, programmiert beim Mob-Programming eine ganze Gruppe zusammen. Beim Zühlke Oster-Coding-Dojo waren es vier bis fünf Entwickler pro Gruppe. Bei der Programmiersprache hatte jedes Team die Qual der Wahl. Diese mal waren Java, C#, JavaScript und Scala vertreten.

Die Kata

Am Tag des DFB-Pokal-Halbfinal-Spiels in München, gab es die passende Scoreboard-Kata (allerdings zur Gruppenphase der WM 2014 in Brasilien – der DFB-Pokal gibt mit seinem K.O.-System ja nicht allzu viel her 😉 ). Die Regeln sind einfach: Für ein gewonnenes Gruppenspiel gibt es 3 Punkte, Unentschieden gibt jeweils 1 Punkt und eine Niederlage Keinen. Bei gleicher Punktezahl zählt zuerst die Tordifferenz, danach die Zahl der geschossenen Tore. Sollten beide Teams dann immer noch gleichauf sein, wird der direkte Vergleich bewertet. Sollte auch dieser gleich sein, entscheidet schlussendlich das Los.

Dies sind genug Regeln um die Teilnehmer des Coding Dojos einen ganzen Abend lang zu beschäftigen. Egal, ob diese mit einem Comparator oder mit Hilfe von Pattern Matching implementiert werden.

Programmieren als Mob

Statt zwei Programmierern teilen sich beim Mob-Programming vier bis fünf Entwickler einen Monitor und eine Tastatur. Dank genügend Fernseher und Beamer war dies auch kein Problem.

Interessant fand ich, dass gleich mehrere Gruppen zum Whiteboard oder Flipchart gegriffen haben, um das Problem zu besprechen und eine grobe Lösungsskizze zu erarbeiten. Beim Pair-Programming habe ich das so noch nie gesehen.

Als das grobe Vorgehen klar war, sah man dann vor jedem Monitor konzentrierte Programmierer, die gelegentlich ein „Da hast du einen Null-Check vergessen.“, „Die Condition muss negiert werden.“ o.ä. einstreuten. Und so konnte man den Kollegen auch die Syntax diktieren, wenn sie diese noch nicht so detailliert beherrschen. (Wie bei Coding Dojos üblich, soll natürlich jeder mal tippen.) Über Lösungen wurde diskutiert und wenn möglich wurden Optimierungen vorgenommen. Auch Tests wurden diskutiert und das führte (zumindest in meiner Gruppe) zu sehr detaillierten Testfällen, die alle erdenklichen Sonderfälle prüfen.

Ist Mob-Programming sinnvoll?

Als jede Gruppe die Ergebnisse präsentierte, wurde schnell deutlich, dass alle Gruppen relativ gleich weit gekommen sind. In der abschließenden Retrospektive hat dann noch einmal jeder seine Meinung zum Mob-Programming teilen dürfen. Das Echo war hier sehr unterschiedlich.

Viele Teilnehmer sprachen sich für das altbekannte Pair-Programming aus. Negative Punkte waren unter anderem, dass viel diskutiert wurde und man sich in der großen Gruppe langsamer einigen konnte, als man das zu zweit hätte tun können. Ganz nach dem Motto „Viele Köche verderben den Brei“. Außerdem wurde kritisiert, dass das Vorgehen für die Praxis wohl viel zu teuer sei.

In anderen Gruppen hat die Absprache gut geklappt. Außerdem wurde positiv hervorgehoben, dass man sich gegenseitig gut helfen kann und gerade nicht in Diskussionen versinkt, weil immer jemand den Fokus zurück auf das Wesentliche lenkt.

Ich denke, es ist eine Frage wie einig und eingespielt die Gruppe ist. Wenn es in einem Mob viele verschiedene Meinungen gibt, dauert es eine Zeit, bis sich alle auf ein Vorgehen/eine Lösung einigen. Sobald sich der Mob aber eingespielt hat, scheint das Ganze gut zu funktionieren.

Arbeitsplatz eines Mobs

Mein persönliches Fazit

Ich persönlich finde Mob-Programming gerade für Coding Dojos sehr sinnvoll. Ich habe schon oft erlebt, dass man beim Pair-Programming (auch mit Leuten, die man vorher nicht kannte) in Diskussionen abdriftet. Die Gefahr ist aus meiner Sicht beim Mob-Programming geringer, weil es immer ein Gruppenmitglied gibt, welches den Fokus wieder auf das Wesentliche lenkt. Außerdem kann man dadurch noch ein bisschen mehr lernen, weil man das Wissen zwischen mehr als zwei Leuten teilt.

Ich würde das Prinzip auch gerne mal in der Praxis ausprobieren. Ich habe in den letzten Jahren in einem Team gearbeitet, bei dem ich mir sehr gut vorstellen kann, dass das wunderbar funktioniert. Allerdings bin auch ich kritisch, ob das nicht viel zu teuer ist. Aber gerade für technologisch/architektonisch neue Features oder Prototypen lohnt sich das bestimmt. Alle Entwickler sind an der Implementierung beteiligt und können etwas beitragen und alle wissen danach, wie es funktioniert. Wenn dann auch noch jemand mit fachlichem Fokus dabei ist, der ggf. unklare Anforderungen und Spezialfälle klären kann, kommt man so sicherlich sehr schnell auf ein gutes Ergebnis. Ich vermute, dass man sich so einige Bugs und Refactore-Iterationen sparen kann. Selbstverständlich ist die Methodik nicht für „Schema F„-Tasks gedacht. Dafür ist sie dann doch zu teuer.

Generell denke ich aber, dass man mit der Methodik gute Ergebnisse erzielen kann und dazu noch den Zusammenarbeit im Team stärkt. Sehr interessant finde ich zu dem Thema den Blog-Beitrag „Get a good start with mob programming“ von Per Jansson.

Alles in allem war das Coding Dojo wie immer eine super Erfahrung und hat viel Spaß gemacht. Falls auch ihr interessiert seid, mal mitzumachen, meldet euch am besten direkt in der Xing-Gruppe an, um über zukünftige Events informiert zu werden.

Wie sind eure Erfahrungen mit Mob-Programming? Habt ihr den Einsatz in der Praxis schon einmal erlebt? Lohnt es sich das in der Praxis umzusetzen oder ist es doch nur etwas für Coding-Events?

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.