Skip to main content

Nel mondo del software e della gestione dei progetti, l’agilità è una parola d’ordine che promette di trasformare il modo in cui le squadre lavorano e consegnano valore. Una delle tecniche emergenti in questo ambito è l’uso degli “Spikes”, una storia abilitante di esplorazione nel Scaled Agile Framework (SAFe), inizialmente definita nell’Extreme Programming (XP).

Gli Spikes sono utilizzati per acquisire la conoscenza necessaria a ridurre il rischio di un approccio tecnico, comprendere meglio un requisito o aumentare l’affidabilità di una stima di storia. Questa attività di indagine, che può includere ricerca, progettazione, esplorazione e prototipazione, produce informazioni piuttosto che codice funzionante.

Principi Fondamentali Nell’agile e nel lean, i fatti hanno la precedenza sulle speculazioni. Di fronte a domande, rischi o incertezze, i team agili conducono piccoli esperimenti prima di passare all’implementazione. È anche importante che i team pianifichino e allocchino tempo per diventare più competenti. Il termine “spike” si riferisce a un’attività di ricerca temporizzata.

Quando Utilizzare uno Spike? A volte il team non è sicuro di poter completare la storia a causa di potenziali ostacoli e potrebbe persino non essere in grado di stimare la storia. Il Product Owner assegna una piccola parte della capacità del team ora, prima che la storia debba essere consegnata, in modo che quando la storia entra nello sprint, il team sappia cosa fare.

Esempi di Utilizzo degli Spikes:

  • Il team potrebbe non avere conoscenza di una nuova tecnologia e gli spikes possono essere utilizzati per la ricerca di base per garantire la fattibilità della nuova tecnologia.
  • Ricerca di base per familiarizzare con una nuova tecnologia o dominio.
  • Acquisire fiducia in un approccio tecnico o funzionale, riducendo rischi e incertezze.
  • Alcune conoscenze sono necessarie per decidere tra diverse architetture.
  • Analisi di fattibilità e altre attività che aiutano a determinare la vitalità degli epic.
  • Una storia richiede di essere implementata utilizzando una libreria di terze parti con un’API scritta e documentata male.

Criteri di Accettazione Come ogni altra storia utente, gli spikes devono soddisfare alcuni criteri per ottenere lo stato di “completato”, assicurandosi che la “Storia dello Spike” sia stimabile, dimostrabile e accettabile.

Stimabile Come altre storie, gli spikes vengono inseriti nel backlog. Uno Spike di solito non riceve una stima di Story Point, ma viene assegnato un numero fisso di ore per essere lavorato. In ogni caso, lo spike dovrebbe sviluppare solo le informazioni sufficienti per risolvere l’incertezza nell’essere in grado di identificare e dimensionare le storie nascoste sotto lo spike.

Dimostrabile Il risultato di uno spike viene dimostrato al team nella Sprint Review. Questo porta visibilità agli sforzi di ricerca e architettura e aiuta anche a costruire un possesso collettivo e una responsabilità condivisa per le decisioni chiave che vengono prese. Sulla base delle nuove informazioni, la domanda originale viene riformulata come una nuova User Story in uno Sprint futuro.

Accettabile Come ogni altra storia, gli spikes vengono accettati dal product owner quando i criteri di accettazione per lo spike sono stati soddisfatti.

Tipi di Spikes Gli Spikes architettonici si presentano principalmente in due forme: funzionali e tecnici.

In sintesi, gli Spikes sono un potente strumento per navigare nell’incertezza e per emergere con soluzioni più informate e affidabili, contribuendo significativamente alla qualità e al successo del prodotto finale.

Lascia un commento