Mob Programming

Mob Programming (deutsch Teamprogrammierung), auch Ensemble-Programming, ist eine Softwareentwicklungsmethode, bei der das gesamte Team gemeinsam und gleichzeitig an einer Aufgabe arbeitet.

Mob Programming ist angelehnt an Paarprogrammierung, das die Qualität von Software durch das Vier-Augen-Prinzip verbessert. Bei Mob Programming arbeiten alle Entwickler gemeinsam im gleichen Raum an einer Aufgabe. Sie benutzen dazu einen einzigen Computer, dessen Bild mithilfe eines Projektors projiziert wird.^[1] In der Regel wechseln sich die Teammitglieder etwa alle 30 Minuten ab, leisten konzeptionelle Arbeit und bringen neue Ideen in die Entwicklung ein. Mob Programming ist nicht nur auf die Programmierung beschränkt: Andere typische Softwareentwicklungsaufgaben wie Anforderungsmanagement, Softwaredesign, Softwaretest etc. werden ebenfalls gemeinsam erledigt. Alle am Projekt beteiligten Personen, darunter auch Anwender und Fachexperten gelten dabei als Teammitglieder.^[2] Bei Teams, die nicht programmieren – also beispielsweise Design- oder Planungsteams – wird der Begriff Swarming genannt.^[3] Mob Programming ist auch für verteilte Teams möglich, indem alle Mitglieder mittels Screen-Sharing in einem virtuellen Raum zusammenarbeiten.^[4]

Als Weiterentwicklung von agilen Methodiken gelten folgende Ziele für Mob Programming:^[5]

• Die Teammitglieder interagieren miteinander mit Freundlichkeit, Rücksichtnahme und Respekt.
• Der physische Arbeitsraum des Teams ist so gestaltet, dass das gesamte Team gleichzeitig an derselben Aufgabe ergonomisch arbeiten kann.
• Das Team arbeitet immer nur an einem Arbeitsgegenstand und schließt ihn ab, bevor es zum nächsten übergeht.
• Das Team ist stets bestrebt, sich durch regelmäßige Retrospektiven mit konkreten Maßnahmen zu verbessern.

Der Begriff Mob Programming wurde erstmals 2002 in einem Aufsatz von Hohman und Slocum in Extreme Programming Perspectives erwähnt.^[6] Unabhängig davon wurde Mob Programming 2011 durch Woody Zuill in einem Team bei Hunter Industries als Weiterentwicklung von Testgetriebener Entwicklung und Coding Dojos eingesetzt.^[5] Seit seinem Vortrag „Mob Programming“ bei der JavaOne 2014 in San Francisco gilt Woody Zuill als Begründer dieses Entwicklungsansatzes. Zuill erklärt Mob Programming folgendermaßen:

Ståhl und Martensson kamen zu dem Ergebnis, dass Mob Programming einen positiven Effekt auf Durchlaufzeit (Zeit bis Entwicklungsaufgaben als fertiggestellt gelten) und Produktivität bei komplexen, mehrere Bereiche übergreifenden Aufgaben hat. Auf der anderen Seite konstatierten sie sowohl hinsichtlich der Gesamtproduktivität als auch des Wissenstransfers widersprüchliche Resultate und wenn dann nur geringe Verbesserungen.^[8]

Wang und Manos verglichen Mob Programming mit Paarprogrammierung und kamen zu dem Ergebnis, dass Mob Programmierung zu weniger Stress führe, allerdings in Situationen schlechter sei, welche intensive Zusammenarbeit und Wissensaustausch fordern. Die Produktivität (im Sinne von umgesetzten Tasks) wäre bei Pair Programming höher, aber die Effizienz (im Sinne von wenig Bugs) bei Mob Programming.^[9]

• Woody Zuill, Kevin Meadows: Software Teaming. A Mob Programming, Whole-Team Approach. 2022, ISBN 979-83-6118693-8 (englisch). 
• Mark Pearl: Code with the Wisdom of the Crowd. Get Better Together with Mob Programming. Hrsg.: Pragmatic Bookshelf. O'Reilly, 2018, ISBN 978-1-68050-615-0 (englisch). 
• Simon Harrer, Jochen Christ, Martin Huber: Remote Mob Programming. At home, but not alone. innoq, Monheim am Rhein 2019, ISBN 3-9821126-0-5 (englisch). 
• Karel Boekhout: Mob Programming. Find Fun Faster. In: Helen Sharp, Tracy Hall (Hrsg.): Agile Processes in Software Engineering and Extreme Programming. 17th International Conference, XP 2016. Band 251. Springer, 2016, ISBN 978-3-319-33514-8, S. 185–192, doi:10.1007/978-3-319-33515-5 (englisch, springer.com [PDF; 12,1 MB; abgerufen am 8. August 2024]). 

• Vom Pair Programming zum Mob Programming

1. ↑ Mob Programming: A Whole Team Approach - Vortrag auf der Agile 2014 von Woody Zuill
2. ↑ Julien Nigri: Le Mob Programming. Présentation. 13. Mai 2014, abgerufen am 9. August 2024 (französisch). 
3. ↑ Boris Gloger, Carsten Rasche: Scrum Think big. Scrum für wirklich große Projekte, viele Teams und viele Kulturen. Carl Hanser Verlag, 2017, ISBN 978-3-446-44634-2, S. 32 (238 S.). 
4. ↑ Simon Harrer, Jochen Christ, Martin Huber: Remote Mob Programming. innoq, abgerufen am 9. August 2024 (englisch). 
5. ↑ ^{a b} Agile Alliance - Mob Programming
6. ↑ Moses Hohman, Andrew Slocum: 28. Mob Programming and the Transition to XP. In: Extreme Programming Perspectives (= The XP Series). Addison-Wesley, 2002, ISBN 978-0-201-77005-6, Kap. 28 (englisch, 700 S.). 
7. ↑ Woody Zuill, Kevin Meadows: Software Teaming. A Mob Programming, Whole-Team Approach. 2022, ISBN 979-83-6118693-8 (englisch, 241 S.). 
8. ↑ Daniel Ståhl, Torvald Martensson: Mob programming: From avant-garde experimentation to established practice. In: Elsevier (Hrsg.): Journal of Systems and Software, 180, 111017. Band 180, Oktober 2021, doi:10.1016/j.jss.2021.111017, urn:nbn:se:liu:diva-178282 (englisch, 18 S., diva-portal.org [PDF; 448 kB; abgerufen am 10. Juni 2024]): “interview results indicate that mob programming has positive effects on lead time optimization and productivity when applied to complex tasks covering multiple domains, whereas effects on productivity more generally are ambiguous and likely to be modest. Similarly, implications of mob programming on learning are ambiguous” 
9. ↑ Yibo Wang, Andreas Manos: Comparative Analysis of Programming Approaches in Software Development. An Emperical Study of Solo, Pair, and Mob Programming. Hrsg.: Linnaeus University. 2023, urn:nbn:se:lnu:diva-122307 (englisch, 33 S., diva-portal.org [PDF; 942 kB; abgerufen am 8. August 2024]): “The comparison between mob and pair programming in articles suggested that the choice largely depends on the team's specific context and needs. For example, Dragos found that mob programming can lead to lower stress levels compared to pair programming, while Kattan et al. observed that pair programming can be more suitable for tasks that require a high level of collaboration. [..] In terms of productivity, mob programming exhibited a superior quality of work even though only one person was operating, while pair programming exhibited variability based on group dynamics."”