Mob Pro­gram­ming: lo sviluppo software nel lavoro in team

Il co­sid­det­to Mob Pro­gram­ming è una forma re­la­ti­va­men­te nuova di sviluppo software in­cen­tra­ta sul lavoro in team. Il prodotto finale viene rea­liz­za­to da più persone tutte in­ca­ri­ca­te dello sviluppo.

Il Mob Pro­gram­ming è un metodo di sviluppo software re­la­ti­va­men­te recente basato es­sen­zial­men­te sul lavoro in team or­ga­niz­za­ti ad hoc. Ispirato al concetto di sviluppo software agile, l’obiettivo di questo approccio consiste nel disfarsi delle strutture ge­rar­chi­che che spesso frenano un processo de­ci­sio­na­le rapido ed ef­fi­cien­te. Un’ulteriore ca­rat­te­ri­sti­ca ripresa dalle me­to­do­lo­gie agili è l’at­ten­zio­ne par­ti­co­la­re alla col­la­bo­ra­zio­ne.

L’approccio col­la­bo­ra­ti­vo del Mob Pro­gram­ming può anche essere inteso come evo­lu­zio­ne del Pair Pro­gram­ming: sempre seguendo il principio “l’unione fa la forza”, quest’ultimo prevede che alla pro­gram­ma­zio­ne si lavori in coppia, mentre il Mob Pro­gram­ming coinvolge una quota minima di cinque persone fino ad arrivare a un massimo di dieci.

Rispetto al lavoro in team tra­di­zio­na­le, il Mob Pro­gram­ming presenta un’ulteriore serie di pe­cu­lia­ri­tà: invece di lavorare su più computer mediante strumenti di col­la­bo­ra­zio­ne consueti nell’ambito in­for­ma­ti­co, come ad esempio GitHub, nel Mob Pro­gram­ming si utilizza un solo terminale, che viene pro­iet­ta­to su una parete in modo che sia visibile a tutto il team. In più, i singoli com­po­nen­ti del sistema com­ples­si­vo non vengono assegnati a seconda della spe­cia­liz­za­zio­ne degli individui: il Mob Pro­gram­ming, infatti, prevede che chiunque faccia parte del team lavori si­mul­ta­nea­men­te allo stesso codice. Persino la rea­liz­za­zio­ne delle linee guida, i test e i deploy dei software sono a carico dell’intera squadra.

Per strut­tu­ra­re il lavoro di gruppo, all’inizio di ciascuna fase del Mob Pro­gram­ming vengono assegnati diversi ruoli ai membri del team. Passato un de­ter­mi­na­to lasso di tempo (in genere dai 15 ai 30 minuti) avviene un cambio di ruoli. Ciascun gruppo è composto da una figura di “driver” e da varie figure di “navigator”:

• driver: si tratta della persona che scrive le ultime righe del codice. Chi ricopre questo ruolo si occupa pertanto di mettere in pratica idee e concetti che sono stati elaborati all’interno del team.
• navigator: i rimanenti membri del gruppo sono definiti navigator e svi­lup­pa­no le idee in modo col­la­bo­ra­ti­vo.

A seconda dell’approccio di Mob Pro­gram­ming prescelto, possono esserci ulteriori ruoli tra i navigator:

Il compito di de­sti­na­ted navigator, ad esempio, è quello di dare una struttura a spunti e idee espresse dal team e di mediare tra opinioni di­scor­dan­ti, in modo tale che chi è driver non si ritrovi a dover scegliere tra diverse varianti di im­ple­men­ta­zio­ne. Spesso a questo ruolo è associato anche quello di ti­me­kee­per, che prevede la gestione del tempo e di con­se­guen­za dei cambi di ruoli.

Infine, è previsto anche il ruolo di re­sear­cher. In caso di dubbi o domande, chi è re­sear­cher si occupa di eseguire ricerche e rac­co­glie­re in­for­ma­zio­ni per l’intero gruppo. Il team può includere anche persone che non con­tri­bui­sco­no di­ret­ta­men­te alla fase di sviluppo, ma che si limitano a osservare l’intero processo e porre domande in caso di dubbi. Si tratta del ruolo di learner.

Non ci sono regole precise su come debba essere pro­get­ta­to in maniera concreta il Mob Pro­gram­ming. La pro­get­ta­zio­ne è più in­cen­tra­ta sullo scopo di sviluppo in­di­vi­dua­le e sulle ri­spet­ti­ve dinamiche dei team. Esistono però delle linee guida che aiutano a far sì che il Mob Pro­gram­ming venga im­ple­men­ta­to con successo.

Ad esempio, risulta opportuno collegare il computer del driver a uno schermo condiviso di grandi di­men­sio­ni oppure a un pro­iet­to­re, per fare in modo che chiunque nel team possa seguire lo stato attuale del codice. Di con­se­guen­za, anche la pros­si­mi­tà fisica svolge un ruolo im­por­tan­te nel Mob Pro­gram­ming: nel migliore dei casi, l’intero team di pro­gram­ma­zio­ne si trova nella stessa stanza. Solo in questo modo si può trarre vantaggio da uno scambio diretto e personale.

In aggiunta, un buon pre­sup­po­sto per un Mob Pro­gram­ming di successo è rap­pre­sen­ta­to dall’as­se­gna­zio­ne dei ruoli all’interno del gruppo. Nello specifico chi ha il ruolo di ti­me­kee­per e avvia il cambio di ruoli è es­sen­zia­le per ottenere il massimo dallo sviluppo col­la­bo­ra­ti­vo. L’elevato turnover all’interno di singoli ruoli consente un flusso costante di nuovi input.

L’approccio del Mob Pro­gram­ming offre numerosi vantaggi. Gli in­nu­me­re­vo­li scambi di espe­rien­za all’interno del team fa­vo­ri­sco­no un processo di sviluppo software creativo e in­cen­tra­to sugli obiettivi. Oltre a ciò, ogni persona che fa parte del team può ap­pro­fit­ta­re dell’espe­rien­za altrui e ampliare la propria visione d’insieme. A fronte di questo scenario, il Mob Pro­gram­ming è perfetto per in­tro­dur­re gra­dual­men­te nuove risorse nei progetti. La figura del learner, che esiste proprio per questo scopo, è parte in­te­gran­te di questo modello di sviluppo software.

Inoltre, il Mob Pro­gram­ming divide le re­spon­sa­bi­li­tà che derivano dallo sviluppo software, riducendo al minimo la pressione sui singoli svi­lup­pa­to­ri. Dato che il codice viene scritto col­let­ti­va­men­te, è meno soggetto a errori e di qualità superiore; in più, i test congiunti con­tri­bui­sco­no a garantire un’elevata qualità. Tutto ciò è ov­via­men­te mi­glio­ra­to dal fatto che l’intero team lavora con­tem­po­ra­nea­men­te sullo stesso codice. Pertanto, gli errori che si ve­ri­fi­ca­no nella fase di in­te­gra­zio­ne di com­po­nen­ti software svi­lup­pa­ti se­pa­ra­ta­men­te vengono eliminati in anticipo.

Cio­no­no­stan­te, il Mob Pro­gram­ming comporta anche alcuni svantaggi. Tra questi, il più rilevante è pre­su­mi­bil­men­te la con­si­de­re­vo­le quantità di tempo e di personale ne­ces­sa­ria per im­ple­men­ta­re l’approccio agile. Mediare tra opinioni diverse su una stessa questione può portare a dif­fi­col­tà anche nella pro­gram­ma­zio­ne di un codice coerente. Un ulteriore punto critico è che il Mob Pro­gram­ming risulta de­ci­sa­men­te meno efficace in un contesto di smart working, di con­se­guen­za è meno adatto al lavoro da remoto. Benché esistano approcci che offrono questa me­to­do­lo­gia di sviluppo software in sessioni online, la pos­si­bi­li­tà di uno scambio personale diretto è uno degli aspetti fon­da­men­ta­li del Mob Pro­gram­ming tra­di­zio­na­le.