Cos’è la metodologia agile e perché agli sviluppatori piace così tanto

In Evoluzione non solo difendiamo tanto questa metodologia ma cerchiamo anche di utilizzarla il più possibile dove ci viene consentito.

Per capire perché siamo dei grandi fan dell’Agile, facciamo innanzitutto un passo indietro e andiamo alle origini di questo movimento: siamo nel 2001 e 17 “mostri sacri” dell’informatica fra cui Kent Beck, Robert C. Martin (o Uncle Bob) e Martin Fowler pubblicano il “Manifesto for Agile Software Development”, chiamato anche “Manifesto Agile”.

I 4 principi del Manifesto Agile come Best Practice d’agenzia

All’interno di questo documento viene delineato un nuovo metodo di sviluppo software, che ha come obiettivo non quello di adempiere ad un contratto ma quello di garantire la piena soddisfazione del cliente (sembra una banalità, ma non sempre le due cose coincidono!). Il Manifesto Agile è composto da 12 punti ben precisi che possono essere raggruppati secondo quattro principi che, con il tempo, abbiamo cercato di integrare all’interno delle nostre Best Practice in agenzia:

  1. Le persone e le interazioni sono più importanti dei processi e degli strumenti: bisogna comunicare! In Evoluzione siamo fermamente convinti che la comunicazione fra tutti i protagonisti di un progetto sia la chiave per il suo successo! Tutti i membri del team devono essere al corrente di ciò che succede, non solo gli sviluppatori: cerchiamo sempre di creare dei team di lavoro cross funzionali e ci piace che tutti i componenti siano sempre al corrente di tutto quello che succede, nonostante alcune operazioni possano riguardare solamente una parte di esso.
  2. È più importante avere software funzionante che documentazione: chiariamoci, non scriviamo del codice non documentato, ma la priorità non è certo quella. Per noi il codice deve essere semplice, leggibile e self explaining… quindi cerchiamo di mantenere i commenti per l’indispensabile. Riteniamo che sia più importante rilasciare sempre nuove versioni del codice funzionante e farlo con una certa frequenza. Solamente attraverso rilasci frequenti e un codice tecnicamente avanzato è possibile rilasciare del vero valore al progetto e, quindi, anche al cliente.
  3. La collaborazione con i clienti è fondamentale, non bisogna “solamente” rispettare il contratto: come nella vita, anche nello sviluppo di un progetto, la collaborazione è in grado di garantire dei risultati fondamentali, andando al di là delle “fredde” condizioni contrattuali. Riteniamo che il dialogo sincero e la collaborazione totale con i nostri clienti sia la chiave per rilasciare valore costantemente, ottenendo dei progetti di successo. Ci piace integrare il cliente all’interno del nostro team Agile, dandogli dove possibile il ruolo del Product Owner: abbiamo visto che in questo modo abbiamo di fronte a noi un interlocutore motivato e consapevole di avere un obiettivo da raggiungere insieme al team: il risultato finale è che noi lavoriamo con il nostro cliente, non per il nostro cliente!
  4. Essere pronti al cambiamento oltre che aderire alla pianificazione: non sempre le cose vanno come ce le siamo immaginate nelle fasi iniziali e, molte volte, è necessario correggere il tiro. Per noi è importantissimo essere reattivi e sapere di poter essere in grado di “cambiare rotta” qualora ci sia la necessità di farlo. Questo richiede di avere una buona flessibilità ma, soprattutto, un interlocutore consapevole che una “deviazione” dalla via tracciata inizialmente può essere la chiave per garantire la buona riuscita del progetto.

Bene, abbiamo visto su cosa si basa il Manifesto Agile ma, nella pratica, cosa viene fatto nel quotidiano per rispettare tutto ciò?

Photo by Paul Hanaoka on Unsplash

Scrum, la metodologia Agile scelta da Evoluzione

Attualmente ci sono varie metodologie Agili che ogni team può seguire per la gestione dei propri lavori: noi in Evoluzione, dopo varie ricerche ed esperimenti, abbiamo scelto di seguire Scrum.

I creatori di Scrum, Ken Schwaber e Jeff Sutherland, hanno preso questo termine in prestito dal gioco del rugby. Indica il pacchetto di mischia, ovvero la situazione di gioco in cui tutti i giocatori devono spingere compatti nella stessa direzione per raggiungere l’obiettivo comune: questo è quello che fa Scrum! Tutto il team deve andare nella stessa direzione per raggiungere un unico obiettivo. Scrum si basa sulla teoria dei controlli empirici dei processi. Questa teoria afferma che la conoscenza deriva dall’esperienza e le decisioni vengono prese in base a ciò che si conosce. I pilastri che ne stanno alla base sono tre:

  1. Trasparenza: gli aspetti significativi del processo devono essere visibili ai responsabili del lavoro. Questi aspetti devono essere definiti attraverso degli standard comuni, in modo tale che possano essere compresi da tutti. Noi cerchiamo di avere un linguaggio più possibile codificato e standard per tutti, evitando ambiguità e incomprensioni. Cerchiamo di inserire alle nostre attività delle descrizioni auto esplicative, che facilitino il compito di chi le legge.
  2. Ispezione: è necessario ispezionare spesso gli artefatti prodotti (vedremo a breve cosa si intende per artefatti) in modo tale da poter capire quali attività sono state portate a termine e, invece, quali possono essere gli impedimenti per il raggiungimento di certi obiettivi.
  3. Adattamento: se alcuni aspetti del processo non stanno andando come previsto o, peggio ancora, non possono essere completati, è necessario intervenire al più presto per ridurre lo scarto al meno possibile.

Rilasciamo valore mediante gli artefatti

Abbiamo parlato di artefatti, ma cosa sono? Gli artefatti di Scrum rappresentano il lavoro e il valore in diversi modi utili per fornire trasparenza e opportunità di ispezione e adattamento. Esistono tre tipi di artefatti:

  1. Product Backlog: il product backlog è la lista di tutte le attività necessarie per realizzare un prodotto. Ogni attività è chiamata Item e, al suo interno, contiene la user story. La lista degli Item viene prioritizzata in modo tale che, ad ogni sprint, si decidano di eseguire le attività con priorità maggiore. All’inizio di ogni sprint, inoltre, è possibile rivedere la lista delle priorità. Dato che cerchiamo di applicare le metodologie agili anche per le nostre attività in Evoluzione, abbiamo creato anche un backlog di agenzia. In esso confluiscono tutti i backlog dei nostri progetti e lo utilizziamo come driver per pianificare i nostri sprint (uno sprint non è altro che il ciclo di lavoro, noi abbiamo deciso di regolare la nostra vita aziendale su sprint di 2 settimane).
  2. Sprint Backlog: è rappresentato da tutti quegli Item che durante lo Sprint Planning vengono “promossi” per essere inseriti nello sprint. Ogni Item viene poi assegnato ad un membro del team che sarà responsabile del suo completamento.
  3. Increment: un incremento è rappresentato da tutto ciò che risponde alla definizione di FATTO stabilita dal team. In alcuni casi la lista degli incrementi, alla fine dello sprint, risulta uguale allo sprint backlog: questo succede in caso di team altamente performanti. In tutta sincerità a noi non capita sempre questa situazione; diverse volte il nostro Increment non è come il nostro sprint backlog ma è proprio qua che, a mio parere, si vede la vera forza dell’Agile: sono gli impedimenti e le situazioni da risolvere attraverso l’adattamento che mostrano la vera potenza di questa metodologia.

Come funzionano gli Sprint in Evoluzione?

L’Agile, però, non rappresenta una dottrina rigida e imbrigliata ma lascia spazio ad alcune interpretazioni a seconda delle necessità che possono scaturire. Di conseguenza in Evoluzione abbiamo messo in campo la nostra idea di Scrum, regolando i nostri sprint attraverso queste due tipologie di eventi:

  • Il Daily Standup: un meeting giornaliero con un timebox fissato di massimo 15 minuti, nel quale ogni membro del team aggiorna gli altri su cosa è stato fatto, cosa verrà fatto prima del prossimo standup, ma soprattutto quali sono eventuali impedimenti che potrebbero ostacolare il raggiungimento dell’obiettivo. Lo Standup viene fatto sempre alla solita ora e…stando in piedi. In questo modo si cerca di non dare la possibilità ai componenti dell’incontro di distrarsi. Ora la situazione è leggermente cambiata e, per i membri del team che sono in remoto, non è necessaria la regola dell’“alzarsi in piedi”.
  • La Sprint Review e lo Sprint Planning (al fine di ottimizzare i tempi, qualora non ci siano criticità particolari, uniamo queste due attività nella medesima riunione, con cadenza bisettimanale). La sprint review rappresenta per noi una possibilità di confronto, di crescita e di poter imparare dagli errori fatti nello sprint precedente. Solleviamo eventuali problemi emersi nelle due settimane appena trascorse e cerchiamo di capire come poter prevenire il fatto che si ripetano.  Lo Sprint Planning, invece, è la base per una corretta e onesta pianificazione: siamo consapevoli che esistono gli imprevisti (per i quali ovviamente non c’è soluzione) ma nel corso del tempo abbiamo capito che più uno sprint è pianificato con accuratezza, più la possibilità di realizzare un prodotto di qualità è alta.
Photo by İrfan Simsar on Unsplash

Tutto il lavoro è pilotato dalla Board dello sprint ma a differenza del classico flusso Scrum, nel quale la board prevede che esistano le colonne

  • ToDo, attività da svolgere
  • In Progress, attività che si sta svolgendo attualmente
  • Done, attività conclusa, validata e pubblicata

noi ne abbiamo aggiunte altre due:

  • Testing, vi inseriamo tutte quelle attività completate che devono essere validate prima del rilascio in produzione.
  • Wating/Blocked, in questa colonna “parcheggiamo” tutte quelle attività per le quali in quel momento è sorto un impedimento o siamo in attesa di un intervento esterno per poterle completare. Preferiamo inserirle in una colonna separata in modo tale che, ad ogni iterazione (che sia Daily o durante la retrospettiva), sia ben chiaro quali sono state le attività critiche dello Sprint e per quale motivo non si è potuto completarle.

Ovviamente nessuno di noi in agenzia è nato “facendo Agile” quindi per il primo anno ci siamo fatti seguire da un facilitatore. In questo modo abbiamo potuto apprendere i concetti chiave dell’agile e della filosofia Scrum, farli nostri e poterli utilizzare al meglio.

Dopo questo periodo di training iniziale, visto che la voglia di fare e di mettersi in gioco erano alte, abbiamo deciso che a turno ogni membro dell’agenzia è responsabile della buona uscita della Sprint Review e dello Sprint planning. In questa situazione storica particolare, non potendo essere tutti presenti fisicamente in ufficio, ci appoggiamo a delle board virtuali di Miro che servono a guidare le nostre riunioni. Speriamo di poterci trovare presto tutti insieme e poter usare quella fantastica lavagna che abbiamo predisposto per incontri come questi!

Siamo arrivati alla conclusione di questa mini-presentazione delle metodologie agili ma, soprattutto, di come noi le utilizziamo per migliorare i nostri processi produttivi. Nei prossimi articoli parlerò di come abbiamo iniziato ad applicare in concreto le metodologie agili sui nostri clienti, di quali sono stati i rischi e le difficoltà iniziali e di quali vantaggi concreti siamo riusciti ad ottenere.

Vuoi saperne di più su come riuscire ad aumentare l’efficacia dei tuoi effort grazie al metodo Agile? Contattaci!

Interessante? Chiedici una consulenza