Nello sviluppo software fino agli anni ’90, tutto era prevedibile e lineare: una chiara sequenza di processi di lavoro, pianificazione passo-passo, documentazione, test e implementazione del prodotto finale.
La gestione dei progetti era eccessivamente rigida e le deviazioni da un piano rigido disturbavano l’intero flusso di lavoro.
Il Waterfall (modello a cascata o modello “waterfall”) è un modello di sviluppo software inflessibile con una chiara sequenza di azioni in cui passare alla fase successiva è impossibile fino al completo completamento della precedente.
Lo sviluppo in Waterfall appare come un flusso di processi che si spostano da una fase all’altra con requisiti chiari. Non si verifica alcuna transizione alla fase successiva fino al completamento di quella attuale.
Negli anni ’90, una famiglia di metodi flessibili ha sostituito quelli rigidi.
Stiamo parlando, ovviamente, di Agile (sviluppo software agile). Questo nuovo approccio alla metodologia di gestione dei progetti è entrato nel mondo IT e successivamente si è espanso nella produzione, ingegneria, sviluppo dell’intelligenza artificiale e altro ancora.
I primi metodi flessibili includevano:
- RAD (focalizzato sulla qualità con un budget minimo e una tempistica limitata)
- XP (Extreme Programming con ownership collettiva del codice)
- Scrum (dove ogni membro del team è responsabile del risultato)
- Kanban (visualizzando le fasi di sviluppo su una bacheca), tra gli altri.
Quattro idee Agile che dovresti conoscere:
- Le persone e le interazioni sono più importanti dei processi.
- La collaborazione con il cliente è più importante della negoziazione del contratto.
- Un prodotto funzionante ha la priorità sulla documentazione.
- Rispondere al cambiamento è più importante che seguire un piano.
Agile | Waterfall |
---|---|
Processi di lavoro flessibili, consentendo cambiamenti in qualsiasi momento | Modello di sviluppo a cascata con una sequenza rigida |
Un prodotto funzionante è più importante della documentazione | La documentazione è più importante del prodotto finito |
Responsabilità individuale di ogni membro del team per il risultato | La responsabilità per il risultato complessivo ricade sul team |
Interazione con il cliente durante lo sviluppo | Il cliente non è coinvolto nel processo |
Massima partecipazione del product owner nel processo | Minima partecipazione del product owner |
Il flusso di lavoro è diviso in sprint brevi, di solito da 1 settimana a 1 mese | Ogni flusso di lavoro è una fase separata che dura fino al completamento e all’approvazione dei test |
Sistemi di gestione dei progetti popolari in Agile
Esploriamo quelli che hanno “messo radici” e sono più comunemente usati nello sviluppo software.
Scrum
Un approccio flessibile allo sviluppo software dove un compito equivale a uno sprint. Uno sprint in Scrum può durare da 1 settimana a 1 mese.

Per chi è Scrum?
Per piccole aziende o dipartimenti dove il proprietario dell’azienda o il capo dipartimento può integrarsi fisicamente nel processo di lavoro e partecipare attivamente. Questo metodo è anche ideale per startup.
Utilizzare Scrum nella gestione dei progetti rende difficile identificare la responsabilità per compiti incompleti. Ogni membro del team è responsabile del risultato, dando priorità all’auto-organizzazione per modellare i flussi di lavoro.
Il team che sceglie Scrum per la gestione del progetto deve essere pronto per la massima flessibilità. Ad esempio, se un membro del team “esce” temporaneamente dal processo, un altro deve prendere in carico i suoi compiti.
Lo Scrum master è il project manager e una figura chiave nel team, supervisionando l’organizzazione del processo aziendale, riunioni, motivazione del team, risposte rapide ai cambiamenti e risoluzione dei problemi.
+ Vantaggi
Il software viene sviluppato più velocemente, con il massimo coinvolgimento del team, riducendo i costi di sviluppo frammentando il flusso di lavoro in sprint brevi.— Svantaggi
Scrum non ha regole o requisiti rigorosi ma consente spazio per esperimenti, cambiamenti di budget e tempistiche. Non è adatto ai clienti che necessitano di un piano chiaro e di un contratto formale.Ad esempio, se hai bisogno di creare un prodotto per un’organizzazione governativa dove la firma del contratto è una priorità, Scrum non è adatto. La massima priorità è il prodotto finito, seguita dalla documentazione, dai report di lavoro, ecc.
Esempio di gestione del progetto utilizzando Scrum
Supponiamo che il compito sia creare software nel minor tempo possibile. Il flusso di lavoro è diviso in sprint, ciascuno che termina con una dimostrazione del risultato completato. Vengono svolte riunioni per rivedere i risultati intermedi e passare allo sprint successivo.
Monitorare la velocità di completamento degli sprint è cruciale in Scrum.
Per comprendere quanto durerà uno sprint, il team può avviare un timer all’inizio. Monitorare il tempo speso su ciascun compito fornisce intuizioni sulla durata necessaria per compiti simili.

Kanban
Una rappresentazione visiva del flusso di lavoro e del movimento passo dopo passo delle attività da “In Corso” a “Fatto.” Tra questi due stati, possono esserci diverse altre fasi: “Sviluppo,” “Test,” “Ottimizzazione,” ecc. Kanban appare come una bacheca dove le attività vengono spostate da una stazione all’altra. Quando un’attività raggiunge la stazione finale “Fatto”, è completata.
Scrum e Kanban sono approcci flessibili alla gestione dei progetti. Tuttavia, Kanban è ancora più flessibile perché:
- Consente di introdurre improvvisamente nuovi compiti e “cambiare” tra di essi.
- La responsabilità collettiva per il risultato aumenta l’efficienza.
- I compiti non pianificati vanno nel backlog, uno spazio di stoccaggio per tutti i compiti non ancora in corso. Il backlog appare come qualsiasi altra fase del processo di lavoro e contiene compiti pronti per essere lavorati quando le altre fasi finiscono prima del previsto.
+ Vantaggi
Rispetto a Scrum, Kanban non richiede riunioni regolari, discussioni o revisioni degli sprint, risparmiando tempo e aumentando l’efficienza dove tutte le fasi sono visibili sulla bacheca.— Svantaggi
Kanban è impegnativo per grandi progetti dove i risultati intermedi sono cruciali, frammentando il processo in sprint, e l’approvazione preliminare di un piano d’azione è necessaria. Kanban è più adatto per progetti e compiti a breve termine.Esempio di gestione del progetto utilizzando Kanban
Il compito è girare un video istruttivo per un cliente. Ciò comporterà la creazione di diversi compiti: “Scrittura del Copione,” “Riprese,” “Montaggio Grezzo,” “Post-Produzione.” Ogni compito sarà una colonna separata sulla bacheca Kanban.

Kanban o Scrum? Quale sistema di gestione dei progetti hai bisogno?
Scrum fornisce maggiore controllo e gestibilità all’inizio dello sviluppo di un nuovo prodotto. Se Kanban offre la massima flessibilità, Scrum si concentra di più su controllo e gestione. Quando i processi sono in atto, Kanban viene in soccorso. È perfetto per lavorare con compiti ripetitivi.Come scegliere uno strumento di gestione dei progetti?
Il giusto gestore di compiti è metà del successo. Una volta scelto un metodo di gestione dei progetti, è fondamentale trasferire il lavoro e i compiti nel sistema selezionato.
6 segnali che hai scelto il giusto gestore di compiti:
- Il team ha migrato senza problemi tutti i flussi di lavoro sull’account.
- La funzionalità è intuitiva e utilizzata dai membri del team.
- Il team utilizza facilmente uno degli approcci di gestione flessibili: Scrum o Kanban.
- La sistematizzazione del flusso di lavoro è stabilita, aumentando l’efficienza complessiva.
- La comunicazione del team diventa più coordinata: progetti, compiti e commenti non vengono persi.
- Il cliente riceve report trasparenti su compiti e progetti, tracciando i flussi di lavoro se lo desidera.