La metodologia agile è un modo di gestire i progetti, soprattutto quelli software, che consegna il lavoro in brevi iterazioni, raccoglie feedback in modo continuo e adatta il piano man mano che il team impara. Si basa sui quattro valori e sui dodici principi del Manifesto Agile e si applica attraverso framework come Scrum, Kanban e, su larga scala, SAFe.
Questa guida spiega cosa significa agile in pratica: valori e principi, Scrum, Kanban e SAFe a confronto, come funziona uno sprint, quali metriche contano, l'agile nei contratti a prezzo fisso e con lo sviluppo assistito dall'IA. Chiude con il modo in cui WWG ha portato l'agile in tutta l'azienda e una breve checklist di adozione.
TL;DR / In sintesi
- Agile è una mentalità prima che un processo: si parte da una comprensione "abbastanza buona", si consegna qualcosa che funziona, poi si ispeziona e si adatta.
- Il Manifesto Agile (2001) fissa quattro valori e dodici principi; Scrum, Kanban e SAFe sono framework che li mettono in pratica.
- Scrum lavora in sprint fissi di un mese o meno, Kanban in un flusso continuo con lavoro in corso limitato, SAFe coordina molti team su un unico Agile Release Train.
- Le metriche utili descrivono flusso e risultati (cycle time, throughput, software funzionante), non quanto sono occupate le persone.
- L'agile funziona anche nei contratti a prezzo fisso, se tempi e budget sono fissi e l'ambito è prioritizzato, e resta valido quando parte del codice lo scrive l'IA.
Cos'è la metodologia agile?
Agile è una metodologia di gestione dei progetti guidata da una serie di principi e da una mentalità che favorisce la capacità di cambiare strategia rapidamente e di migliorare progressivamente. Invece di prevedere ogni elemento del progetto in anticipo, il team parte da una comprensione "abbastanza buona", consegna presto e si adatta mentre procede.
Il valore fondamentale della gestione agile dei progetti è il concetto di "ispezione e adattamento": le modifiche dell'ultimo minuto sono benvenute in qualsiasi fase del progetto, e i cambiamenti che portano valore diventano particolarmente preziosi. Il team verifica regolarmente ciò che ha costruito e come lavora, poi adatta prodotto e processo.
L'agile è nato tra gli sviluppatori software, ma si è diffuso ad altri settori. Oggi lo usano manager del settore bancario, creativi delle agenzie, personale medico, fondatori di start-up, professionisti del marketing e responsabili delle risorse umane. In WWG lo applichiamo in ogni progetto di sviluppo software su misura.
Quali sono i quattro valori e i dodici principi del Manifesto Agile?
Il Manifesto Agile, scritto nel 2001 da diciassette professionisti del software, fissa quattro valori. Gli individui e le interazioni contano più dei processi e degli strumenti, il software funzionante più della documentazione esaustiva, la collaborazione col cliente più della negoziazione dei contratti, e rispondere al cambiamento più che seguire un piano.
Le voci a destra conservano il loro valore, ma quelle a sinistra contano di più. I dodici principi traducono i valori in regole di lavoro e si possono raggruppare in quattro temi, ognuno dei quali è un test da applicare al proprio team:
- Consegnare valore presto e spesso: soddisfare il cliente con consegne anticipate e continue, rilasciare software funzionante frequentemente (da un paio di settimane a un paio di mesi, preferendo i tempi brevi) e considerarlo la misura principale del progresso.
- Accogliere il cambiamento: accettare requisiti che cambiano, anche a sviluppo avanzato, perché il cambiamento può diventare un vantaggio competitivo per il cliente.
- Lavorare insieme: business e sviluppatori collaborano ogni giorno, le persone motivate ricevono fiducia per portare a termine il lavoro e la conversazione faccia a faccia è il modo migliore per comunicare.
- Restare sostenibili e semplici: mantenere un ritmo costante, curare l'eccellenza tecnica, massimizzare il lavoro non fatto, affidarsi a team auto-organizzati e riflettere regolarmente su come migliorare.
In cosa l'agile è diverso dal modello a cascata?
Il modello a cascata pianifica tutto il progetto all'inizio e poi attraversa fasi fisse in sequenza: requisiti, progettazione, sviluppo, test e rilascio. L'agile consegna in cicli brevi, ognuno dei quali contiene tutte queste attività. La cascata si adatta a requisiti stabili e ben compresi; l'agile a progetti in cui requisiti o mercato probabilmente cambieranno.
Molte aziende preferiscono l'agile perché la cascata richiede più preparazione e risorse: ogni requisito va documentato prima di iniziare. Questa impostazione iniziale ritarda spesso l'avvio e allontana il primo rilascio.
Agile o Metodologia a cascata: quale è meglio per te? by octalsoftware
Che differenza c'è tra Scrum, Kanban e SAFe?
Scrum, Kanban e SAFe sono framework che applicano i principi agili in modi diversi. Scrum organizza il lavoro di un team in sprint fissi con ruoli ed eventi definiti. Kanban gestisce un flusso continuo di lavoro rendendolo visibile e limitando il lavoro in corso. SAFe porta l'agile su molti team che pianificano e consegnano insieme su un Agile Release Train.
| Scrum | Kanban | SAFe | |
|---|---|---|---|
| Unità di lavoro | Sprint di un mese o meno | Flusso continuo di elementi di lavoro | Planning Interval di 8-12 settimane, composto da iterazioni |
| Ruoli | Product Owner, Scrum Master, Developers | Nessun ruolo prescritto | Aggiunge Release Train Engineer, Product Management, Business Owner e architetti |
| Pianificazione | Sprint Planning all'inizio di ogni sprint | Il lavoro si prende quando c'è capacità | PI Planning per tutto il treno, poi pianificazione di iterazione per team |
| Controllo principale | Sprint Goal e Definition of Done | Limiti al lavoro in corso | PI objectives e ART planning board |
| Quando conviene | Un team di prodotto con un responsabile chiaro | Supporto, operations e team con domanda imprevedibile | Più team con dipendenze condivise |
I framework si possono combinare: un team Scrum può usare una board Kanban e i team SAFe lavorano con Scrum o Kanban all'interno del treno. Se più team devono pianificare insieme, la nostra guida al PI Planning spiega come lo fa SAFe.
Come funziona uno sprint in pratica?
Uno sprint è un periodo fisso di un mese o meno in cui un team Scrum trasforma elementi del backlog in un incremento utilizzabile. Inizia con lo Sprint Planning, prevede un Daily Scrum di quindici minuti e termina con la Sprint Review su ciò che è stato costruito e la Sprint Retrospective su come ha lavorato il team.
Secondo la Scrum Guide, lo Scrum Team è composto da uno Scrum Master, un Product Owner e i Developers. Il Product Owner ordina il Product Backlog e massimizza il valore del prodotto, i Developers creano l'incremento e lo Scrum Master è responsabile di introdurre Scrum e di aiutare team e organizzazione a comprenderlo e usarlo.
Lo Sprint Planning dura al massimo otto ore per uno sprint di un mese, e di solito meno per sprint più brevi. Qualunque sia la durata scelta, va mantenuta costante, perché un ritmo stabile rende affidabili pianificazione e previsioni.
Quali metriche mostrano se un team agile funziona bene?
Le metriche agili utili descrivono flusso e risultati. Il cycle time mostra quanto tempo richiede il lavoro dall'inizio alla fine, il throughput quanti elementi si completano in un periodo, lavoro in corso ed età degli elementi mostrano dove il lavoro si blocca, e il software nelle mani degli utenti mostra se tutto questo crea valore.
La Kanban Guide definisce con precisione le quattro misure di flusso. Il lavoro in corso (WIP) è il numero di elementi iniziati ma non finiti. Il throughput è il numero di elementi finiti per unità di tempo. L'età di un elemento è il tempo trascorso dal suo inizio, e il cycle time è il tempo tra l'inizio e la fine.
La velocity, cioè la quantità di lavoro, spesso in story point, che un team Scrum completa in uno sprint, è utile per le previsioni del team stesso. Non va confrontata tra team né usata come obiettivo di produttività, perché gli story point sono relativi a ogni team. Qualsiasi metrica di consegna va affiancata a misure di risultato come adozione da parte degli utenti, difetti in produzione o obiettivi di business raggiunti.
L'agile funziona in un contratto a prezzo fisso?
Sì, se il contratto fissa tempi e budget e tratta l'ambito come variabile. Cliente e fornitore concordano un backlog prioritizzato, la definizione di "fatto" e una cadenza di sprint. Ogni Sprint Review diventa un momento di accettazione, e gli elementi meno prioritari vengono scambiati o eliminati quando emergono nuove esigenze, senza rinegoziare tutto il contratto.
A farlo funzionare è la trasparenza. Il cliente vede software funzionante alla fine di ogni sprint e le funzionalità di maggior valore vengono sempre costruite per prime, il che lo protegge se il budget si esaurisce.
Non funziona invece un prezzo fisso su un ambito completamente dettagliato a cui si aggiunge la parola "agile", perché ogni cambiamento diventa una richiesta di modifica. Una breve fase di discovery e una regola chiara per scambiare l'ambito sono le tutele abituali.
Come cambia l'agile con lo sviluppo assistito dall'IA?
L'agile resta valido quando gli assistenti di IA scrivono parte del codice, ma il collo di bottiglia si sposta. Scrivere codice diventa più veloce, mentre revisione, test e integrazione occupano una quota maggiore di ogni sprint. Serve una definizione di "fatto" più rigorosa, con code review, test automatici e controlli di sicurezza su ogni modifica, chiunque l'abbia scritta.
Un codice più veloce rende i cicli di feedback brevi ancora più preziosi: un team che produce più codice può anche produrre più cose sbagliate. Gli elementi del backlog devono indicare criteri di accettazione chiari, perché diventano le istruzioni da cui parte l'assistente di IA.
Cambia anche la stima. La velocity misurata prima degli strumenti di IA non è più una base affidabile, quindi le previsioni vanno ricostruite su cycle time e throughput recenti.
Come WWG ha portato l'agile in tutta l'azienda?
WWG segue i principi agili e lean sin dalle origini e nel 2020 li ha estesi oltre lo sviluppo, a tutta l'azienda. Giovedì 6 agosto 2020 ha organizzato un corso interno di Agile Fundamentals per i reparti marketing, vendite, sviluppo e contabilità, tenuto da due trainer certificati, Andriu Romanukha e Olesia Prots.
"Sono un grande fan del manifesto Agile", dice Mohamed Deramchi, CEO e fondatore di WWG. "Credo molto nei principi del pensiero snello e parlo spesso con i miei collaboratori del concetto di pianificazione incrementale che, in altri termini, significa migliorare, migliorare sempre. Se non accade significa che qualcosa non sta andando per il verso giusto."
"Mi sono affidato totalmente alla metodologia Agile", continua. "Mi sono chiesto come migliorare davvero e ho analizzato tutto, ma proprio tutto ciò che succedeva nella mia azienda. Non credo sia mai stato fatto nulla di simile per ottimizzare un'azienda con 20 anni di storia. Il risultato è stato un cambiamento radicale, ma necessario."
Il programma della giornata comprendeva principi agili, cascata e agile a confronto, Kanban, il Penny game, ruoli Scrum, eventi Scrum, stima in story point, artefatti Scrum e leadership agile. I vantaggi che cercavamo erano la rilevazione precoce dei problemi, una maggiore collaborazione nei team, il raggiungimento più rapido degli obiettivi personali e di team e più flessibilità. Il passo successivo è stata la pianificazione a livello aziendale, con il nostro primo PI Planning a dicembre 2020. Gli obiettivi a quel livello funzionano meglio se è chiaro anche cosa non sono gli OKR.
Cosa deve contenere una checklist per adottare l'agile?
Una checklist di adozione agile copre persone, cadenza, lavoro e misurazione. Serve un product owner con un reale potere decisionale, un framework e una cadenza scelti, tutto il lavoro visibile su un'unica board, una definizione di "fatto" condivisa e poche metriche di flusso e di risultato decise prima del primo sprint.
- Persone: un product owner con autorità sulle priorità, un facilitatore (Scrum Master o equivalente) e un team stabile.
- Cadenza: durata dello sprint o ritmo di revisione scelti e mantenuti; pianificazione, review e retrospettiva in calendario.
- Lavoro: un unico backlog ordinato, elementi con criteri di accettazione, un limite al lavoro in corso.
- Qualità: una definizione di "fatto" che includa revisione, test automatici e rilascio.
- Misurazione: cycle time e throughput tracciati dal primo giorno, più una metrica di risultato che conti per il business.
Introdurre pratiche agili in un'organizzazione consolidata è di solito più difficile che impararle. Il servizio WWG di implementazione del processo di sviluppo software aiuta i team a definire cadenza e strumenti adatti alle loro dimensioni.
Per capire come l'agile può funzionare nella tua organizzazione o nel tuo prossimo progetto, scrivici a business@wwg.it.
Fonti
- Manifesto Agile, Manifesto per lo sviluppo agile di software (2001) — https://agilemanifesto.org/iso/it/manifesto.html
- Manifesto Agile, Principi sottostanti al Manifesto Agile — https://agilemanifesto.org/iso/it/principles.html
- Ken Schwaber e Jeff Sutherland, The Scrum Guide (2020) — https://scrumguides.org/scrum-guide.html
- John Coleman e Daniel Vacanti, The Kanban Guide (maggio 2025) — https://kanbanguides.org/the-kanban-guide/2025.5/
- Scaled Agile, Inc., PI Planning — https://framework.scaledagile.com/pi-planning/
- Octal Software, Scrum vs waterfall methodology — https://www.octalsoftware.com.sg/blog/scrum-waterfall-methodology-which-is-right-for-your-project-development/
FAQ
Domande frequenti
No. L'agile è nato tra gli sviluppatori software, ma oggi i suoi principi guidano team nel settore bancario, nelle agenzie di marketing, nella sanità, nelle risorse umane e nelle start-up. Qualsiasi team che lavora su problemi complessi con requisiti che cambiano può trarre vantaggio da cicli brevi, lavoro visibile e feedback regolari.
No. Agile è l'insieme di valori e principi descritti nel Manifesto Agile, mentre Scrum è un framework specifico per applicarli, con ruoli, eventi e artefatti definiti. Un team può essere agile usando Kanban o un altro metodo, e un team può seguire i rituali di Scrum in modo meccanico senza lavorare davvero in modo agile.
Ispezione e adattamento significa esaminare regolarmente sia il prodotto sia il modo di lavorare del team, e poi cambiare ciò che non produce valore. In Scrum avviene nella Sprint Review, per il prodotto, e nella Sprint Retrospective, per il processo. Senza un adattamento reale, le riunioni diventano rituali che non cambiano nulla.
Gli story point sono una misura relativa dello sforzo, della complessità e dell'incertezza di un elemento del backlog, confrontato con altri elementi già completati dal team. Servono a pianificare quanto lavoro entra in uno sprint e a prevedere le consegne. Sono specifici di ogni team e non vanno convertiti in ore né confrontati tra team.
