Quando si parla di approccio agile istintivamente si è portati a pensare a un metodo privo di tecnicismi, molto flessibile, adattabile più alle persone che a ciò che riguarda produzione o business.

Agli Italian Agile Days 2022, grazie a Silvia, Nicola, Mariano e Michele, abbiamo avuto l’ennesima conferma che l’aspetto sociale e quello tecnologico sono invece strettamente legati tra loro, quando si lavora in un team, e devono necessariamente procedere di pari passo.

Il workshop di Ferdinando Santacroce lo ha spiegato ottimamente raccontando uno studio, effettuato a Londra nel dopo-guerra, su alcuni gruppi di lavoratori delle miniere di carbone. Lo studio in questione ha dimostrato come l’introduzione di macchinari per agevolare il lavoro dei minatori non portasse alcun giovamento alla produttività, se questo non fosse associato al miglioramento delle condizioni sociali del team. In sostanza: senza la coesione del gruppo non si ottiene l’integrazione dei risultati dei diversi task svolti.

In un workshop molto tecnico, Alberto Acerbis ci ha invece raccontato come usare i pattern per affrontare un codice imponente, ovvero gestirlo come un monolite e suddividerlo in micro-servizi, dividendolo in moduli e utilizzando classi non in comune, in modo che questi non possano modificarsi i dati a vicenda. Questo metodo, oltre a facilitare l’aggiunta di features, fa sì che si possa modificare il codice senza rischiare di intaccare altre aree.

Nel workshop di quasi quattro ore, tenuto da Marco Consolaro, Alessandro Di Gioia, è stato spiegato come il behavior driven design (BDD), associato al mob programming, può essere molto efficace quando si deve implementare una funzionalità ben precisa con acceptance test, partendo da una user-story di esempio. In casi come questo si scrivono gli acceptance test sotto forma di test puntuali e precisi, seguendo la pratica red-green-refactor; successivamente si prosegue nel far passare i test scritti. Una delle cose più interessanti di questo approccio è che chi scrive le storie è forzato a pensare a dei casi d’uso precisi e testabili in un ambiente automatizzato, quindi a formalizzare oggettivamente la funzionalità. Chi sviluppa il codice invece è forzato ad implementare tutte le parti necessarie a far passare i test di quella funzionalità, basandosi sul comportamento globale del sistema e non sui singoli pezzi di codice(tdd). Va ricordato che niente è un “silver-bullet”: bisogna sapere come/quando/quanto usare questa tecnica, ragionando in base al contesto del progetto, al team che la deve sviluppare, e alla nostra esperienza pregressa. Grazie a loro abbiamo anche avuto modo di provare più da vicino il mob programming, una pratica di programmazione collettiva molto interessante. Si tratta di un’evoluzione del pair-programming, che può coinvolgere dalle 4 alle 8 persone, ciascuna con ruoli separati, per lo sviluppo di una funzionalità precisa: chi scrive il codice, ovvero colui che non deve preoccuparsi della soluzione filosofica e chi media tra le altre persone. Le persone che scrivono il codice cercano di estrarre dal gruppo (mob) la soluzione migliore concordata e il mob pensa e discute sulla soluzione da applicare al problema.

Informazioni utilissime e ben spiegate che il talk di Emanuele Delbono ci ha spiegato come approcciare, ovvero senza complicarci la vita da soli! Il suo intervento, pur essendo molto tecnico, ha posto le basi per una corretta riflessione sul ruolo degli sviluppatori, invitandoci a scrivere codice “semplice”, sia da leggere che da mantenere aggiornato, anziché farci prendere dall’ansia di soddisfare richieste che il cliente non ha neppure espresso.

Sono stati due giorni intensi, dai quali ci portiamo a casa informazioni vitali per lo sviluppo consapevole e “sano” della nostra attività….oltre alle vesciche ai piedi e a un elenco di osterie tipiche tutte da provare ;)