Mob Pro­gramming – Software-Ent­wick­lung im Team

Eine relativ neue Form der Software-Ent­wick­lung ist das so­ge­nann­te Mob Pro­gramming, bei dem die Team­ar­beit im Fokus steht. Mehrere Ent­wick­le­rin­nen und Ent­wick­ler arbeiten dabei zusammen an demselben End­pro­dukt.

Mob Pro­gramming ist eine relativ neue Software-Ent­wick­lungs­me­tho­de, die vor allem auf die Arbeit in speziell or­ga­ni­sier­ten Teams setzt. Angelehnt an agile Software-Ent­wick­lung sollen hier­ar­chi­sche Struk­tu­ren, die einer schnellen und ef­fi­zi­en­ten Ent­schei­dungs­fin­dung oftmals im Weg stehen, aufgelöst werden. Auch der starke Fokus auf Zu­sam­men­ar­beit ist von anderen agilen Software-Ent­wick­lungs­me­tho­den über­nom­men.

Der kol­la­bo­ra­ti­ve Ansatz des Mob Pro­grammings kann außerdem als Wei­ter­ent­wick­lung von Pair Pro­gramming ver­stan­den werden. Während die Ent­wick­le­rin­nen und Ent­wick­ler bei diesem ganz nach dem Motto „Vier Augen sehen mehr als zwei!“ in Zwei­er­teams an Software ge­ar­bei­tet haben, wird die Teamgröße beim Mob Pro­gramming auf fünf bis zehn Ent­wi­ckeln­de erhöht.

Doch das Mob Pro­gramming weist im Gegensatz zu tra­di­tio­nel­ler Team­ar­beit noch eine Reihe weiterer Be­son­der­hei­ten auf: Statt über in der IT-Welt eta­blier­te Kol­la­bo­ra­ti­ons­tools wie GitHub an mehreren Rechnern gleich­zei­tig zu arbeiten, wird beim Mob Pro­gramming nur ein Terminal genutzt. Dieses wird oftmals mithilfe eines Beamers für alle Ent­wi­ckeln­den sichtbar an die Wand pro­ji­ziert. Außerdem werden die Kom­po­nen­ten des Ge­samt­sys­tems nicht an einzelne, unter Umständen spe­zia­li­sier­te Ent­wi­ckeln­de auf­ge­teilt. Beim Mob Pro­gramming arbeitet das gesamte Team simultan an demselben Code. Auch das Erstellen der An­for­de­rungs­ka­ta­lo­ge oder das Testen und Deployen der fertigen Software ist Teamsache.

Um die Team­ar­beit zu struk­tu­rie­ren, werden den Team­mit­glie­dern zu Beginn jeder Mob-Pro­gramming-Phase ver­schie­de­ne Rollen zugeteilt. Diese Rollen sind al­ler­dings kei­nes­falls statisch. Ganz im Gegenteil, nach einer gewissen Zeit­span­ne (zumeist 15 bis 30 Minuten) wird ein Rol­len­wech­sel ein­ge­lei­tet. In jedem Team gibt es einen Driver und mehrere Na­vi­ga­tors:

• Driver: Driver ist die Person, die letzten Endes den Code eintippt. Die im Team er­ar­bei­te­ten Konzepte und Ideen setzt der Driver also in die Tat um.
• Navigator: Alle anderen Team­mit­glie­der werden als Na­vi­ga­tors be­zeich­net, die die Ideen kol­la­bo­ra­tiv ent­wi­ckeln.

Je nach ver­folg­tem Mob-Pro­gramming-Ansatz kann es unter den Na­vi­ga­tors noch weitere Rollen geben:

Ein De­sti­na­ted Navigator sorgt dafür, die Ansätze und Ideen der Team­mit­glie­der zu struk­tu­rie­ren und zwischen kon­kur­rie­ren­den Meinungen zu ver­mit­teln, sodass der Driver nicht zwischen ver­schie­de­nen Im­ple­men­tie­rungs­va­ri­an­ten ent­schei­den muss. Er nimmt oft gleich­zei­tig die Rolle des Time­kee­pers ein, der nach einer gewissen Zeit für den Wechsel der Rollen innerhalb des Teams sorgt.

Außerdem können Team­mit­glie­der so­ge­nann­te Re­se­ar­cher sein. Bei Un­klar­hei­ten und Un­si­cher­hei­ten re­cher­chie­ren und sammeln sie In­for­ma­tio­nen für das gesamte Team. Dieses Team kann auch Personen be­inhal­ten, die nichts Konkretes zu der Ent­wick­lungs­pha­se beitragen können, sondern den gesamten Prozess lediglich be­ob­ach­ten und Nach­fra­gen bei Un­klar­hei­ten stellen. Sie werden als Learner be­zeich­net.

Wie das Mob Pro­gramming konkret aus­ge­stal­tet wird, ist nirgendwo vor­ge­schrie­ben. Vielmehr ist die Aus­ge­stal­tung abhängig vom in­di­vi­du­el­len Ent­wick­lungs­zweck und der je­wei­li­gen Team­dy­na­mik. Dennoch gibt es Richt­li­ni­en, deren Ein­hal­tung zu einem er­folg­rei­chen Mob Pro­gramming beiträgt.

So ist es sinnvoll, den Rechner des Drivers an einen ge­mein­sa­men, großen Bild­schirm oder einen Beamer an­zu­schlie­ßen, damit alle Team­mit­glie­der den aktuellen Stand des Codes verfolgen können. Auch die räumliche Nähe spielt beim Mob Pro­gramming daher eine Rolle: Im Idealfall befindet sich das gesamte Pro­gram­mier­team in demselben Raum. Nur so kann von direktem, per­sön­li­chem Austausch pro­fi­tiert werden.

Auch die Vergabe der Rollen innerhalb des Teams ist eine wichtige Vor­aus­set­zung für ein er­folg­rei­ches Mob Pro­gramming. Ins­be­son­de­re der Time­kee­per, der den Rol­len­wech­sel einleitet, ist un­ab­ding­bar, um die Vorteile des Mob Pro­grammings aus­zu­schöp­fen. Die hohe Fluk­tua­ti­on innerhalb einzelner Rol­len­bil­der sorgt für ständig neuen Input.

Der Ansatz der Mob Pro­grammings bietet eine Reihe von Vorteilen. Der viel­fäl­ti­ge Er­fah­rungs­aus­tausch zwischen den einzelnen Team­mit­glie­dern sorgt für eine kreative und ziel­füh­ren­de Software-Er­stel­lung. Außerdem können die Ent­wick­le­rin­nen und Ent­wick­ler un­ter­ein­an­der vom Fach­wis­sen der Mit­pro­gram­mie­ren­den pro­fi­tie­ren und so ihren Horizont erweitern. Vor diesem Hin­ter­grund eignet sich Mob Pro­gramming ideal dafür, neue Mit­ar­bei­te­rin­nen und Mit­ar­bei­ter schritt­wei­se an Projekte her­an­zu­füh­ren. Die eigens für solche Zwecke exis­tie­ren­de Rolle des Learners ist in­te­gra­ler Be­stand­teil des Software-Ent­wick­lungs­mo­dells.

Auch die Ver­ant­wor­tung, die mit der Ent­wick­lung von Software ein­her­geht, wird durch Mob Pro­gramming auf­ge­teilt, sodass der Druck, der auf einzelnen Ent­wi­ckeln­den lastet, minimiert wird. Durch die ge­mein­sa­me For­mu­lie­rung des Codes ist dieser weniger feh­ler­an­fäl­lig und hoch­wer­ti­ger. Zudem tragen die ge­mein­sa­men Tests dazu bei, die Code­qua­li­tät zu sichern. Diese wird natürlich auch dadurch ver­bes­sert, dass das gesamte Team gleich­zei­tig an demselben Code arbeitet; Fehler, die erst bei der In­te­gra­ti­on getrennt von­ein­an­der ent­wi­ckel­ter Software-Kom­po­nen­ten entstehen, fallen so bereits im Vorhinein weg.

Dennoch bringt auch Mob Pro­gramming einige Nachteile mit sich. Am re­le­van­tes­ten dürfte der er­heb­li­che Zeit- und Per­so­nal­auf­wand sein, der für die Umsetzung des agilen Ansatzes er­for­der­lich ist. Auch das Ver­mit­teln zwischen ver­schie­de­nen Meinungen zum selben Sach­ver­halt kann beim Pro­gram­mie­ren von kon­sis­ten­tem Code zu Problemen führen. Ein wichtiger Punkt ist auch, dass das Mob Pro­gramming im Ho­me­of­fice we­sent­lich schlech­ter funk­tio­niert und sich damit eher weniger für Remote-Work anbietet. Zwar gibt es Ansätze, die ein Mob Pro­gramming auch in On­line­sit­zun­gen vor­schla­gen; beim tra­di­tio­nel­len Mob Pro­gramming ist die Mög­lich­keit des direkten per­sön­li­chen Aus­tauschs aber wichtiger Be­stand­teil.