La differenza tra framework Agile, SCRUM, Waterfall e Kanban

Da dove nasce il metodo Agile?

Inizio col parlarti del metodo Agile che è quello più usato nel mondo software e anche fuori dal mondo software di oggi. Il metodo Agile nasce nel 2001 da un gruppo di 17 sviluppatori di software che scrisse il manifesto AGILE inconsapevoli di lanciare 12 principi che sarebbero stati poi seguiti in tutto il mondo, anche al di fuori del settore dell’information technology.

Il manifesto ed i suoi principi sono ancora consultabili nella sua forma originaria a questo indirizzo: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

In passato, ci siamo abituati ai metodi cosiddetti di Waterfall o di Stage & Gate dove il progetto, dal punto di vista temporale, è diviso in specifiche e distinte fasi (stage) separate fra di loro da un punto di decisione (una milestone o gate). In poche parole, il punto di decisione è in mano ad un project manager o ad un team di manager che decidono se andare avanti o meno con le altre fasi in base al raggiungimento di determinati obiettivi e risultati. Tipicamente questo approccio ti porta a lavorare “in serie” piuttosto che in parallelo, immaginati questo metodo come un Gantt dove la prossima attività inizia solo se la precedente è completata.

Da dove nasce il metodo SCRUM?

Al contrario, il movimento AGILE ha puntato su strumenti migliori al continuo e veloce cambiamento sia delle attività sia dei tempi. Lo SCRUM è stato il primo strumento adottato in ambito AGILE. Negli anni ’90 da Jeff Sutherland e Ken Schwaber idearono lo SCRUM che portò al successo le prime applicazioni in Yahoo e Google. Il nome SCRUM (mischia dal gioco del Rugby) in realtà è stato portato all’attenzione di tutti dal Giapponese Ikujiro Nonaka in un famoso articolo apparso su Harvard Business Review, anche se lo SCRUM di oggi è particolarmente diverso come strumento applicativo.

Il metodo SCRUM si basa su:

• Brevi periodi di progettazione/sviluppo (es. Sprint)
• Personale coinvolto in team
• Clienti/fornitori a stretto contatto
• Regolare e frequente ridefinizione dei tasks e delle priorità
• Rapidità e flessibilità nei cambiamenti
• Visual Management dei tasks (es. Tabelloni Visual o SCRUM Board)

La gestione dello SCRUM ha inizio, così come nella tradizionale progettazione, tramite la definizione della Mission del prodotto. In poche parole un documento di input che avvia l’iter di progettazione e sviluppo prodotto/processo. Molte aziende che utilizzano il framework SCRUM di fatto non utilizzano diagrammi Gantt o al limite li utilizzano come cornice per identificare le principali milestone senza entrare nel dettaglio dei singoli task, la loro programmazione temporale e assegnazione risorse.

Come funziona lo SCRUM?

Ora ti parlo di come funziona lo SCRUM. In generale, lo SCRUM parte da una cornice generale di Mission prodotto, produce un primo output o "artefatto" denominato Product Backlog. Il product backlog è un elenco di requisiti funzionali e non, che il prodotto deve possedere per soddisfare la Mission.

Il secondo passo, è che una figura prevista dallo SCRUM che si chiama Product Owner assegna le priorità ai diversi requisiti del Product Backlog ed inizia una negoziazione con i SCRUM Team di progettazione e sviluppo ai quali assegna i requisiti secondo le priorità.

Un aspetto interessante dello SCRUM è che le priorità assegnate ai requisiti possono cambiare dipendentemente dalle richieste dei vari stakeholders e la coda di requisiti dipende dalla velocità con cui i team riescono a smaltire i diversi Product Backlog.

Le attività vere e proprie di progettazione e sviluppo sono svolte dai team in unità temporali chiamate Sprint. Uno Sprint, dipendentemente da ciò che si progetta, può durare da una settimana ad un mese.

Il team è responsabile di quanto avviene durante lo Sprint in termini di output. Al termine di ogni giorno lavorativo il team si riunisce in un veloce meeting di circa 15 minuti chiamato Daily Scrum Meeting valutando:

• Cosa è stato fatto realmente in termini di task durante la giornata e se ci sono degli scostamenti rispetto allo Sprint Backlog
• Eventuali impedimenti nati
• Cosa occorre fare nella successiva giornata
• Aggiornamenti dei post-it (task) nello Sprint Board
• Allo scadere dello Sprint, in una riunione veloce di max 4 ore denominata Sprint Review Meeting, il team presenta ciò che realmente è stato progettato e sviluppato in termini di requisiti cercando di capire cosa fare nel successivo Sprint e valutando se sono cambiate le priorità nello Sprint Backlog.

Cito un'altra figura importante dello SCRUM, che è il cosiddetto SCRUM Master. Quest’ultimo è una figura che tipicamente necessita di un particolare training e funge per lo più da facilitatore. La sua autorità è, infatti, più che altro indiretta nel senso che non impone scelte sui requisiti al Product Owner e non può mettere in discussione la programmazione quotidiana dei task fatta dal team.

L’alternativa, ancora più “agile” e più recente per la gestione dello sviluppo dei software è il framework Kanban, inspirato al Toyota Production System.

La differenza sostanziale fra i due framework è che nello SCRUM il team decide il numero di task da portare avanti basandosi sul tempo a disposizione durante lo Sprint; il primo giorno dello Sprint tutti i task si trovano nella prima colonna dei non iniziati per poi muoversi gradualmente verso le due colonne sulla destra. L’ultimo giorno tutto deve essere nell’ultima colonna dei task completati, dopodiché si riparte da sinistra verso destra con un nuovo Sprint ed una nuova board. Analogamente ai cartellini kanban utilizzati in produzione, si può limitare il numero totale di task che il team si impegna a prendere in carico. A tal scopo, nella tipica kanban board nella colonna in progress si indica tramite un numero di quanti task si possono al massimo prendere in carico, limitando in questo modo il numero totale di taks e bilanciando al meglio i compiti del team.

Conclusione

Scegliere quale metodologia di lavoro utilizzare per il tipo di software da sviluppare non è solo una questione di chi è al comando ma di chi lo sviluppa. Il framework più moderno e utilizzato nel campo dello sviluppo software è l'agile - SCRUM, mentre il più datato è il Waterfall che nel mondo digitale di oggi è incompatibile per questione di task, tempistiche e tecnologie.

FAQs

1. Quali sono i vari tipi di framework per lo sviluppo dei software? I vari tipi di framework utilizzati nello sviluppo dei software sono: Kanban, Agile, SCRUM e Waterfall.

2. Come è nato il metodo agile? Il modello di sviluppo Agile nasce nel 2001 quando 17 sviluppatori di software esperti si riunirono nel stato del Utah e scrissero il "manifesto per lo sviluppo dei software Agile".

3. Quale è la differenza tra Agile e Waterfall? La differenza tra Agile e Waterfall è che nel Waterfall la pianificazione è dettagliata fin dall’inizio, con poco spazio per modifiche durante l’esecuzione. Al contrario, nell’Agile consente di rispondere dinamicamente ai cambiamenti, adattando la direzione del progetto in base alle nuove informazioni o alle evoluzioni dei requisiti.

4. Da cosa è inspirato il modello di sviluppo Kanban? Il modello di sviluppo di software Kanban è inspirato al Toyota Production System.

Hai un progetto software da realizzare? Che tu parta da zero o voglia potenziare una soluzione già esistente, il team de La Capitale è al tuo fianco in ogni fase del processo.

Contattaci subito: ti aiuteremo a trasformare la tua idea in un software performante, sicuro e costruito sui tuoi obiettivi.

Contattaci