Agile in JIRA – Due chiacchiere su Agile
In questo primo post, faremo un giro virtuale sui concetti base e sulla storia su Agile. Parleremo del Manifesto Agile e dei concetti fondamentali.
In principio era Waterfall…..
Prima dell’avvento di Agile, lo sviluppo software seguiva le indicazioni di Waterfall:
Come mostrato dalla immagine, che sicuramente ci sembrerà familiare, il processo è sequenziale. Si parte dalla analisi delle necessità del nostro cliente fino ad arrivare alla implementazione e quindi al deploy e relativa manutenzione.
Questa metodologia è sicuramente molto semplice da usare e di facile apprendimento, ma presenta una serie di …. difetti, che cercheremo di dettagliare:
- Non si adegua ai cambiamenti.
- Molto rigida
- Richiede molto tempo dalla analisi al deploy
Non è quello che volevo…..
Questa è la frase che quasi sempre ci siamo sentiti dire, dopo tantissimi sforzi e tantissima fatica per realizzare il tutto, a volte con dei tempi molto stretti. Molto spesso il cliente, pieno di speranza, arrivava ad avere un prodotto che non sempre rispecchiava le sue aspettative.
In aggiunta, abbiamo anche la delusione degli sviluppatori: Anche loro dicono che hanno seguito le istruzioni dettate dell’analisi.
Una piccola precisazione: non voglio assolutamente criminalizzare la metodologia Waterfall. Questa metodologia è valida nonché semplice da apprendere, ma non sempre è indicata in determinate situazioni. A tale scopo sono stati introdotti i concetti di Agile che ben si prestano nella realizzazione di un software (e non solo) destinato a crescere. Vediamo in primo dettaglio 😀
Cosa introduce Agile?
Agile introduce diversi nuovi concetti che sono riassunti nel Manifesto Agile, come mostrato nella seguente figura:
Questi concetti sono da considerare come le nostre tavole della legge dei 10 comandamenti. Sono le fondamenta di tutto l’approccio. Si da maggiore importanza ai 4 concetti espressi, in particolare alle parole a sinistra in quanto sono i pilastri su cui ci poggiamo.
Il tutto si sviluppa in ben 12 punti, che andiamo a dettagliare:
- La nostra massima priorità è soddisfare il cliente
rilasciando software di valore, fin da subito
e in maniera continua.
- Accogliamo i cambiamenti nei requisiti,
anche a stadi avanzati dello sviluppo.
I processi agili sfruttano il cambiamento
a favore del vantaggio competitivo del cliente.
- Consegnamo frequentemente software funzionante,
con cadenza variabile da un paio di settimane a un paio di mesi,
preferendo i periodi brevi.
- Committenti e sviluppatori devono lavorare insieme
quotidianamente per tutta la durata del progetto.
- Fondiamo i progetti su individui motivati.
Diamo loro l’ambiente e il supporto di cui hanno bisogno
e confidiamo nella loro capacità di portare il lavoro a termine.
- Una conversazione faccia a faccia
è il modo più efficiente e più efficace per comunicare
con il team ed all’interno del team.
- Il software funzionante è il principale metro di misura di progresso.
- I processi agili promuovono uno sviluppo sostenibile.
Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado
di mantenere indefinitamente un ritmo costante.
- La continua attenzione all’eccellenza tecnica
e alla buona progettazione esaltano l’agilità.
- La semplicità – l’arte di massimizzare la quantità
di lavoro non svolto – è essenziale.
- Le architetture, i requisiti e la progettazione
migliori emergono da team che si auto-organizzano.
- A intervalli regolari il team riflette su come
diventare più efficace, dopodiché regola e adatta
il proprio comportamento di conseguenza.
Fondamentalmente, cambiamo il nostro modo di ragionare e di approcciare i problema: Non abbiamo dei tempi biblici per rilasciare il software o dei passi rigidi per i quali blocchiamo lo sviluppo. Identifichiamo le varie funzionalità che compongono l’applicativo e le andiamo a rilasciare al più ogni due/quattro settimane.
Confronto continuo, semplicità sulle fasi di sviluppo, accoglimento del cambiamento come qualcosa di positivo. Costruiamo l’applicativo un pezzo alla volta, facendolo crescere in modo da aumentare le potenzialità del gruppo di lavoro.
Abbiamo anche un vantaggio molto importante, o effetto collaterale se vogliamo: La QUALITA’ aumenta perché:
- Si rilascia sempre un software funzionante, anche perché ne rilasciamo sempre una porzione per volta
- il cliente controlla sempre se rispetta le richieste e verifica subito se effettivamente le sue esigenze sono ricoperte.
Interazione faccia a faccia costante dei vari elementi del team di sviluppo. Come gli ingranaggi di una grande macchina, i vari elementi del team di sviluppo devono lavorare in sintonia ed in tranquillità, dando il massimo di loro stessi. Questo significa che la comunicazione deve essere sempre aperta e costante. 🙂
In aggiunta cambiano i concetti di responsabile e di ruoli, come esiste in Waterfall. Non un unico responsabile, che comanda e che risponde di tutto, ma tutti sono responsabili di una intera sprint e del successo/insuccesso.
Ed il cliente?
Lo coinvolgiamo totalmente, come anticipato in precedenza. Ad ogni rilascio gli viene viene richiesto un feedback, un contributo sulle operazioni e che gli da la possibilità di verificare quanto pronto.
In questo modo gli diamo sempre la possibilità di poter verificare direttamente i progressi, vedere l’applicativo crescere e … importantissimo …. non ce lo troviamo tra capo e collo ogni 5 minuti che chiede: Quando sarà pronto l’applicativo??
Il Cliente diventa un valido alleato nello sviluppo del software.
Differenze con il Waterfall?
Diamo una occhiata a questa immagine:
che ci fornisce un confronto tra le due metodologie: Waterfall Vs Agile. Vediamo che Agile meglio si adatta alle situazioni in cui il cambiamento è alto. I problemi vengono scoperti molto più velocemente, anche grazie all’intervento del cliente che, collaborando a stretto gomito con gli sviluppatori, aiutano nella risoluzione.
Kanban, Scrum, scrumban, …
Sono le varie metodologie che sono nate e si sono sviluppate. Queste saranno esaminate, leggermente in dettaglio, nei prossimi post dedicati a questa serie AGILE in JIRA.
References
Suggeriamo le seguenti letture:
ma non sono le uniche. Qualsiasi contributo è sicuramente ben accetto e ringrazio fin da adesso tutti coloro che daranno il loro contributo.
Ringraziamenti
Ringraziamenti per l’aiuto a Michael Forni, che è stato un valido supporto nella redazione di questi articoli. Se volete chiedere, domandare o semplicemente fare una domanda spot, riporto di seguito i suoi contatti:
