---

Dovevi pianificare tutto il progetto prima di comprenderlo? Potrebbe sorprenderti!

Senza Scrum, i nostri team avevano costruito e consegnato prodotti software e hardware completamente sbagliati, che non soddisfacevano le richieste dei clienti.

Ci sono stati momenti nella nostra vita professionale in cui aziende terze imponevano come costruire prodotti e servizi software.

Capability Maturity Model (CMM), ISO 9001:2008 e altri derivati cercavano di aiutare le aziende a costruire il software giusto nel modo giusto.

Il loro successo non è argomento di questo libro, che si concentra sul processo Scrum e sui vantaggi del framework anziché criticare procedure quasi estinte.

Devo però aggiungere che questi framework di miglioramento dei processi, precedenti all'ingegneria Scrum, raccomandavano un approccio per fasi. Suggerivano un'ingegneria del software suddivisa in fasi che chiamavamo modello di ingegneria del software Waterfall.

Con il modello Waterfall, ogni progetto iniziava con l'analisi dei requisiti per comprendere esigenze e desideri del cliente.

Poi progettavamo i requisiti, li implementavamo, li testavamo (verificavamo) e li mantenevamo negli ambienti di produzione. Infine raggiungevamo la fine del ciclo di vita dell'ingegneria del software.

La realtà, però, non andava così!

La metodologia Waterfall e il framework Scrum a confronto

Fasi del modello classico di sviluppo software a cascata

Gli effetti negativi di ritardi imprevisti in una fase Waterfall erano inevitabili per le fasi successive.

Gli studi mostrano che, in oltre l'80% dei progetti software falliti esaminati, l'uso della metodologia Waterfall era uno dei fattori cruciali dell'insuccesso. Ma perché?

Come mostrato a sinistra, Waterfall prevede una catena strettamente sequenziale di fasi. Una deve finire prima che inizi la successiva. Tornare indietro è generalmente difficile, costoso, frustrante per il team e dispendioso in tempo.

Il calendario viene pianificato all'inizio. Un prodotto rilasciabile viene consegnato soltanto alla fine. Se una fase ritarda, ritardano anche tutte le altre.

Per evitarlo, i Project Manager Waterfall cercano solitamente di prevedere tutto in anticipo. In una delle primissime fasi definiscono i requisiti nel modo più dettagliato e completo possibile. Ma farlo all'inizio è spesso complesso e molti requisiti cambiano, o dovrebbero cambiare, durante il progetto.

Gli studi mostrano che nei progetti più grandi e complessi cambia circa il 60% dei requisiti iniziali. Altri vengono implementati come definiti, ma alcuni non servono davvero al cliente. Consumano quindi tempo e denaro che avrebbero potuto realizzare funzionalità con maggiore valore aggiunto.

La separazione in fasi obbliga a stimarle singolarmente. Il problema è che generalmente non sono separate: lavorano insieme e in parallelo.

Per esempio, nessuna persona ragionevole può presumere che lo sviluppo termini prima dell'inizio dei test. Eppure, purtroppo, Waterfall funzionava esattamente così.

La metodologia Waterfall può essere usata per progetti software piccoli e semplici. Ma per quelli più grandi e complessi è un approccio altamente rischioso, se non folle. È spesso più costoso e sempre meno efficiente del framework Scrum per sviluppo e consegna software.

Questa era la vita prima di Scrum. Passare il software avanti e indietro tra team, senza la guida di professionisti con competenze Scrum, rendeva il lavoro burocratico, complesso e improduttivo.

Alla fine non soffriva soltanto il prodotto: anche il morale e l'impegno nella missione organizzativa erano completamente compromessi.