Perché non facciamo più quello che ci piace - Italian Agile Day 2012

Perché
non facciamo più
quello che ci piace.
Ilaria Mauric
Alessandro Violini

Italian Agile Day 2012 Milano, 24 novembre 2012

2008
faccio la cosa che mi piace,
nel modo più facile

2012
faccio la cosa più semplice e veloce,
per consegnare valore al cliente

Alessandro Ilaria
Violini Mauric
. front end developer . creative information architect
. user experience designer . user experience designer

@violo @ilariamauric

2008 - 2012 a confronto
soluzioni
strumenti
#win
#fail
#wip
case
difficoltÀ personali
conclusioni

2008 2008 - 2012 a confronto
1/4

CLIENTE

ACCOUNT
FRONT END
GRAFICA
DEV

2008 2008 - 2012 a confronto
1/4

CLIENTE

ACCOUNT

FRONT END
GRAFICA

2008 2008 - 2012 a confronto
1/4

CLIENTE

ACCOUNT

GRAFICA

FRONT END
DEV

2008 2008 - 2012 a confronto
1/4

CLIENTE

ACCOUNT

GRAFICA

FRONT END

DEV

2008 2008 - 2012 a confronto
2/4

deﬁnisci

disegna

sviluppa

testa

rilascia

ACCOUNT GRAFICA FRONT END DEV

2008 2008 - 2012 a confronto
3/4
1 2 3 4

il cliente
vede
il lavoro

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

lavoriamo
ma il
cliente
non vede
nulla

inizia sviluppo
graﬁca home graﬁca tutti correzioni
e 2/3 template i template ritocchi

correzioni ACCOUNT montaggio
GRAFICA home
DEV
FRONT END montaggio tutti ipotesi:
e primi template i template
progetto sito web

2008 2008 - 2012 a confronto
4/4

campanelli d’allarme
• utente scontento
• cliente contento... a metà (si potrebbe fare meglio)
• team scontento
• sforamento delle ore previste e lavorazioni extra
• l’account è un collo di bottiglia

#1 soluzioni
1/9

cliente account

UX, UI, UX, UI,
stakeholder GRAFICA FRONT ENd

utente dev

Il team è uno solo.
Ed è allargato.

#2 soluzioni
2/9

tutto è
incrementale

#2: DA cosÌ... soluzioni
3/9

deﬁnisci

disegna

sviluppa

testa

rilascia


#2: ... A COSÌ soluzioni
4/9

deﬁnisci

disegna

sviluppa

testa

rilascia

stakeholder utente account UX, UI, UX, UI, dev
cliente GRAFICA FRONT ENd

#3 soluzioni
5/9

parallelizzare i lavori
sullo stesso progetto

#3: DA cosÌ... soluzioni
6/9
1 2 3 4

il cliente
vede
il lavoro

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

lavoriamo
ma il
cliente
non vede
nulla

ACCOUNT GRAFICA FRONT END DEV ipotesi:
progetto sito web

7/9
1 2 3 4 5 6 7 8 9

il cliente
vede
il lavoro

sett 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

lavoriamo
ma il
cliente
non vede
nulla

UX, UI, UX, UI,
cliente stakeholder utente account
GRAFICA FRONT ENd
dev ipotesi:
progetto sito web

7/9
1 2 3 4 5 6 7 8 9

il cliente
vede
il lavoro

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

lavoriamo
ma il
cliente
non vede
nulla

confronto con proposta graﬁca pagg secondarie, supervisione ui demo, ultimi ritocchi e
front end e dev pagg principali, montaggio pagg dev e front end pronti per
schizzi e wireframe front end principali completano pubblicazione
prepara
wireframe ambientestakeholder utentepunto graﬁca, UI,
messa a UX, supervisione ui demo,
UX, UI,
cliente account
GRAFICA FRONT ENd
dev ipotesi:
alta qualità dev e front end dev e front end fanno progetto sito web
dev inizia sviluppo sviluppano montaggio e sviluppano

#3 soluzioni
8/9

parallelizzare i ﬂussi di
lavoro del team sullo stesso
progetto

fornitore
come parte del team

#4 soluzioni
9/9

pair per la gestione
del cliente
(non solo in sviluppo)

flussi strumenti
1/6

DS

UX DEV
organizzazione delle aree di competenza
in ﬂussi interni

flussi strumenti
1/6

DS UX+DEV

contatto con cliente strumenti
2/6

con il cliente (responsabile di progetto, release
e iteration planning allargato, maggiordomo)

riunioni strumenti
3/6

per il monitoraggio dei lavori (standup meeting,
scaletta settimanale e mensile, iteration meeting,
release planning, iteration review...)

condivisione strumenti
4/6

strumenti per la condivisione della conoscenza
sulla situazione dei lavori (pivotal, kanban)

condivisione strumenti
5/6

strumenti per la condivisione della conoscenza
sulla situazione dei lavori (pivotal, kanban)

Monitoraggio strumenti
6/6

del team e del ﬂusso di lavoro (foglio elettronico
con i dati di progetto, retrospettive, A3)

#1 #win
1/10

task di ui
dentro le storie

#2 #win
2/10

schizzi, wireframe, prototipi
sono deliverable

#3 #win
3/10

far diventare agili
procedure che prima
non lo erano
(ui, graﬁca)

#4 #win
4/10

individuazione
dei “vincoli”
(ex colli di bottiglia)
per regolarci

#5 #win
5/10

il cambiamento
è la naturale evoluzione
di un progetto

#6 #win
6/10

rilascio progressivo
e frequente

riduzione drastica
dei tempi di latenza
su un rilascio

REPETITA IUVANT #win
7/10

1 2 3 4

il cliente
vede
il lavoro

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

lavoriamo
ma il
cliente
non vede
nulla


REPETITA IUVANT #win
8/10

1 2 3 4 5 6 7 8 9

il cliente
vede
il lavoro

sett 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

lavoriamo
ma il
cliente
non vede
nulla

cliente stakeholder utente account UX, UI, UX, UI, dev
GRAFICA FRONT ENd

#7 #win
9/10

la lavorazione
extra-time diventa
una rara eccezione
(davvero)

#8 #win
10/10

account UX, UI,
FRONT ENd

UX, UI,
stakeholder GRAFICA dev

cliente utente

team soddisfatto

#1 #fail
1/2

stime e quantiﬁcazioni,
queste sconosciute

#2 #fail
2/2

facciamo fatica
a lavorare con
fornitori che non
lavorano come noi

#2 #fail
2/2

facciamo fatica

#EPICWIN
a lavorare con
fornitori che non
lavorano come noi

#1 #wip
1/4

migliorare feedback,
integrazione,
controllo nel/tra team

#2 #wip
2/4

mantenere una
visione d’insieme
sui progetti
e contribuire
a condurli

#2 #wip
3/4

fare riunioni efﬁcaci
(soprattutto
con i fornitori)

#3 #wip
4/4

contratti agili
(ma questa è un’altra storia...)

Approfondisci su
http://www.slideshare.net/extrategy/lapproccio-agile-ai-contratti-e-la-consegna-di-valore

PRODUCT OWNER Case
1/17

INTERROGATIVI Case
4/17

• 3G
• conﬁgurazione della centralina
• conﬁgurazione dell'app
• numero di dispositivi collegabili
e loro peculiarità (telecomandi radio,
telecamere con indirizzi I.P. ecc.)
• grosso dubbio sul taglio di prodotto:
business o consumer?

APPROCCIO Case
5/17

• scrittura user stories con il cliente
(tutto il team, 2 giornate pagate)

• stima: 12 iterazioni (3 mesi di lavoro)

• durante le iterazioni, discussione insieme al
cliente dei vari punti interrogativi che
avremmo dovuto affrontare
(il cliente fa parte del team di progetto)

OBIETTIVO Case
6/17

pubblicare l’app per iPhone
sull’App Store

USER Stories Case
7/17

valore massimo individuato

fammi capire
come funzionerà l’app

deliverable
• scrittura e discussione user stories
• planning game
• 6 schizzi con le principali schermate dell’app

prime 2 ITERAZIONI Case
8/17


fammi accendere le luci dall'app

deliverable
• sviluppo funzionalità dell’app
• 3/4 icone in due varianti graﬁche
• 1 interruttore monostabile

9/17


fammi accendere altri dispositivi

deliverable
• sviluppo funzionalità dell’app
• 11 icone, 3 tipi di interruttore

10/17

struttura app funzionante,
interruttori dei dispositivi funzionanti

• emerge questione utente installatore:
sistema troppo scarno e meccanico, scoraggiante
• emerge questione utente ﬁnale:
che succede se non ha app?

OBIETTIVO Case
11/17

pubblicare l’app per iPhone
sull’App Store

OBIETTIVO Case
12/17

presentare alla forza
commerciale e ai clienti
un protipo di app mobile
funzionante, per ottenere
feedback

SUCCESSIVE 8 ITERAZIONI Case
13/17

14/17


rendere il tutto semplice
e affidabile sia per l'utente finale
che per l'installatore

• riduzione delle feature ipotizzate per l'app
• introduzione di una webapp da cui:
✴ come utente finale puoi controllare i dispositivi via browser
✴ come installatore puoi configurare facilmente il sistema

15/17


rendere il tutto semplice
e affidabile sia per l'utente finale
che per l'installatore

deliverables
• sviluppo funzionalità webapp
• piccole implementazioni su app
• schizzi, wireframe, grafica webapp e supervisione

RISULTATI Case
16/17

• app mobile funzionante, con poche feature utili
a far capire le potenzialità del sistema

• webapp funzionante per accesso via browser,
con funzionalità d'uso per l'utente
e di conﬁgurazione per l'installatore

• presentazione alla forza vendita e alla rete del
cliente per feedback sul prodotto, raccolta idee
e riﬂessioni (business o consumer? strategia di
mercato, business model, futuri investimenti
ecc.)

SI RIPARTE Case
17/17


commercializzazione
del prodotto
Oltre 30 iterazioni
• valutazione su feedback ricevuti e decisioni strategiche del
product owner
• messa a punto app e webapp
• aggiunta di feature importanti per alcune zone
(Sud America e Spagna)
• commercializzazione e lancio del sistema nel mercato

#1 difficoltà
1/2

accettare che un progetto
potesse essere considerato
riﬁnito anche se per me
non era “perfetto”

#2 difficoltà
2/2

pensare come il cliente,
comprendendo il perché
delle sue richieste

#2 conclusioni
2/4

trovare il modo per discutere
e condividere il lavoro con il
team

(non importa con quale strumento)

#3 conclusioni
3/4

essere pronti
a cambiare abitudini

#4 conclusioni
4/4

focus sull'obiettivo:
consegnare valore
al cliente

Perché non facciamo più quello che ci piace - Italian Agile Day 2012

Perché non facciamo più quello che ci piace - Italian Agile Day 2012

Recommended

More Related Content

Viewers also liked

Viewers also liked(16)

Similar to Perché non facciamo più quello che ci piace - Italian Agile Day 2012

Similar to Perché non facciamo più quello che ci piace - Italian Agile Day 2012(6)

More from Ilaria Mauric

More from Ilaria Mauric(11)

Perché non facciamo più quello che ci piace - Italian Agile Day 2012