[email protected] - freelance - Milano XP User Group Matteo Vaccari Responsive design e analisi XP 1 

Chi son io? Agile Coach Camp Italy 2 

Ho provato il TDD ma non funziona bene Mi dai una mano? Un amico XPer... 3 Extreme Programming è il miglior metodo per sviluppare software che conosca, e il Test- Driven Development ne è una parte importante. Alcuni però trovano difficoltà ad applicarlo. 

Un esercizio... Monopoly: players moving around the squares of the board. Two to eight players can play. A game is played as a series of rounds. During a round, each player takes one turn. In each turn, a player advances his piece clockwise around the board a number of squares equal to the sum of the number rolled on two six-sided dice. Play the game for only 20 rounds. There is no money, no winner or loser, no properties to buy or rent to pay, and no special squares of any kind. Each square has a name. Every player begins the game with their piece located on the square named “Go.” The square names will be Go, Square 1, Square 2, ... Square 39” Run the game as a simulation requiring no user input, other than the number of players. 4 Ho proposto al mio amico di risolvere questo semplice esercizio dal classico libro di Craig Larman. Per farlo in TDD, da dove cominciamo? Da quale test? 

Un esercizio... Monopoly: players moving around the squares of the board. Two to eight players can play. A game is played as a series of rounds. During a round, each player takes one turn. In each turn, a player advances his piece clockwise around the board a number of squares equal to the sum of the number rolled on two six-sided dice. Play the game for only 20 rounds. There is no money, no winner or loser, no properties to buy or rent to pay, and no special squares of any kind. Each square has a name. Every player begins the game with their piece located on the square named “Go.” The square names will be Go, Square 1, Square 2, ... Square 39” Run the game as a simulation requiring no user input, other than the number of players. Qual è il primo test? 4 Ho proposto al mio amico di risolvere questo semplice esercizio dal classico libro di Craig Larman. Per farlo in TDD, da dove cominciamo? Da quale test? 

Test inefficaci • Il dado • La costruzione del gioco (Board+Giocatori+Dadi) • L’intero problema (20 round e tutto) 5 Testare il dado può sembrare un ovvio punto di partenza. Ma è un test debole: parto dal dado perché è la parte che capisco meglio. Piuttosto dovrei cercare di partire dalla parte che mi è meno chiara... Il dado, anche una volta realizzato a dovere, contiene poca dell’essenza del Monopoli. Testare il costruttore è pure debole, perché non ha comportamento. Testare l’intero problema è inefficace perché è troppo grosso: ci metto troppo tempo ad arrivare a Verde. 

Kent Beck’s Responsive Design 4 strategies Can see? Can't see? Leap Parallel Stepping Stone Simplification If you can build it, build it Support two designs simultaneously Build a platform from which your goal is easier to reach Eliminate requirements until you reach a safe step Gradually reintroduce requirements http://www.infoq.com/presentations/responsive-design 6 Kent Beck dice che quando codifica, usa una fra queste quattro strategie. Quando affrontiamo un nuovo problema da zero, quella che consiglio di usare per prima è Simplification 

Simplification: Sudoku 7 Ho già scritto su Simplification http://matteo.vaccari.name/blog/archives/770 e Stepping Stone http://matteo.vaccari.name/blog/archives/777 

Simplification: Tetris http://xp123.com/articles/slicing-functionality-alternate-paths/ 8 Questo è da un utilissimo articolo di Bill Wake e Kent Beck. Quando semplifichi, ci sono diverse maniere di semplificare; ti puoi focalizzare sul singolo aspetto che ti interessa di più. 

Catturare l’essenza del sistema 9 Ma attenzione: non tutte le semplificazioni sono efficaci. Devi arrivare a una versione che pur semplicissima, conservi l’essenza dell’originale. Nel caso del Tetris, l’essenza è un pezzo che cade che il giocatore può parzialmente controllare. Quindi un Tetris 1xN senza interazione con il giocatore sarebbe debole. In questa versione semplificata, il giocatore può accelerare la caduta del pezzo. Può quindi scegliere se perdere velocemente o lentamente. :-) Questo discorso dell’essenza vale anche quando parliamo di Walking Skeleton. 

E il Monopoli? Monopoly: players moving around the squares of the board. Two to eight players can play. A game is played as a series of rounds. During a round, each player takes one turn. In each turn, a player advances his piece clockwise around the board a number of squares equal to the sum of the number rolled on two six-sided dice. Play the game for only 20 rounds. There is no money, no winner or loser, no properties to buy or rent to pay, and no special squares of any kind. Each square has a name. Every player begins the game with their piece located on the square named “Go.” The square names will be Go, Square 1, Square 2, ... Square 39” Run the game as a simulation requiring no user input, other than the number of players. 10 Quante diverse maniere abbiamo di semplificare il Monopoli all’osso, pur mantenendo l’essenza dell’originale? 

Come affrontiamo un progetto? Un requisito? Un task di programmazione? 11 Passiamo a parlare di come le 4 strategie si applicano a un intero progetto. 

My purpose is to maintain a balance of power between business and development. Use cases are complex and formal enough that business doesn't want to touch them. This leads to development asking all the questions and writing down all the answers. Business is reduced to sitting on the other side of the table and pointing. I want a very different dynamic. I want business to feel ownership of and take responsibility for the care and maintenance of "the requirements". User stories Kent Beck -- http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison 12 Che differenza c’è fra Use Case e User Story? Questa citazione di Kent Beck è illuminante: la semplicità estrema delle User Stories ha lo scopo di fare in modo che il business le senta sue. Ha lo scopo di facilitare la collaborazione! 

13 Semplici cartoncini 

Conversational development Definiscono il valore Prioritizzano Sviluppano Stimano Clienti Sviluppatori 14 Kent Beck dice che avrebbe voluto chiamare i Metodi Agili “Conversational Development”: una conversazione che fa scoprire le opportunità di fare cose utili, fra chi sa il business e chi sa la tecnica. I cartoncini servono a focalizzare il discorso. Non sono il “documento dei requisiti dei poveri”! 

Conversational development Definiscono il valore Prioritizzano Sviluppano Stimano Clienti Sviluppatori As a... As a... As a... As a... 14 Kent Beck dice che avrebbe voluto chiamare i Metodi Agili “Conversational Development”: una conversazione che fa scoprire le opportunità di fare cose utili, fra chi sa il business e chi sa la tecnica. I cartoncini servono a focalizzare il discorso. Non sono il “documento dei requisiti dei poveri”! 

• Hanno valore • Sono stimabili • 4-6 per iterazione User stories As a... As a... As a... As a... I want to… so that... 15 Se non so stimare una user story, vuol dire che è troppo grossa. Se non riesco a far stare 4-6 storie in un iterazione, vuol dire che sono troppo grosse. Perché se prometto solo 2 storie in un iterazione e ne manco una, ho mancato il 50% di quello che avevo promesso (troppo!) 

• Hanno valore • Sono stimabili • 4-6 per iterazione Troppo grossa? Spezzala! As a... I want to… so that... As a... I want to… so that... As a... I want to… so that... As a... I want to… so that... As a... I want to… so that... 16 La tecnica standard consiste nello “spezzare” le storie d’uso. Ma occhio! Le user story più piccole devono comunque avere valore! Il cliente deve comunque essere convinto che quelle storie hanno un valore e un senso per lui. 

Problema: le user stories sono troppo grosse Possiamo spezzarla? NO! Più piccola di così non ha senso per il cliente Cattivi! Veniteci incontro! 17 Una funzionalità completa e “vendibile” è in genere troppo grossa e difficile da costruire. Per questo gli sviluppatori chiedono al business di “spezzare” la storia in storie più piccole. Questo ha due possibili esiti negativi: il cliente non accetta lo split perché “da solo non ha valore” oppure gli sviluppatori forzano la mano al business, che perde interesse alla cosa perché pensa che le US siano cosa degli sviluppatori. 

Problema: le user stories sono troppo grosse NO! Possiamo rilasciare qualcosa prima? Lasciateci lavorare! Cattivi! 18 A volte sono gli sviluppatori che si rifiutano di rilasciare. Può essere che abbiano molti scheletri tecnici nell’armadio. Può sembrare che non sia possibile rilasciare prima... Può essere che gli sviluppatori non ne vedano il valore e percepiscano le richieste del business come ingiuste ingerenze. Dipende dai rapporti “politici” fra business e sviluppo. 

4 strategies Can see? Can't see? Leap Parallel Stepping Stone Simplification If you can build it, build it Support two designs simultaneously Build a platform from which your goal is easier to reach Eliminate requirements until you reach a safe step Gradually reintroduce requirements 19 Torniamo alla strategia di base: Simplification 

Definiamo “valore” • Qualcosa che ci fa guadagnare • Qualcosa che ci fa risparmiare • Qualcosa che riduce il rischio di perdere 20 Che cosa intendiamo quando parliamo di valore? Dovremmo essere in grado di ricondurlo sempre ai soldi. In particolare è importante il terzo caso: sviluppare software è un processo in cui business e sviluppatori imparano. Certe user story hanno senso per imparare: così si riduce il rischio di sviluppare la cosa sbagliata. 

Malinteso n. 1 Jeff Patton, I don’t know what I want Il cliente sa quel che vuole 21 http://www.agileproductdesign.com/blog/dont_know_what_i_want.html Se il cliente sapesse quel che vuole, allora lo sviluppo agile sarebbe solo un consegnare a pezzetti quello che già sappiamo che dovremo fare. Ma non è così! 

In realtà.... ... finché non si vede software funzionante... 22 Fino a che non si vede una prima versione del software, tutta la discussione che facciamo è solo filosofia. Quando abbiamo una versione 0 funzionante, l’attenzione si focalizza e si capisce qual è il delta fra la versione n e la versione n+1 

Una prima versione funzionante focalizza l’attenzione 23 

Malinteso n. 2 I requisiti funzionali sono il 95% del lavoro 24 Questo nella mente del 95% degli sviluppatori. I requisiti non funzionali sono alla peggio una cosa a cui si pensa alla fine del progetto, a cui si dedica al più il 5% dell’attenzione. Errore! 

“Rick Kazman mio prof di architetture software diceva: i progetti falliscono per il non soddisfacimento dei requisiti non funzionali, raramente per il non soddisfacimento dei requisiti funzionali.” Francesco Cirillo, extremeprogramming-it, 18/02/2010 25 Questa frase un po’ sibillina di Francesco mi ha dato parecchio da pensare. L’ho capita meglio quando ho capito che i requisiti non funzionali sono molto di più che non cose tipo “rispondere in 200ms”. 

In realtà... 26 Questo è un esempio che si trova in Evo http://www.gilb.com/Project-Management. Diverse soluzioni possono fornire la funzionalità di una sedia. La differenza sta nelle diverse qualità. Le qualità sono requisiti non funzionali! E non sono binari, sono quantificabili. 

Il cliente ha già un sistema che funziona. Replicare le funzioni non basta. Più veloce Più stabile Più usabile Più bello ... Deve farmi fare più soldi! 27 Deve funzionare meglio. I requisiti non funzionali non sono binari, sono quantificabili 

Tom Gilb 1. Identifica gli stakeholder (almeno 20) 2. Identifica i loro valori 3. Stabilisci gli obiettivi 4. Fai un esperimento (max 2% budget) 28 I valori degli stakeholder sono requisiti non funzionali. E sono quantificabili! 

Tom Gilb 1. Identifica gli stakeholder (almeno 20) 2. Identifica i loro valori 3. Stabilisci gli obiettivi 4. Fai un esperimento (max 2% budget) n. di click conversioni 28 I valori degli stakeholder sono requisiti non funzionali. E sono quantificabili! 

Tom Gilb 1. Identifica gli stakeholder (almeno 20) 2. Identifica i loro valori 3. Stabilisci gli obiettivi 4. Fai un esperimento (max 2% budget) n. di click conversioni 60% conversioni 300K click/giorno 28 I valori degli stakeholder sono requisiti non funzionali. E sono quantificabili! 

Follow the money Ci serve un’app per iPad! Perché? Perché gli agenti in viaggio possano aggiornare il gestionale Ah! Quindi volete informazioni aggiornate in tempo reale Perché? 29 Non accettiamo che i clienti ci presentino una pila di user stories. Dove sarebbe la conversazione? Continuiamo a chiedere “perché” fino a quando non arriviamo al valore. 

Obiettivo: ridurre inventario del 15% Agenti Capisquadra Aggiornamento tempestivo sui contratti chiusi App per iPad Web app Emulatore terminale Miglioramento efficienza Training lean Riorg. gruppi di lavoro Assumere segretario App PC specializzata per ottimizzare Inserisci contratto Inserisci cliente Aggiorna contratto 30 Gojko Adzik coniuga il metodo di Tom Gilb con le mappe mentali nel libro Impact Mapping http://impactmapping.org . Nota che i collegamenti fra i nodi della mappa sono legati da assunzioni. Il valore di una semplice user story può essere nel validare una assunzione. 

Obiettivo: ridurre inventario del 15% Agenti Capisquadra Aggiornamento tempestivo sui contratti chiusi App per iPad Web app Emulatore terminale Miglioramento efficienza Training lean Riorg. gruppi di lavoro Assumere segretario App PC specializzata per ottimizzare Inserisci contratto Inserisci cliente Aggiorna contratto Assunzioni! 30 Gojko Adzik coniuga il metodo di Tom Gilb con le mappe mentali nel libro Impact Mapping http://impactmapping.org . Nota che i collegamenti fra i nodi della mappa sono legati da assunzioni. Il valore di una semplice user story può essere nel validare una assunzione. 

In Extreme Programming proviamo a cavarcela con una soluzione ridicolmente semplice. Poi iteriamo se necessario. Una soluzione semplicissima a) focalizza il discorso b) fornisce feedback c) valida un assunzione 31 Se la soluzione ridicolmente semplice funziona, siamo a posto! Altrimenti abbiamo un punto di partenza per iterare. Assumere che la user story debba realizzare una funzionalità corretta e completa al primo posto è una ricetta per la delusione. Ha più senso mettere in programma di lavorare la stessa user story tre volte: a) primo tentativo, b) incorporiamo il feedback del cliente c) tocchi finali. 

Agile Coach Camp Italy Sono freelance! Faccio coaching XP e TDD @xpmatteo 32