spike immagine decorativa
trianglee

Insights Spike solutions: affrontare i rischi con efficacia nel SW (solo?)

Per chi fa uso (e a volte abuso) delle spike, o per chi non ne ha mai sentito parlare, in questo articolo trovate qualche informazione su come sono nate, perché, e su quali aspetti stare attenti. Sono concetti che interessano per lo più chi realizza prodotti SW ma non solo.

Linkedin Twitter
Scroll
02/09/2020

Articoli

di Stefano Muro

 

Di recente ho iniziato a seguire un paio di team scrum appena formati e, essendoci alcuni rischi tecnologici da mitigare, questi hanno deciso di eseguire alcune spike. Confrontandomi anche con alcuni colleghi e amici Scrum Master, mi sono reso conto che sulla definizione di spike c’è un po’ di confusione e interpretazioni contrastanti: alcuni fanno sprint di sole “spike” (di solito 2 o 3) ma saltano la sprint review, altri non implementano una storia se prima non c’è stato una spike. La maggior parte interpreta come “spike” lo studio di soluzioni tecniche, senza però definire un perimetro ben delimitato: ovviamente questo genere di attività può durare anche mesi.

 

Al di là del piacere nel vedere che la spike sia una delle pratiche di XP maggiormente diffuse a prescindere del processo di sviluppo adottato, mi sono pertanto reso conto che spesso mancano dei punti di riferimento fondamentali per definire una spike e renderla veramente efficace. Di seguito ho provato ad identificare questi riferimenti sperando che vi siano utili. In fondo all’articolo vi porrò anche un quesito su cui vi invito a ragionare. Buona lettura!

 

Incominciamo dalla definizione:

“I would often ask Kent (Beck ndr), “What is the simplest thing we can program that will convince us we are on the right track?” Such stepping outside the difficulties at hand often led us to simpler and more compelling solutions. Kent dubbed this a Spike.”

Questo episodio riportato da Ward Cunningham (inventore del concetto di wiki e firmatario del manifesto agile per lo sviluppo SW) descrive chiaramente l’origine della spike solution: il più semplice programma “end to end” in grado di convincerci che stiamo seguendo la strada giusta; una’altra buona definizione è secondo me quella di programma più semplice possibile che ci consenta di apprendere informazioni sufficienti su un problema o un oggetto sconosciuto così da poter individuare una soluzione per gestirlo.

 

Sebbene in principio le spike solutions fossero principalmente strumenti volti a mitigare rischi tecnici (in termini di design tecnologie), la sua definizione si è nel tempo allargata: a titolo di esempio sul sito di Safe le spike sono identificate come “enabler stories” il cui scopo è “ridurre il rischio di un approccio tecnico, capire meglio un requisito o aumentare l’affidabilità della stima di una storia. E’ da notare l’introduzione, legata al discorso della comprensione del requisito, del concetto di spike funzionale che ha lo scopo di mitigare un rischio relativo all’interazione tra l’utente e il sistema in fase di realizzazione (in questo senso un mockup, un wireframe o un prototipo parzialmente funzionante possono essere considerati spike).

 

A prescindere di quale sia la definizione da voi preferita, in ogni caso la spike (solution) è un esperimento volto a mitigare un rischio e, in quanto tale deve avere delle caratteristiche ben precise che qui di seguito proviamo ad elencare:

 

La spike è una implementazione (SW?) ma non deve andare in produzione.

 

La spike, risponde ad una necessità ben precisa del team: mitigare un rischio tecnologico, architetturale o funzionale che sia, valutando una o più opzioni, imparando dall’esperienza invece che affrontando il problema da un punto di vista puramente teorico.

 

Sebbene il perimetro è bene che sia legato ad una specifica esigenza utente (user story) da implementare, la spike non richiede tutte le accortezze richieste dal SW che va rilasciato, perché nel caso in cui l’esperimento fallisca, il SW creato va buttato, quindi più semplice e veloce è l’implementazione e meglio è; a volte è sufficiente scrivere un test.

 

Scopo (Purpose) e Perimetro (Scope).

 

La spike deve avere uno scopo ben preciso legato ad un rischio da mitigare/risolvere: lo studio a prescindere di una nuova infrastruttura o di un nuovo linguaggio non può essere di per sè chiamata una spike a meno che non sia legato a uno specifico rischio, ad es. di performance.

 

Ad esempio “studio della migrazione da database relazionale a database a grafo” non può essere considerata una spike, ha molto più senso qualcosa del tipo: “confronto delle prestazioni nello storage/retrieve delle informazioni relative al percorso di un camion della raccolta vetro usando l’attuale database relazionale (es. oracle) e un set di database a grafo (es. oracle graph e orientdb)”. Lo scopo in questo caso dello spike potrebbe essere la riduzione del 30% nel tempo medio delle operazioni di query sui percorsi (perimetro), mantenendo prestazioni analoghe per le update e garantendo la consistenza della base dati.

 

Il focus è fondamentale: non di rado mi sono imbattuto in team che al termine dell’attività avevano affrontato problematiche che andavano ben al di là del contesto specifico che aveva reso necessario fare una esplorazione (con uno spreco notevole di risorse). Al contrario, mi è capitato di vedere team che hanno fatto spike di settimane senza poi aver effettivamente mitigato il rischio alla radice e quindi selezionando soluzioni non adatte alle esigenze dell’applicativo in fase di sviluppo.

 

Per evitare che ciò accada, è molto utile definire sin dall’inizio dei criteri di accettazione che consentano di capire quando la spike solution è finita (ossia quando si è raggiunto il minimo livello di conoscenza sufficiente tale da consentirci di prendere una decisione sulle differenti opzioni).

 

Durata limitata nel tempo

 

La regola di Extreme programming relativa alle spike recita: “When a technical difficulty threatens to hold up the system’s development put a pair of developers on the problem for a week or two and reduce the potential risk.”

 

L’idea è che le spike durino al massimo il tempo di un’iterazione (sprint se usate Scrum) ma è importante ricordare che è comunque il più piccolo e semplice esperimento volto a mitigare un rischio, mai come negli spike vale il motto “fail fast, learn fast”.

 

Di conseguenza se il rischio da mitigare è l’incertezza sulla stima di una storia la spike non può durare uno sprint: La mia idea è che le spike in generale debbano essere così brevi che non ci sia neanche bisogno di pianificarle o stimarle con una durata compresa tra 15 min e 2-3 ore.

 

Certo, spesso i rischi e le problematiche da mitigare sono molto più grandi ma, una strategia che spesso ho visto adottare e io stesso adotto, al fine di mantenere massimo il focus su un problema specifico, è quella di associare alla spike un time box massimo di uno-due giorni. L’idea è che se ci sono tematiche molto vaste da affrontare (ad es. la migrazione ad un nuovo database), si individuino dei “sotto-rischi” ordinati per priorità per cui le spike puntino a validare le soluzioni: in questo modo in caso di fallimento, le soluzioni possono essere scartate o rivalutate al massimo dopo 2 giorni, non 2 settimane .

 

Dimostrazione

 

L’esito della spike va mostrato a tutto il team in modo da condividere e rendere proprietà comune la conoscenza (architetturale, funzionale o tecnica che sia) acquisita e ricevere eventuali feedback e idee su come utilizzare quanto emerso. Ricordate che lo scopo delle spike è fondamentalmente l’apprendimento, la conoscenza e questa, in un team agile, deve essere patrimonio collettivo, non dell’individuo.

 

Spero che questo articolo vi abbia chiarito qualche concetto e vi risulti in qualche modo utile ma vorrei lasciarvi con una riflessione:

 

il concetto di spike solution può essere secondo me applicato (con le dovute varianti) a qualsiasi ambito in cui sia possibile realizzare velocemente un prototipo, dal marketing all’ingegneria meccanica.