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

Transcript

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 una community che permette ai viaggiatori di pianificare le proprie vacanze con l aiuto di locali, esperti e professionisti Alpha: Febbraio Beta: Maggio (est.)

5 I PROTAGONISTI Project Managing Community design ideato web ideas for sale Sviluppo PHP su Symfony 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 Iterazione Punti Velocity Cliente Fattura 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 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

13 AGILE PROJECT MANAGER S C APM UX V

14 AGILE PROJECT MANAGER S C APM UX V

15 AGILE PROJECT MANAGER S C APM UX V

16 AGILE PROJECT MANAGER S C APM UX V

17 AGILE PROJECT MANAGER S C APM UX V

18 AGILE PROJECT MANAGER S C APM UX V

19 AGILE PROJECT MANAGER S C APM UX 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 APM e 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 è: 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)

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 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!)

29 DOMANDE, OSSERVAZIONI? Antonio Bonanno