Cosa vuol dire fare AGILE
Miti dell'AGILE, alcuni degli approcci più comuni - ed errati- su questa disciplina
Molto spesso si sente parlare di AGILE come di una panacea capace di risolvere tutti i mali dell'informatica. È davvero così?
In generale si sa che le metodologie AGILI aiutano ad ottenere risultati più in fretta e migliori, ma in pochi sanno cosa vuol dire realmente lavorare con una metodologia AGILE. È quindi necessario fare un po' di chiarezza.
Per AGILE si intende un "cappello" sotto cui troviamo diversi tool e metodologie di lavoro che condividono alcuni principi di base.
Questi principi sono:
- Le persone e le interazioni sono più importanti dei processi e degli strumenti
- È più importante avere software funzionante che documentazione
- Bisogna collaborare con i clienti oltre a rispettare il contratto
- Bisogna essere pronti a rispondere ai cambiamenti oltre che ad aderire alla pianificazione
Qualunque realtà capace di sostenere tali principi è quindi di per sé aderente all'approccio. Tuttavia, questi quattro semplici punti racchiudono diverse consapevolezze e linee di comportamento che non rendono l'AGILE per tutti accessibile (o comunque realmente applicabile).
Vediamo ora in dettaglio le tipiche frasi e i comportamenti più contraddittori di coloro che dichiarano di lavorare con AGILE pur non facendolo realmente.
1. Applichiamo l'AGILE perché facciamo micro-rilasci
La pratica del micro-rilascio non ha nulla a che vedere con la costruzione di deliverable potenzialmente integrabili e con le dinamiche di continuous integration che sono previste dalla maggior parte delle metodologie AGILI. In particolare, per micro-rilascio spesso s’intende la consegna di un componente ridotto che non può essere utilizzato dal committente per generare valore di business e, in quest’ottica, è quindi solo una "milestone", non un PSPI (Potentially Shippable Product Increment).
2. Applichiamo l'AGILE perché lavoriamo a finestre di tempo prestabilito
L'approccio timeboxed è uno dei requisiti necessari per l'applicazione di alcune metodologie AGILI, come Scrum, ma da solo non è sufficiente. Tanto più, come spesso accade, dove lo si considera solo per il volume di lavoro erogato e non per tutti i momenti che coinvolgono la realizzazione. In effetti in Scrum, ad esempio, ogni singolo momento - dai meeting agli sprint - è "time boxed".
Spesso si sente parlare di finestre temporali prestabilite come un blocco di allocazione delle risorse in modo esclusivo, ma questo non è AGILE: è quello che nel project management tradizionale prende il nome di pianificazione forfettaria.
3. Applichiamo AGILE perché abbiamo uno Scrum Master che assegna e coordina i compiti del team
Questa è forse una delle contraddizioni più comuni. L'AGILE prevede un modello organizzativo PULL, non PUSH. Ciò significa che non esiste una figura preposta all'assegnazione di un compito (o task), ma è il team che deve autogovernarsi per offrire la massima efficienza e recepire i compiti in autonomia.
Un team con un buon grado di maturità e conoscenza del metodo sa come auto coordinarsi per smaltire al meglio il lavoro offrendo il miglior prodotto possibile. Inoltre, dall’applicazione della metodologia Scrum è previsto che lo Scrum Master ricopra un ruolo distinto rispetto al team e al Product Owner, ruolo che non è e non può mai essere quello di assegnare dei compiti.
Quando sentiamo parlare di AGILE e di agenzie che hanno abbracciato questo fantastico approccio al lavoro è quindi importante saper distinguere chi lo ha fatto per "ammaliare" i clienti con nuovi nomi e chi ha invece maturato la consapevolezza di un metodo facilitante.
In conclusione, alla frequente domanda "Tutti possono fare AGILE?", la nostra risposta è:
"Tutti possono dire di farlo. Alcuni lo fanno sul serio e sono davvero bravi... gli altri sono solo ottimi commerciali."