Tesi di laurea di Andolfatto Filippo: Pratiche di Project Management e User Experience Design: Una Integrazione Possibile

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

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 Management
I 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 progetto
La 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 scopi
Nella 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 processo
Pianificare 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 aggiustamenti
Dopo 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 revisione
L’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/Scopi
ascoltare 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 Design
Lo 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

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 Waterfall
La 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 Cascata
In 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 design
In 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
• Implementazione
Una 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 Waterfall
Dal 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 agili
Un 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 strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere 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 basa
Il 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 team
Di grandi dimensioni (più
di 20 persone), anche se
distribuiti
Di 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

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 finale
In 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 story
Una 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 story
Ogni 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

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
Nella 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 fondamenta
Il 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 Startup
Il 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 UX
Nel 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 assunzioni
In 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 sperimentare
L’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 ricerca
E’ 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 Agile
Durante 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 prodotto
La 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”
Descrizione
L’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 prodotto
Una 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 asettico
Al 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 workspace
Il 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 raggiunti
I 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

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 ( Gothelf, 2013)
57

Fig.26 Organizzazione aziendale DOPO l’applicazione del metodo Lean UX Gothelf, 2013)
58

Bibliograﬁa
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 Sciences
University 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

Tesi di laurea di Andolfatto Filippo: Pratiche di Project Management e User Experience Design: Una Integrazione Possibile

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (14)

Ähnlich wie Tesi di laurea di Andolfatto Filippo: Pratiche di Project Management e User Experience Design: Una Integrazione Possibile

Ähnlich wie Tesi di laurea di Andolfatto Filippo: Pratiche di Project Management e User Experience Design: Una Integrazione Possibile (20)

Tesi di laurea di Andolfatto Filippo: Pratiche di Project Management e User Experience Design: Una Integrazione Possibile