Metodologia

Stefano Bussolon

Project management

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:

Gestione di progetto e aspetti salienti

Nella gestione di un progetto vanno tenuti in considerazione 4 aspetti (Easterbrook 2001):

Rischi più frequenti

Il modello a cascata

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.

processo a cascata

processo a cascata

Le fasi nel modello a cascata

Nel modello che proporrò in questo corso si distinguono le seguenti fasi:

Una rappresentazione piuttosto dettagliata del modello a cascata dell’User centered design è riassunta nel sito usabilitynet.org, che divide il processo in pianificazione, raccolta dei requisiti, design, implementazione, test e misurazione, post rilascio.

Vantaggi del modello a cascata

Limiti dell'approccio a cascata

Sebbene molto razionale, l’approccio classico (a cascata) a volte fallisce, in quanto emergono una serie di problemi che costituiscono dei seri ostacoli al successo progettuale (Parnas and Clements 1986).

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:

Approccio agile

Approccio agile

Per superare i limiti del modello a cascata è stato adottato un approccio, definito agile, che 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

processo agile

processo agile

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

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

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.

Vantaggi

Limiti dell’approccio agile

Nonostante i suoi vantaggi, anche lo sviluppo agile ha dei limiti, come evidenziati da Boehm (2002).

Requisiti

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, diventa essenziale 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.

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.

Metodologia: fasi, piani, domande

Le fasi progettuali

Il modello progettuale che propongo distingue le seguenti fasi

Le fasi del modello

Le fasi

Le fasi

Jesse James Garrett: 5 piani

Nel suo “The elements of user experience” Garrett (2003) distingue 5 piani, che corrispondono a diversi livelli di astrazione della ricerca e rappresentazione:

Le domande

Ermagora di Temno, nel II secolo a.C. ha identificato 8 loci argomentorum, ripresi da Agostino e da Tommaso d'Aquino:

  1. Chi
  2. Perché
  3. Cosa
  4. Come (in che modo)
  5. Dove
  6. Quanto
  7. Quando
  8. Con che mezzi

I loci argomentorum possono servire da guida nel processo di design

Garrett vs Ermagora

Grafo: Garrett vs Ermagora

Grafo: Garrett vs Ermagora

I metodi

I metodi, classificati per fase e domanda

I metodi, classificati per fase e domanda

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:

Perché: strumenti e documenti

Esplorazione

Ricerca

Documenti

Cosa (scope - il dominio)

A questo livello vengono definite

Cosa: strumenti e documenti

Esplorazione

Ricerca

Documenti

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

Ricerca

Documenti

Come (structure)

Vengono progettate, secondo Garrett (2003):

Come: strumenti e documenti

Strumenti

Documenti

Dove: i canali

Nell'ambito dell'UX - IA possiamo identificare i mezzi nei vari canali:

Lo scheletro

Garrett (2003) definisce 3 componenti:

Nella progettazione multicanale, è necessario progettare differenti scheletri per i diversi device.

Strumenti

Documenti

La superfice

A questo livello si progettano gli aspetti visuali. Gli aspetti di cui tener conto sono molteplici:

Testi citati

Boehm, Barry. 2002. Get Ready for Agile Methods, with Care. IEEE Computer (January).

Cockburn, Alistair. 2000. Agile Software Development. Draft version: 3b. Cockburn * Highsmith Series.

Cooper, Alan. 1999. The Inmates are running the Asylum. Macmillan.

Easterbrook, Steve. 2001. Project Management. University of Toronto – Department of Computer Science.

Garrett, Jesse James. 2003. The elements of user experience. Berkeley - CA - US: New Riders.

Parnas, David L., and Paul C. Clements. 1986. A rational design process: How and why to fake it. IEEE Transactions on Software Engineering 12, no. 2: 251–57.