Embed Size (px)
DESCRIPTION
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à?
Citation preview
AGILE IL TEAM, MA IL CLIENTE?Trasmettere al cliente valori, vantaggi e necessità
dello sviluppo agile
ANTONIO BONANNO
• 27 anni, Milano, laureato in legge
• 2003, Etz.it
• 2007, Digital Natives
• 2008, TripShake.com
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
IL PROGETTO:TRIPSHAKE
• E’ una community che permette ai viaggiatori di pianificare le proprie vacanze con l’aiuto di locali, esperti e professionisti
• Alpha: Febbraio 2009
• Beta: Maggio 2009 (est.)
I PROTAGONISTI
ideatoweb ideas for sale
SviluppoPHP su Symfony
ProgettazioneUser Experience
VisualXHTML
Project ManagingCommunity design
CAPITOLO IFeature 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
CAPITOLO IFeature creeps: il cliente ha sempre ragione?
Il linguaggio specifico
Sviluppatore
Iterazione
Punti
Velocity
CAPITOLO IFeature creeps: il cliente ha sempre ragione?
Il linguaggio specifico
Sviluppatore
Iterazione
Punti
Velocity
Cliente
Fattura
€
Lentezza
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...
CASE STUDY: TRIPSHAKE
MAJOR SCREW UP!
Iterazione 10 giorni -> 17 giorni
=
impennata di costi
ritardo sulla release
client panic!
CASE STUDY: TRIPSHAKE
Durante il debriefing, le cause sono state individuate:
mancanza di comunicazione tra i team, geograficamente distribuiti
mancanza di “agile project management”
AGILE PROJECT MANAGER• Gestisce la 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
AGILE PROJECT MANAGER
C
S
UX
V
APM
AGILE PROJECT MANAGER
C
S
UX
V
APM
AGILE PROJECT MANAGER
C
S
UX
V
APM
AGILE PROJECT MANAGER
C
S
UX
V
APM
AGILE PROJECT MANAGER
C
S
UX
V
APM
AGILE PROJECT MANAGER
C
S
UX
V
APM
AGILE PROJECT MANAGER
C
S
UX
V
APM
# 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
# 1: PROGETTAZIONE
• L’APM e il team di progettazione (UX) incontrano il cliente e formulano le storie utente
• L’APM e UX trasferiscono le storie al team di sviluppo, che le completa con le storie funzionali, i requirement, etc.
# 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
# 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
# 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.
# 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
MA CHI È APM?
• APM è:
• il confessore del cliente, al quale il cliente racconta bisogni, necessità, frustrazioni nell’esperienza della creazione della sua applicazione
• il filtro e il riferimento del team: funge da filtro dei rant del cliente, e da parafulmine per eventuali difficoltà durante la fase di sviluppo e consegna (sì, è sempre colpa sua)
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
TRASMETTERE IL VALORE
• Il problema più rilevante, come per tutte le professioni ad alto valore aggiunto, è la percezione del valore da parte del cliente
• Value proposition: taglio dei costi di realizzazione, taglio dei tempi di sviluppo (ma bisogna mantenere la promessa!)
