Mob programming, una pratica di sviluppo software per ridurre il tempo di rilascio

In questo articolo descriveremo cosa è il Mob programming, quali sono le sue regole – dal set up tecnico ai ruoli – e quali sono gli obiettivi e i vantaggi di tale pratica. Scopriremo come, attraverso il Mob Programming, si favorisce un lavoro efficace tra membri del team, un minor tempo di rilascio della funzionalità considerata prioritaria nel backlog e una riduzione del waste.

Manuel Togni, sviluppatore in Intrè, ha condiviso con noi l’esperienza di mob programming del suo team fatta a seguito di un workshop sul tema tenuto da Woody Zuill, uno dei pionieri della pratica.

Mob programming

Il mob programming, chiamato anche ensamble programming, è la pratica di sviluppo software che permette al team di lavorare insieme sullo stesso task nello stesso momento, luogo e con un solo computer.

E’ considerato un’evoluzione del pair programming, quindi da sessioni di lavoro in coppia si passa a sessioni di lavoro in gruppo.

L’obiettivo pratico delle sessioni di mob programming è concludere il task descritto nella storia fornita dal product owner riducendo il tempo di rilascio.

Come funziona? Set up tecnico, i ruoli e le storie

Il set up tecnico

La buona riuscita del Mob programming è condizionata dal set up tecnico e dall’ambiente circostante.

Una sessione di ensemble programming richiede:

• Un ambiente tranquillo e senza distrazioni
• Un computer
• Una tastiera
• Un proiettore o uno schermo di grande dimensione
• Facoltativo: una flipchart o una lavagna

I ruoli

• La sessione è inoltre caratterizzata dalla presenza di due figure principali:
  Un driver, cioè colui che scrive il codice e ha le mani sulla tastiera. Il driver riceve le istruzioni dai navigator e pone la sua attenzione sulla traduzione di queste in codice. Il driver è considerato un device di input intelligente nel senso che ha il compito di tradurre il linguaggio naturale in codice.
• I navigator, ovvero gli altri membri del team, sono coloro che danno le istruzioni al driver. I navigator si sobbarcano il carico cognitivo della scrittura del codice e possono (e devono) confrontarsi per trovare la migliore soluzione possibile per l’implementazione della funzionalità richiesta dal task.

Ogni 15 minuti circa avviene il cambio dei ruoli per favorire il coinvolgimento di tutto il team e condividere il carico cognitivo tra le persone .

Il team, oltre che dagli sviluppatori, è composto da figure quali: il PO, che fornisce la storia e i suoi stakeholder; i designer; gli esperti di specifiche funzionalità. Tutto il team può partecipare alla sessione di mob programming in base alle necessità. Avere un gruppo eterogeneo con skills diverse tende a ridurre il numero di errori, soprattutto quelli legati alle scelte tecniche, grazie ai confronti che avvengono in simultanea alla scrittura del codice.

Storie

Come accennato nel paragrafo precedente il team lavora su una storia.

Il Product Owner ha il compito di scrivere e di fornire al team delle stories che abilitino un lavoro di gruppo. Rispondendo alle domande “chi lo chiede”, “cosa chiede”, “perché lo chiede” e “quali sono i criteri di accettazione”, lo scope del lavoro viene delineato. Durante la scrittura del codice, i componenti del team prendono decisioni sulla base delle richieste della storia e dei suoi criteri di accettazione che guidano lo sviluppo.

E da remoto?

Il Mob programming da remoto si può fare, ma richiede più regole. Come tutti noi abbiamo avuto modo di testare, da remoto si perde facilmente la concentrazione e il coinvolgimento su quello che si sta facendo.

Per continuare ad essere delle presenze attive che portino valore, si lavora in piccoli team e si richiede ai membri di tenere la videocamera accesa ed eventualmente di ridurre il tempo per il cambio di ruolo tra driver e navigator . Costante è la condivisione dello schermo da parte del driver. Tramite esperimenti, ogni team trova le proprie buone pratiche per le sessioni da remoto grazie anche a tecnologie di supporto, e in particolare è necessario avere un repository condiviso per la codebase in modo che le modifiche siano sempre disponibili a tutti i soggetti coinvolti nella sessione di mob programming.

L’obiettivo del mob programming e il concetto di waste

L’obiettivo del mob programming è ridurre il waste, per minimizzare il tempo che trascorre tra l’inizio della lavorazione di una storia dello sprint e la sua conclusione.

Cosa intendiamo con il termine waste?

Con il termine waste, intendiamo tutte quelle attività o azioni che non portano valore al cliente finale nelle tipiche forme di costi, tempo, manodopera e materiali.

Alcuni fattori che rallentano o distruggono la produttività e aumentano il waste sono:

• Problemi di comunicazione a causa di numerosi scambi di informazioni e di messaggi differenti in tempi diversi. La presenza di tutto (o quasi) il team guida gli sviluppatori grazie alla comunicazione chiara e precisa che si può avere real time.
• Problemi di decision making per la scelta della soluzione migliore. In una sessione possono emergere varie opinioni grazie alla varietà dei punti di vista di coloro che compongono il team. Per evitare il protrarsi della discussione, è meglio passare alla valutazione dei pro e contro, per poi procedere con l’implementazione che sembra più valida e l’osservazione di ciò che emerge.
• Trashing, ovvero le interruzioni che causano cali di attenzione. Il trashing comporta un costo non solo di tempo, ma anche di energia.
• Politics, ovvero le pressioni dal lato business sul team. La presenza di una figura di business nei momenti di allineamento tra le parti è ideale per ridurre il tempo necessario per chiudere un ciclo di lavoro su un task.
• E molte altre ragioni…

Riprendendo l’analisi degli obiettivi del mob programming, abbiamo detto che il principale è quello di ridurre il tempo necessario a concludere un’attività.

Come l’ensemble programming, quindi, lo rende possibile?

La storia su cui si concentra l’effort viene chiusa e rilasciata in meno tempo grazie al lavoro in team nello stesso momento, nello stesso luogo e sullo stesso computer e grazie al coinvolgimento di colleghi con skills diverse e figure legate al business.

Grazie alla collaborazione di più parti nell’esecuzione, si affrontano subito determinate situazioni che potrebbero portare rallentamenti o errori.

Il Mob programming è uno strumento che aiuta a concentrare tutti gli sforzi in vista di un singolo obiettivo: massimizzare il valore di business rilasciato il prima possibile.

Ha sempre senso il mob programming? E’ necessario coinvolgere tutto il team?
Le critiche al mob programming

La classica critica che viene fatta al mob programming è la seguente: da soli si possono portare avanti più attività, invece che una sola. Perché, quindi, coinvolgere tutto il team su una singola attività? Non è uno spreco di risorse?

Partiamo dal presupposto che il team lavora sull’attività individuata in seguito alla fase di prioritizzazione delle storie del backlog e che la comune necessità è quella di chiudere la storia più urgente. Il mob programming aiuta a ridurre i tempi di lavorazione. Unificando le attività in una sessione in cui tutte le parti sono coinvolte, il task viene chiuso prima. Se si adotta la pratica ensemble programming quando la storia non è prioritaria, l’errore è a monte nell’analisi del backlog.

Inoltre, è vero che il mob programming è adatto per certe situazioni rispetto ad altre. Nei task complessi risulta vantaggioso, in quanto un solo membro del team impiegherebbe molto più tempo per la loro risoluzione; mentre le attività più semplici possono essere affrontate anche singolarmente. Quindi, emerge come non sia sempre necessario l’utilizzo del mob programming; è importante capire quando conviene adottarlo, tenendo presente il valore formativo di questa pratica.

L’esperienza di Intré

Intrè ha sperimentato il mob programming e Manuel Togni, durante il meetup tenuto da lui sull’argomento, ha condiviso alcuni suggerimenti sugli aspetti più critici emersi dalla loro esperienza. A questo link il loro articolo.

Nelle sessioni di mob programming, le dinamiche sociali emergono e vengono amplificate. Questo implica un’attenzione maggiore a come la sessione si evolve e a come viene gestita. Manuel ha sottolineato l’importanza delle retrospettive, anche brevi, per monitorare il lavoro fatto e per ragionare su come è stata l’interazione tra le persone del team.

Nelle interazioni tra i navigator, si può riscontrare una mancanza di disciplina che genera confusione, soprattutto per il driver impegnato a tradurre in codice le loro conversazioni. Per imparare a dare la parola a tutti e per riflettere sui propri interventi, il team di Intrè ha sperimentato l’esercizio di Coding Dojo con dei benefici.

Come illustrato anche nei paragrafi precedenti, la comunicazione deve essere chiara, in particolar modo quella tra driver e navigator. Questi devono trovare un equilibrio e il giusto livello di comunicazione per permettere al driver di avere informazioni chiare per procedere con la scrittura del codice.

Da evitare è l’effetto gregge. Se tutti hanno lo stesso background e la stessa prospettiva, infatti, si rischia di non vedere le varie possibilità e soluzioni tecniche. E’ preferibile quindi, creare dei team misti, favorendo così anche una maggiore condivisione di conoscenza.

I vantaggi

I vantaggi della pratica di mob programming sono molteplici.

• Condivisione della conoscenza grazie al coinvolgimento di persone con esperienze, background e sensibilità diverse.
• I feedback immediati: se non si condivide una scelta se ne parla subito e non a fine lavoro, evitando il rischio di dover rivedere tutto il lavoro svolto fino a quel momento.
• Maggiore coinvolgimento dei partecipanti “perché è divertente!”.
• Condivisione del carico cognitivo;
• Collective code ownership: tutti sanno quanto è stato fatto e il team è autonomo anche in assenza di una persona.
• Autogestione e responsabilizzazione del team, che permette la crescita professionale delle persone.
• Riduzione dei bug e degli errori.
• Favorire l’inclusione di persone nuove e di non-tecnici.
• “Quando è finito è finito”, poiché non sono necessarie code review ed emerge request.
• Favorire il benessere delle persone, le quali possono prendersi una pausa cambiando ruolo o staccandosi dalla sessione, senza fermare il lavoro del team.

Conclusione

Il mob programming è uno strumento, non la soluzione. Non è una pratica che si può sempre adottare, ma quando possibile e se si impara ad utilizzarla, può condurre a numerosi vantaggi.
Il mob programming permette di chiudere le storie prioritarie in meno tempo, di avere una visualizzazione completa e meno interruzioni possibili da parte di tutto il team sul lavoro che si sta facendo.

Risorse

• Articolo sul mob programming dal blog di Intré
• Sito di Woody Zuill
• Linkedin Manuel Togni