In questo tipo di approccio, apportare change request diventa complicato e costoso, una volta che la soluzione viene rilasciata.
La metodologia Agile è un’alternativa a questo approccio.
Ma che cosa è? In cosa consiste?
Termine sempre più diffuso, molti si entusiasmano solo nel sentirlo nominare, magari non sapendo realmente in che cosa consiste.
Scrum, Kanban, Lean, Scrum Master, Product Owner… tutto cool, ma a volte questi termini possono creare confusione. Facciamo un po’ di chiarezza: sotto ti raccontiamo cos’è l’Agile in poche parole, e quali sono i suoi componenti principali.
Se lo descriviamo con semplicità, possiamo dire che l’Agile è un metodo che consente di iniziare a costruire prima che il sistema sia definito nei minimi dettagli.
Questa metodologia si basa sulle iterazioni e si applica perfettamente allo sviluppo software in quanto consente di apportare modifiche, sia piccole che grandi, alle funzioni e all’architettura, durante il progetto.
Scrum e Kanban sono modi per gestire dei progetti in cui si usa l’Agile.
Scopriamo il team
Dobbiamo essere agili, per questo i team devono essere piccoli, con membri autonomi e focalizzati.
Ecco gli essenziali:
Scrum Master che coordina e aiuta il team di sviluppo a operare al massimo delle possibilità
- Business Analyst, che traduce i requisiti di business in funzionalità, passandole al team di sviluppo
- Product Owner, che con il Business Analyst definisce i dettagli del progetto in base alla propria visione operativa e degli obiettivi di business
- Team di sviluppo, che realizza la soluzione software
Se vuoi saperne di più sulle potenzialità dei team multidisciplinari, ti invito a leggere questo approfondimento dedicato: The “Big Bang” Team: amplia la tua visione con team multidisciplinari
Specifiche e modo di documentare
Realizzare il prodotto è lo scopo principale, e tutto quello che non è inerente a questo viene ridotto al minimo.
Questo significa non scrivere la documentazione? Assolutamente no.
Nei progetti agili si “racconta” tramite le Stories, che racchiudono, in un linguaggio informale, tutto quello che dovrebbe fare il prodotto.
Tutte le Stories vengono raccolte in Epic ed elencate nel Backlog.
Backlog, la risorsa fondamentale del tuo progetto
Un backlog è una lista ordinata dei casi d’uso, funzionalità e di tutto ciò che vorresti che facesse il tuo software.
E’ un punto base per condividere i contenuti con tutti gli stakeholder e supporta il cliente nella revisione delle richieste e delle priorità.
I backlog possono essere su un supporto digitale, oppure, come accade di vedere su molte immagini, con una serie di post-it su una board dedicata alla gestione dei task.
Ma come funziona?
E’ semplicissimo: uno sviluppatore sceglie un’attività dal backlog e inizia a lavorarci.
Quando questa viene completata, la si segnala come tale e si prosegue scegliendo un’altra attività… finchè il progetto non è terminato!
E’ necessario precisare che il backlog subisce molte variazioni durante tutto lo sviluppo: se mantenuto con costanza e precisione, diventa un requisito fondamentale per la gestione del progetto.
E gli sprint?
Come abbiamo già detto l’Agile si basa sulle iterazioni. Per questo lo sviluppo/implementazione della soluzione software è suddiviso in periodi di iterazione che vanno dall’una alle quattro settimane, chiamati Sprint.
Dopo ogni iterazione, il team di sviluppo ed il Product Owner e/o il Business Analyst di incontrano in sessioni per la revisione dello sprint, discutere su quelle precedenti e pianificare la prossima.
Ogni mattina, daily meeting e caffè caldo per colazione
Ogni giorno il team di sviluppo si incontra per condividere il piano di lavoro, evidenziando eventuali impediments, ovvero le criticità. Questi momenti sono chiamati Daily meeting.
Ogni task, da to do, va in doing per arrivare al done, dopo i test e il controllo che sia conforme alle richieste.
Qui viene utilizzata la board che abbiamo citato sopra.
Proseguiamo il “viaggio”
Terminato lo Sprint, viene presentata la demo al Product Owner, pronto a dare un feedback su quanto sviluppato e a confrontarsi in merito all’incremento del progetto, quali task sono stati fatti e quali no, e le relative motivazioni. Questa fase è chiamata Review.
Successivamente alla demo, arriviamo alla Retrospective, ovvero il momento in cui il team di sviluppo ed il Product Owner si confrontano, “riflettono”, su come sia andato lo Sprint precedente.
Cosa è andato bene? Cosa è andato peggio? Quali soluzioni potremmo adottare in futuro?
Queste ed altre sono le domande che si pongono, avendo come scopo di evitare i problemi riscontrati o migliorare qualcosa che non è stato affrontato al meglio (qui citiamo il concetto di continuous improvement).
Ecco che arriviamo alla preparazione del prossimo Sprint, ovvero lo Sprint Planning: un momento dove team e Product Owner definiscono lo Sprint Backlog successivo, l’insieme di task che il team si impegna ad eseguire.
Si arriva quindi ad un piano definito per i rilasci, che può anche comprendere funzionalità di diversi Sprint.
Concludendo…
Scegliere di adottare l’Agile non significa imparare tecniche nuove, ma introdurre un nuovo approccio mentale.
La scommessa di questo metodo è che creando uno sviluppo incentrato sulle persone e sulle iterazioni, sia possibile ottenere migliori risultati. E questo significa giocare per vincere.
Come dopo ogni Review degna di questo nome, ci chiediamo: quale sarà il prossimo passo?
Per noi, sicuramente l’obiettivo di creare valore per il cliente, tramite la collaborazione e la comunicazione.
“ La collaborazione col cliente più che la negoziazione dei contratti ”
Come definito nel Agile Manifesto, che puoi leggere qui.
Vuoi sapere di più su di noi? Visita la sezione dedicata e restate sintonizzati per altri approfondimenti, tramite la nostra sezione Insights oppure sulla nostra pagina Linkedin.
