class: profilo <h1>La metodologia</h1><h2 class="author">Stefano Bussolon</h2> --- layout: true <img src="https://www.bussolon.it/assets/logo_250.png" width="50px" height="50px" style="position:absolute;top:5px;left:5px;"/><div id="footer" style="position:fixed; bottom: 0px;left: 0px;height: 40px; padding:5px; width: 100%;display: flex;align-items: center;"></div> --- class: centraleArancio # Gestione dei progetti --- ## Metodologia progettuale La progettazione di un artefatto cognitivo è un processo complesso che coinvolge un team multidisciplinare. È dunque necessario applicare una metodologia progettuale per minimizzare i rischi di fallimento del progetto. --- ## Gestire un progetto Gestire un progetto significa: * identificare gli **obiettivi** e i risultati attesi, e se possibile quantificarli; * identificare i **vincoli**; * identificare e gestire le **risorse**; * pianificare il **processo** in modo da raggiungere gli obiettivi rispettando i vincoli; * **monitorare** il processo ed aggiustarlo quando necessario; * mantenere un ambiente di lavoro calmo, positivo e produttivo. --- ## Aspetti salienti Nella gestione di un progetto vanno tenuti in considerazione 4 aspetti [ Easterbrook (2001)]: * il prodotto; * le risorse; * i tempi; * i fattori di rischio; --- ## Rischi più frequenti * sforare il **budget** o i **tempi** * sviluppare funzioni non necessarie * continue modifiche dei **requisiti** * problemi tecnici di **implementazione** * problemi di **prestazione** del prodotto, ad esempio una applicazione troppo lenta * problemi di **usabilità**, di **accessibilità** o di utilità che non erano stati preventivamente identificati --- class: centraleArancio # Modello a cascata vs approccio agile --- ## Il modello a cascata La modalità di progettazione tradizionale, sviluppata intorno agli anni settanta, è definita a cascata, in quanto presuppone una **sequenza** quasi lineare di passaggi. La figura descrive graficamente il modello. Si inizia con l’analisi dei requisiti, si passa ad una fase di analisi, progettazione, implementazione, test e distribuzione.  --- ## Le fasi nel modello a cascata Nel modello che proporrò in questo corso (un modello ibrido) si distinguono le seguenti fasi: * esplorazione * ricerca * rappresentazione * progettazione * test * implementazione --- ## Vantaggi del modello a cascata * L'analisi e pianificazione iniziale costituisce una buona **base** per la progettazione e l’implementazione, diminuendo il rischio di errori o la necessità di modifiche strategiche al progetto. * L’adozione di **standard procedurali** può essere di aiuto soprattutto nella gestione contemporanea di più progetti, ma anche per affinare la metodologia fra un progetto e l’altro. * Se si segue uno standard procedurale diventa più facile **monitorare** i progressi fatti e gli eventuali problemi. * Avere una **prospettiva** a medio-lungo termine aiuta le persone ad organizzarsi --- ## Limiti dell'approccio a cascata L’approccio classico (a cascata) a volte fallisce, in quanto emergono una serie di problemi che costituiscono dei seri ostacoli al successo progettuale [ L. Parnas et. al. (1986)]. * Non tutto è analizzabile a priori: * Difficoltà nello stabilire i **requisiti** del cliente * Difficoltà nell'analizzare i **vincoli** progettuali * Possono sopraggiungere dei **cambiamenti** esterni. * Non ottimale gestione degli **errori** di progettazione e sviluppo --- exclude: true ## Non tutto è analizzabile a priori I fenomeni che rientrano nella progettazione non sono analizzabili con precisione, perché spesso vi sono vincoli, interni o esterni al progetto, che non possono essere analizzati con precisione a priori, e possono emergere solo in fase di test. --- ## Testare troppo tardi Se la fase di test avviene solo alla fine dello sviluppo, si aumentano i fattori di rischio: * si dilatano i **tempi** di consegna; * aumentano i **costi**, in quanto diventa necessario fare delle modifiche importanti ad un prodotto già sviluppato; * se gli errori sono relativi all’analisi dei requisiti, bisogna sostanzialmente **ripartire** dall’inizio. --- ## Approccio agile L'approccio agile modifica in maniera piuttosto radicale la progettazione di software. Questa modalità si basa sullo sviluppo **iterativo** ed è fondata su di una serie di linee guida (l’agile manifesto). --- ## Approccio agile: il grafico  --- ## Minimum viable product ed evoluzione Lo sviluppo agile assume un approccio **iterativo** e **incrementale**, per permettere al team di sviluppo di imparare e ricevere feedback dagli utenti. L’idea è quella di iniziare con una **implementazione di base**, semplice, di un sottogruppo di funzioni e iterativamente far **evolvere** il progetto versione dopo versione. Ad ogni iterazione è possibile apportare delle **modifiche** al design e **aggiornare** la lista dei requisiti. --- ## Manifesto agile L’approccio agile basa i suoi vincoli non su regole specifiche ma su principi generali: sviluppare e distribuire, presto e **frequentemente**, prodotti **funzionanti**, in stretto contatto con il committente e tenendo conto di eventuali **mutamenti** di contesto. Gli autori che hanno elaborato l’approccio agile hanno scritto un manifesto, che è costituito da un decalogo di principi da rispettare nello sviluppo agile [ Cockburn (2000)]. --- class: vCentrale * **soddisfare il committente** * **distribuzioni frequenti** * **software funzionante**: è la principale misura dello stato di avanzamento. * **accettare i cambiamenti** di requisiti, anche quando arrivano tardi nella fase di sviluppo. * **collaborazione** (work together) fra committenti, sviluppatori e team multidisciplinare * **persone motivate** --- class: vCentrale * **comunicazione diretta** e meno documentazione formale (documentazione lean) * gruppi auto-organizzati * attenzione alla **qualità** * **sviluppo sostenibile** (sustainable development) * **semplicità**, ovvero l'arte del **non fare** le cose inutili * **adattare il metodo**: ad intervalli regolari, il team cerca di capire come diventare più efficace, e cerca di aggiustare la propria metodologia. --- ## Vantaggi * risultati parziali ma **immediati** * offre delle **gratificazioni** intermedie: si vedono da subito alcuni risultati * in caso di sopraggiunte difficoltà vi è comunque un prodotto che funziona; * l'approccio iterativo permette un **continuo miglioramento** del prodotto --- ## Limiti dell’approccio agile Nonostante i suoi vantaggi, anche lo sviluppo agile ha dei limiti, come evidenziati da Boehm (2002). * **documentazione**: una documentazione informale non è adeguata a tutti i progetti, a tutti i team, a tutte le circostanze * l'approccio agile implica il **coinvolgimento** dei committenti; quando manca, aumenta il rischio di incomprensione con il cliente, in quanto manca sia la comunicazione conversazionale che la documentazione più formale --- ## Circostanze L’approccio tradizionale funziona meglio quando i requisiti possono essere determinati a priori, anche attraverso la prototipazione, e rimangono **stabili**. Se, al contrario, i requisiti cambiano spesso e molto, l’enfasi tradizionale verso una pianificazione precisa, completa, consistente, testabile e tracciabile diventa fortemente controproducente. Dimensioni del progetto: lo sviluppo agile appare vincente in team piccoli, mentre lo sviluppo tradizionale, più pianificato, può funzionare meglio in gruppi di lavoro di grandi dimensioni. --- ## Bilanciare agilità e disciplina Un eccesso di pianificazione porta ad un aumento dei tempi e dei costi. Troppo poca pianificazione porta ad un aumento dei rischi di errore. A seconda del contesto diventa essenziale trovare un buon rapporto fra agilità e disciplina. --- ## Agile e UX: aspetti convergenti *Semplicità*, buon *design* ed eccellenza, *funzionalità* sono obiettivi sia dell'agile che dell'ux team. Lavorare in team *co-locati*, *motivati*, capaci di *auto-organizzarsi*, di **adattarsi ai cambiamenti**, di imparare dall'esperienza, sono pratiche che ben si adattano sia allo sviluppo agile che all'UX design, entrambi interessati ad uno **sviluppo sostenibile**. --- ## Agile e UX: divergenze L'agile manifesto si concentra sul customer inteso come committente, non sull'utente finale. Ma senza il **coinvolgimento degli utenti**, non c'è User Experience design. Il software (funzionante) è il primario indice di progresso per lo sviluppo agile. Ma l'esperienza non è il software. Il software è un tassello nell'esperienza, e la fase di **ricerca** nell'UX deve prescindere dallo sviluppo del prodotto. --- class: vCentrale Un approccio esclusivamente iterativo è incapace di gestire gli aspetti **gerarchici** dell'esperienza e della sua **concettualizzazione**. Ignorare le gerarchie concettuali non ci permette di distinguere gli elementi *stabili*, da progettare prima, e quelli più mutevoli, perché legati al contesto, dove un approccio agile è necessario. Per approfondire: [Ux e Agile](https://www.bussolon.it/newsletter_ux/ux-e-agile.html) --- class: centraleArancio # La metodologia Lean --- ## Toyota Production System > "people doing the work are best suited to create solutions" > "The right process will produce the right results" Il metodo lean, sviluppato da Toyota è un approccio organizzativo finalizzato ad **aumentare il valore** e **ridurre gli sprechi** nella produzione industriale. --- ## Princìpi * focalizzarsi su quello che i clienti considerano di **valore** * identificare un **processo** capace di creare valore e minimizzare gli sprechi * adottare di strategie finalizzate a rendere il processo il più **fluido** possibile * **perfezionare** il processo: minimizzare i passaggi, il tempo, le informazioni necessarie per arrivare a soddisfare il cliente --- ## Dimensioni della *lean transformation*: * le finalità (**why**): i bisogni e gli scopi dei clienti * il processo (**how**): identificare il *flusso di valore*, valutare che ogni passaggio crei valore in maniera efficace, adeguata, consistente e flessibile, e che tutti i passaggi contribuiscano a garantire un processo fluido e capace di adattarsi alle esigenze e alle richieste della produzione; * le persone (**who**): identificare le persone responsabili del flusso di valore, della valutazione dei passaggi, della loro coerenza con gli scopi di business e con la cultura lean; identificare modalità di ingaggio delle persone, ed abilitarle a lavorare al processo per correggerlo e miglioararlo. --- ## 5S 1. Seiri (Sort): mantenere solo ciò che è essenziale 2. Seiton (Systematize): disporre gli strumenti nel modo più appropriato per favorire un flusso di lavoro fluido 3. Seiso (Shine): mantenere lo spazio di lavoro pulito 4. Seiketsu: standardizzazione del processo 5. Shitsuke (Sustain): la necessità di continuare a mantenere alti gli standard Interfaccia pulita (Seiri) ed esteticamente piacevole (Seiso), macro e micro architettura (Seiton), che adatta gli standard esterni ed interni (Seiketsu) e aggiornata nel tempo (Shitsuke) --- class: centraleArancio # Metodologia: fasi, piani, domande --- class: vCentrale ### &nbsp; In questa sezione introduciamo un quadro metodologico, distinguendo tre dimensioni: * le **fasi** progettuali * i **piani** di *astrazione* * le **domande** di design --- ## Le fasi progettuali Il modello progettuale che propongo distingue le seguenti fasi * esplorazione * ricerca * rappresentazione/sintesi * progettazione * test * implementazione --- ## Le fasi del modello  --- ## Jesse James Garrett: 5 piani Nel suo “The elements of user experience” James Garrett (2003) distingue 5 piani, che corrispondono a diversi livelli di *astrazione* della ricerca e rappresentazione: * the strategy plane (la **strategia**); * the scope plane (il **dominio**); * the structure plane (la **struttura**); * the skeleton plane (lo **scheletro**); * the surface plane (l’aspetto **visuale**). --- ## Le domande [Ermagora di Temno](http://it.wikipedia.org/wiki/Ermagora_di_Temno), nel II secolo a.C. ha identificato 8 *loci argomentorum*, ripresi da Agostino e da Tommaso d'Aquino: <!-- 1. Quis - Chi - Who -> persona 1. Cur - Perché - Why -> causa 1. Quid - Cosa - What -> factum 1. Quomodo (quem ad modum) - In che modo (come) - How -> modus 1. Ubi - Dove - Where -> locus 1. Quantum - Quanto 1. Quando - Quando - When -> tempus 1. Quibus Auxiliis (quibus adminiculis) - Con quali mezzi -> facultas --> 1. Chi 1. Perché 1. Cosa 1. Come (in che modo) 1. Dove 1. (Quanto) 1. Quando 1. Con che mezzi I loci argomentorum possono servire da guida nel processo di design ---  --- ## Chi (strategy) Identificare gli utenti, segmentarli. ### Esplorazione Segmentazione preliminare dell'utenza ### Ricerca Interviste, questionari, osservazione partecipata .... ### Documenti Personaggi (personæ) --- ## Perché (strategy) > Se progettiamo e realizziamo prodotti attraverso cui gli utenti possono soddisfare i propri scopi, quelle persone saranno soddisfatte, efficaci e felici, saranno soddisfatte di aver acquistato i nostri prodotti, li raccomanderanno agli amici, e questo si traduce in un successo di business > Cooper (1999). Identificare le motivazioni (degli utenti, dei committenti) è il processo alla base del goal oriented design. --- Si definiscono: * i **bisogni degli utenti** che l’artefatto vuole soddisfare, attraverso l’analisi degli utenti attuali e potenziali; * gli **obiettivi dei committenti**: * **business goals**: guadagnare soldi, risparmiare soldi, migliorare la produttività ... * **branding**, **advertising**: far conoscere il proprio marchio, i propri prodotti, i propri servizi a potenziali clienti e partner. --- ## Perché: strumenti e documenti ### Esplorazione * analisi degli stakeholder ### Ricerca * intervista ai committenti * ricerche di mercato * interviste, questionari, repertory grid, laddering --- ### Documenti * segmentazione degli utenti su base motivazionale: bisogni, scopi, valori, interessi; * aspetti motivazionali come elementi delle personæ. * stakeholder analysis * documento di strategia --- ## Cosa (scope - il dominio) A questo livello vengono definite * le **specifiche funzionali** - quali funzioni vogliamo sviluppare, in che ordine di priorità, a che iterazione; - quali funzioni **non** vogliamo sviluppare; * il dominio informativo (**content requirements**): quali informazioni. --- ## Cosa: strumenti e documenti ### Esplorazione * analisi competitiva (benchmark) * analisi contenuti esistenti --- ### Ricerca * richieste dei committenti: - interviste - focus group - affinity diagram * coinvolgimento degli utenti: - repertory grid - free listing - valutazione di importanza - interviste strutturate - questionari --- ### Documenti * inventario contenuti e funzioni esistenti (as-is) * elenco contenuti e funzioni desiderati, ordinato per importanza * matrice competitiva * mappe concettuali - ontologie --- ## Quando Nella progettazione della User Experience il quando mappa le fasi dell'esperienza (prima, durante, dopo). Vengono rappresentate le esperienze lungo l'asse temporale. ### Esplorazione * analisi e mappatura dei processi esistenti ### Ricerca * interviste: scenari / task analysis --- ### Documenti * mappa dell'esperienza * customer journey * *service blueprint* --- ## Come (structure) Vengono progettate, secondo James Garrett (2003): * l’**interaction design**: - come il sistema si comporta in risposta ai comportamenti dell’utente; - definizione dei flussi di processo; - flussi dei compiti degli utenti * l’**architettura dell’informazione**, la struttura dell’informazione nello spazio informativo: - la struttura gerarchica - le faccette - le (micro)ontologie. --- ## Come: strumenti e documenti ### Strumenti * interaction design: - task analysis * architettura informativa: - card sorting - affinity diagram --- ### Documenti * diagrammi di flusso (interazione) * tassonomie * alberi di navigazione * filtri / navigazione a faccette --- ## Dove: i canali Nell'ambito dell'UX - IA possiamo identificare i mezzi nei vari canali: * desktop o laptop; * web; * mobile (smartphone, tablet); * chioschi interattivi; * sistemi interattivi montati su veicoli e automobili; * sistemi di home entertaimnent (console per giochi, TV interattive, home theater); * strumenti professionali (scientifici, medicali). * **luoghi fisici** --- ## Lo scheletro James Garrett (2003) definisce 3 componenti: * l’**information design**: la presentazione delle informazioni all’utente; * l’**interface design**: la progettazione degli elementi dell’interfaccia per permettere agli utenti di interagire con l’applicazione; * la progettazione della **navigazione**, che permette agli utenti di muoversi all’interno della struttura informativa. Nella progettazione multicanale, è necessario progettare differenti *scheletri* per i diversi device. --- ### Strumenti * pattern * linee guida ### Documenti * wireframes * prototipi --- ## La superfice A questo livello si progettano gli aspetti visuali. Gli aspetti di cui tener conto sono molteplici: * estetica; * accessibilità; * brand, identità; * consistenza interna ed esterna; * colori, tipografia, impaginazione. --- <h2>Testi citati</h2><div class="reference">Steve Easterbrook (2001). Project Management; </div><div class="reference">David L. Parnas and Paul C. Clements (1986). {A rational design process: How and why to fake it}; IEEE Transactions on Software Engineering</div><div class="reference">Alistair Cockburn (2000). Agile Software Development; </div><div class="reference">Barry Boehm (2002). Get Ready for Agile Methods, with Care; IEEE Computer</div><div class="reference">Jesse James Garrett (2003). The elements of user experience; </div> --- <h2>Testi citati (2)</h2><div class="reference">Alan Cooper (1999). The Inmates are running the Asylum; </div>