La Transizione dal metodo Waterfall all'Agile: applicazione delle metodologie agili al caso studio Spotify

1 
 
Introduzione/Premessa 
Nell’era della digitalizzazione in continua evoluzione, le organizzazioni perseguono 
incessantemente approcci più efficienti ed efficaci per lo sviluppo dei loro prodotti. 
Negli ultimi decenni, il passaggio dall’approccio convenzionale Waterfall alle 
metodologie Agile è emerso come reazione agli ostacoli affrontati nel processo di 
sviluppo software e nella gestione dei progetti in vari ambiti, estendendosi oltre il regno 
dell’IT. Tale transizione riflette la necessità di adattarsi a un ambiente in cui i requisiti 
dei clienti possono cambiare rapidamente e in cui la velocità di consegna è fondamentale 
per rimanere competitivi sul mercato.  
Un’ambiente simile è sicuramente quello del regno dei servizi di musica digitale, in 
particolare il settore dello streaming musicale, caratterizzato da un panorama dinamico in 
cui le richieste dei consumatori si evolvono rapidamente. Tra i principali contendenti in 
questo settore spicca Spotify come il migliore servizio di streaming musicale, seguito da 
Apple Music. Il fattore chiave che distingue Spotify e contribuisce al suo successo risiede 
nel suo modello di divisione e coordinamento a matrice “inversa”, impiegando anche 
collegamenti orizzontali. Questo quadro strategico è stato determinante nel consentire a 
Spotify di perseguire efficacemente i propri obiettivi aziendali.  
Alla luce di ciò, com’è la configurazione effettiva della sua struttura organizzativa? Quali 
sono i principali reparti o divisioni al suo interno e quali responsabilità ricoprono?  
L'obiettivo di questo studio è fornire una risposta completa alle suddette domande e 
analizzare meticolosamente la trasformazione emblematica, dal modello Waterfall a 
quello Agile, con particolare enfasi sul caso studio di Spotify come esempio di 
un'organizzazione Agile che ha integrato con successo le relative metodologie agili. 
Pertanto, dopo un'accurata ricerca documentaria, nel capitolo iniziale, verrà esaminato 
l'approccio convenzionale comunemente indicato come metodologia Waterfall. Questa 
analisi comprenderà un'esplorazione delle sue radici storiche, un esame approfondito 
delle fasi sequenziali coinvolte in questo processo, nonché una valutazione completa dei 
suoi punti di forza e di debolezza intrinseci. Inoltre, saranno approfondite le diverse 
applicazioni di questa metodologia in diversi contesti, estendendoci oltre il settore dei 
sistemi informatici, e faremo luce sulla sua percezione e rilevanza contemporanea.
2 
 
Il capitolo successivo, fornirà un esame approfondito delle metodologie Agile, adottate 
al posto dei metodi tradizionali a causa di una moltitudine di fattori, inclusa la necessità 
di adattarsi al cambiamento. Verranno esplorate le sue radici, risalendo all'origine del 
Manifesto Agile e ai suoi principi fondamentali. Successivamente, verranno chiariti i 
framework più importanti, come Scrum e Kanban, insieme a un'analisi completa dei 
vantaggi e dei limiti inerenti a questo approccio. Inoltre, una breve sezione sarà dedicata 
all'applicazione delle metodologie Agile nella gestione dei progetti e dei prodotti, 
estendendosi oltre il settore dei sistemi informativi, con un confronto dettagliato tra le 
due metodologie, Waterfall e Agile, nel contesto più ampio del project management. 
Il terzo capitolo, invece, verterà sull’implementazione delle metodologie Agile all’interno 
dell’azienda Spotify. Verranno analizzati gli aspetti strutturali dell'organizzazione, come 
le Tribù, le Squadre, i Capitoli e le Gilde, oltre a valutarne i benefici e le sfide.  
Infine, si procederà con un'analisi della filosofia aziendale "People First" e la sua 
influenza sulla cultura organizzativa, in particolare per quanto riguarda il benessere, gli 
interessi e le preoccupazioni dei propri dipendenti, presentando al contempo diverse 
iniziative come: “Spotify Gives Back”, “Heart & Soul”, “Work from Anywhere”, ecc.
4 
 
1 IL WATERFALL MODEL 
1.1 Origini 
Durante gli anni '50 e '60, quando lo sviluppo del software cominciò a essere concepito 
come attività industriale, il metodo Waterfall, a seguito della crisi del software, fu il primo 
modello di ciclo di vita del software. La crisi, iniziata negli anni ’60 e proseguita fino 
agli anni ’80, fu un periodo di sconvolgimento nell’industria del software, nella quale i 
progetti erano generalmente in ritardo, con budget superiore e al di sotto delle 
aspettative. Le cause della crisi furono molteplici, tra cui: 
• La crescente complessità dei progetti di software: in cui i sistemi software 
diventavano sempre più complessi, rendendo difficile la loro progettazione e 
realizzazione. 
• L'assenza di metodologie di project management
1
 efficaci: i progetti di software 
erano spesso gestiti in modo informale, senza l'utilizzo di metodologie efficaci. 
• La mancanza di comunicazione e collaborazione tra gli sviluppatori: gli 
sviluppatori di software spesso lavoravano senza una comunicazione e una 
collaborazione efficace. 
Pertanto, per far fronte alle sfide della crisi, il modello a cascata, conosciuto anche come 
la prima metodologia tradizionale di project management, fu documentato per la prima 
 
1
 Pagnoni A., Engineering Manager vs. Tech Lead: cosa serve alla mia azienda? in 
https://www.ctomastermind.it/blog/engineering-manager-e-tech-lead-cosa-serve-alla-mia-azienda/ (20 novembre 
2023). Con il termine project management si intende come l’applicazione, a opera del project manager, di 
conoscenze, strumenti e tecniche all’insieme delle attività che costituiscono un progetto, al fine di 
permetterne il conseguimento degli obiettivi.
5 
 
volta da Benington nel 1956
2
 e modificato poi in seguito da Winston W. Royce nel suo 
articolo del 1970
3
. 
Il modello a cascata originale di 
Bennington raccomandava, come 
riporta Ruparelia nel suo articolo
4
, che 
lo sviluppo del software avvenisse con 
le seguenti fasi: analisi operativa → 
specifiche azionali → specifiche di 
progettazione e codifica → sviluppo → 
test → distribuzione → valutazione. 
Tuttavia, Royce ha apportato dei 
miglioramenti, poiché ha riscontrato 
una possibilità di sviluppo di difficoltà 
nella progettazione quando viene creata una linea di base alla fine di ogni fase, per questo 
ha introdotto un ciclo di feedback che permette di rivedere ogni fase precedente (Figura 
1). Pertanto, a Royce venne attribuito il merito di aver creato un sistema di gestione dei 
progetti lineare e rigoroso, nonostante abbia presentato questo modello come un esempio 
di metodo di sviluppo del software difettoso e vulnerabile a causa delle sue numerose 
carenze. Infatti, nel suo articolo afferma: «I believe in this concept, but the 
implementation described above is risky and invites failure.»
 5
, ed è per questo che 
presentò delle caratteristiche aggiuntive a questo approccio di base per eliminare la 
maggior parte dei rischi di sviluppo.  
Per di più, considerato che Royce non nominò mai questo modello “cascata”, il nome 
“Waterfall” apparì ufficialmente nel 1976 grazie all’articolo di T.E. Bell e T.A. Thayer
6
. 
 
2
 Benington D., 1983, “Reduction of Large Computer”, in Annuals of the History of Computing, vol. 5(04), 
pp.351–361. 
3
 Royce W. W., 1970, “Managing the Development of Large Software Systems”, in IEE Wescon, vol. 26. 
4
 Ruparelia N. B., 2010, “Software development lifecycle models”, in ACM SIGSOFT Softw. Eng. Notes , 
vol. 35(03) , pp.8-13. 
5
 Royce W. W., op. cit., p.329. 
6
 Bell T. E., Thayer T. A., 1976, “Software Requirements: Are they really a problem?”, in Proceeding of 
the 2nd international conference on Software Engineering, p.62. 
 
Figura 1 - Il modello Waterfall con feedback 
iterativo di Royce - “Software development 
lifecycle models”, Ruparelia N. B., 2010, p.9
6 
 
Figura 2 - Le Fasi del Waterfall Model - 
Royce W. W., 1970, Managing the 
Development of Large Software 
Systems”, p.329 
1.2 Le Fasi  
 
 
 
 
 
 
 
 
 
Il modello Waterfall, che si basa su un approccio logico-temporale in cui le attività sono 
svolte in sequenza e il progresso è considerato come un flusso costante verso il basso, 
non permette alcuna flessibilità. Questo perché prevede una sequenza di esecuzione 
chiaramente definita, con fasi del progetto indipendenti l'una dall'altra che avanzano fino 
a quando ciascuna fase non ottiene l'approvazione finale. 
Pertanto, questo modello si articola in sei fasi (Figura 2):  
 
• Analisi dei Requisiti (requisiti di sistema e software) 
In questa fase iniziale, considerata la più delicata, vengono definite le esigenze 
del cliente, in modo tale che si passi all’analisi e alla raccolta dei requisiti che il 
software deve possedere e all’utilizzo di quest’ultimi per determinare gli 
obbiettivi del progetto. Difatti come affermano Smith et al., in questa fase si 
prevede una comprensione dei bisogni degli stakeholder e una definizione dei 
requisiti di sistema, evidenziando l’importanza di quest’ultimi come chiari e 
inequivocabili per garantire risultati positivi nel progetto
7
.  
Questa fase comprende due attività: 
- Stesura dei requisiti, serve per determinare lo scopo esatto del sistema. 
- Analisi di fattibilità, è la valutazione del progetto in termini di costi, 
profitti e fattibilità. 
 
7
 Smith C., Johnson B., Brown A., 2018, “Requirements Analysis in the Waterfall Model”, in Journal of 
Software Development, vol. 15(01), pp.32-45.
7 
 
I requisiti dovranno inoltre specificare le risorse necessarie per il progetto, quale 
sarà il lavoro di ciascuno membro del team e in quale fase, stabilire una sequenza 
temporale per l'intero progetto che delinea quanto tempo richiederà ogni fase e 
i dettagli su ciascuna fase del processo. È inoltre, improbabile che essi saranno 
modificati dal progetto stesso durante il processo. 
Successivamente, verrà redatta un'analisi funzionale con l’obbiettivo di 
delineare i risultati del progetto al fine di limitare possibili conflitti tra le parti. 
È perciò importante che in questa fase siano coinvolti sia il cliente che 
l'organizzazione che gestisce il progetto.  
Al termine di questa fase, i requisiti del progetto devono essere riportati in modo 
chiaro e specifico all’interno del documento di specifica dei requisiti
8
, che sarà 
condiviso con l'intero team prima di passare alla fase successiva.  
• Progettazione  
Durante la fase di progettazione vengono definite l'architettura del sistema e le 
soluzioni applicative necessarie allo sviluppo del progetto.  
L'architettura software è la struttura generale del sistema software, che 
comprende le definizioni, le relazioni e le interfacce tra i suoi componenti, 
l’approccio tecnologico più adeguato, il modello dei dati e il tipo di archiviazione 
ed annessione degli stessi. Influisce sull’adoperabilità del software, sulla facilità 
di manutenzione, sulla scalabilità e sulla sicurezza. Una buona architettura 
dovrebbe essere modulare, duttile e adattabile al cambiamento. In sostanza, questa 
fase richiede una conoscenza approfondita delle funzionalità richieste dal sistema, 
delle tecnologie disponibili e delle possibili alternative.  
 
8
 Visure, Che cos'è la specifica dei requisiti: definizione, migliori strumenti e tecniche | Guida, in 
https://visuresolutions.com/it/blog/specifica-dei-requisiti/ (20 novembre 2023). 
Una specifica dei requisiti è un documento che delinea le esigenze specifiche di un progetto o di un sistema. 
La specifica dei requisiti è importante perché funge da base per tutto il lavoro futuro sul progetto. La 
specifica dei requisiti software (SRS) è diversa dalla specifica dei requisiti aziendali (BRS), sebbene siano 
correlate. L'SRS si concentra su ciò che il sistema deve fare, mentre il BRS si concentra sul motivo per cui 
il sistema è necessario e su come verrà utilizzato.  
Per una migliore comprensione vedi esempio di Fasolino A., Documento Di Specifica Dei Requisiti 
Software, in http://wpage.unina.it/fasolino/is/materiale/SRS/SRS-esempio.pdf  (Consultato il 23 ottobre 
2023).
8 
 
Dato che ogni progetto dispone delle proprie caratteristiche specifiche, il supporto 
dei team tecnici è essenziale per definire correttamente tutte le parti da sviluppare.  
Successivamente, i “tech leader”, coinvolti in base alla tipologia del progetto (ad 
esempio, programmatori, designer, copywriter, ecc.), dovranno procedere alla 
stima della quantità di lavoro necessaria per ultimare ciascuna fase del progetto
9
. 
Questa attività richiede un’analisi accurata delle risorse disponibili, delle attività 
necessarie e delle interazioni tra le diverse fasi del progetto, affinché che la stima 
della quantità di lavoro compiuta garantisca che il progetto sia completato entro i 
tempi e i costi previsti. Per compiere ciò, si possono impiegare diversi modelli di 
calcolo previsionale, tra cui uno dei più celebri in project management: il 
diagramma di Pert
10
. Pertanto, è per questo che in questa fase, si richiedono 
programmatori esperti in grado di tradurre le specifiche di progettazione in codice 
funzionale, poiché è significativa la qualità del codice e il rispetto degli standard 
di codifica per garantire l'affidabilità e la manutenibilità del software
11
. 
• Implementazione/Codifica 
La fase di implementazione, comunemente nota come sviluppo, è chiaramente la 
più lunga e impegnativa in termini di tempo e quella che impiega il maggior 
numero di risorse, poiché rappresenta il momento in cui viene scritto il codice 
software per realizzare le funzionalità previste nella fase di analisi dei requisiti. 
Durante questa fase, il team di sviluppo utilizza le tecnologie e gli strumenti 
selezionati nella fase di progettazione per codificare le specifiche funzionali in 
 
9
 EthictSoft Informatica, Il technical leader, in https://ethicsoft.it/articoli-il-technical-
leader#:~:text=Chi%20%C3%A8%20il%20Technical%20Leader,e%20ai%20requisiti%20di%20progetta
zione (17 novembre 2023). Un Tech leader è una figura professionale incaricata di fornire soluzioni ai 
problemi tecnici, responsabile del rispetto dei tempi di sviluppo e di garantire che la consegna sia conforme 
alle specifiche tecniche e ai requisiti di progettazione. 
10
 Rizzoli, 1996, “Grande Enciclopedia Rizzoli”, Milano, Rizzoli Editore, vol.12, p. 4518.  
PERT è la sigla di “Program Evaluation and Review Technique”, tecnica di ricerca operativa applicata nella 
programmazione di progetti di lavoro di grandi dimensioni. Consiste nel determinare le relazioni di 
precedenza tra le singole operazioni del progetto così da permetterne il controllo nel tempo e da stabilire i 
punti critici del programma.  
11
 Chen D., Johnson B., Smith C., 2020,” Implementation Challenges in the Waterfall Model”, in Software 
Development Journal, vol. 32(04), pp.78-92.
9 
 
codice eseguibile e per definire e sviluppare la struttura del software sulla base 
dell'architettura precedentemente progettata. Inoltre, dato l'uso dei linguaggi di 
programmazione e degli strumenti scelti nella fase di progettazione, è importante 
evidenziare quanto le competenze del team siano essenziali per la qualità del 
risultato finale. 
L’aspettativa è che il codice scritto sia conforme alle specifiche funzionali; 
tuttavia, in questo aspetto il Project Manager
12
 non ha margine di manovra ma è 
la competenza e il livello di “seniority” del team a garantire la qualità del prodotto 
finale. Sebbene il PM non possa selezionare direttamente i membri del team, può 
comunque svolgere un ruolo di coordinamento e supporto, ad esempio 
rimuovendo gli ostacoli e i problemi che limiterebbero la linearità alla 
concentrazione del team sul lavoro e garantire che ogni membro lavori al meglio 
delle proprie capacità. 
• Test/Verifica 
Tra le cinque fasi del Waterfall Model, questa è quella più trascurata e con il più 
basso livello di attenzione all’interno dell’intero flusso di sviluppo di un software 
in modalità Waterfall. Ciò è dovuto al fatto che spesso si tende a ridurre 
drasticamente il tempo ad essa dedicata per cercare di recuperare il ritardo che 
tipicamente si è accumulato nelle fasi precedenti, soprattutto quella di 
implementazione.  La fase di “Test” consente di accertare che il software funzioni 
correttamente e sia rispondente alle specifiche funzionali, effettuando una serie di 
verifiche per garantire che svolga lo scopo previsto. 
Tornando alla fase di progettazione, è importante definire i processi da testare 
attraverso una strategia chiara che consente di verificare singolarmente tutte le 
funzionalità del software e le dipendenze associate, al fine di identificare eventuali 
problemi o bug. Ecco perché la strategia di testing deve essere definita in termini 
di specifiche funzionali e deve includere:  
- I test funzionali: consistono nella verifica delle funzionalità del software e 
nella valutazione del loro comportamento in diverse situazioni, 
consentendo di verificare che il software risponda correttamente alle 
 
12
 Dall’Enciclopedia Treccani, il Project Manager è colui che ha il compito di gestire un singolo programma 
o la programmazione del lavoro in un’azienda, ed è responsabile della verifica dei risultati.
10 
 
richieste dell’utente e che le funzionalità siano rispondenti alle specifiche 
funzionali. 
- I test non funzionali: vengono utilizzati per verificare le caratteristiche del 
software non direttamente correlate alle funzionalità, come la sicurezza, le 
prestazioni, la scalabilità e la compatibilità con altri sistemi. 
Per valutare la qualità e la stabilità del software durante la fase di test, come 
affermano Smith e Johnson, sono molto importanti i test completi ed è per questo 
che si utilizzano diverse tecniche e strumenti che garantiscono la qualità del 
software
13
: 
- I test unitari: consistono nella verifica delle singole unità di codice. 
- I test di integrazione: consentono di verificare la corretta integrazione delle 
diverse unità di codice. 
- I test di sistema: consentono di verificare il corretto funzionamento del 
software nel suo complesso. 
- I test di accettazione: consentono di verificare che il software sia conforme 
alle specifiche funzionali e che soddisfi le esigenze dell’utente. 
Tutti i test eseguiti devono essere registrati e documentati, in modo che i problemi 
possano essere facilmente identificati e le correzioni effettuate, per garantire che 
il software sia mantenuto correttamente nel tempo. 
Perciò, nonostante la tentazione di usare scorciatoie e omissioni, la fase di "test" 
è un passaggio importante per verificare la qualità del software, identificare 
problemi o bug e ridurre al minimo i rischi. 
• Distribuzione (operazioni) 
Nella fase di distribuzione, il prodotto software viene rilasciato e installato 
nell'ambiente operativo in cui dovrà essere eseguito, perciò la conoscenza 
analitica di quest'ultimo è fondamentale, sia che vengono attuate soluzioni stand-
alone (installate fisicamente sulle macchine), o soluzioni web-based 
(pubblicazione online del software).  
 
13
 Smith C., Johnson B., 2017, “Testing Techniques in the Waterfall Model”, in Software Quality Journal, 
vol. 22(03), pp.78-92.