Spike: Cos'è ?
La pratica Prove It With Code / Spike Solution / Build Prototypes (vedere [AC_PRT]), prevede di sviluppare un prototipo laddove si sia in presenza di dubbi e/o potenziali rischi (a livello di Analisi / Design / Applicativo / Tecnologico) da chiarire / esplorare / consolidare.
In XP, tale programma di prova viene chiamato Spike.

Spike: Perché ?
Lo Spike è utile in svariate situazioni:

• Consolidare la validità delle principali scelte architetturali intraprese e verificare i punti ritenuti delicati e/o critici del Modello di Design
• Esplorare costi e benefici legati al Design effettuato (es: utilizzo corretto dei pattern, verificare se il Design è sotto-ingegnerizzato o sovra-ingegnerizzato, …)
• Esplorare ed approfondire aree di Analisi/Design/Tecnologiche poco chiare per ridurre il rischio di incorrere in problemi tecnici durante la fase di sviluppo
• Ottenere indicazioni attendibili sulla mole di lavoro necessaria per implementare requisiti particolarmente impegnativi
• Migliorare la conoscenza tecnica (es. scarsa conoscenza del linguaggio, uso prodotti di nuova generazione o mai usati in precedenza).
• Sperimentare in modo mirato nuove tecnologie
  

Spike: Come ?
Lo Spike può assumere varie "forme e dimensioni" in funzione dello specifico obiettivo per cui viene creato. Ad esempio, per validare presso il Customer un'interfaccia grafica complessa, si può decidere di realizzare una pagina statica HTML che in tempi rapidi proponga il layout al Customer, consentendo di raccogliere gli eventuali feedback prima della realizzazione definitiva (JSP/ASPX).

Figura 1: Uno Spike GUI

Uno Spike può anche essere una semplice classe di test che, ad esempio, metta in rilievo le funzionalità ed il comportamento di uno o piu' oggetti di business che solo in un secondo momento saranno realizzati nella loro completezza.

Figura 2: Uno Spike costituito da una classe Java di Test

Nei casi piu' delicati/complessi si può trattare di un prototipo completo (end-to-end) che implementi una o piu' funzionalità campione e che consenta di verificare le principali scelte Architetturali o di validare una "Candidate Architecture".

Figura 3: Prototipo end-to-end

Nel caso si intenda verificare l'uso di linguaggi/prodotti/tecnologie nuove o mai usate in precedenza, uno Spike può essere utile per acquisire know-how.
Ad esempio negli articoli [MOKA_INT5] e [MOKA_JCA_CICS] abbiamo effettuato degli Spike per prendere confidenza con i web services e con i connettori JCA.

Figura 4: Spike tecnologici

Da quanto detto precedentemente si evince che lo Spike deve puntare, in modo "cinico" e mirato, a chiarire il motivo per cui è stato "pensato". Lo Spike deve quindi ignorare i dettagli implementativi (non deve andare in produzione) e può essere "grezzo" da un punto di vista di codifica. Per questo motivo, spesso, gli Spike non sono riusabili e devono essere "buttati via" una volta assolto il loro compito "esplorativo".

Spike: Quando ?
Come si è detto, uno Spike può essere avviato per ridurre possibili rischi o punti da chiarire/verificare, in questo senso è ipotizzabile ad ogni iterazione.
In RUP si prevede la costruzione di un prototpipo end-to-end alla fine di ogni iterazione nelle fasi di Inception/Elaboration (vedere [MOKAMET_1]) per capire la fattibilità/ritorni del progetto e per verificare/consolidare/approfondire le principali scelte Architetturali.
In XP lo Spike è invece previsto ad ogni iterazione nella fase di Pianificazione (vedere [MOKAMET_2]) principalmente per la stima di una user-story.

Figura 5: Quando effettuare uno Spike in XP

Conclusioni
Con questo articolo si conclude la mini-serie dedicate alle Pratiche di sviluppo del software.
Le pratiche che abbiamo presentato sono:

• Test Driven Development (vedere [MOKA_TDD] e [MOKA_QS_2])
• Refactoring (vedere [MOKA_REFAC])
• Continuous Integration (vedere [MOKA_CI_1] e [MOKA_CI_2)])
• Coding Standards (vedere [MOKAMET_2] e [MOKA_QS_1])
• Collective Code Ownership e Pair Programming (vedere [MOKAMET_2])
• Spike Solution

Bibliografia
[MOKAMET_1] S. Rossini: Processi e metodologie di sviluppo(II): introduzione alle
metodologie di sviluppo- Mokabyte 83 Marzo 2004
[MOKAMET_2] S. Rossini: Processi e metodologie di sviluppo(II): Le Metodologie Agili -
Mokabyte 85 Maggio 2004
[MOKA_TDD] S. Rossini, Pratiche di sviluppo del software (I): Test Driven Development,
MokaByte N.86 - Giugno 2004
[MOKA_REFAC] S. Rossini, Pratiche di sviluppo del software (IV): Il Refactoring
MokaByte N.86 - Giugno 2004
[MOKA_CI_1] Stefano Rossini, A. D'Angeli: Pratiche di sviluppo del software (II)
Continuous Integration: la teoria - Mokabyte N.87 Luglio Agosto 2004
[MOKA_CI_2] Stefano Rossini, A. D'Angeli: Pratiche di sviluppo del software (III)
Continuous Integration: la pratica - Mokabyte N.88 Settembre 2004
[MOKA_QS_1] S. Rossini: Qualità del software: auditing del codice
Mokabyte N. 90 - Novembre 2004
[MOKA_QS_2] S. Rossini: Qualità del software(II): i Test - Mokabyte N. 91 - Dicembre 2004
[MOKA_INT5] S.Rossini, A. D'Angeli: Integrazione di applicazioni Enterprise (V) MokabyteN.74-Settembre 2003
[MOKA_JCA_CICS] S. Rossini: JCA VI parte: un Resource Adapter per accedere a CICS -
MokaByte 89 - Ottobre 2004
[PAM] Scott W. Ambler: The Practices of Agile Modeling (AM)-
http://www.agilemodeling.com/practices.htm
[SA_AMRUP] http://www.agilemodeling.com/essays/agileModelingRUP.htm: S. Ambler: Agile Modeling and the Rational Unified Process (RUP)
[XP_CSS] Create Spike Solution: http://www.extremeprogramming.org/rules/spike.html
[WK_SS] Spike Solution: http://c2.com/cgi/wiki?SpikeSolution
[WK_SS2] http://c2.com/cgi/wiki?HowXpPlansDeploymentDiscussion
[XP] Estreme Programming: A gentle introduction - http://www.extremeprogramming.org [XP_12P] http://www.xpexchange.net/english/intro/practices.html
[AM_XP] Scott W. Ambler: Agile Modeling and eXtreme Programming (XP)
http://www.agilemodeling.com/essays/agileModelingXP.htm
[AC_PRT] AlistairCockburn's :
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?BuildPrototypes
[AC_CTF] AlistairCockburn's : Clear The Fog:
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ClearTheFog