Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Extreme Programming and Responsive Design

1,742 views

Published on

My slides at Codemotion Rome 2013-3-22.

In Extreme Programming le attività di analisi, design, test e codifica sono un continuo; condividono uno stile di lavoro e un modo di pensare. L'analisi è come la codifica, ma a un livello molto astratto. Spesso i team agili scrivono user stories che non hanno forza, perché sono troppo grosse, o sono state splittate in maniera poco efficace. Kent Beck propone 4 strategie di "responsive design": leap, parallel, simplification, stepping stone. Vedremo come queste strategie si applichino all'analisi, per scrivere user stories che hanno forza, valore e una dimensione appropriata

Published in: Technology

Extreme Programming and Responsive Design

  1. 1. Matteo VaccariResponsive design e analisi XPvaccari@pobox.com - freelance - Milano XP User Group 1
  2. 2. Chi son io?Agile Coach Camp Italy 2
  3. 3. Un amico XPer... Ho provato il TDD ma non funziona bene Mi dai una mano? 3Extreme Programming è il miglior metodo per sviluppare software che conosca, e il Test-Driven Development ne è una parte importante. Alcuni però trovano difficoltà ad applicarlo.
  4. 4. 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. 4Ho proposto al mio amico di risolvere questo semplice esercizio dal classico libro di CraigLarman. Per farlo in TDD, da dove cominciamo? Da quale test?
  5. 5. 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 Qual è il primo number rolled on two six-sided dice. Play the game for only 20 rounds. test? no money, no winner or loser, no properties There is 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. 4Ho proposto al mio amico di risolvere questo semplice esercizio dal classico libro di CraigLarman. Per farlo in TDD, da dove cominciamo? Da quale test?
  6. 6. Test inefficaci • Il dado • La costruzione del gioco (Board+Giocatori+Dadi) • L’intero problema (20 round e tutto) 5Testare il dado può sembrare un ovvio punto di partenza. Ma è un test debole: parto dal dado perché è la parte checapisco meglio. Piuttosto dovrei cercare di partire dalla parte che mi è meno chiara... Il dado, anche una volta realizzatoa 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.
  7. 7. Kent Beck’s Responsive Design Leap If you can build it, build it Can see? Parallel Support two designs simultaneously Stepping Stone Build a platform from which 4 strategies your goal is easier to reach Cant see? Eliminate requirements until you reach a safe step Simplification Gradually reintroduce requirementshttp://www.infoq.com/presentations/responsive-design 6Kent Beck dice che quando codifica, usa una fra queste quattro strategie. Quando affrontiamoun nuovo problema da zero, quella che consiglio di usare per prima è Simplification
  8. 8. Simplification: Sudoku 7Ho già scritto su Simplificationhttp://matteo.vaccari.name/blog/archives/770e Stepping Stonehttp://matteo.vaccari.name/blog/archives/777
  9. 9. Simplification: Tetris http://xp123.com/articles/slicing-functionality-alternate-paths/ 8Questo è da un utilissimo articolo di Bill Wake e Kent Beck. Quando semplifichi, ci sonodiverse maniere di semplificare; ti puoi focalizzare sul singolo aspetto che ti interessa di più.
  10. 10. Catturare l’essenza del sistema 9Ma 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 questaversione semplificata, il giocatore può accelerare la caduta del pezzo. Può quindi scegliere se perdere velocementeo lentamente. :-)Questo discorso dell’essenza vale anche quando parliamo di Walking Skeleton.
  11. 11. 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. 10Quante diverse maniere abbiamo di semplificare il Monopoli all’osso, pur mantenendol’essenza dell’originale?
  12. 12. Come affrontiamo un progetto? Un requisito? Un task di programmazione? 11Passiamo a parlare di come le 4 strategie si applicano a un intero progetto.
  13. 13. User stories My purpose is to maintain a balance of power between business and development. Use cases are complex and formal enough that business doesnt 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". Kent Beck -- http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison 12Che differenza c’è fra Use Case e User Story? Questa citazione di Kent Beck è illuminante: lasemplicità estrema delle User Stories ha lo scopo di fare in modo che il business le senta sue.Ha lo scopo di facilitare la collaborazione!
  14. 14. 13Semplici cartoncini
  15. 15. Conversational development Clienti Sviluppatori Definiscono il valore Sviluppano Prioritizzano Stimano 14Kent Beck dice che avrebbe voluto chiamare i Metodi Agili “Conversational Development”: unaconversazione che fa scoprire le opportunità di fare cose utili, fra chi sa il business e chi sa latecnica. I cartoncini servono a focalizzare il discorso. Non sono il “documento dei requisiti deipoveri”!
  16. 16. Conversational development Clienti Sviluppatori As a... As a... As a... As a... Definiscono il valore Sviluppano Prioritizzano Stimano 14Kent Beck dice che avrebbe voluto chiamare i Metodi Agili “Conversational Development”: unaconversazione che fa scoprire le opportunità di fare cose utili, fra chi sa il business e chi sa latecnica. I cartoncini servono a focalizzare il discorso. Non sono il “documento dei requisiti deipoveri”!
  17. 17. User stories As a... • Hanno valore I want to… As a... so that... • Sono stimabili As a... As a... • 4-6 per iterazione 15Se non so stimare una user story, vuol dire che è troppo grossa. Se non riesco a far stare 4-6storie in un iterazione, vuol dire che sono troppo grosse. Perché se prometto solo 2 storie inun iterazione e ne manco una, ho mancato il 50% di quello che avevo promesso (troppo!)
  18. 18. Troppo grossa? Spezzala! As a... I want to… so that... As a... • Hanno valore I want to… so that... As a... • I want to… Sono stimabili so that... • 4-6 per iterazione As a... I want to… so that... As a... I want to… so that... 16La 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 quellestorie hanno un valore e un senso per lui.
  19. 19. Problema: le user stories sono troppo grosse Possiamo spezzarla? NO! Più piccola di così non ha senso per il cliente Cattivi! Veniteci incontro! 17Una funzionalità completa e “vendibile” è in genere troppo grossa e difficile da costruire. Per questo gli sviluppatorichiedono al business di “spezzare” la storia in storie più piccole. Questo ha due possibili esiti negativi: il cliente nonaccetta lo split perché “da solo non ha valore” oppure gli sviluppatori forzano la mano al business, che perde interessealla cosa perché pensa che le US siano cosa degli sviluppatori.
  20. 20. Problema: le user stories sono troppo grosse Possiamo rilasciare qualcosa prima? NO! Lasciateci lavorare! Cattivi! 18A 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 percepiscanole richieste del business come ingiuste ingerenze. Dipende dai rapporti “politici” fra business e sviluppo.
  21. 21. Leap If you can build it, build it Can see? Parallel Support two designs simultaneously Stepping Stone Build a platform from which 4 strategies your goal is easier to reach Cant see? Eliminate requirements until you reach a safe step Simplification Gradually reintroduce requirements 19Torniamo alla strategia di base: Simplification
  22. 22. Definiamo “valore” • Qualcosa che ci fa guadagnare • Qualcosa che ci fa risparmiare • Qualcosa che riduce il rischio di perdere 20Che cosa intendiamo quando parliamo di valore? Dovremmo essere in grado di ricondurlosempre ai soldi. In particolare è importante il terzo caso: sviluppare software è un processo incui business e sviluppatori imparano. Certe user story hanno senso per imparare: così siriduce il rischio di sviluppare la cosa sbagliata.
  23. 23. Malinteso n. 1 Il cliente sa quel che vuole Jeff Patton, I don’t know what I want 21http://www.agileproductdesign.com/blog/dont_know_what_i_want.htmlSe il cliente sapesse quel che vuole, allora lo sviluppo agile sarebbe solo un consegnare a pezzettiquello che già sappiamo che dovremo fare. Ma non è così!
  24. 24. In realtà.... ... finché non si vede software funzionante... 22Fino 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 laversione n e la versione n+1
  25. 25. Una prima versione funzionantefocalizza l’attenzione 23
  26. 26. Malinteso n. 2 I requisiti funzionali sono il 95% del lavoro 24Questo nella mente del 95% degli sviluppatori. I requisiti non funzionali sono alla peggio unacosa a cui si pensa alla fine del progetto, a cui si dedica al più il 5% dell’attenzione. Errore!
  27. 27. “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 25Questa frase un po’ sibillina di Francesco mi ha dato parecchio da pensare. L’ho capitameglio quando ho capito che i requisiti non funzionali sono molto di più che non cose tipo“rispondere in 200ms”.
  28. 28. In realtà... 26Questo è un esempio che si trova in Evo http://www.gilb.com/Project-Management. Diversesoluzioni 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.
  29. 29. 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! 27Deve funzionare meglio. I requisiti non funzionali non sono binari, sono quantificabili
  30. 30. Tom Gilb 1. Identifica gli stakeholder (almeno 20) 2. Identifica i loro valori 3. Stabilisci gli obiettivi 4. Fai un esperimento (max 2% budget) 28I valori degli stakeholder sono requisiti non funzionali. E sono quantificabili!
  31. 31. Tom Gilb conversioni 1. Identifica gli stakeholder (almeno 20) 2. Identifica i loro valori 3. Stabilisci gli obiettivi n. di click 4. Fai un esperimento (max 2% budget) 28I valori degli stakeholder sono requisiti non funzionali. E sono quantificabili!
  32. 32. Tom Gilb conversioni 1. Identifica gli stakeholder (almeno 20) 2. Identifica i loro valori 3. Stabilisci gli obiettivi n. di click 4. Fai un esperimento (max 2% budget) 60% 300K conversioni click/giorno 28I valori degli stakeholder sono requisiti non funzionali. E sono quantificabili!
  33. 33. Follow the money Ci ser ve un’app per iPad! Perché? Perché gli agenti in viaggio possano aggiornare il gestionale Ah! Quindi volete informazioni aggiornate in tempo reale Perché? 29Non accettiamo che i clienti ci presentino una pila di user stories. Dove sarebbe laconversazione? Continuiamo a chiedere “perché” fino a quando non arriviamo al valore.
  34. 34. Inserisci contratto App per iPad Inserisci cliente Agenti Aggiornamento tempestivo Aggiorna contratto Web app sui contratti chiusi Emulatore terminale Assumere segretario Obiettivo: ridurre inventario del 15% Capisquadra Miglioramento Training lean efficienza Riorg. gruppi di lavoro App PC specializzata per ottimizzare 30Gojko Adzik coniuga il metodo di Tom Gilb con le mappe mentali nel libro Impact Mappinghttp://impactmapping.org . Nota che i collegamenti fra i nodi della mappa sono legati daassunzioni. Il valore di una semplice user story può essere nel validare una assunzione.
  35. 35. Assunzioni! Inserisci contratto App per iPad Inserisci cliente Agenti Aggiornamento tempestivo Aggiorna contratto Web app sui contratti chiusi Emulatore terminale Assumere segretario Obiettivo: ridurre inventario del 15% Capisquadra Miglioramento Training lean efficienza Riorg. gruppi di lavoro App PC specializzata per ottimizzare 30Gojko Adzik coniuga il metodo di Tom Gilb con le mappe mentali nel libro Impact Mappinghttp://impactmapping.org . Nota che i collegamenti fra i nodi della mappa sono legati daassunzioni. Il valore di una semplice user story può essere nel validare una assunzione.
  36. 36. 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 31Se la soluzione ridicolmente semplice funziona, siamo a posto! Altrimenti abbiamo un punto dipartenza per iterare. Assumere che la user story debba realizzare una funzionalità corretta e completaal primo posto è una ricetta per la delusione. Ha più senso mettere in programma di lavorare la stessauser story tre volte: a) primo tentativo, b) incorporiamo il feedback del cliente c) tocchi finali.
  37. 37. Sono freelance!Agile Coach Camp Italy Faccio coaching XP e TDD @xpmatteo 32

×