2013-­2014

1

3

3

7

7

8

9

11

12

13

14

19

19

20

23

24

26

27

28

31

31

32

Indice

Introduzione .....................................................................................................................

Capitolo 1: Introduzione al Project Management .........................................................

! 1.1 Storia del Project Management ........................................................................

! 1.2 Le Attività di gestione di un progetto ...............................................................

1.2.1 Definizione degli obbiettivi e degli scopi .................................................

1.2.2 Definizione dei vincoli di progetto e del loro impatto sulla qualità ..........

1.2.3 Pianificazione ed avvio del processo .....................................................

1.2.4 Controllo del processo ed aggiustamenti ...............................................

1.2.5 Completamento del progetto ed attività di revisione ..............................

Capitolo 2: Lo User Experience Design .......................................................................

! 2.1 I principi chiave dello User Centered Design .................................................

Capitolo 3: Dal Waterfall lifecycle all’Agile .................................................................

3.1.1 Il software e la nascita della metodologia Waterfall ..............................

3.1.2 Le fasi del modello a Cascata ..............................................................

3.1.3 L’evoluzione del framework Waterfall ....................................................

3.1.4 Le motivazioni che spingono alla nascita dell’Agile: L’evoluzione dei canali

di distribuzione, la prima bolla Dot-com e la necessità di progettare esperienze

d’uso per le persone ......................................................................................

! 3.2 La nascita delle metodologie agili ..................................................................

3.2.1 I 12 principi su cui l’Agile si basa ..........................................................

3.2.2 Il processo di sviluppo Agile ed alcune differenze rispetto al modello a

Cascata ..........................................................................................................

Capitolo 4: Lo Scrum, uno dei framework Agile ........................................................

! 4.1 Introduzione allo Scrum Agile ........................................................................

! 4.2 La teoria su cui si basa lo Scrum Agile ..........................................................

33

34

35

35

36

39

39

39

41

44

44

45

46

46

47

47

50

52

52

54

55

57

59

61

! 4.3 Lo scheletro che sorregge lo Scrum e il suo processo ..................................

! 4.4 I ruoli nello Scrum ..........................................................................................

! 4.5 User Story: la più piccola unità di lavoro all’interno del product backlog

! espressa come bisogno per l’utente finale ...........................................................

4.5.1 La struttura di una user story ................................................................

4.5.2 I criteri di accettazione di una user story ..............................................

Capitolo 5: Come lo User Experience Design può integrarsi con un framework Agile:

la Lean UX .....................................................................................................................

! 5.1 Lo User Experience Design: da parte del processo di sviluppo fino a divenire il

! processo stesso ...................................................................................................

5.1.1 La nascita della Lean UX e le sue fondamenta ....................................

5.1.2 I principi della Lean UX ........................................................................

! 5.2 Il processo di Lean UX ..................................................................................

5.2.1 Fase 1: La dichiarazione di assunzioni ................................................

5.2.2 Fase 2 e 3: Creare un Minimum Viable Product e sperimentare .........

5.2.3 Fase 4: Feedback e Ricerca ................................................................

! 5.3 Caso Studio: l’integrazione possibile tra UX Design e Agile .........................

5.3.1 Una breve introduzione al prodotto ......................................................

5.3.2 La Kick-Off session ..............................................................................

5.3.3 La necessità di una visione comune del prodotto ................................

5.3.4 Lavorare prima veloci per poi arrivare ad un design asettico ..............

5.3.5 Implementare un processo di Lean UX sfruttando il ritmo dello Scrum

5.3.6 Il workspace ........................................................................................

5.3.7 I risultati raggiunti .................................................................................

Conclusioni ...................................................................................................................

Bibliografia ....................................................................................................................

Ringraziamenti ..............................................................................................................

Introduzione

Il project management, ovvero la capacità umana di organizzare, pianificare, controllare

e migliorare un processo, può essere anche visto come una delle necessità e uno dei

bisogni dell’uomo moderno. Un esempio è l’uso del calendario, come supporto per

scandire gli impegni quotidiani. Spostando l’attenzione nell’ambito aziendale, non

esiste impresa moderna che non si affidi ad un framework di project management, sia

esso basato sul modello Waterfall, Agile o altro. Pianificare, conoscere e prevedere sono

infatti aspetti chiave per l’abbassamento del rischio di fallimento di un’impresa o di un

progetto.

Lo User-Centered Design, disciplina fondata nella seconda metà degli anni ’80, ha

avuto sin da subito l’occasione di entrare in stretta sinergia con il project management,

ispirando in parte alcune delle sue evoluzioni e venendo a sua volta ispirato da questo.

La tesi si presenta divisa in 3 parti: Nella prima, discuteremo i concetti di project

management e user experience in modo generale lasciandoli distinti, per poi andare a

trattare nella seconda parte l’evoluzione delle pratiche di gestione del progetto a partire

dal modello a cascata fino ad arrivare allo Scrum Agile, accostandole allo User-

Centered Design e trattando il rapporto che è andato negli anni ad instaurarsi tra le due

discipline.

Nell’ultimo capitolo analizzeremo infine il più moderno approccio allo User

Experience Design, e come questo possa integrarsi in modo efficace con il framework

Scrum Agile, portando come esempio un case study estratto dalla mia esperienza di

tirocinio, svoltasi in una startup, Future Workshops, con base a Londra tra la fine del

2012 e l’inizio del 2013 dove ho avuto l’occasione di confrontarmi con un asset

aziendale ben definito lavorando all’interno di un team multidisciplinare ad un progetto

interno di prototipazione.

1

2

Capitolo 1: Introduzione al Project Management

L'espressione inglese "project management" si riferisce ad una serie di attività atte a gestire e coordinare uno o più progetti contemporaneamente, in cui i membri di uno o più team multidisciplinari lavorano in sinergia per raggiungere scopi ed obbiettivi, rispettando dei vincoli imposti. Il P.M.I. (Project Management Institute) definisce inoltre il project management come l'applicazione di conoscenze, attitudini, tecniche e strumenti alle attività di un progetto al fine di conseguirne gli obiettivi (Project Management Institute, 2003).

1.1 Storia del Project ManagementI primi esempi di project management di cui troviamo traccia nella storia, nascono in tempi remoti, in seno a civiltà distanti tra di loro. Pensiamo ad esempio alle Piramidi Egiziane e a quelle Maya, due progetti colossali, costruiti in due continenti lontani, da civiltà che probabilmente non si incontrarono mai. Opere imponenti come queste, a cui vi lavorarono fino a 100.000 uomini per un periodo di vent'anni come nel caso della piramide di Cheope in Egitto, non sarebbero mai state realizzabili, senza una corretta gestione delle risorse umane, economiche, materiali e temporali. E’ solo a seguito della rivoluzione industriale, con il fermento da essa suscitato e con l'avvento delle fabbriche, che il Project Management si evolse divenendo progressivamente una disciplina. Frederick Taylor (1865-1915), ingegnere ed imprenditore statunitense, espresse nelle sue teorie la necessità di analizzare in modo sperimentale i metodi produttivi al fine di renderli più efficienti. Secondo i suoi studi, era fondamentale creare un canale di comunicazione e collaborazione diretto tra manager ed operai specializzati, al fine di trovare insieme la "one best way", il modo, ritenuto unico e migliore, per compiere una qualsiasi operazione e quindi ottimizzare un processo. Inizialmente il Taylorismo, puntava a migliorare solamente il lato produttivo della fabbrica, ma successivamente, propose anche una standardizzazione del lato manageriale della stessa, con la definizione di 8 figure dirigenziali. Agli inizi del '900, i suoi studi vennero ripresi da Henry Ford (1863–1947), altro celebre imprenditore statunitense e fondatore dell'omonima casa automobilistica, che li usò come base su cui progettare il ciclo produttivo della

3

Fig.1 catena di montaggio della Ford Motors Company nel 1908

Ford Motor Company. Apportando alcune modifiche (si parla in questo caso di

Fordismo e non più di Taylorismo) ingegnerizzò quella che è considerata la prima catena di montaggio della storia applicata all'industria.

Altro "discepolo" di Taylor e suo associato, fu Henry Gantt (1861-1919), un

ingegnere meccanico ed imprenditore statunitense, che come il suo predecessore, credeva nel bisogno di osservare ed analizzare con metodo sperimentale i

processi di produzione, scomponendoli in piccoli pezzi detti task. Fù lui

l’ideatore attorno al 1910 di uno strumento grafico detto Diagramma di Gantt, ancora oggi molto usato nelle attività di project management. Questo, consente la pianificazione del lavoro su di una linea temporale e di tenere controllati i

progressi di produzione. Fù talmente rivoluzionario e moderno per i tempi che solo negli anni 90' venne aggiornato, con l'aggiunta di linee di collegamento,

dette link, che permettono di rappresentare in modo più accurato le dipendenze esistenti tra le attività di progetto.

Poco prima della Seconda Guerra Mondiale, nel 1939, il governo degli U.S.A avviò un progetto di ricerca denominato Manhattan il quale, pochi anni

dopo (1942) fù trasformato in un progetto militare atto alla costruzione del primo ordigno atomico. Esso riuscì ad impegnare fino a 130.000 persone, tra cui

numerosi scienziati europei scappati negli Stati Uniti dalle persecuzioni naziste. Inoltre, il suo costo raggiunse circa i 2 miliardi di dollari dell’epoca (28 miliardi

di dollari attuali). La direzione dei lavori venne affidata al fisico Robert Oppenheimer, che, per timore di non riuscire a costruire la bomba atomica in una

finestra temporale utile, ovvero prima degli scienziati dell’asse nazista, diede avvio a due linee di ricerca indipendenti, cercando così di ottimizzare lo

4

sfruttamento delle ingenti risorse messe a disposizione dal governo statunitense.

Entrambe riuscirono, attorno al 1945, a realizzare con successo l’ordigno atomico, attraverso l’uso di due tecniche distinte. Questo viene considerato il

primo esempio di project management moderno. La fine del Secondo Conflitto Mondiale fù caratterizzata sul fronte civile,

dall’esigenza di ricostruire, soprattutto in Europa, numerose opere impiantistiche ed infrastrutturali di grandi dimensioni che erano andate distrutte durante la

guerra. La necessità di realizzare progetti in tempi ridotti e con risorse limitate, diede l’impulso alla nascita di metodologie di project management sempre più

efficaci come il CPM (Critical Path Model) ed il PERT (Program Evaluation and Review Technique), uno strumento di gestione, che permise per esempio alla

Marina Militare Statunitense, coordinando contemporaneamente migliaia di fornitori e di subappaltatori, di ridurre i tempi di costruzione dei sottomarini

nucleari durante la guerra fredda (Luis Yu Chuen-Tao, 1994) E’ in questi anni di ripresa economica che il project management cominciò

ad infiltrarsi in tutte le tipologie d’industria, che sentivano il bisogno di nuovi strumenti per rimanere al passo con un mondo sempre più competitivo ed in

veloce evoluzione. Negli anni ’60, entrò nel mondo del management il concetto di earned

value (valore raggiunto), secondo cui, per un'effettiva comprensione dello stato di avanzamento di un progetto, è necessario conoscere la relazione esistente tra

l'avanzamento temporale e quello economico. In altre parole, al momento della pianificazione, viene definito un planned value desiderato per ogni momento del

progetto (linea rossa nel grafico). Durante le fasi di avanzamento, solitamente di settimana in settimana, il project manager tiene traccia dell’actual cost (Linea

blu), cioè dell’ammontare dei costi affrontati. Inoltre, sommando il valore degli obbiettivi raggiunti dal progetto fino a quel momento si ottiene appunto l’earned

value. Nel caso del grafico proposto in figura 2, il progetto ha un earned value superiore ai costi, ma comunque si presenta in ritardo in termini di tempo e

valore rispetto al planned value (Fleming, Koppelman, 2000). Uno dei primi progetti a cui venne applicato il paradigma sopra descritto fù

il Programma Apollo, che culminò con lo sbarco del primo uomo sulla luna nel 1969. Il progetto, rappresentò una sfida senza precedenti in termini di tecnologia

e capacità organizzative, visto il considerevole aumento del numero di dipendenti della NASA (da 10.000 a 36.000 addetti) tra il 1960 e il 1963

5

Fig.2 Grafico per la valutazione ed il tracking dell’Earned Value

Negli anni ’70 ed ‘80 si verificò una nuova evoluzione grazie all’avvento di

sistemi informatici di tipo hardware e software a supporto delle attività di gestione dei progetti. A partire dagli anni ’70, inoltre, il Project Management

entrò nel mondo del Software e dell’IT, con l’ideazione e l’adozione da parte delle industrie dell’epoca della metodologia del Modello a Cascata (Waterfall

Model) o Ciclo di vita/sviluppo a Cascata (Waterfall life-cycle) che verrà in seguito pesantemente criticata a partire dalla fine degli anni ‘80.

Il project management estese in quegli anni le sue applicazioni a progetti critici per la strategia aziendale come il re-engineering dei processi produttivi,

l'introduzione di nuovi prodotti e servizi, l'adeguamento del business aziendale ai benchmark di mercato e lo sviluppo di nuovi business.

Attorno agli anni 2000, è nuovamente dall’industria del software che arriva una spinta al rinnovamento delle metodologie di gestione progetto. Ci si

rendeva infatti conto che il Modello a cascata non si adattava alle esigenze di velocità e snellezza sempre più richieste nello sviluppo del software, ma

6

soprattutto, che la vecchia metodologia limitava il coinvolgimento dei clienti e

degli utenti solo alle fasi iniziali e finali del ciclo. Per questo, nel 2001, alcuni progettisti del software e guru dell’informatica, decisero di fondare l’Agile

Alliance, che portò alla pubblicazione del documento oggi conosciuto come Agile Manifesto, uno sforzo d’intenti, sottoscritto dai soci dell’associazione, che

mirava a spostare l’attenzione del mondo IT sulla necessità di soddisfare il cliente e l’utente piuttosto che sullo sviluppo di un software migliore. Nasceva

così l’Waterfall, l’ultima grande metodologia di project management e sviluppo, da cui derivarono in seguito framework tra cui lo Scrum Agile che vedremo in

modo approfondito nel capitolo 4.

1.2 Le attività di gestione di un progettoLa gestione di un progetto, comincia già nelle fasi preliminari di stima e di preventivazione, dove diventa importante l’identificazione dei suoi confini

dimensionali. Questa è una attività delicata e complessa in quanto il project manager deve procedere alla scomposizione e valutazione di ogni singola parte

del processo, tenendo conto di molti fattori che andremo ora ad analizzare.

1.2.1 Definizione degli obbiettivi e degli scopiNella prima parte di un progetto, si devono identificare e fissare per quanto possibile gli obbiettivi e i risultati attesi dal cliente (nel caso di un progetto per

conto terzi) o dall’azienda per cui si lavora (nel caso di un progetto interno), tenendo conto che durante le varie fasi del progetto ci potranno comunque essere

degli aggiustamenti o dei cambiamenti più o meno importanti, a seconda della metodologia di project management adottata.

Le persone, come gli stakeholder, sono inclini a fornire obbiettivi ad un alto livello di granularità di dettaglio come ad esempio:

“Vorrei un nuovo sito accattivante”

Diventa quindi fondamentale estrapolare informazioni circa le loro aspettative, in

modo più approfondito e definito. Per stabilire gli obbiettivi di un progetto molte aziende si affidano allo S.M.A.R.T criteria che è l’acronimo di: Specific,

Measurable, Attainable, Relevant e Time-Bound (Kerzner, 2013).

7

Questo, permette la redazione di obbiettivi che siano:- Specifici, chiari e comprensibili a tutti gli stakeholder (Soggetti coinvolti nel

progetto). E’ infatti ampiamente riconosciuto come tra le principali cause di fallimento o ritardo nei progetti, specialmente nel mondo del software/IT, ci

siano gli errori di comunicazione (Al-Rawas, Easterbrook, 1996). La specificazione dei requisiti e degli obbiettivi, è una attività che implica il

coinvolgimento di vari domini di conoscenza, come quello tecnico ed amministrativo. Normalmente, i membri appartenenti ad un team di lavoro non

hanno tutte le conoscenze necessarie per comprendere al meglio ogni dominio. Per essere produttivi, hanno quindi bisogno di integrare le loro conoscenze

attraverso flussi d’informazione esterni, la cui acquisizione e condivisione può avvenire solo attraverso una comunicazione chiara ed efficace;

- Misurabili, in quanto diventeranno delle metriche importanti per la

comprensione dei progressi del progetto e del suo successo conclusivo;

- Realistici e raggiungibili, ovvero devono esser stilati tenendo in considerazione le risorse disponibili;

- Rilevanti: ogni obbiettivo dovrebbe essere per il progetto portatore di valore

aggiunto;

- Con una data d’inizio e di fine definite, al fine di concentrare gli sforzi del team sul soddisfacimento del prossimo obbiettivo in scadenza.

1.2.2 Definizione dei vincoli di progetto e del loro impatto sulla qualitàTutti i progetti, indipendentemente dalle loro dimensioni, sono condizionati da molti vincoli (detti anche variabili). La loro definizione, come per gli obbiettivi, è

fondamentale nella gestione di un processo di sviluppo. Per analizzare e capire le difficoltà che possono emergere nell’implementazione ed esecuzione di un

progetto, i product manager fanno solitamente uso di uno strumento grafico detto “triangolo del project management” (Kerzner, 2013), ai cui vertici vengono poste

le 3 categorie di vincoli interdipendenti tra loro che sono:

8

Fig. 3 Il Triangolo del Project Management

- Risorse e costi: Le risorse finanziare, umane e tecnologiche, allocate e

destinate al progetto, dovranno essere valutate e conosciute fin da subito, ma soprattutto dovranno essere commisurate realisticamente alle ambizioni e al

livello di difficoltà del progetto. Per fare ciò, i costi, dovranno essere stimati e definiti correttamente, tenendo conto di un certo margine d’errore;

- Tempo: deve essere considerato un’altro vincolo fondamentale. Come le risorse, dovrà essere anche’esso commisurato alle ambizioni e alle difficoltà del

progetto;- Features e scopi: rappresentano la quantità ed il tipo di funzionalità che un

prodotto dovrà possedere al termine del progetto. Durante il processo di stima ad ogni feature verrà assegnato un peso specifico differente relativo alla

difficoltà di sviluppo, al tempo e alle risorse necessarie per la sua implementazione.

Al centro del triangolo infine viene posta la qualità finale del progetto/prodotto sviluppato, influenzata dalle forze poste ai vertici. Essa viene definita

come la capacità di un insieme di caratteristiche inerenti un prodotto, sistema, o processo di ottemperare a requisiti di clienti e di altre parti interessate (Hoyle,

2008). In altre parole, la qualità è il grado con cui il prodotto risponde alle aspettative del committente. Per non comprometterla, il product manager deve

essere in grado di mantenere equilibrio tra le tre diverse categorie di vincoli durante tutto il processo di sviluppo (Curtis et al., 1988).

1.2.3 Pianificazione ed avvio del processoPianificare l’esecuzione di un processo significa, passare dalla fase di studio

preliminare, descritta nei due paragrafi precedenti, ad una fase di ricerca delle operazioni o task necessari al raggiungimento degli obbiettivi nel rispetto dei

9

Fig. 4 Esempio di WBS

vincoli precedentemente fissati. Pianificare significa quindi dare una struttura

d’esecuzione al progetto. Questa struttura viene definita solitamente nella WBS, acronimo di Work Breakdown Structure, un processo top-down attraverso cui il

project manager scompone il progetto, prima in macro-task e poi prendendo questi ultimi li divide nuovamente in operazioni più piccole, fino ad arrivare a

descrivere ciascun compito con il livello di dettaglio desiderato. Se un task presente nella struttura risultasse troppo complesso, il project manager lo

scomporrà in una nuova serie di elementi più semplici. La WBS assicura che ogni dettaglio rilevante venga mostrato nella struttura finale, senza rischiare d’esser

dimenticato durante le fase di esecuzione del progetto, perchè “inglobato” in un task troppo grande e complesso. Un errore comune che spesso si presenta durante

la fase di pianificazione consiste nella creazione di una WBS troppo dettagliata e ricca di particolari non rilevanti, soprattutto nella fase iniziale del progetto.

In seguito alla definizione della struttura del progetto, il project manager deve

procedere alla allocazione delle risorse dedicate a ciascun task, in modo da assicurare il rispetto dei vincoli emersi nella fase di studio preliminare.

Per ogni task il project manager deve:- Pianificare il momento e valutare la durata di esecuzione del compito, tenendo

conto dell’interdipendenza che esiste tra tutte le operazioni che compongono un progetto;

- Assegnare un budget;- Allocare le necessarie risorse umane;

Per la stesura della pianificazione solitamente il project manager si affida a strumenti grafici come il Diagramma di Gannt, già incontrato nel paragrafo

10

1.1, o similari. Questo, oltre ad aiutarlo nelle fasi iniziali di pianificazione, risulta

utile anche per tener traccia dello stato di avanzamento del progetto.

1.2.4 Controllo del processo ed aggiustamentiDopo la parte di pianificazione, il progetto entra nella sua fase più intensa: quella dello sviluppo. Il ruolo del project manager assume ora una nuova funzione di

controllo e di gestione del rischio, che va ad integrarsi con tutte le attività fino a qui descritte e che continuano a far parte della sua routine. Al fine che questa fase

avvenga in modo agevole, è necessario che gli obbiettivi definiti ad inizio progetto siano misurabili, in modo da divenire ora indici di valutazione e

confronto.Controllare il processo significa:

- Monitorare l’avanzamento del progetto in funzione della pianificazione effettuata in precedenza;

- Monitorare le variabili/vincolo descritte nel paragrafo 1.2.2, apportando degli aggiustamenti, se necessari;

- Monitorare altri elementi detti “di rischio” che possono portare il progetto al fallimento o alla sua compromissione;

I fattori di rischio, assieme all’incertezza, vengono definiti come gli

elementi che caratterizzano le situazioni dove il risultato attuale per un particolare evento o attività è deviato dalle previsioni e dal valore stimato

(Raftery, 1994). In altre parole, può essere considerato rischioso, un qualsiasi

evento che possa diventare causa del fallimento o compromissione di un progetto. Tuttavia i fattori di rischio possono essere in molte occasioni previsti.

Nel caso questo non avvenga, è compito del product manager eliminarli o calmierarli. Questo può essere possibile lavorando sulla pianificazione del

progetto ed allocando nuove risorse.Alcuni dei fattori di rischio che possono presentarsi durante lo sviluppo di un

software sono:a. Mancanza di adeguate competenze all’interno del team;

b.Budget e tempistica non realistici: Il rischio consiste nel non rispettare i vincoli di budget e tempo imposti dal cliente oppure sottostimati durante la fase di

definizione e pianificazione del progetto;

11

c. Sviluppo di funzioni non necessarie: L’eccessivo tempo dedicato a funzioni

minori potrebbe intaccare la qualità delle funzioni principali;d.Continue modifiche dei requisiti da parte del committente, nel caso

dell’utilizzo di metodologie di management definite pesanti come la Waterfall;

1.2.5 Completamento del progetto ed attività di revisioneL’ultima parte della gestione di un progetto, soprattutto nel caso di software e

prodotti IT, riguarda il completamento ed il rilascio del prodotto preceduto da:- una fase di validazione da parte del reparto QA (Quality Assurance) che

controlla e certifica che il prodotto soddisfi tutti i requisiti definiti all’inizio del progetto;

- una fase di usability testing dove alcune persone, identificate come soggetti rappresentativi della popolazione a cui il prodotto è rivolto, vengono coinvolte

nella valutazione del grado con cui l’artefatto rispetta i criteri di usabilità;

L’effettiva fase di chiusura a seguire, può essere guardata da due punti di

vista:- Chiusura del progetto con lo scioglimento del team di lavoro e l’assegnazione

di quest’ultimo a nuovi progetti. Sarà compito del product manager, stilare un bilancio finale del progetto che comprenda, i costi effettivi, le statistiche circa la

performance del team, ed un rapporto di chiusura;- Chiusura del contratto: Il project manager si occupa di ottenere l’accettazione

formale del prodotto da parte del cliente, assicurandosi che entrambe le parti adempiano a tutti gli obblighi contrattuali;

12

Capitolo 2: Lo User Experience Design

Il termine User Experience, venne usato per la prima volta a metà degli anni ’90

(precisamente nel 1995), da Donald Norman, Professore di Psicologia, Scienze

Cognitive ed Informatica presso la Northwestern University e consulente del

Nielsen Norman Group. Come da lui stesso dichiarato, coniò questa espressione in quanto riteneva che “Human Interface” e “Usability” fossero concetti troppo

limitati per coprire tutti gli aspetti dell’esperienza, inclusi l’industrial design, la grafica, l’interfaccia, l’interazione fisica, che una persona prova interagendo con

un sistema.

! Lo UCD (acronimo di User Centered Design) Design viene definito, sempre da Norman, come una metodologia di progettazione che nasce con l’obbiettivo di creare prodotti in grado di servire le persone, piuttosto che utilizzare una tecnologia specifica o creare un elegante “pezzo di codice”. Gli utenti e i loro bisogni, dovrebbero dominare il design dell’interfaccia e esser chiamati in causa ad ogni passo del processo di sviluppo di un prodotto (Norman, 1986). Alan Cooper, riguardo all’Experience Design nel campo dei prodotti digitali, sottolinea, come fece Norman nella sua definizione di UCD, la

multidisciplinarità della materia e come sia richiesta per un design project una particolare attenzione nell’orchestrazione di un gran numero di discipline di

design, ciascuna avente un ruolo diverso ma complementare alle altre (Cooper et al.,2007) (Fig . 5).

Fig. 5: Diagramma che mostra come la User Experience abbia un carattere fortemente multidiscplinare

13

iPod Software CAD

Utenti Teenagers, Sportivi etc.Architetti, progettisti, Ingegneri meccanici etc.

Bisogni/Scopiascoltare musica in mobilità, magari facendo sport etc.

Progettare, esplorare soluzioni, condividere disegni con i clienti etc.

Ambiente d’utilizzo

Dal salotto al parco

In un ufficio silenzioso oppure in un ambiente come la metropolitana, durante il percorso casa lavoro

Fig.6 Comparazione dei differenti utenti di un iPod e un software CAD, gli utilizzi che essi ne fanno e l’ambiente in cui le persone e il prodotto interagiscono

2.1 I 6 principi chiave dello User Centered DesignLo normativa standard ISO 9241-210 del 2010, definisce i 6 principi chiave che certificano ed assicurano che un processo di design sia di tipo user-centered:

• Il design deve essere basato sulla esplicita comprensione degli utenti, dei loro bisogni e scopi e degli ambienti in cui l’interazione tra user e sistema avviene: Prima, durante, e nelle reiterazioni del processo di design e sviluppo, si devono comprendere in modo chiaro e definito le tre variabili sopraelencate in modo da progettare adeguatamente il sistema in funzione di esse. Ad esempio, le caratteristiche che definiscono ed influenzano una buona esperienza d’uso per un’interfaccia che permetta di ascoltare la musica in mobilità come quella di un lettore mp3, potrebbero non essere adeguate anche per un software CAD studiato per progettare edifici ed usato da un architetto seduto nel silenzio del suo ufficio (Fig 6).

• Gli utenti devono essere coinvolti lungo tutto il processo di design e sviluppo: Lo scopo di questo principio consiste nell’assicurasi che gli Agile e

gli stakeholder (tutte le persone che hanno influenza su di un progetto) siano coinvolti dal team in tutte le fasi del processo. La loro partecipazione al design

deve assumere un ruolo attivo oltre che di consulto e valutazione, attraverso ad esempio sessioni di design partecipativo, un approccio alla progettazione che

coinvolge gli utenti in questa attività, al fine di garantire che un prodotto risponda ai loro bisogni reali e risulti usabile.

14

Fig.7 Esempio di Prototipo cartaceo

• Il design deve essere guidato e rifinito dalle valutazioni degli utenti:

Le attività di usability testing, sono uno dei più importanti strumenti a disposizione dello UX Designer e dell’intero team per validare, migliorare e

rimediare il prima possibile a problemi di usabilità presenti nel prodotto. Si stima che la scoperta e la risoluzione di questa tipologia di errori in fase di

progettazione ammonti ad un costo circa 10 volte inferiore rispetto alla risoluzione degli stessi problemi ad implementazione iniziata.

L’errore metodologico a cui spesso si va incontro, è quello di eseguire un singolo test, generalmente alla fine dello sviluppo quindi in una fase ormai

avanzata del processo. Il principio chiave, invece, sottolinea l’importanza della validazione dei design, anche nel loro stadio preliminare, attraverso l’utilizzo di

strumenti come prototipi di carta (Fig.7), o software di prototipazione veloce i quali non richiedono un ingente dispendio di tempo e risorse, ottenendo così

risultati con il minimo investimento. L’usabilità e la trovabilità, come emerso da alcuni studi statistici,

risultano così importanti che per ogni dollaro speso nel migliorarle in un sito commerciale, si stima un incremento di vendite nell’ordine di 50 – 100 dollari.

Lo stesso non vale per gli investimenti fatti per perfezionare il visual design o lo stile del sito.

15

Fig.8 Scomposizione della User Experience in livelli

• Il processo deve essere iterativo e incrementale: lo standard descrive il

principio senza alcuna ambiguità definendo come tipicamente, il design più appropriato per un sistema interattivo, non possa essere ottenuto senza

iterazione. Il prodotto non ha bisogno di esser migliorato solo dal punto di vista del codice, come spesso avviene, ma anche da quello della user experience

attraverso una serie di cicli di design e valutazione dove l’osservazione e l’analisi delle reazioni dell’utente consentiranno di procedere al redesign del

prodotto e ad un nuovo ciclo di iterazione. Il processo deve essere incrementale, ovvero deve aggiungere ad ogni ciclo nuove funzionalità ed

elementi da testare ed eventualmente rilasciare.

• Ogni aspetto del prodotto ha influenza sull’intera user experience e sul risultato finale: la figura 8 mostra come l’intera esperienza d’uso sia costruita

attorno a molti fattori, tra cui l’utilità, l’usabilità, la desiderabilità e la brand experience, percepiti dall’utente durante le interazioni con un prodotto. La

parziale o nel peggiore dei casi totale insoddisfazione di anche uno solo di questi livelli, potrebbe rendere il prodotto un fallimento (Garret, 2010).

16

• Il team di design deve essere multidiscplinare e cross-funzionale in modo

da assicurare la presenza di prospettive diverse sui problemi, sulle soluzioni e sul prodotto: Per molti team, la collaborazione è una attività che

avviene tra persone che compiono mansioni simili all’interno dell’azienda, mantenendo così una visione limitata non solo delle problematiche, ma anche

delle soluzioni, del prodotto e delle nuove strade da intraprendere. Creare gruppi di lavoro eterogenei dal punto di vista del background, al cui interno vi

sia un alto grado di collaborazione, risulta necessario per evitare che questo avvenga.

Conclusioni del capitolo:In questo capitolo, abbiamo visto il significato di User Experience, User Experience Design e dei principi su cui la progettazione user-centered si basa.

Non abbiamo volutamente trattato fin qui le metodologie per la definizione e per lo sviluppo di una esperienza utente che verranno descritte in parte nel capitolo 5

dove andremo a trattare come esse si possono intersecare ed inserire in un framework di project management come lo Scrum Agile.

17

18

Capitolo 3: Dal Waterfall lifecycle all’Agile

Il terzo capitolo della tesi introduce i passaggi principali del percorso evolutivo dei framework di project management nell’ambito della progettazione e dello

sviluppo del software dagli anni ‘70 ad oggi. Inoltre, tratta l’argomento della riqualifica della figura dell’utente all’interno di un processo di sviluppo,

avvenuta grazie alla progressiva integrazione della metodologia di progettazione user-centered all’interno di quest’ultimo, e di come questa metodologia, assieme

alle esigenze di un mercato in continua evoluzione, abbia in parte ispirato questi cambiamenti.

3.1.1 Il software e la nascita della metodologia WaterfallLa parola “Software”, definita come una serie di programmi ed istruzioni

eseguite da un computer per compiere delle operazioni, viene coniata nel 1957 dallo statistico statunitense John Wilder Tukey. E’ però solo nel decennio

successivo, precisamente nel 1970, che un framework di sviluppo e project management ben definito viene accostato all’ICT (Information and

Communication Technology). Fu infatti Winston Royce il primo a trattare l’argomento parlando di ciclo di vita a Cascata (Waterfall lifecycle) in uno dei

suoi articoli. Questa metodologia di sviluppo, descritta graficamente nella figura

9, si basa su una sequenza lineare di passaggi .

Fig.9 Rappresentazione grafica del modello di sviluppo Waterfall descritto da Royce

19

L’idea alla base del modello è che il team di sviluppo non possa passare alla fase successiva del processo prima che la fase in corso sia stata documentata, approvata e che quindi possa essere considerata conclusa. E’ per questo motivo che la metodologia presa in esame viene definita “a cascata”

3.1.2 Le fasi del modello a CascataIn questo paragrafo verranno trattati i 5 passaggi fondamentali della metodologia Waterfall, cercando di sottolineare le cause e le motivazioni che hanno portato in una prima fase ad un parziale adattamento dello User Centered Design ad essa, fino alla migrazione verso l’Agile di molte software house moderne. !! I passaggi caratterizzanti del framework sono:

• L’analisi e la definizione dei requisiti: Nel primo capitolo è stata discussa l’importanza di una buona pianificazione e

definizione degli obbiettivi durante la prima fase di gestione del progetto. Nel modello a cascata, questa attività di analisi risulta ancor più fondamentale per la

riuscita ed il successo del prodotto. Prima che lo User-Centered Design venisse applicato allo sviluppo del

software, questa fase si riduceva ad una esplorazione che in seguito ad un’analisi di fattibilità, portava a definire dei:

- requisiti funzionali: in altre parole, cosa il prodotto dovrebbe essere in grado di fare. Ad esempio distribuire bevande nel caso di un distributore automatico;

- requisiti non funzionali: ovvero, come il prodotto dovrebbe essere. Ad esempio, la capacità del distributore automatico preso sopra in esame di

resistere agli scassi; Con l’introduzione e l’integrazione nel framework della metodologia di

design centrata sull’utente, la fase di analisi evolve diventando più organica ed integrando nuove attività che facilitino uno sviluppo user-centered tra cui:

- La creazione di un team di sviluppo e progettazione che diventa Multidisciplinare;

- L’analisi degli stakeholders;- L’esecuzione di un’analisi competitiva detta anche di benchmarking per definire

lo stato dell’arte e i possibili concorrenti per la tipologia di applicazione che si andrà a sviluppare;

- L’esecuzione di interviste agli utenti;- Il Coinvolgimento di questi in focus-group

20

- Lo sviluppo di personas e scenari d’uso;

- La definizione di obbiettivi di business e dell’utente;- La definizione delle metriche di valutazione dell’usabilità e dell’accessibilità

che verranno utilizzate successivamente in fase di test per la valutazione del prodotto;

Nell’uso del framework a cascata, risulta importante cogliere tutti gli aspetti legati ai requisiti durante le prime due fasi del processo (Analisi e Design), in

quanto, una rivisitazione e modifica successiva all’inizio della fase di implementazione potrebbe risultare molto costosa.

• Il designIn origine, il documento prodotto nella fase d’analisi e definizione dei requisiti,

fungeva da input per la fase di design. Lo scopo di questa parte del processo, era quello di definire l’architettura di sistema ed era questa una mansione affidata

alla figura del software architect. L’output generato, aveva la struttura di una documentazione molto dettagliata, contenente un progetto statico, quindi non

modificabile, redatto per gli sviluppatori che avrebbero implementato e sviluppato il codice per l’applicativo. Come avvenne per la fase d’analisi, con

l’introduzione della metodologia user-centered, anche la fase di design subì degli aggiornamenti, aggiungendo attività come:

- La creazione di design concept validati dal team;- Lo sviluppo di diagrammi di flusso, mappe concettuali, e user journey che

simulano la navigazione dell’utente all’interno dell’applicativo, arricchiti con walkthrough;

- L’aggiunta di cicli di prototipazione veloce, spesso su carta, che portano

successivamente allo sviluppo di wireframes (Fig.10) a bassa/alta fedeltà su cui vengono effettuati dei test di usabilità che permettono al team di individuare

errori prima di passare alla fase d’implementazione;

I nuovi output della fase di design aggiungono alla documentazione standard descritta sopra anche delle Linee guida di Design e la definizione ad esempio di

Pattern d’interazione. Inoltre, essendo testati, si possono ritenere più sicuri dal punto di vista dell’usabilità rispetto a dei design su cui questo non avveniva.

21

Fig.10 Esempio di wireframe

• ImplementazioneUna volta terminata la fase di progettazione, il documento di design viene

consegnato agli sviluppatori che effettuano la traduzione in codice del suo contenuto. In passato, gli errori di usabilità che emergevano in questa parte del

processo di sviluppo, aggiungevano oneri molto pesanti ai costi di progetto, anche se questi raramente venivano individuati durante la fase di

implementazione a causa della parziale se non totale assenza dell’attività di usability testing al suo interno.

Con l’innesto nel framework Waterfall della metodologia di progettazione centrata sull’utente, si è ottenuto l’avvio di una stretta collaborazione tra designer

e sviluppatori aggiungendo nella fase implementativa:- L’esecuzione di una serie di valutazioni euristiche di usabilità ed accessibilità

condotte da esperti non solo sul prodotto finale, ma anche durante gli stadi intermedi di sviluppo del codice;

- L’esecuzione di test di usabilità anche questi effettuati su stralci di prodotto preliminare;

22

• Fase di Verifica

Fino all’introduzione delle pratiche di progettazione centrate sull’utente, questa fase del processo era dedicata al restauro ed al perfezionamento del codice, oltre

che alla verifica che tutti i requisiti definiti nelle fasi di analisi e design fossero stati rispettati. Solo in ultima istanza, questa parte del processo era dedicata ai

test di usabilità. Questo comportava una verifica dell’esperienza utente tardiva, che avveniva nel momento subito precedente il rilascio dell’applicativo, quando

oramai la risoluzione dei problemi di user experience sarebbe risultata difficile a causa dei costi in termini di denaro e tempo che questi aggiustamenti avrebbero

comportato. Con l’introduzione dello User-Centered Design, questa fase cessa di

essere netta. Le problematiche vengono spesso individuate e risolte molto prima della release del software grazie alla distribuzione dei test di usabilità lungo tutto

il processo di sviluppo.

• Fase di rilascio e mantenimento

In passato, questa fase, che cominciava con il primo rilascio del software e terminava alla sua dismissione, era dedicata alla risoluzione dei problemi

individuati nella fase di verifica precedentemente descritta e all’attività di bug-fixing, cioè di ricerca e sistemazione di problematiche minori dovute ad errori nel

codice. Se questi risultavano molto complessi e quindi costosi da sistemare, la loro risoluzione era procrastinata al rilascio successivo del software che poteva

avvenire anche dopo anni. Lo UCD, una volta introdotto, ha condotto il mondo del management alla

scoperta dell’importanza del coinvolgimento degli utenti anche in questa fase, attraverso ad esempio la somministrazione di interviste e questionari. La raccolta

di dati risulterà infatti utile all’inizio di una nuova iterazione per definire i bisogni vecchi o emergenti degli user. E’ inoltre nella fase di rilascio che viene

verificato il raggiungimento degli obbiettivi definiti durante la pianificazione iniziale, e che decretano in che misura un prodotto possa essere considerato

soddisfacente sia dal punto di vista degli stakeholder che da quello dell’utente finale.

3.1.3 L’evoluzione del framework WaterfallDal 1970 ai giorni odierni, la metodologia di sviluppo a cascata si è evoluta

notevolmente in seguito alle numerose critiche a cui essa è stata sottoposta a

23

Fig.11 Ciclo di vita a cascata modificato

partire dalla fine degli anni ’80, introducendo cicli di test ed iterazione continui

durante tutte le fasi di sviluppo (Fig.11).

Ciò nonostante, la spinta verso una metodologia di project management e

sviluppo più leggera, come vedremo nel prossimo paragrafo, deriva in parte dai mutamenti del mercato del software che fanno emergere la necessità di procedure

più agili ed incrementali, che mirino alla soddisfazione del cliente e degli utenti e non solo alla produzione del software.

Il modello a cascata resta comunque fondamentale per progetti che richiedano, ad esempio, il coinvolgimento di molte persone, dove la

conversazione faccia a faccia non è possibile e dove quindi una precisa documentazione si rende necessaria.

3.1.4 Le motivazioni che spingono alla nascita dell’Agile: L’evoluzione dei canali di distribuzione del software, la prima bolla Dot-com e la necessità di progettare esperienze d’uso per le persone

Tra gli anni ’70 e la diffusione di internet, avvenuta a fine anni ‘90, l’approccio al design che caratterizzò i progettisti del software fù molto simile a quello adottato

24

nella progettazione di oggetti fisici. Quando un designer si avvicina ad esempio

al design di un’automobile, è necessario che egli preveda e risolva i problemi prima dell’avvio della produzione, in quanto, allestire una catena di montaggio

ha dei costi elevati e la risoluzione di problematiche in fase di produzione e distribuzione risulterebbe un’operazione molto costosa che potrebbe decretare il

fallimento di un progetto. E’ qui possibile notare un’analogia con il modello Waterfall dove

l’ottimale definizione dei requisiti all’inizio del processo di sviluppo di un software, era un passo fondamentale per il successo del prodotto che andava

distribuito in tutto il mondo, attraverso supporti fisici costosi come il compact disc ed il floppy disc, costringendo così i designer ed i team di sviluppo ad

adeguare a questi vincoli il loro lavoro ed il loro approccio al progetto. Con la diffusione globale di internet, a partire dalla fine degli anni ’90, i

metodi di distribuzione del software sono radicalmente cambiati passando dal canale fisico al canale digitale. Un esempio sono gli app store come quelli di

Apple e Google, dove l’utente ha la possibilità di acquistare applicazioni tramite internet e di ricevere aggiornamenti continui direttamente sulla macchina dove

l’applicativo è installato. Questa evoluzione ha sortito tre effetti:

- Abbattendo i costi di distribuzione, attualmente i software possono godere di continue release, anche quotidiane, a costo zero, dando ai team di sviluppo la

possibilità di sperimentare che prima mancava.;- Ha innalzato il livello di concorrenza tra competitors obbligando le software

house a cicli di rilascio sempre più brevi;- Le possibilità di rilasciare continui aggiornamenti ha provocato

un’accelerazione nel miglioramento dei software innalzando le aspettative degli utenti;

All’evoluzione dei canali di distribuzione, nel 2000 si aggiunse anche lo scoppio

della prima bolla speculativa dot-com che ha causato dei tagli pesanti ai budget dei progetti di sviluppo software, che difficilmente potevano risultare

nuovamente compatibili con una metodologia dai costi e rischi elevati come quella Waterfall.

Inoltre, in un contesto così dinamico, una metodologia di sviluppo pesante come quella a cascata, non risulterebbe adeguata a causa della lunghezza del suo

25

ciclo di rilascio e della mancanza di flessibilità nella definizione dei requisiti, che

la renderebbero poco reattiva alle aspettative ed esigenze in continua crescita e mutazione del mercato e degli utenti.

3.2 La nascita delle metodologie agiliUn framework di project management e sviluppo si definisce Agile quando basato su di un processo iterativo ed incrementale, dove le soluzioni ed i requisiti

nascono ed evolvono grazie alla collaborazione, durante tutta la durata del processo tra, team auto-organizzati, multidisciplinari, cross-funzionali e

committenti. Questa metodologia promuove pratiche di pianificazione adattiva e di sviluppo in continua evoluzione, in cui il rilascio di software funzionante deve

avvenire in modo continuo, rapido e flessibile, per permettere al team di rispondere efficacemente ai cambiamenti richiesti dal mercato, dagli utenti e dai

committenti. Il termine Agile, viene coniato nel 2001, a seguito di un incontro tra un

gruppo di 17 professionisti di spicco del mondo del software che si radunò per discutere la necessità di un’evoluzione del project management IT verso metodi

di sviluppo leggeri, in anni di cambiamento veloce e crisi speculativa come quelli attorno al 2000.

Il risultato dell’incontro, fù la pubblicazione di un documento sottoscritto da tutti i partecipanti e conosciuto con il nome di Agile Manifesto, all’interno del

quale veniva descritto l’approccio alla progettazione software Agile. Il manifesto recita:

Stiamo scoprendo modi migliori di creare software,sviluppandolo e aiutando gli altri a fare lo stesso.

Grazie a questa attività siamo arrivati a considerare importanti:

Gli individui e le interazioni più che i processi e gli strumentiIl software funzionante più che la documentazione esaustiva

La collaborazione col cliente più che la negoziazione dei contrattiRispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra,consideriamo più importanti le voci a sinistra.

(Beck et al. 2001)

26

3.2.1 I dodici principi su cui l’Agile si basaIl framework Agile è basato su 12 ulteriori principi fondamentali:1. La massima priorità è data alla soddisfazione del cliente/utente raggiungibile

tramite il rilascio di software di valore, fin da subito e in maniera continua;2. I cambi di requisiti sono ben accettati anche a stadi avanzati dello sviluppo e

vengono sfruttati a favore del vantaggio competitivo del cliente;3. Le release di parte del software funzionante devono avvenire frequentemente,

con cadenza variabile tra un paio di settimane e un paio di mesi, con preferenza per i periodi brevi;

4. Committenti e sviluppatori devono lavorare insieme e quotidianamente per tutta la durata del progetto;

5. I progetti devono esser fondati su Team di sviluppo composti da individui motivati, che devono essere supportati nei loro bisogni e nelle loro esigenze e

sulle cui capacità, l’azienda deve porre fiducia;6. La documentazione è importante, ma la conversazione faccia a faccia è il

modo più efficiente ed efficace per comunicare all’interno e all’esterno del team;

7. Il software funzionante è il principale metro di misura di progresso;8. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli

sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante in quanto il processo non termina con il

rilascio del software;9. La continua attenzione all’eccellenza tecnica e alla buona progettazione,

esaltano l’agilità. In alcuni cicli iterativi infatti è più importante sviluppare velocemente delle nuove idee, in modo da avere un feedback tempestivo sulla

loro efficacia ed utilità. Una volta ottenuti i feedback ed aggiornato il piano progettuale, è però importante tornare ad un lavoro di pulizia, sia a livello

progettuale che a livello di implementazione;10. La semplicità ovvero l'arte di massimizzare la quantità di lavoro non svolto

risulta è essenziale;11. Le architetture, i requisiti e la progettazione migliori emergono da team che si

auto-organizzano;12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché

regola e adatta il proprio comportamento e piano di sviluppo di conseguenza.(Beck et al. 2001)

27

Fig.12 Schematizzazione del modello di sviluppo Agile

3.2.2 Il processo di sviluppo Agile ed alcune differenze rispetto al modello a Cascata

Esistono vari metodi di sviluppo che rientrano nella definizione di Agile e la maggior parte di essi promuove l’adattabilità del processo durante il ciclo di vita del progetto. Essendo quindi un framework adattivo e non sequenziale come nel caso della metodologia Waterfall, risulta difficile da standardizzare.

Ci sono comunque delle caratteristiche e delle fasi comuni a tutti i processi di sviluppo basati su metodologie Agile che possiamo vedere nel grafico in figura 12.

! Innanzitutto i passi “monolitici” del modello a cascata, vengono scomposti in piccoli task incrementali e distribuiti all’interno degli sprint, finestre temporali della durata compresa tra le 2 settimane e i 2 mesi.

Ogni iterazione, corrispondente ad uno sprint, comprende fasi di analisi e ricerca, design, sviluppo e test, al termine del quale una parte di software funzionante deve essere mostrata al cliente per raccogliere feedback ed per un’eventuale approvazione e rilascio. L’idea alla base del pensiero Agile è quella di arrivare nel minor tempo possibile al rilascio di un M.V.P. (Minimum Viable Product), una implementazione di base dell’applicativo, ed iterativamente renderla sempre più completa e migliore, rispondendo ai feedback del cliente e del mercato. L’emergere continuo di nuovi requisiti, permette quindi di abbassare il rischio di fallimento del progetto, adattandolo alle necessità e ai bisogni del committente dopo ogni iterazione, e rilasciando incrementi di valore continui e non solo alla fine dello sviluppo come avveniva nel modello Waterfall.

28

Metodologia Waterfall Metodologia Agile

Metodologia Pesante Leggera

Tipo di processo Sequenziale o semi-sequenziale Adattivo

Processo reiterativo Generalmente no Si

Durata di un ciclo del processo Anche anni tra le 2 settimane (a volte

meno) e i 2 mesi

Value delivery Alla fine del processo Lungo tutto il processo

Gestione del rischio Bassa Alta

Accettazione nuovi requisiti o modifiche ai

vecchi

Solo nelle prime due fasi del progetto (Analisi e

Design)Lungo tutto il processo

Adatto a teamDi grandi dimensioni (più di 20 persone), anche se

distribuitiDi piccole dimensioni,

meglio se non distribuiti

Integrazione con le pratiche di

progettazione User-Centered

Si, ma con numerose limitazioni Si

L’applicazione della metodologia Agile, sembra risultare vincente nel caso di

progetti in cui sono coinvolti team di dimensioni ridotte, mentre la pianificazione tipica del metodo tradizionale diventa essenziale in presenza di team di grandi

dimensioni, dove la comunicazione faccia a faccia risulta difficoltosa e dove la documentazione è quindi fondamentale.

Per concludere, molte delle caratteristiche dei framework agili, rendono più compatibile l’integrazione al loro interno di pratiche user-centered, che nel ciclo

a cascata trovavano poco spazio per diversi motivi (fig.13) come:

- Il limitato numero di reiterazioni;

- L’impossibilità di modificare i requisiti a partire dalla fase implementativa;

- La limitata e tardiva importanza data ai test di usabilità;

Fig.13 Tabella riassuntiva delle differenze tra metodologia Waterfall e modello Agile

29

30

Capitolo 4: Lo Scrum, uno dei framework Agile

Come sottolineato nel capitolo precedente, il termine Agile, riunisce una serie di framework di sviluppo fondati sui principi dell’omonimo manifesto. Lo Scrum

Agile, o più semplicemente Scrum, appartiene a questa categoria e ne è l’esempio più diffuso. Nel capitolo 4, la tesi lo descriverà in maniera approfondita, per dare

al lettore una visione più precisa di almeno una delle metodologie Agile. Sarà però solo nel capitolo 5 che vedremo, all’interno di un case study, come un

processo basato sullo Scrum possa essere accostato e supportato dalle più moderne pratiche di User Experience Design.

4.1 Introduzione allo Scrum Agile

Lo Scrum Agile nasce all’inizio degli anni ’90, ancor prima della stesura dell’Agile Manifesto e viene definito da Ken Schwaber e Jeff Sutherland, autori

della Scrum Guide e due dei 17 fondatori del movimento Agile, come “un framework di processo [...] per gestire lo sviluppo di prodotti complessi. Scrum

non è un processo o una tecnica per costruire prodotti ma piuttosto è un framework all’interno del quale è possibile utilizzare vari processi e

tecniche” (Schwaber, Sutherland 2011)

Il team di lavoro che si appresta ad utilizzare tale strumento deve

possedere caratteristiche di multidisciplinarità e cross-funzionalità, ovvero, essere composto da persone con diversi background di conoscenza che

lavoreranno in sinergia in ogni fase del processo per il raggiungimento dello stesso obbiettivo. Un Project Manager, non andrà ad interferire nel loro operato

finchè il team dimostrerà di utilizzare le conoscenze e le capacità dei membri per prendere decisioni collettive. Lo Scrum, essendo anch’esso, come tutti i metodi

agili, un framework reiterativo, da al committente la flessibilità e la libertà di cambiare ed aggiornare i requisiti lungo tutto il processo, garantendo comunque

al team la certezza necessaria per rilasciare un potenziale incremento di software funzionante ad ogni ciclo. E’ questa una delle caratteristiche chiave che lo

rendono uno strumento potente (VII, 2012).

31

1. Trasparenza

2.Ispezione(controllo continuo durante l’avanzamento del

progetto)

3.Adattamento(Cambio del prodotto o del processo in base alle esigenze e ai bisogno

emersi nella fase di controllo)

Fig.14 Schema che riassume i 3 principi base dello Scrum Agile

4.2 La teoria su cui si basa lo Scrum Agile

Lo Scrum posa le sue basi sulla Teoria dei controlli empirici del processo o empirismo. Quest’ultima afferma che la conoscenza discenda dall’esperienza e

che le decisioni si basano su ciò che si conosce. Lo Scrum utilizza quindi un metodo iterativo ed un approccio incrementale per ottimizzare la prevedibilità ed

il controllo del rischio (VII, 2012).

! La figura 14 riassume i 3 concetti chiave su cui il framework in questione

si basa:

- La trasparenza: Questa garantisce che gli aspetti del processo che influenzano

il risultato risultino chiari e visibili a tutti, facilitando così la costruzione di comune conoscenza e fiducia all’interno del team;

- L’ispezione: I vari aspetti del processo, devono esser ispezionati con una frequenza tale da permettere l’individuazione al suo interno di variazioni

inaccettabili;

- L’Adattamento: Se durante l’ispezione del processo, vengono rilevati uno o

più aspetti al di fuori dei limiti accettabili al fine di garantire l’approvazione e il rilascio del prodotto finale, il processo deve subire un adattamento nel minor

tempo possibile in modo che le problematiche derivanti dal superamento di tali confini vengano minimizzate;

32

Fig.15 Schema della struttura del framework di tipo Scrum

4.3 Lo scheletro che sorregge lo Scrum e il suo processo

In questo paragrafo, verranno descritti i passaggi e le componenti chiave della

struttura del framework (Fig. 15):

- Il Product Backlog: si compone di una lista che racchiude tutte le funzionalità, elencate in ordine di priorità, che il committente desidera per il software che si

andrà a sviluppare. Ciascuna feature deve esser accompagnata dalla descrizione dei suoi criteri di accettazione;

- Lo Sprint (rappresentato nella figura 16 dal cerchio più grande): è considerato il

cuore dello Scrum ed è una iterazione della durata di un mese o meno, di lunghezza coerente per tutta la durata del progetto. Ad ogni iterazione,

all’interno di esso vengono eseguiti i processi di analisi, design, sviluppo e test descritti nel capitolo precedente trattando la metodologia Agile (VII, 2012);

- Il Daily Sprint: Sopra il cerchio dello Sprint, viene posto sempre nella figura

16il Daily sprint. Esso rappresenta come i membri del team si incontrino in uno Scrum Meeting a cadenza giornaliera per eseguire il processo di ispezione ed

adattamento dei loro piani di lavoro per quel giorno (VII, 2012).

- Lo Sprint Backlog: è la lista di compiti necessari a trasformare una parte di product backlog relativa ad uno sprint in un incremento di prodotto pronto per

33

una potenziale release. Al termine di ogni sprint, questa viene consegnata al committente, al fine di consentirne la valutazione ed eventualmente il suo rilascio (VII, 2012).

Dopo la consegna, il team si riunisce in altri due momenti importanti di ispezione ed adattamento:- Lo Sprint Review Meeting dove vengono discussi i progressi verso l’obbiettivo

di rilascio conseguiti durante lo sprint;- Lo Sprint Retrospective Meeting dove viene esaminato (ispezione) lo sprint

appena terminato in modo trasparente, e vengono decise le modifiche (adattamento) che potranno rendere il prossimo ciclo di iterazione più produttivo, appagante ed in qualche modo divertente;

4.4 I ruoli nello Scrum

Il framework riduce a tre le tipologie di ruolo al suo interno, garantendo semplicità anche sotto questo punto di vista. Esse sono:

- Lo Scrum Master, ovvero il responsabile dell’adesione del team ai valori, alle pratiche e alle regole dello Scrum. Esso guida il gruppo di lavoro verso una maggiore produttività e qualità dei prodotti sviluppati eliminando nel mentre gli ostacoli ad uno sviluppo ottimale;

- Il Product Owner ha la responsabilità esclusiva di gestire il Product Backlog rendendo esplicita a tutti la prioritarizzazione dei task (user stories) al suo interno. Inoltre deve essere garante del valore del lavoro svolto dal team.

- Lo Scrum Team ha come obbiettivo la trasformazione del product backlog in

incrementi di funzionalità potenzialmente rilasciabili al termine di ogni sprint. Il team deve possedere tutte le competenze necessarie per raggiungere lo scopo. Oltre ad essere multidisciplinare, esso deve essere cross-funzionale. Non ci possono esser titoli in uno Scrum team e non sono ammesse eccezioni. Non sono adatti a farne parte ad esempio designer che si rifiutino di scrivere almeno in piccola parte codice. Tutti devono esser coinvolti anche quando si rende necessario uno sforzo per l’apprendimento di nuove nozioni. In aggiunta, il team deve essere auto-organizzato. Nemmeno lo Scrum Master detiene il potere di istruire il team riguardo la trasformazione di un elemento del

34

product backlog in un incremento di funzionalità. Ogni membro del gruppo deve portare la sua conoscenza ed esperienza in tutti i problemi incontrati e la sinergia che ne risulta migliorerà l’efficacia e l’efficienza complessiva dell’intero team. La dimensione considerata ottimale per il gruppo di lavoro varia tra le 5 e le 9 persone. Se il team risulta composto da meno di 5 elementi, l’interazione diminuisce, abbassando così il livello di produttività. In più si potrebbero incontrare problemi dovuti alla parziale mancanza di competenze. Al contrario, la presenza di più di 9 elementi, porta il team ad avere problemi nella sua gestione. Ad esempio i membri del gruppo di lavoro potrebbero generare troppa complessità non gestibile con un processo empirico come quello Scrum. Il product owner e lo scrum master non sono generalmente inclusi nel team salvo che non siano anch’essi sviluppatori, designer o altre figure professionali coinvolte nel processo produttivo.

4.5 User Stories: La più piccola unità di lavoro all’interno del product backlog espressa come bisogno per l’utente finaleIn questo paragrafo, andremo a trattare uno degli artefatti del framework sotto esame, che risulterà necessario per una comprensione migliore degli argomenti trattati nel capitolo 5, data la sua correlazione con lo User Experience Design. La user story è uno degli artefatti più importanti del framework Scrum. Essa descrive un requisito dal punto di vista dell’utente finale. L’idea alla base del suo utilizzo è che consegnare valore all’utente avrà come effetto un più alto ritorno negli investimenti (R.O.I. acronimo di Return On Investment) e la produzione di un prodotto migliore (VII, 2012)

4.5.1 La struttura di una user storyUna user story segue generalmente la seguente struttura, definita delle 3 “r”:

Come <ruolo dell’utente> voglio <requisito> così che <ragione/ROI>

La definizione del ruolo dell’utente, aiuta a concentrare il team sul tipo di user che la funzionalità, descritta nella storia, andrà a servire. Il requisito, descrive ciò che l’utente desidererebbe fare e la ragione/ROI riassume il valore che il requisito avrà per l’utente e per il business. L’uso delle user stories così

35

strutturate aiuta il Product Owner ad eliminare o non aggiungere funzionalità

poco utili al prodotto finale (VII, 2012).

Un esempio di user story per un lettore mp3 potrebbe essere:

Come teenager voglio vedere il titolo della canzone in riproduzione così da essere al corrente di quale brano sto ascoltando in quel momento.

4.5.2 I criteri di accettazione di una user storyOgni user story deve essere accompagnata da una serie di criteri di accettazione che

definiscono quando essa possa essere considerata conclusa dal punto di vista del Product Owner, in modo da permettere al team di passare alla storia successiva presente nel product backlog. Questi criteri dovrebbero esser tradotti in dei test che un utente o un QA (Quality Assurance tester) possono usare per verificare la qualità delle funzionalità sviluppate

prima che queste vengano rilasciate. Solitamente i criteri di accettazione vengono prodotti utilizzando il seguente template:

Un<ruolo dell’utente> dovrebbe <vedere/essere in grado di>:

- <criterio accettazione 1>; - <criterio accettazione 2>;etc.---------------------------------Casi limite:

- <criterio accettazione caso limite 1>- <criterio accettazione caso limite 2>etc.---------------------------------

La lista dei criteri di accettazione non deve essere lunga e complessa, ma solo contenere una serie di criteri necessari e sufficienti a testare una feature. I casi

limite spesso vengono omessi nella compilazione del template, ma possono risultare utili nell’individuazione di problematiche che potrebbero sorgere in

futuro

36

Un esempio di criteri di accettazione nel caso di un lettore mp3 potrebbe essere:

Un Teenager dovrebbe vedere il titolo della canzone in riproduzione:-In modo che questo sia leggibile anche alla distanza di 30 cm dallo schermo;-In qualsiasi condizione di luce;

Caso limite:- Se la riproduzione della canzone non è possibile per un eventuale errore, questo errore deve prendere il posto del titolo nello schermo

37

38

Capitolo 5: Come lo User Experience Design può integrarsi con un framework Agile: la Lean UX

5.1 Lo User Experience Design: da parte del processo di sviluppo fino a divenire il processo stessoNella prefazione del libro Lean UX, Eric Ries dà una visione molto chiara dell’organizzazione delle company moderne, descrivendole come una serie di reparti aziendali stagni, detti silos, che se analizzati singolarmente, sembrano godere di una organizzazione efficiente grazie all’applicazione al loro interno di pratiche iterative e l’uso di un approccio al problem solving centrato sull’utente. Studiando però i silos nella loro unione e completezza sia le pratiche user-centered che quelle agili sembrano svanire (Ries, 2012). Sempre secondo quest’ultimo:”Stiamo ancora costruendo organizzazioni lineari in un mondo che rivendica il cambiamento costante” (Ries, 2012). La user experience in esempi come questi non può che rimanere parte di un processo, mentre quest’ultima, secondo Gothelf deve evolvere e divenire il processo stesso (Gothel, 2013).

5.1.1 La nascita della Lean UX e le sue fondamentaIl termine Lean UX dà il nome al più moderno approccio allo UX design. Questo, viene definito dal suo fondatore come “la pratica di portare alla luce la vera

natura di un prodotto più velocemente, in un modo collaborativo e cross-funzionale che riduca l’enfasi sulla minuziosa documentazione spostando

l’attenzione sulla costruzione di una comune comprensione dell’attuale esperienza d’uso del prodotto che si sta progettando” (Gothelf, 2013). Essa nasce prendendo ispirazione dal Design Thinking, dalla metodologia di sviluppo Agile e dal movimento Lean Startup, su cui posa le sue fondamenta.

La Lean UX e il Design Thinking

Il design thinking, viene descritto da Tim Brown, CEO della storica design firm IDEO, come “innovazione mossa da... l’osservazione diretta di cosa le persone

vogliono e di cui hanno bisogno nelle loro vite e cosa a loro piace o non piace del modo in cui particolari prodotti sono costruiti, inscatolati, pubblicizzati,

venduti. [...] E’ una disciplina che usa la sensibilità del designer e i suoi metodi

39

per far corrispondere i bisogni delle persone con ciò che è tecnologicamente

fattibile e con ciò che una strategia di business sostenibile può convertire in valore per il cliente e in opportunità di mercato” (Brown, 2009).

Dal punto di vista della Lean UX il design thinking diventa fondamentale, in quanto sottolinea la possibilità di usare metodi di design per esplorare nuovi

aspetti di business. Incoraggia quindi i designer ad uscire dal loro perimetro di competenza e allo stesso tempo, i nondesigner ad utilizzare le pratiche di design

nel risolvere i problemi che quotidianamente incontrano nel loro dominio di expertise. In altre parole, spinge il gruppo di lavoro ad aumentare il livello di

collaborazione al suo interno, senza fare alcuna distinzione di ruolo o disciplina di competenza.

La Lean UX e la metodologia Agile

I 4 principi fondamentali dell’Agile elencati nel suo Manifesto e già visti nel capitolo 3, vengono applicati anche nella Lean UX che li fa propri con opportune

modifiche dovute al differente dominio di utilizzo a cui vengono applicati:

- Individui e interazioni sopra processi e strumenti: L’intero team va coinvolto nel processo di generazione delle idee, all’interno del quale le queste

vanno scambiate liberamente e frequentemente. La conversazione continua tra colleghi diventa fondamentale;

- Software funzionante sopra documentazione comprensibile: ogni problema di business può essere risolto in molte modalità. La sfida consiste nel capire e

nell’implementare la soluzione più sostenibile nel minor tempo possibile al fine di testarla ed adattarla alle esigenze di mercato;

- La collaborazione col cliente più che la negoziazione dei contratti: La collaborazione deve essere promossa dentro il team di lavoro e tra questo e i

clienti per costruire una comune comprensione del problem space accellerando così la fase di proposta delle soluzioni e creando inoltre consenso dietro ogni

decisione. Il risultato saranno iterazioni più rapide ed importanti tagli alla quantità di documentazione prodotta;

- Rispondere al cambiamento più che seguire un piano: La Lean UX, assume che il primo design sarà sicuramente errato e che lo scopo delle iterazioni è

quello di individuare nel minor tempo possibile gli errori in esso contenuti, per

40

permettere la loro correzione, muovendo così il prodotto verso la soluzione

migliore (Gothelf, 2013).

La Lean UX e il metodo Lean StartupIl Lean startup method, descritto per la prima volta da Eric Ries, imprenditore

seriale e fondatore del movimento Lean Startup, è basato su un ciclo di sviluppo iterativo diviso in tre fasi:

- Build (costruire): la fase di costruzione è caratterizzata dall’implementazione

nel minor tempo possibile di un M.V.P (Minimum Viable Product già visto nel capitolo 3) al fine di testare delle assunzioni di business;

- Measure (misurare): una volta ultimato, l’M.V.P deve essere introdotto nel mercato, ed entrare a stretto contatto con gli utenti;

- Learning (imparare): ricevendo feedback dagli user, l’M.V.P consentirà al team di capire quali sono le assunzioni corrette e quali invece da rivedere e da

testare nuovamente in una iterazione successiva con un nuovo prototipo; (Ries 2011)

Allo stesso modo, nella Lean UX, ogni design è considerato una possibile

soluzione ad un problema di business ed una ipotesi, che deve essere testata e validata in modo efficiente e continuo raccogliendo i feedback dei clienti e degli

utenti (Gothelf, 2013).

5.1.2 I principi della Lean UXNel paragrafo, verranno trattati i principi che traggono ispirazione in parte dalle 3

discipline descritte in precedenza e su cui la Lean UX si basa. Essi sono:

1. Il Team deve essere Cross-funzionale: i componenti del team devono provenire da diversi background disciplinari. Ingegneri del software, product

manager, interaction & visual designer, esperti di marketing etc, devono essere coinvolti nel progetto ed il livello di collaborazione tra le discipline deve

risultare alto e continuativo in modo da far collassare le barriere tra i diversi reparti aziendali. Questo principio è molto simile a quello visto in precedenza

nella metodologia Agile e in particolare nello Scrum;

41

2. Il team deve essere piccolo, dedicato, ed i membri devono lavorare a

stretto contatto: Il gruppo di lavoro va mantenuto di dimensioni ridotte, e deve essere impegnato in un solo progetto alla volta. Inoltre, i membri facenti

parte di questo, devono condividere la stessa location. Queste tre caratteristiche del Lean Team sono fondamentali per assicurare comunicazione,

concentrazione e cameratismo, ovvero l’instaurazione tra i colleghi di un rapporto sano;

3. Sono considerati successo i risultati e non gli output: La differenza tra

questi è molto sottile. Diversamente dagli output, nonchè funzionalità e servizi, i risultati sono gli scopi di business che gli output cercano di

raggiungere. La Lean UX, a tal proposito, misura i successi in termini di risultati di business;

4. I team devono essere Problem-focused: come lo Scrum affronta una user

story alla volta, allo stesso modo, il Lean team cerca di trovare risposta a un problema di business;

5. Rimuovere le cose inutili: Come visto nello Scrum Agile dove lo Scrum

Master aveva il compito di rimuovere tutti gli impedimenti e le operazioni inutili durante il processo, allo stesso modo, nella Lean UX dovrà essere

rimosso tutto ciò che non porti al raggiungimento dello scopo di business al fine di preservare le risorse limitate del team;

6. Creare solo i design necessari: Per design necessario, si intende il design che

permetta al team di progredire verso un risultato. Evitare design non necessari rende il team più efficiente;

7. Il processo deve essere una continua scoperta: ciò deve avvenire

coinvolgendo l’utente lungo tutte le fasi di design e sviluppo, attraverso la pianificazioni di attività regolari come meeting, usability test e release. Lo

scopo del processo deve essere quello di capire come e perchè l’utente usa il prodotto che si sta sviluppando. La ricerca deve essere un’attività che

coinvolge tutto il team, e non solo lo UX Designer come in passato, creando

42

così empatia diffusa nel gruppo verso l’utente e riducendo inoltre la quantità di documentazione necessaria;

8. Approccio di tipo GOOB, un nuovo concetto di centralità dell’utente: GOOB è un acronimo coniato da Steve Blank, noto imprenditore e professore della Stanford University, che sta per “Getting out of the building”, in italiano “Uscite dagli edifici”. Secondo i sostenitori del GOOB, le meeting room non sono i luoghi ideali per comprendere i bisogni degli utenti che vivono solo nel mondo reale. Secondo Blank, sono necessarie attività di ricerca sugli utenti nei loro ambienti di vita quotidiani, testando le idee prima di investire troppe risorse su di esse. Il successo di un prodotto non deve essere visto come derivante dalle decisioni del team, ma da quelle dello user ;

9. La comprensione deve essere condivisa: questa deve divenire conoscenza comune a tutti i membri del team del mercato, del prodotto e degli utenti che si andranno a servire, costruita lungo tutto il processo. Viene considerata la moneta della Lean UX;

10. Il team prima degli individui: secondo Gothelf, quelle che lui definisce “Rockstars, gurus, Ninjia ed altri esperti d’elite” (Gothelf, 2013) minano la coesione del team e rendono difficile la collaborazione, causando la rovina dell’ambiente e dell’atmosfera di lavoro necessari per creare comprensione e conoscenza condivisa;

11. Il lavoro deve essere esteriorizzato: questo significa sottoporre i design, anche se in fase preliminare, al giudizio dei membri del team, dei colleghi, e degli utenti attraverso l’uso di strumenti anche basilari come lavagne e post-it avendo così accesso a feedback immediati e creando inoltre un flusso informativo costante all’interno del gruppo di lavoro;

12. Costruire piuttosto che condurre lunghe analisi: la Lean UX considera più importante spendere del tempo nel costruire un’idea e validarla piuttosto che condurre lunghe sessioni di analisi senza possibilità di ricevere feedback dagli utenti reali;

43

Fig.16 Grafico Riassuntivo del Processo di LEAN UX

13. Imparare piuttosto che crescere: la Lean UX pone l’accento sul conoscere

per poi crescere. Scalare un’idea senza prima averla testata, come avviene nel modello Waterfall, risulterebbe troppo rischioso;

14. Il team deve essere libero di fallire: deve cioè possedere la libertà di testare numerose idee prima di trovare la soluzione ottimale ad un problema di

business con la consapevolezza che la maggior parte di queste si riveleranno, almeno inizialmente, errate. Il permesso di fallire, infonde una cultura alla

sperimentazione che si rende necessaria per il raggiungimento di migliori risultati;

15. Usare meno documentazione: Il processo di design, grazie alle applicazioni delle pratiche di Lean UX, non deve più risiedere nella documentazione ed il

focus della progettazione deve concentrarsi sul raggiungimento di risultati misurabili.

5.2 Il processo di Lean UX:Dopo aver trattato i principi e le fondamenta su cui si basa la Lean UX, verrà descritto in questo paragrafo il processo necessario per implementarla.

Siamo nuovamente di fronte ad un ciclo iterativo come illustrato nella figura qui sotto (Fig.16) composto da 4 fasi non sempre sequenziali.

5.2.1 Fase 1: La dichiarazione di assunzioniIn passato, lo scopo del lavoro del team era quello di consegnare un prodotto. Con la Lean UX, c’è un radicale cambiamento, che muove il gruppo di lavoro

verso il raggiungimento di risultati partendo da ipotesi, che vengono costruite, testate e misurate, e quindi avallate o modificate in un nuovo ciclo.

La dichiarazione di ipotesi è il punto d’inizio di ogni progetto oltre che un modo per descrivere delle assunzioni in una forma testabile.

44

Generalmente nella Lean UX una ipotesi segue la seguente struttura:

1) Assunzioni: una dichiarazione ad alto livello di granularità di ciò che si ritiene essere vero;

2) Ipotesi: una descrizione più dettagliata rispetto alle precedenti assunzioni, contenente informazioni ad esempio sul mercato di riferimento del prodotto;

3) Risultati attesi: una lista dei segnali attesi dal mercato e dagli utenti necessari per validare o invalidare le assunzioni in fase di test;

4) Personas: una modellazione delle persone che il prodotto andrà a servire;5) Funzionalità: come il prodotto guiderà il team ai risultati a cui si aspira;

La dichiarazione di assunzioni avviene all’ìnizio di ogni progetto, anche

in contesti diversi dalla Lean UX, ma spesso, in questi casi, vengono trattate come fatti certi piuttosto che come ipotesi.

Dichiararle nel modo precedentemente descritto e discuterle fin da subito con il team in forma esplicita, diventa fondamentale per creare una base di

conoscenza iniziale comune a tutto il gruppo di lavoro, dando voce anche ai non designer e ponendo in evidenza le idee comuni, le divergenze d’opinione, e le

possibili soluzioni. In secondo luogo, la dichiarazione di assunzioni aiuta ad identificare i

possibili rischi. Questo permette quindi di prioritizzare ogni ipotesi e di andare a lavorare testando in prima istanza le assunzioni più rischiose in modo da mitigare

fin da subito l’insorgere futuro di possibili problematiche.

5.2.2 Fase 2 e 3: Creare un Minimum Viable Product e sperimentareL’implementazione in tempi brevi di un prototipo il più semplice possibile, ha lo

scopo di aiutare ad individuare le assunzioni su cui si deve continuare ad investigare ed iterare, minimizzando allo stesso tempo il lavoro speso su idee non

provate ed eliminando le ipotesi errate. Inoltre, consegnare fin da subito valore al mercato attraverso un prodotto o una funzionalità permette già ai primi stadi del

progetto di innescare un processo di apprendimento a cui il team è soggetto. L’ M.V.P viene usato per dare risposta a domande come:

- C’è un bisogno dell’utente a cui il team sta rispondendo attraverso il prodotto?- C’è un valore nella soluzione che viene proposta?

- La soluzione o funzionalità è usabile dallo user?

45

L’ M.V.P può essere implementato in vari modi, a seconda di chi lo userà,

di cosa si spera di imparare da esso e dalla quantità di tempo disponibile per il suo sviluppo. Al variare di queste tre variabili il team verterà verso un prototipo

ad alta piuttosto che a bassa fedeltà. Per concludere, in alcune occasioni, è utile creare un prototipo dell’M.V.P stesso per testarlo su una base d’utenza ristretta

prima del suo rilascio finale all’intera comunità (Gothelf, 2013).

5.2.3 Fase 4: Feedback e ricercaE’ questa la fase in cui l’M.V.P. sviluppato in precedenza viene testato. Fino a

questo momento, il lavoro del team si è basato su assunzioni che ora hanno la possibilità di essere sottoposte alla validazione da parte degli utenti finali.

La Lean UX propone il coinvolgimento dell’intero gruppo di lavoro anche nell’attività di ricerca, che spesso viene invece affidata a team specializzati

esterni e di conseguenza eseguita di rado. Più approfonditamente, secondo la metodologia in questione, questa

attività deve essere:- Continuativa, ovvero deve entrare a far parte di ogni sprint, ed avere cadenza

regolare in modo da testare ogni assunzione all’interno di una finestra temporale ridotta, sollevando, così facendo, il team dal timore di prendere

decisioni o di assumere ipotesi sbagliate;- Collaborativa: non deve essere cioè esternalizzata o affidata solo agli UX

Designer, in modo da perseguire così lo scopo della creazione di conoscenza condivisa all’interno del gruppo anche durante quest’ultima fase;

Una volta raccolti i dati, comincia una lunga analisi che molto spesso viene affidata a specialisti, a cui viene chiesto di distillare e sintetizzare le

scoperte a cui l’attività di ricerca eseguita dal team è giunta. L’approccio Lean UX sostiene anche in questo caso l’urgenza di affidare tale compito al gruppo di

lavoro nella sua interezza, e senza distinzione di ruoli. Il team può così contare su una visione più ampia dei risultati e delle intuizioni ottenute, se comparata con

quella univoca offerta da uno specialista o da un team esterno.

5.3 Caso Studio: L’integrazione possibile tra UX Design e Scrum AgileDurante l’esperienza di tirocinio svolta tra il settembre 2012 e il febbraio del

2013 in Future Workshop, una startup inglese con base a Londra, ho avuto modo di partecipare ad un progetto di prototipazione e creazione di un M.V.P. della

46

durata di 3 settimane, entrando per la prima volta a contatto con un framework di

project management: lo Scrum Agile. Il concetto di Lean UX ed il libro che lo divulgava non erano ancora stati pubblicati, ma dopo la lettura di quest’ultimo,

ho realizzato come in parte alcune pratiche di integrazione tra Agile e user experience design descritte da Gothelf venissero già utilizzate “inconsciamente”

all’interno dell’azienda. In questo paragrafo passerò in rassegna alcune delle tecniche e

best-practice descritte nel libro Lean UX, portando però ad esempio il case study della mia esperienza di tirocinio, sottolineando le fasi e i metodi utilizzati,

limitandomi però a descrivere solamente il processo di design che ha portato allo sviluppo di un menu con caratteristiche non propriamente convenzionali

all’interno della app.

5.3.1 Una breve introduzione al prodottoLa modellazione 3D e le tecnologie associate, come stampanti 3D, realtà

aumentata etc, sono uno dei settori più interessanti ed in continua crescita dell’economia attuale.

Vertix, la app per iPad a cui ho contribuito con il mio lavoro, è stata progettata per assistere l’utente in 3 processi:

- nell’esplorazione di modelli virtuali tridimensionali;- nella loro modifica ed adattamento alle esigenze dell’utente;

- nella fase di discussione dei 3D model con amici, colleghi, familiari, e clienti grazie anche a funzionalità di condivisione remota attraverso socialnetwork e

altri canali come l’e-mail o il cloud. Sono presenti sul mercato alcune app simili, ma la user experience di

queste spesso risulta progettata solo per utenti con una profonda conoscenza del mondo delle tecnologie 3D e quindi non adatta ad un’utenza meno specializzata.

Una delle sfide di Vertix è quella di riuscire a servire i bisogni di quest’ultima tipologia di utenti, senza comunque trascurare le esigenze dei power user.

5.3.2 La Kick-off session Una Kick-off session è considerata il primo meeting di inizio progetto in cui:- Viene illustrata e descritta la vision temporanea del prodotto, basata su

assunzioni, e riportata nel paragrafo precedente;

47

Fig.17 Illustrazione raffigurante un Kick-Off meeting

- Vengono assegnati gli ruoli: Lo scrum team, nel case study portato ad esempio

è composto da solamente 3 persone (escludendo lo scrum master ed il product owner), andando contro ad una delle pratiche consigliate dalla Scrum Guide e

dalla Lean UX. Entrambe sostengono, come abbiamo già visto in precedenza, che il numero di elementi minimo di cui lo scrum team si deve comporre sia 5.

Questo, ha portato ad alcuni rallentamenti in fase di sviluppo, dovuti ad esempio alla mancanza di uno User Inteface Designer, di cui ho dovuto

personalmente prendere il ruolo;- Comincia la definizione del product backlog: La vision è stata usata come

punto di partenza per avviare una discussione collaborativa (Fig.17) con tutto il team, per estrarre i punti chiave del progetto, distillare e discutere alcune idee

ragionando anche sulle divergenze d’opinione e mitigandole.

48

Requisito Funzionale Esplorare un modello 3D

User Story“Come utente, vorrei esplorare

il modello 3D in un modo prevedibile”

DescrizioneL’utente vorrebbe esplorare e manipolare nel modo più naturale possibile un modello salvato nel suo tablet.

Fig.18 Esempio di requisito funzionale

Il risultato finale della riunione è stata la stesura delle prime user stories

(descritte nel capitolo 4) nella seguente forma:

Questi artefatti non contengono volutamente informazioni e soluzioni tecniche come “Muovere il modello attraverso l’uso di un bottone” per non togliere al

team la libertà di esplorare altre strade che potrebbero rivelarsi migliori. Sarà parte del lavoro del gruppo quello di scendere nei particolari di ogni user story

per successivamente progettare e testare le varie alternative individuate durante il processo di design.

In passato ero solito utilizzare personas e scenarios molto più ricchi di empatia ed informazioni sugli utenti, ma le caratteristiche che ho notato nella

loro implementazione durante la prima parte del progetto e che mi hanno spinto al loro abbandono (almeno in un framework rapido come quello Scrum) sono le

seguenti:- Richiedono molto tempo per essere implementate;

- La loro prolissità tende a renderle noiose e troppo lunghe da leggere, anche se ridotte a poche righe. Questo le porta troppo spesso ad essere ignorate o

sottovalutate;- E’ bene ricordare inoltre come sia le user stories che le personas e gli scenari

d’uso siano basati su assunzioni da testare e non su certezze. Il minor tempo speso nelle assunzioni, si traducerà in un minor tempo impiegato per arrivare ai

test e quindi alle certezze. Anche in questo le user stories si dimostrano uno strumento dall’efficienza maggiore.

49

Fig.19 Evoluzione dai primi sketch fino alla definizione nell’ultimo disegno in basso di una idea su cui lavorare

5.3.3 La necessità di una visione comune del prodottoUna volta definito il product backlog, il team ha dato inizio ad una sessione di design collaborativo, in cui si sono ricercate le soluzioni ai problemi e alle

necessità degli utenti evidenziate nelle user stories. Per fare ciò, il gruppo ha trascorso un paio d’ore in piedi davanti ad una lavagna ragionando sulle idee ed

esternandole tramite degli sketch (Fig.19), raggiungendo alla fine un accordo comune sulla strada da seguire per soddisfare le user stories appartenenti al

primo sprint. Gli sketch si sono rivelati importanti in quanto:

- Costringono ognuno a esteriorizzare non solo i pensieri tramite le parole, ma attraverso un artefatto che rende le idee chiare, esplicite ed utili per suscitare

curiosità e domande;- Gli sketch possono essere modificati da persone diverse dall’autore, e quindi

usati come punti di partenza attorno cui far evolvere la discussione e le idee;- Un prototipo su carta o su una lavagna può essere testato ad esempio su colleghi

non appartenenti al team, raccogliendo così feedback immediati;

50

Menu Chiuso

Menu Aperto

Fig.20 Primo prototipo in Axure

Una volta trovata un’idea comune e convincente su cui lavorare abbiamo

trascorso qualche ora preparando un prototipo da testare su alcuni colleghi, utilizzando, a questo scopo, un software di prototipazione veloce: Axure Rp. Il

risultato spartano ottenuto è visibile nella figura 20. Il test su questo design allo stadio preliminare si è rivelato utile per verificare, per esempio, se la presenza di

un solo bottone sullo schermo, un piccolo “+” posizionato nella parte in basso a sinistra, sarebbe risultato disorientante per l’utente.

In meno di 24 ore abbiamo così facendo avallato le nostre prime ipotesi e permesso al

team di condividere una visione comune su come sviluppare il menu della applicazione,

senza bisogno di elementi di user interface aggiuntivi, che avrebbero reso questa meno

pulita.

Inoltre, questo ha permesso al designer e ai 2 sviluppatori di lavorare in

parallelo. Il primo, ha potuto affinare i design producendo delle bozze da presentare al

weekly meeting mentre i secondi hanno potuto implementare lo scheletro del codice

della app e dedicarsi alla risoluzione di problemi più tecnici massimizzando il tempo

disponibile.

51

5.3.4 Lavorare prima veloci per poi arrivare ad un design asetticoAl primo Sprint meeting, il team ha presentato il lavoro svolto fino a quel momento che comprendeva:- una app funzionante con un menu privo di animazioni e molto spartano;- alcune delle funzioni considerate di base implementate e testate sia su colleghi

che su persone esterne all’azienda; Ben poco se considerata la app finale. ma comunque il software risultava funzionante e quindi potenzialmente rilasciabile. Il nostro obbiettivo era quindi raggiunto. Nello sprint successivo, oltre ad andare a soddisfare le ultime user stories principali, abbiamo dedicato del tempo alla progettazione delle animazioni e al visual design del menu, creando numerosi prototipi attraverso l’utilizzo di applicazioni solitamente usate nei montaggi video come Adobe After Effect ed Adobe Edge Animate. Nonostante queste non siano state concepite con lo scopo di supportare attività di animation prototyping, si sono comunque rivelate efficaci strumenti per lo sviluppo di un menu interattivo pienamente funzionante senza andare ad utilizzare del codice e risparmiando di conseguenza molto tempo, considerata la complessità delle animazioni che volevamo testare. In parallelo, con l’utilizzo di Adobe Photoshop, abbiamo curato il visual design, passando da sketch e wireframes a qualcosa di esteticamente accattivante, oltre che funzionale (Fig. 21-22).

5.3.5 Implementare un processo di Lean UX sfruttando il ritmo dello Scrum Lo Scrum, come visto nel capitolo precedente, è caratterizzato dalla presenza di molti meeting a cadenza costante. Gothelf, suggerisce di sfruttare questa caratteristica del framework per incastonare al suo interno pratiche di User Experience Design (Gothelf, 2013). Nella mia esperienza, ho potuto apprezzare soprattutto come i daily meeting siano un fondamentale momento di incontro e discussione tra il team, lo Scrum Master e il Product Owner. Ogni componente del gruppo durante questa riunione deve esprimere in modo trasparente:- Cosa ha fatto ieri;- Cosa sta facendo oggi;- Se ha incontrato degli impedimenti che lo rallentano o lo bloccano;

52

Fig.22 Il menu in uno dei suoi stati

Oltre a questo momento di ispezione ed adattamento, molto spesso i daily meeting diventavano occasione di confronto su particolari minori, ma che potevano potenzialmente rivelarsi una perdita di tempo e rallentare il gruppo di lavoro se non valutati accuratamente.

Fig.21 Il menu in uno dei suoi stati

53

L’errore che spesso si compie è quello di considerare i meeting come gli

unici momenti di confronto rischiando così di abbassare il livello di collaborazione fondamentale per massimizzare la quantità e qualità di lavoro

svolto (dal punto di vista Agile) ed aumentare la qualità della conoscenza e della visione condivisa all’interno team (dal punto di vista della Lean UX).

5.3.6 Il workspaceIl capitolo conclude trattando volutamente per ultima l’importanza dell’ambiente in cui il Team lavora nell’applicazione del metodo Lean UX e Scrum.

Gothelf sottolinea l’urgenza dell’assenza di barriere che intralcino la collaborazione. Anche sotto questi aspetti Future Workshops si è rivelata

un’azienda all’avanguardia, costruendo un ufficio open space, accessoriato con whiteboard dove poter discutere con i colleghi, una piccola biblioteca dove

trovare ispirazione ed una meeting room dove le riunioni possono svolgersi in tranquillità.

Anche il cameratismo ed il divertimento atto alla sua creazione non mancano nell’azienda, con la presenza di numerosi momenti ricreativi come una partita a

calcio balilla (Fig.23) o la visione a cadenza settimanale di un video che a rotazione un membro del team propone, e che poi viene da tutti commentato,

arricchendo così la cultura aziendale su un argomento specifico.

Fig.23 Momenti di svago a Future Workshops

54

Fig.24 Vertix in uso

5.3.7 I risultati raggiuntiI 3 sprint, durati complessivamente 3 settimane, hanno portato

all’implementazione di un M.V.P. Il progetto è al momento congelato per motivi di priorità aziendale, ed attende solo alcune rifiniture per poter essere immesso

nell’app store.

55

56

Conclusioni

Nella tesi sono state trattate numerose metodologie appartenenti alle discipline

del project management e dello User Centered Design. Abbiamo visto la loro storia, e i loro vicendevoli punti di allontanamento ed incontro.

Il metodo Lean UX tenta di spingere le organizzazioni in cui le pratiche di management Agile sono applicate un passo avanti verso un nuovo paradigma di

organizzazione aziendale. Una gerarchia che non veda più le company divise in silos stagni (Fig.25), ma bensì in piccoli team multidisciplinari e cross-funzionali

all’interno dei quali i ruoli vengono annullati ed ognuno è elevato al ruolo di ricercatore UX (Fig.26), creando così la cultura, la conoscenza e la visione di

progetto comune che prima mancava. Alcuni sostengono che lo Scrum e la Lean UX siano framework per sole startup.

In realtà, la adozione di queste da parte di aziende come Google, Nokia, IBM, HP dimostra il contrario. Queste non sono più piccole aziende innovative, ma è la

loro cultura e il loro approccio all’organizzazione che è rimasto tale a renderle grandi.

Fig.25 Organizzazione aziendale PRIMA dell’applicazione della Lean UX (8VDWD�FRQ�SHUPHVVR�GD Gothelf, 2013)

57

Fig.26 Organizzazione aziendale DOPO l’applicazione del metodo Lean UX��8VDWD�FRQ�SHUPHVVR�GD Gothelf, 2013)

58

Bibliografia

Project Management Institute (2013) A Guide to the Project Management Body of Knowledge: PMBOK(R) Guide, Pubblicato da Project Management Institute; Luis Yu Chuen-Tao (1994) Applicazioni pratiche del Pert e del CPM. Nuovi Metodi di Direzione per la Pianificazione, la Progettazione e il Controllo dei Progetti, Pubblicato da Franco Angeli;

Q.W.Fleming, J.M.Koppelman (2000) Earned Value Project Management - Second Edition, Pubblicato da Project Management Institute;

Harold R.Kerzner (2013) Project Management: A Systems Approach to Planning, Scheduling, and Controlling, Pubblicato da Wiley

D.Hoyle (2008) ISO 9000 Quality Systems Handbook, Pubblicato da Butterworth-Heinemann;

Al-Rawas, S.Easterbrook (1996) Communication Problems in Requirements Engineering: A field Study, Pubblicato da School of Cognitive and Computing SciencesUniversity of Sussex;

J.Raftery, (1994) Risk Analysis in Project Management, pubblicato da E & FN SPON;

B.Curtis, H.Krasner , & N.Iscoe (1988) A Field Study of the Software Design Process for Large Systems. Communications of the ACM, Volume 31, issue 11;

D.Norman, S.Draper (1986) User Centered System Design: New Perspectives on Human-Computer Interaction, Pubblicato da Crc Pr I LIc

A.Cooper, R. Reimann, D. Cronin (2007) About Face 3: The Essentials of Interaction Design, Pubblicato da John Wiley & Sons;

J.J.Garret (2010) The Elements of User Experience: User-Centered Design for the Web and Beyond, Pubblicato da New Riders Pub;

K.Beck, M.Beedle, A.van Bennekum, A.Cockburn, W.Cunningham, M.Fowler, J.Grenning, J.Highsmith, A.Hunt, R.Jeffries, J.Kern,B.Marick, R.C.Martin, S.Mellor, K.Schwaber, J.Sutherland, D. Thomas (2001), Agile Manifesto, Pubblicato su www.agilemanifesto.org;

!

59

P.VII (2012) Kanban, The Kanban guide, For the Business, Agile Project Manager, Scrum Master, Product Owner and Development Support Team, Pubblicato da Pashun Publishing;

E.Ries (2012) Introduzione a Lean UX: Applying Lean Principles to Improve User Experience, di J.Gothelf e a cura di J.Seiden, Pubblicato da Oreilly & Associates Inc;

J.Gothelf (2013) Lean UX: Applying Lean Principles to Improve User Experience, a cura di J.Seiden, Pubblicato da Oreilly & Associates Inc;

E.Ries (2011) The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Pubblicato da Crown pub;

T. Brown (2009) Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, Pubblicato da HarperBusiness;

!

60

Ringraziamenti

Dedico questa tesi a tutte le persone che hanno creduto in me, e che mi sono state sempre vicine in tutto

il percorso universitario.

Ringrazio tutte le persone che ho incontrato in questi tre anni, alcune ci sono state, altre ci sono e altre ci saranno,

ma per ognuna di queste porto qualcosa con me.

Ringrazio tutti i Professori ed il mio relatore, per quello che mi hanno trasmesso. Ne farò tesoro.

Un ringraziamento speciale va a tutta Future Workshops, soprattutto a Fabio, Davide, Jenny, Cole, Jonathan e Matt,

per come mi hanno accolto come un fratello e per avermi sempre fatto sentire a casa,

insegnandomi le basi del lavoro di UX Designer con pazienza e dedizione.

La dedico soprattutto ai miei genitori che mi hanno sempre supportato e non hanno mai smesso di credere in me,

nonostante sia il loro figlio più pazzo.

Filippo

61