Pensare “Agile”
Pensare Agile – La metodologia Agile è fortemente focalizzata sul prodotto da realizzare piuttosto che sul processo per realizzarla e considera le variabili “Qualità”, “Tempo” e “Costi” non negoziabili spostando la flessibilità verso le Funzionalità del prodotto.
Detto così sembra essere contraddittorio ma in realtà l’obiettivo è quello di realizzare un prodotto che soddisfa il cliente per le sue caratteristiche essenziali e non in tutte le funzionalità.
Il gruppo di lavoro
Siccome bisogna essere agili, il gruppo di lavoro deve essere piccolo (5/10 membri) e i suoi componenti devono essere competenti, autonomi e focalizzati sul progetto (quindi la qualità e la disponibilità delle persone coinvolte deve essere elevata).
Membri essenziali del team sono (le terminologie variano tra le metodologie):
- Project Manager (in Scrum, Scrum Master) ha un ruolo di coordinamento e il suo obiettivo fondamentale e mettere in condizione il Team di Sviluppo di operare a pieno regime
- Business Analyst ha il compito di tradurre i requisiti di Business in funzionalità del prodotto e passare queste allo sviluppo
- Business Ambassador (in Scrum, Product Owner) ha il compito di definire insieme al Business Analyst i dettagli del prodotto fornendo la visione di dettaglio dal lato del Business
- Team di Sviluppo è il gruppo di lavoro che fisicamente realizza il prodotto.
Attorno a questo gruppo possono operare anche altre figure.
Le specifiche del prodotto
Nella metodologia Agile, la realizzazione del prodotto è lo scopo primario, quindi tutte le attività che non sono focalizzate su questo obiettivo vengono ridotte al minimo.
Qualcuno interpreta questo principio come “progetto senza documentazione”: niente di più lontano dal vero. Nei progetti Agili si documenta il prodotto in ogni sua vista ma lo si fa usando un approccio molto pragmatico. I requisiti sono descritti in “Stories” che raccontano in linguaggio non formale cosa deve fare il prodotto e i criteri di verifica. Le “Stories” sono raccolte in “Epic” e vengono elencate nel “Product Backlog”.
Dalle “Stories”, che vengono discusse e approfondite in incontri plenari, si generano i “Task” che sono assegnati al team di sviluppo.
La realizzazione del prodotto
Il prodotto non viene realizzato con un unico processo ma attraverso una serie di cicli di rifinitura (detti “Sprint”) che da un lato aggiungono nuove funzioni, dall’altro raffinano quelle esistenti.
Gli Sprint hanno durata prefissata (2/4 settimane) e hanno un elenco di Task da realizzare che vengono raccolti dal Project Manager in base alla priorità indicate dal Business Analyst e dal Business Ambassador (“Sprint plan”, “Sprint Backlog”).
Il Team di Sviluppo sviluppa le funzionalità del prodotto realizzando i Task presenti nello Sprint Backlog senza un piano preciso ma in base alla effettiva disponibilità e capacità dei suoi membri, garantendo quindi una occupazione a pieno regime .
Il processo di sviluppo
Ogni giorno il team di sviluppo si allinea (“Daily meeting”) e condivide il piano di lavoro ed evidenziando eventuali criticità (“Impediments”)
Ogni Task parte con stato “To do” e passa in “Doing” per poi finire in “Done” dopo averlo verificato sulla base dei criteri di accettazione indicati. L’effetto che si ottiene è quello dello svuotamento della lista dei Task che può essere controllato con una lavagna che conta i Task da risolvere all’interno dello sprint (“Burndown chart”).
Finita la durata dello Sprint le funzionalità vengono presentate (“Demo”) al Business Analyst e al Business Ambassador che verifica cosa è stato effettivamente prodotto. Quindi si fa una review dello Sprint: si vede lo stato di risoluzione dei Task, si valuta la effettiva capacità, si discute dei problemi incontrati e si prepara lo Sprint successivo.
In base al piano dei rilasci (un Rilascio può contenere le funzioni di diversi Sprint) e all’effettivo stato dello sviluppo, si rilasciano le funzionalità per un UAT esterno al team.
Confronto tra metodologia Agile e Waterfall (approccio tradizionale)
Non esiste un modo migliore per gestire i progetti, entrambi gli approcci sono validi e consolidati negli anni, tuttavia può essere utile una tabella comparativa che permette anche di capire quando è conveniente usare un approccio o un altro.
| Agile | Tradizionale | |
| Soluzione | Miglioramento continuo delle funzionalità | Completamente prevedibile e definibile |
| Pianificazione | Numerosi rilasci ravvicinati | Definita a priori in ogni sua fase |
| Controllo | Demandato al gruppo di lavoro | Centralizzato su PM |
| Priorità risultati | Soluzione | Obiettivi |
| Gruppi di lavoro | Stabili con grande autonomia | Dinamici e con scarsa autonomia |
| Stile di gestione | Leadership e collaborazione | Controllo completo |
| Comunicazione | Informale e continua | Formale e pianificata |
| Ruolo Cliente | Critico | importante |
Quando usare una metodologia Agile
Pensare Agile garantisce flessibilità al cambiamento ma questa caratteristica ha dei costi che il Business deve avere sempre presente:
- E’ indispensabile che vi sia una stretta e continua collaborazione tra Business e Team di Sviluppo in quanto la definizione dei dettagli delle funzionalità avviene in modo altamente destrutturato per garantire velocità e risparmio di tempo.
- Può accadere che le funzionalità a più bassa priorità non vengano realizzate perché le risorse non erano sufficienti. Ecco perché la gestione delle priorità assume una importanza fondamentale come il ruolo e le capacità del Business Analyst.
L’esperienza del Project Manager può fare la differenza tra un progetto di successo o meno e il pensare Agile è il metodo che permette l’ottimizzazione delle performance del team