Un Waterfall iterativo non è agile
Negli ultimi due anni ho notato una tendenza preoccupante – in team di tutto il mondo.
È la tendenza a creare un processo Waterfall iterativo e poi chiamarlo “agile”.
Un Waterfall iterativo
In uno Sprint qualcuno (forse un Business Analyst insieme al Product Owner) cerca di capire cosa deve essere sviluppato.
Poiché si vuole essere agili, si lavora con le User Story. Ma invece di trattare le User Story come segnaposto per conversazioni future, ogni User Story diventa un piccolo documento di specifica di tre-cinque pagine – e ne ho visti anche di più lunghi.
Queste mini-specifiche/User Story documentano quasi tutto ciò che può venire in mente.
Poiché serve un intero Sprint per scoprire e documentare tutto ciò, un secondo Sprint viene dedicato al design dell’interfaccia utente della User Story. A volte il team cerca di essere un po’ più agile (almeno in teoria) e inizia il lavoro di design poco prima che la mini-specifica per una User Story sia completamente scritta.
Molti membri del team vedono questo come pericoloso, perché le specifiche non sono ancora completamente definite. Ma vabbe’, a questo punto entra in gioco l’agilità.
Ai programmatori vengono poi consegnati due documenti. Uno mostra chiaramente come la User Story dovrà apparire alla fine, e l’altro fornisce tutti i dettagli rilevanti sul comportamento della Story.
Si può iniziare a programmare solo quando entrambi questi artefatti sono pronti. In alcune aziende sono i programmatori stessi a imporre questo modo di lavorare. Hanno l’atteggiamento di sviluppare tutto ciò che si vuole – ma è meglio dir loro esattamente cosa serve all’inizio dello Sprint.
Alcune organizzazioni vanno ancora oltre e fanno lavorare i tester un’iterazione indietro rispetto ai programmatori. Questo sembra accadere perché le User Story di un team diventano più grandi quando ogni Story deve avere una mini-specifica e un design UI completo prima che il codice possa essere scritto.
Fortunamente la maggior parte dei team capisce che programmatori e tester devono lavorare nella stessa iterazione, tuttavia non estendono questa teoria a un intero team che collabora.
Questo porta al seguente processo
Una prima iterazione viene dedicata all’analisi. Una seconda iterazione (che può sovrapporsi leggermente alla prima) viene dedicata al design dell’esperienza utente e la terza iterazione è pensata per la codifica e il testing. Questo non è agile. Potrebbe essere il primo passo di un’organizzazione verso l’agilità. Ma non è agile.
È un Waterfall iterativo.
Nello sviluppo tradizionale con Waterfall, un team svolge tutta l’analisi per l’intero progetto all’inizio. Poi viene affrontato tutto il design per il progetto. Poi viene scritto tutto il codice per il progetto. Poi vengono eseguiti tutti i test per il progetto.
Nel processo Waterfall iterativo appena descritto, il team fa fondamentalmente lo stesso, ma ogni Story viene trattata come un piccolo progetto a sé. Prima viene completata tutta l’analisi per la Story, poi il design per quella Story, poi viene scritto tutto il codice e testato tutto. Questo è un processo Waterfall iterativo, non un processo agile.
In un processo agile, idealmente tutti i lavori verrebbero completati esattamente nello stesso momento. Il team finirebbe quindi contemporaneamente l’analisi del problema, il design della soluzione, il codice e i test per quella soluzione. Tutte e quattro le discipline (e altre che non ho menzionato in questo esempio) sarebbero completate esattamente nello stesso momento.
È un po’ ingenuo credere di poter raggiungere questo al 100%. (A volte ci si riesce.) Può però essere un obiettivo verso cui un team lavora.
Un team dovrebbe sempre cercare di svolgere il più lavoro possibile contemporaneamente. Tutte le riflessioni preliminari (analisi, design ecc.) dovrebbero essere fatte il più tardi possibile, non essere troppo dettagliate e allo stesso tempo rendere possibile il completamento del lavoro durante l’iterazione.
Se tratti le tue User Story come piccoli documenti di specifica, smetti di farlo. Inizia invece a vedere ogni Story come un segnaposto per una conversazione. Puoi aggiungere alcune note alle Story con cose che non vuoi dimenticare alla prossima riunione. Queste note dovrebbero però essere opzionali e non un passaggio necessario in un processo sequenziale. Questo mantiene l’agilità e impedisce che il processo diventi un Waterfall.
Questo testo proviene dal blog di Mike Cohn ed è stato da noi tradotto in italiano.
Gestione degli Stakeholder
=> Impara i consigli e i trucchi più importanti di Roman Pichler sulla gestione degli Stakeholder
Definition of Done: semplice eppure complessa
=> Scopri come la Definition of Done ti aiuta nel lavoro agile.
Come si svolge una Sprint Review?
=> Qui trovi un’agenda esemplificativa per la Sprint Review
