I meccanismi e i metodi dell'agile sono spesso di difficile comprensione per i clienti, abituati a lavorare con metodologie diverse, in strutture organizzative complesse e meno agili per natura. Il cliente agile, quindi, è ancora un miraggio o è già realtà?

1. AGILE IL TEAM, MA IL CLIENTE?
Trasmettere al cliente valori, vantaggi e necessità
dello sviluppo agile

2. ANTONIO BONANNO
• 27 anni, Milano, laureato in legge
• 2003, Etz.it
• 2007, Digital Natives
• 2008, TripShake.com

3. DIGITAL NATIVES
• promozione dell’immagine aziendale sui social media
• progettazione, sviluppo e gestione di social network e
community
• progettazione, sviluppo
e gestione di progetti di
comunicazione e marketing on-line
• personalizzazione di piattaforme CMS
• formazione e training di community management

4. IL PROGETTO:
TRIPSHAKE
• E’ unacommunity che permette ai
viaggiatori di pianificare le proprie
vacanze con l’aiuto di locali, esperti e
professionisti
• Alpha: Febbraio 2009
• Beta: Maggio 2009 (est.)

5. I PROTAGONISTI
Project Managing
Community design
Sviluppo
ideato
PHP su Symfony
web ideas for sale
Progettazione
User Experience
Visual
XHTML

6. CAPITOLO I
Feature creeps: il cliente ha sempre ragione?
• Il cliente:
• sa cosa vuole, ma non sa come ottenerlo
• sa cosa vuole, sa come ottenerlo, ma non è in grado di
valutare l’effort
• non sa cosa vuole, ma sa che se qualcosa va male, è colpa
tua

7. CAPITOLO I
Feature creeps: il cliente ha sempre ragione?
Il linguaggio specifico
Sviluppatore
Iterazione
Punti
Velocity

8. CAPITOLO I
Feature creeps: il cliente ha sempre ragione?
Il linguaggio specifico
Sviluppatore Cliente
Iterazione Fattura
Punti €
Velocity Lentezza

9. CASE STUDY: TRIPSHAKE
• Settembre 2008: iterazione 1
• dopo una prima fase di progettazione, si sono
scritte le storie di tutto il progetto (da qui a 5
anni, probabilmente!)
• durante lo sviluppo: il cliente era tranquillo che
gli sviluppatori avessero capito, gli sviluppatori
erano tranquilli che il cliente avesse capito, il
progettista era tranquillo che il visual avesse
capito...
RISULTATO...

10. CASE STUDY: TRIPSHAKE
MAJOR SCREW UP!
Iterazione 10 giorni -> 17 giorni
=
impennata di costi
ritardo sulla release
client panic!

11. CASE STUDY: TRIPSHAKE
Durante il debriefing, le cause sono state individuate:
mancanza di comunicazione tra i team, geograficamente
distribuiti
mancanza di “agile project management”

12. AGILE PROJECT MANAGER
• Gestiscela comunicazione tra il cliente e i team di
sviluppo e progettazione
• Traduce
le esigenze del cliente in un linguaggio
comune al team
• Traduce il linguaggio del team di sviluppo in
concetti comprensibili al cliente
• Assicura
la comunicazione continua all’interno del
team durante le fasi di progettazione e sviluppo

13. AGILE PROJECT MANAGER
S
APM UX
C
V

14. AGILE PROJECT MANAGER
S
APM UX
C
V

15. AGILE PROJECT MANAGER
S
APM UX
C
V

16. AGILE PROJECT MANAGER
S
APM UX
C
V

17. AGILE PROJECT MANAGER
S
APM UX
C
V

18. AGILE PROJECT MANAGER
S
APM UX
C
V

19. AGILE PROJECT MANAGER
S
APM UX
C
V

20. # 0: STRATEGIA
• L’APM incontra il cliente e definisce la visione strategica e gli
obiettivi del progetto
• L’APM accompagna il cliente alla definizione delle linee guida
di progetto
• L’APM definisce con il cliente modi e tempi di esecuzione

21. # 1: PROGETTAZIONE
• L’APM e il team di progettazione (UX) incontrano il cliente e
formulano le storie utente
• L’APMe UX trasferiscono le storie al team di sviluppo, che le
completa con le storie funzionali, i requirement, etc.

22. # 2: TEMPI E COSTI DI
SVILUPPO
•S manda a APM una valutazione dei costi e dei tempi, e una
lista di requisiti da richiedere agli altri team
• APM raccoglie e gestisce le valutazioni di costi e tempi da tutti
i team, scrive il progetto e li trasferisce al cliente

23. # 3: REALIZZAZIONE
• APM si occupa di raccogliere tutto il materiale necessario per
l’inizio dello sviluppo, che *non comincia* finché tutto il
materiale non è stato raccolto
• APM si assicura che le scadenze di ogni team siano rispettate
e coordina la comunicazione interna del team

24. # 4: TESTING
• APM testa personalmente l’applicazione, con un approccio
“story by story” e ne verifica l’aderenza con le aspettative, la
vision e la mission del cliente
• APM organizza un’iterazione di bug fixing, coinvolgendo tutti
team: per “bug” non si intende solo difetti tecnici, (codice o
visual) ma anche di progettazione, usabilità, etc.

25. # 5: CONSEGNA
• APM e S si recano dal cliente per la consegna: viene
organizzata una demo, e si determinano le fasi e le modalità
dell’installazione preferita dal cliente
• APM rimane a disposizione del cliente per la fase di testing e
implementazione, e si occupa di trasferire ulteriori richieste di
bug fixing: è APM che filtra le necessità del cliente

26. MA CHI È APM?
• APM è:
confessore del cliente, al quale il cliente racconta bisogni,
• il
necessità, frustrazioni nell’esperienza della creazione della
sua applicazione
filtro e il riferimento del team: funge da filtro dei rant del
• il
cliente, e da parafulmine per eventuali difficoltà durante la
fase di sviluppo e consegna (sì, è sempre colpa sua)

27. WHAT COULD GO WRONG?
• APM, durante lo sviluppo, si troverà tipicamente ad affrontare:
• disallineamenti: tra le richieste del cliente e la
progettazione, tra il progettato e il realizzato, tra le richieste
di S e il deliverable del V, etc...
• ritardi: sulle
milestone intermedie da parte di un singolo
team o più team, sulla consegna del progetto, sulle consegne
del materiale necessario o delle richieste da parte del cliente

28. TRASMETTERE IL VALORE
• Ilproblema più rilevante, come per tutte le professioni ad alto
valore aggiunto, è la percezione del valore da parte del cliente
proposition: taglio dei costi di realizzazione, taglio dei
• Value
tempi di sviluppo (ma bisogna mantenere la promessa!)

29. DOMANDE, OSSERVAZIONI?
Antonio Bonanno
antonio@digitalnatives.eu
+393381163721