Metodologia di progetto software: come scegliere tra Waterfall, Agile, Scrum, Kanban, DevOps e ibrido

Che cos’è una metodologia di progetto software e perché la scelta conta

Una metodologia di progetto software è un approccio strutturato che definisce come un progetto software viene pianificato, eseguito e consegnato. Prescrive fasi (o la loro deliberata assenza), ruoli, artefatti, ritmi e schemi decisionali. Metodologie diverse ottimizzano risultati diversi: Waterfall per la prevedibilità e la documentazione, Agile per l’adattabilità e la consegna di valore, DevOps per la velocità di rilascio e l’integrazione operativa. Nessuna metodologia è universalmente migliore; ciascuna è migliore per un insieme specifico di condizioni. Il compito del PM non è scegliere la propria preferita ma adattare la metodologia al progetto in corso.

La scelta non è cosmetica. Il State of Project Management Report 2024 di Wellingtone ha mostrato che solo il 34% delle organizzazioni completa i progetti nei tempi e il 34% nel budget, e sebbene la metodologia sia solo una variabile, è una variabile controllabile. I progetti con requisiti stabili condotti in Agile spesso sprecano sforzi ripianificando ciò che non aveva mai bisogno di cambiare; i progetti con requisiti volatili condotti in Waterfall spesso consegnano rispetto a un piano che non corrisponde più al bisogno aziendale. Entrambe le modalità di fallimento sono evitabili con la selezione della metodologia, ed entrambe sono comuni nelle organizzazioni che scelgono per preferenza del team invece che per adattamento al progetto.

Per un PM o un analista PMO il framework decisionale conta perché la scelta della metodologia è una delle prime decisioni di progetto e una delle più difficili da invertire. Cambiare metodologia a metà progetto è possibile ma costoso: contratti, aspettative dello sponsor, strumenti e competenze del team si allineano a una metodologia, e cambiare rotta significa riallinearli tutti. Le cinque metodologie qui sotto più l’ibrido coprono la maggior parte dei progetti software; scegliere bene all’inizio evita l’adattamento successivo.

Le cinque principali metodologie di progetto software in sintesi

La tabella seguente riassume le cinque principali metodologie più l’ibrido, offrendo una panoramica rapida prima delle sezioni dettagliate. Ogni riga risponde alle domande che un PM si pone per prime: come è organizzato il lavoro, qual è il ritmo, per cosa è più adatta, dove è debole.

Il resto di questo articolo tratta ogni metodologia in maggiore profondità, seguito dal framework decisionale per scegliere tra esse.

Waterfall: prevedibile, guidata dal piano, sequenziale

La metodologia Waterfall, formalizzata da Winston Royce in un articolo del 1970 (ironicamente, descrivendo quello che considerava un approccio difettoso), organizza un progetto software in fasi sequenziali che fluiscono l’una nell’altra: raccolta dei requisiti, progettazione del sistema, implementazione, integrazione e test, distribuzione e manutenzione. Ogni fase si completa prima che inizi la successiva, e tornare a una fase precedente è trattato come un evento significativo che richiede un controllo formale delle modifiche. La disciplina della metodologia deriva dal suo presupposto che i requisiti possano essere definiti in anticipo e non cambieranno sostanzialmente durante l’esecuzione.

Waterfall non è il relitto obsoleto che il marketing di Agile talvolta suggerisce. Rimane la scelta giusta in diverse situazioni. I settori regolamentati (farmaceutico, aviazione, difesa, conformità finanziaria) richiedono spesso una documentazione completa in anticipo e la validazione formale di ogni fase, cosa che Waterfall fornisce naturalmente. I contratti a perimetro fisso e scadenza fissa (progetti pubblici, deliverable dei fornitori) beneficiano della chiarezza di Waterfall su cosa sarà consegnato e quando. I progetti con alto costo del cambiamento durante l’esecuzione, come infrastrutture fisiche, integrazione hardware o approvazioni normative complesse, si allineano alla disciplina di Waterfall di definire bene i requisiti prima di costruire. La prevedibilità che Waterfall impone è esattamente ciò di cui questi progetti hanno bisogno.

Le debolezze di Waterfall sono lo specchio dei suoi punti di forza. Quando i requisiti cambiano durante l’esecuzione, il controllo formale delle modifiche di Waterfall aggiunge costi e tempo che le metodologie agili assorbirebbero nella normale iterazione. Il feedback arriva tardi, spesso solo durante i test di integrazione, per cui difetti e fraintendimenti emergono dopo un investimento significativo. La consegna di valore aziendale è rinviata alla fine del progetto, quindi se il progetto viene annullato presto, non è stato consegnato nulla di utilizzabile. La metodologia si adatta benissimo a certi progetti; non si adatta a progetti con reale incertezza su cosa costruire. La nostra guida alla metodologia Waterfall tratta le fasi e la loro esecuzione più in dettaglio.

Agile: iterativa, adattiva, orientata al valore

Agile non è una singola metodologia ma un framework ombrello che comprende diversi metodi specifici (Scrum, Kanban, Extreme Programming, Crystal e altri). Ciò che li unisce è il Manifesto Agile del 2001, che ha dato priorità agli individui e alle interazioni rispetto ai processi e agli strumenti, al software funzionante rispetto alla documentazione esaustiva, alla collaborazione con il cliente rispetto alla negoziazione contrattuale, e alla risposta al cambiamento rispetto al seguire un piano. Dodici principi sottostanti rendono operativi questi valori: consegnare software funzionante di frequente, accogliere i requisiti che cambiano, team auto-organizzati, ritmo sostenibile e altri. I valori del Manifesto non sono contrari alla pianificazione o alla documentazione; stabiliscono priorità quando servono compromessi.

Agile si adatta a progetti con requisiti in evoluzione, perimetro incerto, alto valore del feedback precoce e team autorizzati a prendere decisioni di consegna. Lo sviluppo di prodotti software, le iniziative di trasformazione digitale e qualsiasi progetto in cui l’apporto del cliente durante lo sviluppo migliori sensibilmente il risultato beneficiano dei cicli brevi e dell’adattamento continuo di Agile. La forza della metodologia deriva dal ciclo di feedback ristretto: costruire un piccolo incremento, mostrarlo agli stakeholder, imparare cosa aggiustare, costruire l’incremento successivo. Nel corso di un progetto, questo ciclo produce di solito qualcosa di più vicino a ciò di cui gli stakeholder hanno realmente bisogno rispetto alle alternative pianificate in anticipo.

L’implementazione pratica di Agile incontra un comune problema di strumenti: gli sviluppatori preferiscono nettamente Jira, Azure DevOps o piattaforme agili simili incentrate sul team perché si adattano nativamente alla meccanica degli sprint e alla cura del backlog, mentre i PMO hanno bisogno di una visibilità a livello di portfolio che questi strumenti non forniscono bene. Lo schema pragmatico è l’integrazione: gli sviluppatori lavorano in Jira, i PMO vedono il sottoinsieme rilevante per il portfolio nel loro sistema PPM tramite sincronizzazione dei dati. FlexiProject implementa questo schema con un’integrazione diretta con Jira che importa epic, story e task preservando stato, responsabile e tipo, così che PMO e direzione vedano il lavoro agile nella stessa vista di portfolio dei progetti non agili senza che i team cambino strumento. Per una definizione più completa di Agile, vedi la nostra guida Che cos’è Agile; per la vista operativa PM/PMO, il nostro articolo Gestione dei progetti di sviluppo software agile nel PPM tratta il modello di consegna in profondità.

Scrum e Kanban: due varianti di Agile nella pratica

Scrum e Kanban sono i due metodi agili più usati nello sviluppo software. Condividono i valori sottostanti di Agile ma li implementano in modo diverso, e la scelta tra loro dipende dallo schema di lavoro del team.

Scrum: Agile basato su sprint con ruoli definiti

Scrum organizza il lavoro agile in iterazioni di durata fissa chiamate sprint (di solito due settimane). Ogni sprint inizia con la pianificazione dello sprint, dove il team si impegna su un insieme di user story del product backlog, e termina con la revisione dello sprint (dimostrazione agli stakeholder) e la retrospettiva (miglioramento del processo del team). Tre ruoli portano avanti il lavoro: Product Owner (prioritizza il backlog), Scrum Master (facilita gli eventi e rimuove gli impedimenti) e Team di Sviluppo (consegna l’impegno dello sprint). Scrum funziona bene per team che costruiscono nuove funzionalità a ritmo prevedibile, con un Product Owner in grado di impegnarsi sul perimetro dello sprint e un team che trae beneficio dalla disciplina di iterazione. La nostra guida alla metodologia Scrum tratta ruoli, eventi e artefatti in dettaglio.

Kanban: flusso continuo con limiti WIP

Kanban sostituisce i confini degli sprint di Scrum con un flusso continuo. Gli elementi di lavoro avanzano attraverso colonne di flusso (di solito Da fare, In corso, Revisione, Fatto) con limiti di lavoro in corso a ogni colonna, il che costringe il team a finire prima di iniziare. Non ci sono ruoli fissi oltre a quelli che il team ha già, né eventi obbligatori (anche se la maggior parte dei team adotta stand-up quotidiani e revisioni operative periodiche), né raggruppamento del lavoro in sprint. Kanban si adatta a team di supporto, lavoro DevOps, campagne di marketing e qualsiasi flusso in cui le priorità cambiano più spesso della durata di uno sprint. La nostra guida al sistema Kanban tratta l’intera metodologia, incluse le sei pratiche, le metriche e gli schemi di adozione nel PMO.

La scelta tra Scrum e Kanban non è permanente. I team iniziano spesso con la struttura di Scrum mentre imparano Agile, poi evolvono verso lo Scrumban (eventi Scrum con una board Kanban e limiti WIP) man mano che il loro lavoro diventa più continuo, e infine verso il Kanban puro quando dominano le interruzioni. Il framework dovrebbe servire lo schema di lavoro del team; lo schema serve raramente il framework.

DevOps: sviluppo e operazioni come una cosa sola

DevOps è una metodologia, una cultura e un insieme di pratiche che integrano lo sviluppo software e le operazioni IT in un’unica pipeline di consegna continua. Il termine è stato coniato intorno al 2009 da Patrick Debois, e la pratica è emersa da team frustrati dal muro tradizionale tra sviluppatori (che scrivevano il codice) e operazioni (che lo distribuivano e lo eseguivano). DevOps rimuove quel muro: lo stesso team possiede il codice dal commit alla produzione, con l’automazione che sostituisce i passaggi manuali in ogni fase.

Le pratiche centrali sono l’integrazione continua (CI, in cui ogni commit di codice attiva build e test automatizzati), la consegna continua (CD, in cui ogni build riuscita viene preparata automaticamente per la distribuzione), l’infrastruttura come codice (IaC, in cui l’infrastruttura è versionata e distribuita come software), i test automatizzati (test unitari, di integrazione, di sicurezza e di prestazioni eseguiti automaticamente) e il monitoraggio continuo (il comportamento in produzione alimenta le priorità di sviluppo). Insieme, queste pratiche comprimono il ciclo di rilascio da mesi a giorni o ore, e trasformano la distribuzione da evento pianificato a operazione di routine.

DevOps si adatta a progetti software con diverse caratteristiche. I servizi cloud-native ad alta frequenza di rilascio (prodotti SaaS, applicazioni web, microservizi) beneficiano di DevOps perché il ciclo di rilascio è la dimensione competitiva. I team che consegnano in produzione in modo continuo (non solo a fine progetto) hanno bisogno dell’automazione che DevOps fornisce. Le organizzazioni con mentalità di prodotto (non di progetto) trattano la consegna come continua anziché terminale, cosa che DevOps abilita. I fornitori di infrastruttura cloud (AWS, Azure, GCP) hanno costruito i loro strumenti attorno ai presupposti di DevOps, rendendo l’adozione molto più semplice di un decennio fa.

DevOps non si adatta a ogni progetto. I settori regolamentati con cicli di rilascio trimestrali obbligatori e validazione formale di ogni modifica spesso non possono accogliere il rapido ritmo di distribuzione di DevOps, perché l’onere di conformità della validazione di ogni distribuzione consumerebbe i guadagni di velocità. I team piccoli con rilasci occasionali trovano spesso l’onere degli strumenti di DevOps sproporzionato rispetto al beneficio. I sistemi legacy costruiti senza un’architettura adatta all’automazione possono richiedere anni di refactoring prima che le pratiche DevOps funzionino in modo significativo. In questi casi, adottare pratiche DevOps selettive (CI, test automatizzati) senza la distribuzione continua completa dà spesso gran parte del beneficio senza l’impegno totale.

Il panorama degli strumenti è ampio ma convergente. Tra le piattaforme CI/CD ci sono Jenkins, GitLab CI, GitHub Actions, CircleCI ed equivalenti cloud-native (AWS CodePipeline, Azure Pipelines). Tra gli standard di infrastruttura come codice ci sono Terraform (multi-cloud), Ansible (gestione della configurazione), Kubernetes (orchestrazione di container) e Docker (containerizzazione). Gli stack di monitoraggio combinano metriche (Prometheus, Datadog), log (stack ELK, Splunk) e tracing (Jaeger, OpenTelemetry). Gli strumenti specifici cambiano; le pratiche che supportano rimangono stabili. DevOps coesiste spesso con le metodologie agili a livello di team: Agile per la pianificazione e la prioritizzazione, DevOps per la consegna e le operazioni. Questa combinazione è ciò che la maggior parte delle moderne organizzazioni software esegue realmente, che la chiamino così o no.

Ibrido: combinare le metodologie per i progetti reali

La gestione ibrida dei progetti combina elementi di più metodologie per adattarsi a progetti che non corrispondono nettamente a un singolo approccio. Non è un compromesso ma una scelta deliberata: usare la disciplina di Waterfall dove conta la prevedibilità, la flessibilità di Agile dove c’è incertezza, e integrarle ai confini. Lo schema ibrido più comune nei progetti software combina la pianificazione a livello di progetto di Waterfall (budget fisso, governance basata su milestone, approvazioni formali) con esecuzione agile all’interno delle fasi (sviluppo iterativo, consegna basata su sprint, feedback continuo degli stakeholder).

L’ibrido si adatta a diverse situazioni ricorrenti. I settori regolamentati che necessitano di date di rilascio fisse per ragioni di conformità ma desiderano flessibilità di esecuzione agile adottano spesso l’ibrido: il ritmo di rilascio è in stile Waterfall (pianificato trimestralmente, con approvazioni formali), mentre lo sviluppo all’interno di ogni rilascio procede in modo agile. I progetti software enterprise con contratti fissi ma dettagli di implementazione incerti usano l’ibrido: il contratto impegna perimetro e date, ma il come all’interno di quegli impegni procede in modo iterativo. I programmi multi-team che mescolano team di prodotto agili e team di infrastruttura Waterfall hanno bisogno di coordinamento ibrido: ogni team esegue la propria metodologia nativa, con punti di sincronizzazione basati su milestone che li collegano. La nostra guida alla gestione ibrida dei progetti tratta gli schemi e le insidie più in dettaglio.

Il rischio dell’ibrido è la deriva dall’intenzionale all’accidentale. Un approccio ibrido che specifica con cura cosa procede in Waterfall e cosa in Agile funziona bene; un approccio ibrido che mescola i due in modo ambiguo perché nessuno ha deciso esplicitamente finisce con la disciplina di nessuno dei due. Il ruolo del PMO nell’ibrido è rendere espliciti i confini: quali decisioni sono in stile Waterfall (pianificate, approvate, modificate formalmente), quali in stile Agile (iterative, aggiustate di continuo) e dove si collegano. Un ibrido ben progettato combina i punti di forza di entrambi gli approcci. Un ibrido trascurato eredita le debolezze di entrambi.

Come scegliere la metodologia giusta: un framework decisionale

La selezione della metodologia è una delle decisioni iniziali più importanti del progetto, ed è meglio prenderla in modo sistematico anziché per preferenza. I quattro criteri seguenti coprono la maggior parte della decisione. Ogni criterio spinge verso alcune metodologie e lontano da altre, e combinarli produce una scelta difendibile.

Stabilità dei requisiti

Il criterio di gran lunga più importante è quanto siano realmente stabili i requisiti del progetto (non quanto lo sponsor sostenga che lo siano). Requisiti stabili, come deliverable regolamentati, integrazioni ben definite o la sostituzione di un sistema esistente con specifiche chiare, si allineano a Waterfall o all’ibrido, dove la pianificazione anticipata cattura gran parte di ciò che sarà costruito. Requisiti volatili, come nuovi prodotti, funzionalità rivolte al cliente, trasformazione digitale o qualsiasi cosa con incertezza di mercato, si allineano ad Agile, Scrum o Kanban, dove il team si aspetta e accoglie il cambiamento. In caso di dubbio sulla stabilità, propendi per Agile: il costo di Agile su requisiti stabili è un onere modesto; il costo di Waterfall su requisiti volatili è una rilavorazione significativa.

Ritmo di rilascio e pressione delle scadenze

Il secondo criterio è quale debba essere il ritmo di rilascio. Scadenze fisse con perimetro fisso (deliverable contrattuali, scadenze normative, campagne di marketing legate a date precise) richiedono Waterfall o ibrido perché esigono un impegno anticipato su cosa sarà consegnato e quando. Rilasci a lotti prevedibili (rilasci di funzionalità ogni 6-8 settimane, versioni di prodotto) si adattano a Scrum, perché i confini degli sprint si allineano naturalmente ai confini dei rilasci. Un flusso continuo senza struttura a lotti (lavoro di supporto, miglioramenti incrementali, lavoro guidato da incidenti) si adatta a Kanban. Un’alta frequenza di rilascio (distribuzioni quotidiane od orarie in produzione) richiede DevOps, perché la distribuzione manuale non può sostenere il ritmo.

Composizione del team e maturità agile

Il terzo criterio è ciò che il team può effettivamente eseguire. Un team agile maturo con diversi anni di esperienza può condurre Agile completo in modo efficace; un team nuovo ad Agile beneficia spesso della struttura di Scrum mentre impara, per poi evolvere verso metodi meno prescrittivi. I team che mescolano fortemente sviluppo e operazioni tendono naturalmente verso DevOps, perché le pratiche corrispondono alla loro realtà. I team in ambienti regolamentati con documentazione obbligatoria e validazione formale si allineano a Waterfall o all’ibrido indipendentemente dalla preferenza agile, perché i requisiti di conformità prevalgono sulla filosofia della metodologia. La composizione del team determina cosa è realistico, non solo cosa è teoricamente ideale.

Contesto di portfolio

Il quarto criterio è spesso sottovalutato: il progetto non procede in isolamento ma come parte di un portfolio organizzativo con altri progetti. I PMO gestiscono tipicamente portfolio misti in cui coesistono lavoro di prodotto agile, progetti di investimento Waterfall e iniziative regolamentate ibride. La scelta della metodologia di ogni singolo progetto influenza ed è influenzata dal resto del portfolio: un progetto agile che dipende dagli output di un progetto Waterfall ha bisogno di sincronizzazione alle milestone; un team Kanban che alimenta un release train Scrum ha bisogno di coordinamento dei passaggi. FlexiProject supporta i portfolio misti rendendo Kanban una delle tre viste di pianificazione (elenco attività, diagramma di Gantt, Kanban), così che team diversi possano lavorare nella loro rappresentazione preferita mentre il PMO li vede tutti in una dashboard di portfolio unificata. Combinato con l’integrazione diretta con Jira, questo consente ai team agili di restare in Jira per il loro lavoro quotidiano mentre le loro attività rilevanti per il portfolio appaiono in FlexiProject accanto ai progetti Waterfall.

FAQ: metodologia di progetto software

Qual è la differenza tra una metodologia e un framework?

Una metodologia è un approccio completo alla gestione di un progetto: fasi, ruoli, artefatti, ritmi e schemi decisionali. Un framework è una struttura più leggera che fornisce principi e pratiche senza una prescrizione completa. Scrum, per esempio, è spesso chiamato framework anziché metodologia perché prescrive ruoli ed eventi ma lascia aperte le pratiche ingegneristiche. Kanban è similmente simile a un framework. Waterfall è inequivocabilmente una metodologia perché prescrive l’intera struttura di fasi. Agile in sé non è esattamente né l’uno né l’altro, ma piuttosto un ombrello di valori che metodologie e framework specifici implementano.

Si possono usare più metodologie in un singolo progetto?

Sì, ed è ciò che la gestione ibrida dei progetti formalizza. Uno schema comune è Waterfall a livello di progetto (budget fisso, milestone, governance formale) con Agile a livello di fase (esecuzione iterativa all’interno di ogni fase). Un altro è Scrum per lo sviluppo di funzionalità più Kanban per il supporto continuo dello stesso prodotto. La chiave è la progettazione deliberata: specificare quale metodologia si applica dove e come si collegano i confini. La mescolanza casuale tende a produrre il peggio di entrambe anziché il meglio.

Quale metodologia è la migliore per i team piccoli?

I team piccoli (2-6 persone) beneficiano di solito di Kanban perché ha il minore onere obbligatorio: nessun ruolo oltre a quelli del team, nessun evento oltre a quelli che sceglie, solo visualizzazione, limiti WIP, gestione del flusso, politiche esplicite, revisioni regolari e miglioramento continuo. I team piccoli che sviluppano nuovi prodotti usano spesso uno Scrum leggero con ruoli combinati (una persona fa da Product Owner e Scrum Master, per esempio). I team piccoli con contratti a perimetro fisso possono ancora usare Waterfall per la semplicità di governance, poiché l’onere di Agile può essere sproporzionato per consegne semplici.

Che relazione c’è tra DevOps e Agile?

Agile e DevOps sono complementari, non concorrenti. Agile è una metodologia per organizzare il lavoro di sviluppo (cicli iterativi, pianificazione adattiva, collaborazione con gli stakeholder). DevOps è un insieme di pratiche per integrare sviluppo e operazioni (pipeline automatizzate, consegna continua, infrastruttura come codice). La maggior parte delle moderne organizzazioni software esegue entrambi: Agile per la pianificazione e la prioritizzazione a livello di team, DevOps per la consegna e le operazioni lungo tutto il ciclo di vita del software. Nessuno sostituisce l’altro; risolvono problemi diversi a livelli diversi del processo di consegna del software.

Che ruolo ha un PMO nella selezione della metodologia?

Il ruolo del PMO è fornire una guida alla selezione senza imporre una singola metodologia. Progetti diversi nel portfolio beneficiano di metodologie diverse, e forzare tutti i progetti in un unico approccio di solito riduce le prestazioni complessive del portfolio. Il contributo del PMO include: criteri di selezione (framework come quello di questo articolo), standard a livello di portfolio validi tra le metodologie (ritmi di governance, reporting dei costi, categorizzazione dei rischi), strumenti che supportano più metodologie simultaneamente e affiancamento ai team che scelgono una metodologia per la prima volta. Il PMO possiede il framework; i team possiedono la scelta al suo interno.

La metodologia di progetto software giusta è quella che si adatta alla stabilità dei requisiti, al ritmo di rilascio, alla composizione del team e al contesto di portfolio del progetto, non quella con il miglior marketing o i sostenitori più convinti nel team. Waterfall funziona per lavoro prevedibile, guidato dal piano, con requisiti stabili. Agile funziona per lavoro adattivo e iterativo con requisiti in evoluzione. Scrum funziona per team che costruiscono a ritmo prevedibile. Kanban funziona per lavoro continuo guidato da interruzioni. DevOps funziona per consegna ad alta frequenza che integra sviluppo e operazioni. L’ibrido funziona quando una singola metodologia non si adatta alle condizioni reali del progetto. La ricerca Power Skills del PMI ha rilevato che 9 professionisti di progetto su 10 ritengono che le power skill, come comunicazione, empatia, adattabilità e leadership, li aiutino a lavorare in modo più intelligente, e la metodologia da sola non le sostituisce mai. La migliore metodologia nelle mani sbagliate rende meno di una metodologia imperfetta in mani competenti. La metodologia dà struttura; le persone consegnano i risultati. FlexiProject supporta l’intera gamma di metodologie tramite tre viste di pianificazione (elenco attività, diagramma di Gantt, Kanban) tra cui i team possono passare man mano che il loro schema di lavoro evolve, e un’integrazione diretta con Jira che mantiene visibile il lavoro dei team agili a livello di portfolio senza costringere i team a uscire dai loro strumenti preferiti. Scegli la metodologia che si adatta al progetto; investi nelle persone che lo eseguiranno; usa strumenti che supportino entrambe le cose. È questo lo schema che porta i progetti nel 34% che rispetta gli impegni anziché nel 66% che fallisce.