Alai

Se sapessimo cosa stiamo facendo, non si chiamerebbe ricerca.

-Albert Einstein

Gli Spikes sono un tipo di esplorazione Enabler Story in SAFe. Definiti inizialmente in Extreme Programming (XP), rappresentano attività come la ricerca, il design, l’investigazione, l’esplorazione e la prototipazione. Il loro scopo è quello di ottenere la conoscenza necessaria per ridurre il rischio di un approccio tecnico, capire meglio un requisito, o aumentare l’affidabilità della stima di una storia.

Come le altre storie, le punte sono stimate e poi dimostrate alla fine dell’Iterazione. Forniscono anche un protocollo concordato e un flusso di lavoro che i Treni di Rilascio Agile (ART) usano per aiutare a determinare la fattibilità degli Epici.

Agile e Lean apprezzano i fatti rispetto alle speculazioni. Di fronte a una domanda, un rischio o un’incertezza, i team Agile conducono piccoli esperimenti prima di passare all’implementazione, piuttosto che speculare sul risultato o saltare a una soluzione. I team possono usare i picchi in una varietà di situazioni:

• Stimare nuove funzionalità e capacità per analizzare il comportamento implicito, fornendo informazioni sull’approccio per dividerle in pezzi più piccoli e quantificabili
• Eseguire analisi di fattibilità e altre attività che aiutano a determinare la fattibilità delle epopee
• Condurre ricerche di base per familiarizzare con una nuova tecnologia o dominio
• Acquisire fiducia in un approccio tecnico o funzionale, riducendo il rischio e l’incertezza

Le punte comportano la creazione di un piccolo programma, attività di ricerca o test che dimostri qualche aspetto della nuova funzionalità.

Punte tecniche e funzionali

Le punte sono principalmente in due forme: tecniche e funzionali.

Punte funzionali – Sono usate per analizzare il comportamento generale della soluzione e determinare:

• Come suddividerla
• Come organizzare il lavoro
• Dove esistono rischi e complessità
• Come usare le intuizioni per influenzare le decisioni di implementazione

Punte tecniche – Sono usate per cercare vari approcci nel dominio della soluzione. Per esempio:

• Determinare una decisione build-versus-buy
• Valutare il potenziale impatto sulle prestazioni o sul carico di una nuova user story
• Valutare specifici approcci di implementazione tecnica
• Sviluppare la fiducia sul percorso di soluzione desiderato

Alcune caratteristiche e user story possono richiedere entrambi i tipi di spike. Ecco un esempio:

“Come consumatore, voglio vedere il mio uso giornaliero di energia in un istogramma in modo da poter capire rapidamente il mio consumo di energia passato, attuale e previsto.”

In questo caso, una squadra potrebbe creare entrambi i tipi di picchi:

• Un picco tecnico per ricercare quanto tempo ci vuole per aggiornare il display di un cliente all’uso corrente, determinando i requisiti di comunicazione, la larghezza di banda, e se spingere o tirare i dati
• Un picco funzionale – Prototipare un istogramma nel portale web e ottenere un feedback dagli utenti sulla dimensione della presentazione, lo stile e i grafici

Guidelines for Spikes

Siccome i picchi non forniscono direttamente valore all’utente, usali con parsimonia. Si applicano le seguenti linee guida.

Quantificabile, dimostrabile e accettabile

Come altre storie, gli spike sono messi nel Team Backlog, stimati e dimensionati per essere inseriti in un’iterazione. I risultati degli spike sono diversi da una storia perché gli spike tipicamente producono informazioni piuttosto che codice funzionante. Dovrebbero sviluppare solo i dati necessari per identificare e dimensionare le storie che lo guidano con fiducia.

L’output di uno spike è dimostrabile, sia per il team che per qualsiasi altro stakeholder, il che porta visibilità agli sforzi di ricerca e di architettura, e aiuta anche a costruire una proprietà collettiva e una responsabilità condivisa per il processo decisionale. Il proprietario del prodotto accetta i picchi che sono stati dimostrati e soddisfano i suoi criteri di accettazione.

Tempistica dei picchi

Poiché rappresentano l’incertezza in una o più storie potenziali, pianificare sia il picco che le storie risultanti nella stessa iterazione è talvolta rischioso. Tuttavia, se è piccola e diretta, e se è probabile che si trovi una soluzione rapida, allora può essere abbastanza efficiente fare entrambe le cose nella stessa iterazione.

L’eccezione, non la regola

Ogni storia utente ha incertezza e rischio; questa è la natura dello sviluppo Agile. Il team scopre la soluzione giusta attraverso la discussione, la collaborazione, la sperimentazione e la negoziazione. Così, in un certo senso, ogni storia utente contiene attività simili a spike per identificare i rischi tecnici e funzionali. L’obiettivo di un team Agile è quello di imparare come affrontare l’incertezza in ogni iterazione. Gli spike sono critici quando esiste un’alta incertezza o ci sono molte incognite.

Per saperne di più

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.

Ultimo aggiornamento: 10 febbraio 2021