Cos'è

È il tentativo di applicare valori agili ad una situazione anomala come quello di un xpug per trovare un modo efficace di lavorare anche con queste condizioni.

Dove nasce

Nasce da una sparata del sottoscritto (Simone) - probabilmente anche influenzato dalle due pinte di Guinness bevute all'Old Fox Pub - nell'ambito di un meeting di retrospettiva dell'xpug-milano.

Si stava discutendo su come approcciare la prossima iterazione considerato che quella appena finita non aveva portato i risultati previsti ed io - confidando nell'efficacia di XP (e probabilmente anche sopravvalutando la mia esperienza) - mi sono immaginato che se fossi riuscito ad adattare quei valori a questa situazione avrei probabilmente ottenuto un modo più efficace di lavorare.

In un impeto ho sparato nel mucchio ed il buon Gabriele ha colto al volo l'occasione incatenandomi abilmente alle mie parole.

Penso di aver detto qualcosa del genere: "Datemi due pair ed io vi organizzo un ciclo XP completo nelle tre ore del meeting... e alla fine sono sicuro che avremmo fatto meglio degli altri" (ndr molto Archimede l'inizio della frase)

Con ciclo completo intendevo pianificazione più implementazione.

Ok, l'ho sparata grossa, datemi almeno l'attenuante dell'alcool. (c:

In ogni caso penso che possa essere un buon esercizio per mettere alla prova quanto ho capito/imparato fin'ora e per allenare le capacità di improvvisazione ed adattamento.

Obiettivo

Trovare un modo di lavorare più efficace attraverso il continuo adattamento di valori, principi e pratiche agili ad una situazione molto particolare.

Requisiti

• gli Acceptance Test (offerti gentilmente dalll'xpug)
• macchine produttive (ovvero ci si può lavorare comodamente senza perdere un'ora per far girare il primo "hello test")
• qualche volenteroso partecipante dell'xpug
• almeno una story-card - ricevuta all'inizio del meeting - che spero di poter restituire alla fine con tanto di Acceptance Test funzionanti

Metriche

Integrare

L’idea di questo secondo anno dell’xpug-milano è la seguente: tutti i pair sviluppano la stessa storia ed i primi che fanno riescono a far passare tutti i test “vincono” il diritto di integrare il loro codice. Tutti gli altri lo buttano.

Ovviamente il gruppo ha diritto di veto se il codice prodotto non rispetta i canoni di qualità richiesti.

Questo è semplice: se integriamo noi, abbiamo fatto meglio degli altri!

Potrebbe essere visto come una variazione del “Running tested features” di Ron Jeffries.

Semplicità/Divertimento

Più è semplice e divertente lavorare in questo modo è più sarà efficace.

Per questo mi affiderò alle esperienze di chi ha lavorato con me intervistandoli brevemente a fine meeting considerato che questi valori sono soggettivi e quindi difficilmente misurabili.

Altre

Inizialmente non vorrei cadere nelle canoniche(?) metriche tipo: Numero ciclomatico di Mc Cabe, Test Coverage, ecc. ecc. in quanto le trovo poco applicabili alla situazione particolare.

La prima ad esempio sarebbe poco indicativa per la semplicità della logica (per lo meno iniziale) del progetto.

La seconda deve essere 100%, semplice.

Ad ogni modo mi lascio spazio per la fantasia, magari osservando gli sviluppatori mi farò venire in mente qualcosa…

1° Tentativo