Date post: | 06-May-2015 |
Category: |
Technology |
Upload: | matteo-vaccari |
View: | 1,154 times |
Download: | 1 times |
[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 whichyour goal is easier to reach
Eliminate requirementsuntil you reach a safe step
Gradually reintroducerequirements
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 Simplificationhttp://matteo.vaccari.name/blog/archives/770e Stepping Stonehttp://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 valorePrioritizzano
SviluppanoStimano
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 valorePrioritizzano
SviluppanoStimano
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 whichyour goal is easier to reach
Eliminate requirementsuntil you reach a safe step
Gradually reintroducerequirements
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 moneyCi 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 inventariodel 15%
Agenti
Capisquadra
Aggiornamento tempestivo sui contratti chiusi
App per iPad
Web app
Emulatore terminale
Miglioramentoefficienza
Training lean
Riorg. gruppi di lavoro
Assumere segretario
App PC specializzataper 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 inventariodel 15%
Agenti
Capisquadra
Aggiornamento tempestivo sui contratti chiusi
App per iPad
Web app
Emulatore terminale
Miglioramentoefficienza
Training lean
Riorg. gruppi di lavoro
Assumere segretario
App PC specializzataper 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 semplicissimaa) focalizza il discorsob) 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 coachingXP e TDD
@xpmatteo
32