L'esercizio IN SINTESI

La maggior parte dei programmatori dice di non saper come fare per decomporre le features a livello di ore. Al contrario, i programmatori migliori riescono con facilità a tradurle in episodi di programmazione di 15-30 minuti. Che cosa serve per fare questa transizione qualitativa?

Questo esercizio ha avuto talmente successo nell'aiutare la gente a capire lo sviluppo con nano-incrementi che lo uso dappertutto: da analisti di business (associati a un programmatore) a programmatori in coppia; incoraggio la gente che partecipa alle mie sessioni di riproporlo all'interno delle proprie ditte. Penso che la discussione prima e il debriefing dopo siano importanti, ma il vero apprendimento consiste nella sezione di programmazione.

Risultati ATTesi

• Come decomporre grandi applicazioni in richieste che vanno da 1 giorno a una settimana, dal punto di vista del business.
• Come decomporre richieste di applicazioni in "fette" di lavoro di 15-30 minuti, sia dal punto di vista del business che del programmatore.
• Che cos'è il carpaccio (non lo avete già capito da queste pagine?)

ProcessO/MeccanicHe

1. Formate squadre di 2-3 persone, con almeno un programmatore per team.
2. Parlate di elefanti, bistecche, sashimi e carpaccio, se necessario. Vedi Elephant Carpaccio (Elephant carpaccio (discussione: Re: Elephant carpaccio) e Design as Knowledge Acquisition (discussione: Re: Trim the Tail)).
3. Mostrare il compito.
4. Per 15 minuti, i team dovranno "ritagliare" il compito in 8-18 user story o richieste di feature, ciascuna delle quali potenzialmente programmabili in 3-8 minuti; le loro funzionalità dovranno essere provate tramite un demo alla fine di ogni sprint (niente disegni, niente tabelle, non vogliamo vedere il codice).
5. Discutete, correggete, litigate, arringate, finché i partecipati capiranno cosa è necessario mettere in ogni "fetta".
6. Eseguite cinque sprint di programmazione, dai 7 ai 10 minuti ciascuno. Al termine di ogni sprint, ogni team mostra l'ultima versione del programma ad un altro team. L'orologi NON si ferma durante le iterazioni, dato che anche i demo hanno un costo di programmazione. (Si, la gente riesce a fare tutto questo all'interno di iterazioni di soli 7 minuti!)
7. Debriefing. Usate i grafici di Design as Knowledge Acquisition (discussione: Re: Trim the Tail) .

NOTA: Le foto che seguono sono state effettuate da Panopto durante CSEET 2010.