Esercizio: Carpaccio di Elefante

Guida per i facilitatori

Henrik Kniberg & Alistair Cockburn, 11 luglio 2013

Di che si tratta?

L'esercizio Carpaccio di elefante è un modo simpatico per chi si occupa di software di far pratica e imparare come spezzare le storie in sottili strisce verticali. Conduce anche a discussioni interessanti sulla qualità e sulle pratiche tecniche.

L'esercizio fu inventato da Alistair Cockburn. Lo abbiamo cofacilitato un sacco di volte e incoraggiamo la gente a riproporlo ovunque. .

Questa è una guida facilitatori (a livello shu) basata sul mondo con cui di solito Alistar la esegue, con qualche adattamento di Henrik.

L'esercizio richiede 90-120 minuti e scala piuttosto bene. Noi lo facciamo di solito con 10-20 persone ma è stato fatto anche con gruppi da 30.

Tempi

L'ideale è 2 ore. Con 1.5 ore funziona lo stesso ma è forse un po' affrettata.

• 15-20m discussione sulle user story
• 20-30m decomporre il backlog
• 40m codifica
• 15-20m debriefing

È possibile saltare la parte di codifica e far pratica solo sulla creazione del backlog. Ma è molto meno divertente, e in più si perde la discussione conclusiva sulla qualità del codice.

Preparazione

• Stampate questo handout per tutti i partecipanti (oppure, copiatene la metà inferiore su una LIM/flipchart).
• Fate in modo che la metà dei partecipanti abbia un laptop o workstation con un ambiente di sviluppo funzionante. Va bene anche con qualcuno in meno, ma almeno un terzo dei partecipanti dovrebbe averne uno.
• Assicuratevi che nella stanza ci siano prese elettriche per tutti.
• Internet non è necessaria per questo workshop, ma può essere utile per cercare le cose durante la programmazione.

Esecuzione del workshop

Introduzione

• L'obiettivo del workshop è quello di imparare a decomporre le storie in pezzi molto piccoli.

PerchE'SPEZZARE LE STORIE (opZionale)

Questa parte è necessarioa solo se non avete già discusso del valore ricavato dallo spezzare le storie

• User Story = verticale, testabile, portatrice di valore per l'utente. Passa attraverso molti strati architetturali.

• Affettare le storie = creare storie più sottili (ma sempre verticali)

• Quanto sono grandi le vostre storie? I task? I commit? (porre l'accento sulle dimensioni)
• Obiettivo: Story = qualche giorni. Task = Qualche ora. Commit = più volte all'ora.
• Perché spezzare le storie? Discutetene a coppie. (chiedere a ogni coppia un resoconto, chiedere cosa manca, aggiungere gli elementi mancanti dalla lista qui sotto).
• Imparare più in fretta. Consegnare più frequentemente. Stakeholder più contenti. PIù in sincronia con le altre persone/team. Migliore scelta delle priorità. Prodotti migliori. Prodotti consegnati in anticipo. Più opzioni di business. Minor rischio (meno tempo con l'acqua alla gola). Senso di velocità. Pianificazione più semplice.
• Disegnare le curve del valore per waterfall, storie grandi e storie piccole. Discutete. Perché la curva delle storie piccole mostra un valore cumulativo più alto?

• La decisione sul "quanto piccola" deve diventare non deve essere limitata da "non possiamo spezzare questa storia". In questo worshop facciamo pratica esagerando. Faremo le storie così minuscole che tutto quello che farete sembrerà grande al confronto.

Che cosa faremo

• Costruiremo una applicazione semplice in 40 minuti, divisi in 5 iterazioni di 8 minuti.
• La maggior parte della gente costruirebbe quest'app con 2-3 fette, noi la faremo in 15-20.
• Carpaccio di elefante = fette molto sottile, ognuna della quali con la forma dell'elefante. Assieme, formano l'elefante intero..

Il prodotto

• Chiudete i laptop! (altrimenti la gente pasticcerebbe con con l'ambiente invece di ascoltare)
• (fate riferimento all'handout).
• Costruiremo un calcolatore di cassa. Si tratta di un'eseguibile con interfaccia utente, tre input e un output.
• Usate qualsiasi linguaggio di programmazione. L'interfaccia può essere a linea di comando, web, gui, la qualsiasi, insomma.
• Tre input:
  • Quanti articoli
  • Prezzo unitario
  • Codice nazionale a 2 lettere
• Output: prezzo totale dell'ordine. Fornire uno sconto in base al prezzo complessivo, quindi aggiungere l'IVA in funzione della nazione e del prezzo scontato.

Priorita'

• Illustrerò le priorità con questa curva dei valori.

• L'obiettivo è: 5 sconti, 5 stati.
• Scomporrete questo in 10-20 fette.
• Una fetta è valida solo se ha una interfaccia utente, input ed output, ed è visibilmente differente dalla fetta precedente.
• Voglio 5 stati prima di fare qualunque cosa sugli sconti. Perché? (così si può rilasciare! Le tasse sono un'imposizione legale, gli sconti no)

• Validazione & GUI strafiga vengono dopo 5 stati & 5 sconti. Non perdete tempo su questo prima!

• Niente abbellimenti! Fate pratica costurendo prima le cose con il massimo valore, tutte le volte. Per esempio, prima di avare 5 stati, non perdete il minimo tempo su codice legato agli sconti!
• Non m'importa quanto arrivate in alto lungo questa curva. La cosa importante è far pratica con i microaffettamenti. Se arrivate in fondo con con 3 sole fette, avete perso tempo e non avete compreso qual è il punto di questo esercizio.

Creare il backlog

• Dividetevi in gruppi di 2 o 3 (2 è meglio). Ogni gruppo dovrebbe avere almeno un programmatore con un ambiente di sviluppo funzionante.
• 10 minuti: Scrivete il vostro backlog su carta (computer ancora chiusi).
  • Scrivete 10-20 storie dimostrabili (“fette”) che vi porteranno dal nulla a 5 stati e 5 sconti .
  • Linee guida per una storia valida:
    • Implementabile (incluso interfaccia utente) in 2-6 minuti.
    • Visibilmente diversa dall'ultima fetta
    • Con maggior valore per l'utente dell'ultima fetta (eccezione: per le primissime fette, concentrarsi sul minimo rischio va bene lo stesso).
  • Nessuna fetta deve essere solo una simuluazione di UI, una struttura datai o un test.
• Cosa c'è nella vostra prima fetta?
  • (tutto quello che è più grande di un hello-world o copia-input-su-outpun è troppo grande)
  • Discutete del valore di riduzione del rischio di implementare e "consegnare" un hello world come priam fetta. Valore = valore per il cliente + valore di conoscenza
  • Discutete del valore della costruzione di uno "scheletro ambulante" dell' applicazione (tutte le componenti architetturali sono presenti e connesse, ma non c'è "ciccia"; da qui il termine di scheletro ambulante)
  • Ad un certo punto raggiungerete la milestone "ordine" - avrete 2 input (numero di articoli e prezzo per oggetto) e li moltiplicate tra loro. Niente sconti e tasse.

• Qual è la vostra prossima fetta, dopo l'ordine semplice?
  • (sarà probabilmente troppo grossa: sfidateli a renderla più piccola!!).
  • Esempio di backlog:
    • Ordine semplice. 2 input, 1 output. Niente tasse o sconti.
    • Una tassa fissa. Ancora 2 input, 1 output. Tassa italiana aggiunta automaticamente. (Ora possiamo rilasciarla in Italia!).
    • 3 input (prezzo per articolo, numero di articoli, tassa in %). L'output è il prezzo totale ivato.
      • L'utente inserisce il valore della tassa anziché il codice nazionale. Fornisce un codice più semplice (senza strutture per mappare il codice nazionale sul valore delle tasse, in modo da avere una consegna più rapida.
    • 3 input (prezzo per articolo, numero di articoli, codice nazionali), ma solo due nazioni sono supportate; tutte le altre danno un messaggio di errore.
    • Aggiungi le altre 3 nazioni. (discutete perché c'è un incremento limitato di valore aggiungendo uno stato alla volta - non c'è riduzione del rischio, e servono pochi secondi per aggiungere tutti gli stati in un colpo solo.
• Punto chiave: Minimizzare il numero di tasti premuti per ogni fetta! Vogliamo il massimo valore con il minimo sforzo (= Lean!)
• 5 minuti: rendete le vostre fette più sottili. Provate a raggiungere almeno 15 fette.

Come lavorare? (Opzionale)

Il workshop è principalmente incentrato sull'affettare le storie, ma aggiungere degli aspetti di pratica tecnica lo rende più appetitoso.

• Come scriverete e testerete il codice? Prendete una decisione e attenetevi ad essa in modo responsabile! Mi riservo il diritto di tormentare i gruppi che non lo faranno.
  • Opzione 1: TDD. Test Driven Develoment con tutti i crismi. Red Green Refactor. Iniziate da ogni fetta scrivendo un test che funziona ma fallisce. Rendere quindi il test verder. Poi rifattorizare il codice e renderlo bello e pulito.
  • Opzione 2: Rosso-verde. Come sopra, ma il refactoring è opzionale.
  • Opzione 3: Qualche test. Scriverete qualche test ,ma non per tutte le fette e non necessariamente test-first.
  • Option 4: NCDT (nessun C*o di test).
• Userete il pair programming (= cambio frequente), o avrete una persona del business e un programmatore (il business fa i test, dà il feedback e migliora il backlog)? Entrambi vanno bene.

Sviluppo

• 40 minuti, 5 iterazioni, 8 minutes per iteratione.
• Al termine di ogni iterazione, urlerò "demo time!". Vuol dire stop alla codifica, e dimostrare l'app ad un altro team. Poi si torna a programmare.
  • Il tempo non si ferma tra le iterazioni! Per cui non perdete troppo tempo nelle demo.
• Urlate “fetta” quando finite una fetta.
• Partite!
• (far partire un time di 8 minute. Ricordarsi di far ripartire il timer immediatamente dopo ogni sprint. Inoltre, tenete traccia del numero dell'iterazione cui siete arrivati - è facile perdere il conto).

Riflessione

• Fin dove siete arrivati? (Segnate il punto raggiunto da ogni squadra sulla curva del valore)
  • (risultato tipico: alcune squadre raggiungono i 5 stati e 5 sconti. La maggior parte delle squadre raggiunge almeno le tasse hard-coded).
• Quante fette avevate?
• Test di Accettazione:
  • Fate partire l'applicazione e inserite questi dati: Sono in Italia, sto comprando 978 articoli, ogni articolo costa €278,88. (o altri valori scelti da voi).
  • Ditemi il risultato! (scrivete l'output di ogni team sulla LIM).
  • Non paciugate, limitatevi a far partire l'applicazione, inserire i risultati e vedere che cosa salta fuori.
  • (confrontate i risultati. Spesso i risultati differiscono, cosa che è diveretente. Potete discutere i motivi per cui accade... qualche team non support i decimali, potete parlare anche di falsi presupposti e come identificarli.).

DebriefING

• Non-programmatori: Come è andata?
• Programmatori: Come è andata?
  • Parliamo di qualità del codice: quanto siete soddifatti dalla qualità del codice prodotto? (ogni programmatore alza da 1 a 5 dita).
    • Chi ha usato TDD dovrebbe indicare o 5, altrimenti non hanno ben compreso o applicato il concetto di refactoring del TDD.
    • La maggior parte dei programmatore indicherà 1 o 2. Discutete su come questao possa essere un potenziale problema legato alle iterazioni brevi e storie piccole. Discutete dell'importanza di tenere un passo e una qualità sostenibile, e come i progrmmatori ne siano responsabili (Principio agile di base: il team decide per quanto lavoro impegnarsi). Discutete della pressione "percepita" rispetto alla pressione reale.
• Altre domande o riflessioni?
• Chiedere a ciascuno: What did you learn? What will you do? Name one take-away insight from today, and one thing you will do differently in the future.