La storia di Agile affonda le radici nella pubblicazione del “Manifesto per lo Sviluppo del Software Agile”, composto da 12 principi fondamentali nel 2001. Senza dubbio, alcuni approcci Agile erano già apparsi prima di allora, ma solo questo documento ha sistematizzato e definito tali aspetti a tal punto da essere utilizzabili. Anno dopo anno, nuove aziende, specialisti IT e project manager si attengono al Manifesto. Emergono nuovi metodi e versioni del sistema di sviluppo agile.
Cos’è la metodologia Agile (flessibile)?
Agile è un modello di sviluppo interattivo in cui il software viene creato in modo incrementale fin dall’inizio di un progetto, a differenza dei modelli a cascata in cui il codice viene consegnato al termine del ciclo di lavoro.
La metodologia flessibile si basa sulla suddivisione dei progetti in piccoli pezzi operativi chiamati storie utente. In base alle priorità, i compiti vengono risolti all’interno di brevi cicli di due settimane (iterazioni).
I 12 principi che costituiscono la Metodologia Agile possono essere riassunti in 4 idee principali:
- Priorità alle persone e alla comunicazione rispetto a strumenti e processi;
- Priorità a un prodotto funzionale rispetto a una documentazione abbondante;
- Priorità alla collaborazione con i clienti rispetto alla conferma dei contratti;
- Priorità alla disponibilità ai cambiamenti rispetto al seguire il piano iniziale.
Metodi propri di Agile:
Scrum
Il termine Scrum è stato preso in prestito dal rugby, dove questa parola significa il metodo di gioco di squadra in cui tre linee vengono formate da ciascun avversario che tenta di afferrare la palla. Per un ri-approccio riuscito, non solo è essenziale una buona forma fisica: ogni giocatore scrum deve agire di concerto con gli altri, con chiara consapevolezza dell’obiettivo.
Questo metodo è utilizzato con successo da aziende come Microsoft, Yahoo, Siemens Healthcare. Un project manager di Amazon ha persino descritto un caso di introduzione di Scrum basato sull’esperienza acquisita.
Poiché Scrum è un framework per lo sviluppo, ogni esempio che segue può differire dal precedente.
Jeff Sutherland, l’autore del libro “Scrum. L’arte di fare il doppio del lavoro in metà tempo”, ha distinto 8 passaggi per utilizzare la metodologia:
- Selezionare il product owner che è consapevole dell’obiettivo del progetto e del risultato atteso.
- Organizzare un team — fino a 10 persone con le competenze necessarie per creare un prodotto operativo.
- Nomina il Scrum master che supervisionerà il flusso di lavoro del progetto e assisterà il team di progetto nell’affrontare le sfide.
- Creare il product backlog — per ciascun requisito del prodotto, stabilire priorità nella board Agile. In questo processo, il ruolo del product owner è essenziale, poiché raccoglie le richieste per il prodotto affinchè il team di backlog le valuti.
- Programmare sprint (iterazioni) — frammenti di tempo per completare catene definite di compiti.
- Organizzare incontri quotidiani di quindici minuti — chiedere a ciascun membro del team 3 domande: cosa ha fatto ieri, cosa farà oggi, cosa ostacola il completamento del compito.
- Effettuare revisioni delle parti operative del prodotto — coinvolgendo gli stakeholder in tali revisioni.
- Tenere retrospettive — discussione sui problemi con ricerca di soluzioni dopo ogni sprint. Applicare il piano di modifica risultante nel successivo sprint.
Retrospettiva in Agile
Scrum ha 4 elementi chiave:
- Product Backlog — elenco dei requisiti per il progetto
- Sprint Backlog — elenco dei requisiti da soddisfare nell’imminente sprint
- Sprint Goal — obiettivo dello sprint
- Sprint Burndown Chart — il diagramma che viene aggiornato man mano che i compiti vengono completati. Facilita la comprensione della dinamica e del livello di avanzamento del team nel progetto.
eXtreme Programming (XP)
Kent Beck, lo sviluppatore di questa metodologia, ha creato un metodo di programmazione estrema mirato a rispondere ai requisiti software volatili e a migliorare la qualità dello sviluppo.
È applicabile solo nel campo dello sviluppo software e si basa su 4 processi:
- codifica — secondo gli standard di layout comuni del team;
- test — i test vengono sostanzialmente creati dai programmatori prima di scrivere un codice che verrà testato;
- pianificazione — sia per la build finale che per le singole iterazioni. Queste ultime avvengono mediamente ogni due settimane.
- audizione — sia degli sviluppatori che di un cliente, per eliminare punti poco chiari e definire requisiti e valori.
Metodologie Crystal
Questa famiglia di metodologie sviluppata da Alistair Cockburn, uno degli autori del “Manifesto per lo Sviluppo del Software Agile”, è poco conosciuta in alcuni domini locali della gestione di progetti. Cockburn propone di fare la classificazione per colori, basata su un criterio come il numero di persone in un team: da 2 (Crystal Clear) a 100 (Crystal Red). I colori Marrone, Blu e Viola sono assegnati a progetti su larga scala.
I progetti Crystal devono conformarsi a 3 caratteristiche di base:
- spedizione veloce del codice operativo — evoluzione dell’idea per il modello iterativo nello sviluppo Agile.
- miglioramento tramite riflessione — una nuova versione software viene migliorata sulla base delle informazioni sulla versione precedente.
- interazione “osmotic” — innovazione di Alistair, una metafora per comunicazione e scambio di informazioni tra sviluppatori software all’interno di una stessa stanza.
Questa famiglia di metodologie è descritta in dettaglio nel libro “Crystal Clear: A Human-Powered Methodology for Small Teams” di Alistair.
Metodologia di Sviluppo Software Dinamico (DSDM)
Non solo una singola persona, né una squadra, ma un consorzio di 17 aziende britanniche ha lavorato allo sviluppo di DSDM. Proprio come la programmazione estrema, DSDM è utilizzato principalmente per creare software.
Il consumatore finale (utente) ha un ruolo speciale nel processo di sviluppo. Questo principio fondamentale è integrato dai seguenti principi di base:
- rilasci frequenti delle versioni operative del prodotto
- autonomia degli sviluppatori nelle decisioni
- test durante tutto il ciclo di lavoro.
DSDM è suddiviso in versioni che vengono aggiornate man mano che le tecnologie si sviluppano e appaiono nuovi requisiti di sviluppo software. Attualmente l’ultima è DSDM Atern rilasciata nel 2007, anche se la precedente (del 2003) è ancora in servizio.
All’inizio, il team considera la fattibilità dello sviluppo di un’applicazione e il suo ambito di utilizzo. Poi, il lavoro viene suddiviso in tre cicli interconnessi:
- ciclo del modello funzionale — creazione di documenti analitici e prototipi.
- ciclo di progettazione e ingegneria — messa in funzione di un sistema.
- ciclo di implementazione — distribuzione del sistema.
Sviluppo Driven dalle Caratteristiche (FDD)
Questa metodologia è emersa anche prima del “Manifesto per lo Sviluppo del Software Agile”.
Sebbene FDD utilizzi anche il modello di sviluppo iterativo, si differenzia da Agile nelle seguenti caratteristiche:
- maggiore attenzione alla modellazione preliminare
- maggiore (rispetto ad Agile) significato della stesura di report e grafici
- la metodologia è progettata per lo sviluppo aziendale.
Sviluppo Driven dalle Caratteristiche si compone delle seguenti fasi cicliche:
- Creazione di un modello generale — visione del progetto basata su dati preliminari.
- Sviluppo di un elenco di proprietà — simile al product backlog nella metodologia Scrum.
- Pianificazione per proprietà — la complessità delle proprietà viene valutata da ciascun membro del team.
- Per ciascuna proprietà — design e implementazione tecnica – la fase finale al termine della quale la proprietà si integra nel prodotto, e il ciclo si ripete.
Sviluppo Software Snello
Lo Sviluppo Software Snello è un insieme di principi di gestione snella (anziché una metodologia) che mirano ad aumentare l’efficienza del processo di sviluppo e a minimizzare i costi.
Questo insieme include i seguenti 7 principi fondamentali:
- eliminazione delle perdite — tutto ciò che non aggiunge valore al prodotto per il consumatore finale.
- formazione continua — lo sviluppo continuo di un team migliora le possibilità di adempimento efficiente dei compiti.
- prendere decisioni il più tardi possibile — si dà priorità a soluzioni deliberate, ben sviluppate e basate su conoscenze acquisite, piuttosto che a quelle spontanee.
- consegna rapida — questo è sostanzialmente il principio fondamentale del modello iterativo.
- rafforzamento del team — uno dei principi fondamentali del “Manifesto…” afferma che le persone e le loro interazioni sono più importanti di processi e strumenti. Un team di progetto è la migliore garanzia per il completamento riuscito dei compiti.
- integrità e qualità — è necessario realizzare un prodotto originale di alta qualità per non sprecare tempo e risorse in ulteriori test e correzione di bug.
- visione di un quadro complessivo — un progetto non può essere suddiviso in parti separate senza comprendere lo stato attuale dello sviluppo, così come le finalità, il concetto e le strategie del software sviluppato.
Versioni delle metodologie di sviluppo Agile
Modellazione Agile (AM)
La Modellazione Agile è un insieme di valori, principi e pratiche per la modellazione software.
AM è utilizzato come un elemento nelle metodologie di sviluppo software complete — ad esempio, nella programmazione estrema o nello Sviluppo di Applicazioni Rapide.
La Modellazione Agile ha le seguenti caratteristiche fondamentali:
- interazione efficace tra le parti interessate del progetto;
- ricerca di sviluppare la soluzione più semplice di tutte quelle possibili, che soddisfi tutti i requisiti;
- ricezione continua di feedback;
- coraggio di prendere decisioni e di esserne responsabili;
- realizzare di sapere assolutamente tutto.
Processo Unificato Agile (AUP)
AUP è una versione semplificata di un’altra metodologia di sviluppo software — il Processo Unificato Razionale (RUP). Dal 2012, è stato sostituito dal Disciplined Agile Delivery (DAD), ma AUP è ancora presente qua e là.
Scott Ambler, l’autore della metodologia, ha evidenziato i seguenti punti chiave nel Processo Unificato Agile:
- Il tuo team sa cosa fa;
- La semplicità viene prima di tutto.
- Conformità ai principi della metodologia di sviluppo flessibile.
- Focus sulle attività di valore per il progetto.
- Indipendenza nella scelta degli strumenti.
- Configurazione personalizzata di AUP per i requisiti di un progetto specifico.
Metodo Dati Agile (ADM)
ADM è un insieme di metodologie di sviluppo software iterative che enfatizzano la formazione dei requisiti e delle soluzioni in un progetto attraverso la collaborazione di diversi team. Come AUP, questa metodologia non è autonoma.
Il principio del Metodo Dati Agile è definito da sei fondamentali:
- Dati — la base per la creazione di qualsiasi applicazione.
- Problemi in un progetto — possono essere individuati solo se l’obiettivo del progetto e il concetto sono chiaramente compresi.
- Gruppi di lavoro — oltre al team base di sviluppatori, ci sono gruppi aziendali che supportano altri gruppi di lavoro.
- Unicità — non esiste metodologia perfetta, quindi ogni progetto richiede di combinare strumenti provenienti da metodologie diverse.
- Lavoro di squadra — il lavoro congiunto è molto più efficiente dell’attività individuale.
- “Sweet spot” — ricerca della soluzione ottimale di un problema (“sweet spot”) evitando estremi.
Processo Unificato Essenziale (EssUP)
È stato sviluppato da Ivar Jacobson, uno scienziato svedese, per migliorare il Processo Unificato Razionale.
EssUP utilizza il concetto di pratica che include:
- scenario d’uso — descrizione del comportamento di un sistema.
- sviluppo iterativo — creazione di pezzi operativi del codice in brevi cicli nell’arco di poche settimane.
- pratiche di team — mirate a unire il team e ad aumentarne l’efficienza.
- pratiche procedurali — ad esempio, “Pensa in grande, inizia in piccolo” oppure “Coinvolgi gli stakeholder nei processi aziendali”.
In una forma o nell’altra, tutte le pratiche sono presenti nelle metodologie RUP e CMMI, nonché nella metodologia di sviluppo flessibile.
Getting Real (GR)
Questa è una metodologia efficace per startup e team all’avvio, che suggerisce il massimo utilizzo di caratteristiche specifiche proprie di piccoli progetti e aziende, come la mobilità, la flessibilità, la ricerca di nuove soluzioni, l’assenza di una gerarchia rigida e confusa, ecc.
Jason Fried e David Hansson, fondatori della 37signals Company (attualmente Basecamp), hanno definito Getting Real come un sistema per risolvere compiti fattibili, che è infine semplice, comprensibile e funzionale.
GR è un mix di una dozzina di strumenti di sviluppo agile utilizzati per minimizzare i seguenti aspetti:
- alternative
- opzioni e impostazioni
- struttura aziendale
- riunioni
- promesse.
Una tale concezione straordinaria non è diventata mainstream, sebbene alcuni dei suoi elementi siano stati fusi in altre metodologie.
OpenUP (OUP)
Questa è una metodologia di sviluppo software indipendente dagli strumenti e priva di una struttura rigida, che fornisce tali pratiche:
- misurare la velocità di operazione del team;
- tenere riunioni quotidiane e retrospettive al termine delle iterazioni;
- concetto di micropassi e test anticipati utilizzando checklist;
- metodologia di Sviluppo Basato su Modelli Agile (AMDD).
Queste pratiche vengono realizzate sulla base di quattro principi:
- riconciliazione degli interessi e raggiungimento della visione comune nel lavoro congiunto;
- miglioramento continuo attraverso feedback costante;
- focus sull’architettura dell’applicazione nelle fasi iniziali per minimizzare i rischi;
- maximizzazione del valore per il consumatore finale.
Indicatori Agile
Data la diversità degli strumenti, delle pratiche, dei metodi e delle metodologie Agile, dobbiamo scegliere uno strumento che ci aiuti a determinare quanto siano efficaci ciascuno di essi.
Le metriche vengono utilizzate come tale strumento.
Per la maggior parte dei progetti, queste 4 categorie di metriche saranno sufficienti:
- Produttività — si associa alle metriche Velocity e WIP. La prima potrebbe non adattarsi a tutti i progetti, poiché si misura il numero di compiti eseguiti per iterazione, ma le iterazioni non sono uguali. La metrica Work-in-Progress definisce il limite dei compiti in diverse fasi: e più è alto, peggio va;
- Previsione — la metrica Capacity, che consiste nel determinare il numero di ore perfette disponibili nel prossimo sprint. Di conseguenza, è possibile capire la quantità di tempo disponibile per il lavoro, il grado di efficienza nel completamento dei compiti, così come pianificare il numero di compiti per uno sprint;
- Qualità — ad esempio, l’indice di stabilità dei requisiti che viene calcolato dalla formula = (Numero totale di requisiti aziendali originali + Numero di requisiti alterati nel tempo fornito + Numero di requisiti aggiunti + Numero di requisiti sottratti) / (numero totale di requisiti originali). Questa metrica è utilizzata per determinare il tempo speso nel rielaborare i compiti;
- Valori — questa metrica viene calcolata individualmente in ogni caso, a seconda del formato del progetto. Ad esempio, nella startup AirBnb, il numero di foto di alta qualità scaricate è stata scelta come metrica per determinare il valore finale del prodotto per gli utenti. Poiché questo numero aumentava, il numero di utenti cresceva in proporzione.
Le regole applicabili alle metriche sono le stesse di quelle per altri strumenti Agile.
Non esiste una singola metrica che sia univocamente corretta e pertinente per il tuo progetto.
Le metriche devono essere riviste continuamente, quelle obsolete devono essere eliminate e nuove devono essere aggiunte all’occorrenza. Dovrebbero essere comprensive e disponibili per l’intero team senza trasformarsi in un obiettivo in sé. Le metriche per il solo gusto delle metriche sono una cattiva soluzione.
Smontare Miti: Agile
La popolarità della metodologia di sviluppo flessibile ha giocato un brutto tiro e i miti su determinati aspetti di Agile possono essere visti anche su portali specializzati. Facciamo chiarezza!
Mito N.1: Agile si adatta a tutti i progetti.
Questo è il malinteso più assertivo. Un singolo metodo Agile di per sé non apporterà valore al prodotto, né motiverà il team.
Mito N.2: Agile sfavorisce la documentazione.
La metodologia di sviluppo Agile non sfavorisce la documentazione, nega la documentazione come obiettivo in sé. Quando si tratta di selezionare la documentazione come mezzo di comunicazione, Agile favorisce effettivamente la comunicazione personale.
Mito N.3: Agile e pianificazione sono incompatibili.
Questo mito è contestato da eventi di pianificazione quotidiani con stand-up di 10 minuti, così come da pianificazioni iterative che si svolgono ogni due settimane, riunioni sprint, ecc.
Mito N.4: Agile richiede molte rielaborazioni.
La metodologia di sviluppo software Agile prevede la rielaborazione in due forme: rielaborazione dei requisiti (gli utenti capiscono ciò di cui hanno davvero bisogno) e rielaborazione del software (i team di sviluppatori trovano modi migliori per scrivere e progettare applicazioni). Ma questo è il caso che si incontra anche in altre metodologie! Inoltre, una novità Agile come il modello iterativo serve a ridurre l’influenza negativa della rielaborazione.
Vantaggi e svantaggi dell’uso di Agile
Vantaggi:
- coinvolgimento degli stakeholder — il team diventa più capace di comprendere i requisiti del cliente. Inoltre, la consegna precoce e frequente del software aumenta la fiducia degli stakeholder nel team di progetto e rende il coinvolgimento nel progetto più profondo.
- consegna precoce e prevedibile — il modello di sviluppo basato su iterazioni (in brevi periodi che vanno da 1 a 6 settimane) offre flessibilità e stimola il rilascio del prodotto.
- focus sul valore commerciale — collaborazione con il cliente assicura che il team comprenda come rendere il prodotto di valore per il consumatore finale.
- miglioramento continuo della qualità — test durante ogni iterazione con la suddivisione della build finale in parti separate del codice operativo facilitano il miglioramento e l’eliminazione degli errori software prima del rilascio del prodotto finale.
Svantaggi:
- requisiti rigorosi per il team e i clienti — senza una stretta interazione tra il team di progetto e gli utenti, è impossibile garantire il rilascio di un prodotto di alta qualità con alto valore. Inoltre, l’abbondanza di strumenti e metodi Agile presuppone che il team debba essere esperto per la loro corretta introduzione.
- non adatto per outsourcing e per progetti in cui i partecipanti interagiscono tra loro solo in modalità online.
- il rischio che la versione finale del software non venga mai rilasciata — sorprendentemente, questo svantaggio deriva da vantaggi di Agile come lo sviluppo iterativo e il miglioramento continuo del prodotto.
- fallisce senza una chiara visione degli obiettivi aziendali del progetto — poiché un team Agile è guidato dagli stakeholder, è impossibile sviluppare un prodotto senza un obiettivo e un concetto chiaramente definiti.
Applicazioni
Non tutti i servizi o programmi di gestione progetti saranno adatti per la gestione progetti basata su Agile, poiché ciascuno di essi ha le sue caratteristiche specifiche.
Se la tua azienda è un’agenzia di marketing & pubblicità, design, SEO o digitale, puoi utilizzare il servizio saas di Worksection affinché l’intero team vi operi. Finora siamo stati raccomandati da COXO Digital, Royal ® Advertising e Prozorro.
Ecco un paio di suggerimenti per configurare Agile in Worksection:
- configurare tag e stati che sono necessari per il lavoro nella tua azienda. Gli stati possono essere: in corso, controllo, completato, rielaborazione necessaria, critico, funzionalità, pagamento dovuto. I tag spesso sono: layout, testing, produzione, concetto, codice.
- creare il backlog del progetto e lo sprint del progetto.
- creare compiti e checklist preliminari, schizzi, ecc. nel backlog.
- durante gli incontri, determinare i compiti dello sprint e trasferirli dal backlog allo sprint.
- utilizzare l’accesso ospite dei clienti ai compiti in modo da avere sempre feedback coordinato e pertinente sul progetto.
- contrassegnare le persone responsabili nei compiti affinché ciascun collega sappia la sua area di responsabilità e si senta coinvolto nell’esito dello sprint.
Verdetto
Grazie alla metodologia di sviluppo software agile, i piccoli team di progetto guadagnano la massima efficienza. L’Agile si realizza attraverso altri metodi flessibili come Scrum, XP, Lean, ecc.
Non può essere implementata in fretta, da un team inesperto, in un breve lasso di tempo,
ma una volta introdotta, Agile migliorerà l’interazione tra IT e business, stimolerà il rilascio del prodotto sul mercato e aumenterà il valore del prodotto per il consumatore finale.