vaccari@pobox.com - 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