L’argomento del titolo, ovvero come sposare lo sviluppo Agile e lo User-Centered Design, è stato ultimamente al centro dei miei interessi. Dopo aver letto innumerevoli articoli su blog e riviste, ho frequentato, per approfondire, il corso di specializzazione Agile Development and Usability del Nielsen Norman Group ad Amsterdam, letto il loro report sull’argomento e ascoltato l’intervento di Alberto Mucignat al RomeCamp. Quelle che seguono sono le conclusioni a cui sono arrivato, alla luce anche delle mie esperienze, che in genere sono con progetti della durata massima di due o tre mesi e solo in ambito web.

Per chi non sappia nulla dello sviluppo Agile, mi limiterò a una descrizione sintetica degli elementi più importanti. Agile è un processo di sviluppo che sostituisce il classico waterfall lifecycle nella produzione del software. In estrema sintesi Agile spezzetta in più cicli quello che di solito viene fatto in un unico ciclo. Quindi le fasi di Analisi, Progettazione, Programmazione e QA Testing e Rilascio vengono svolte solo per un piccolo gruppo di funzionalità e ripetute per i cicli che seguono, su altri piccoli gruppi di funzionalità. Ognuna di queste fasi, quasi sempre di carattere incrementale, è, nella terminologia Agile (metodo SCRUM), chiamato sprint.

Lo sviluppo Agile è nato nell’ambito della produzione del software e questo, a mio parere, lo rende suscettibile di adattamenti per essere proficuamente utilizzato in ambito web. Inoltre, dei principi alla base dell’Agile Manifesto pubblicato nel 2001, metto in evidenza quello che ritengo il più importante, sostituendo software con user experience: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable experience“. Questo, aggiungo io, con lo scopo di permettere al committente di raggiungere i suoi obiettivi, informativi o commerciali che siano.

Veniamo alla mia visione su come sposare lo sviluppo Agile e lo UCD. Lo farò dividendo il processo in fasi, analizzando quelle essenziali.

Fase A - Ricerca e analisi
La fase di Ricerca e analisi è fondamentale per la buona riuscita di un progetto web. Oltre a definire gli obiettivi aziendali e gli scopi del sito web, si pianificano le attività di ricerca per acquisire informazioni sui suoi fruitori, potenziali o reali che siano. A tal fine si effettuano interviste all’interno dell’azienda, si analizza la concorrenza, si esamina il sito web già on line (analisi dei log) e si effettuano attività di ricerca etnografica (di qualunque tipo, dalle interviste informali nelle fiere ai test di usabilità sul campo). Al termine di queste attività il committente deve tassativamente approvare un documento dove sono riportati gli obiettivi del progetto.

Fase B - Sprint 0: sviluppo dei personaggi, degli scenari e delle stories
Servendoci dei risultati delle ricerche possiamo, nello sprint 0, definire i personaggi e gli scenari che ci porteranno a individuare le principali stories (altro termine dello sviluppo Agile). Una delle criticità dello sviluppo Agile è la gestione della priorità delle stories. Con l’uso dei personaggi e degli scenari questo aspetto è affrontato a monte con la segmentazione e quindi le stories più significative riguardano i personaggi primari. Durante lo sprint 0 il team di programmazione, o almeno un suo rappresentante, deve essere coinvolto nello sviluppo dei personaggi e degli scenari. Il committente, se coinvolto, parteciperà al loro sviluppo e, se non coinvolto, dovrà condividere la loro scelta. Sempre in questo sprint si avvieranno le procedure per il reperimento dei partecipanti al card sorting e/o alla prototipazione partecipata e/o ai test di usabilità, in modo da poterli convocare con un breve preavviso. Anche in questo caso i personaggi torneranno utili per la preparazione dello screener.

Fase C - Sprint 1: architettura informativa, task, wireframe e interfaccia grafica
A mio parere, le stories più importanti dello sprint 1 sono quelle che portano allo sviluppo dell’architettura informativa generale, a individuare i task principali, alla progettazione dei wireframe generali e al progetto grafico dell’interfaccia. Gli strumenti UCD a supporto di queste attività sono il card sorting, la prototipazione partecipata e il cognitive walkthrough con i personaggi. L’eventuale coinvolgimento di persone nella progettazione tornerà utile alla raccolta di informazioni per rifinire e perfezionare i personaggi e gli scenari. In questo sprint il team di programmazione procederà alla raccolta di informazioni sullo stato dell’arte delle tecnologie in uso nel dominio specifico (analisi dei siti concorrenti) e alla definizione di specifiche tecniche compatibili con le caratteristiche dei personaggi. Chiaramente il committente sarà partecipe delle decisioni prese e dovrà condividerle.

Fase D - Dallo sprint 2 allo sprint (N): produzione
Nella fase di produzione vengono individuate stories che, di volta in volta, portano allo sviluppo di determinate sezioni del sito web oppure a determinati task dell’applicativo web (una procedura di registrazione, per esempio). Per essere subito produttivi, conviene arrivare allo sprint 2 con almeno 1 o 2 stories già progettate, in modo da procedere subito alla fase di programmazione. Parallelamente altre stories saranno progettate per essere pronte nello sprint successivo. Una certa asincronicità, quindi, è essenziale per procedere spediti. Le attività UCD per la verifica delle scelte fatte, sono i test di usabilità (tradizionali o RITE, Rapid Iterative Testing and Evaluation) con prototipi più o meno evoluti e il cognitive walkthrough con i personaggi. Al rilascio di una sezione del sito web o di una o più funzionalità dell’applicativo web, il committente valuterà e fornirà il proprio feedback. Per questa ragione si dovranno prevedere alcuni sprint per gli eventuali aggiustamenti.

Fase E - Sprint (N)+1: pubblicazione
Le attività di questo sprint sono essenzialmente di revisione e controllo. Un’attenta correzione dei testi, il controllo dei messaggi di errore e un debug finale, garantiscono al prodotto una maggiore qualità. Il sito web potrà essere pubblicato completo oppure, se il committente lo richiede, si procederà con la pubblicazione di una parte significativa, rimandando a sprint successivi il suo completamento.

Fase F - Sprint di ottimizzazione e modifica
Se il progetto lo prevede si potranno identificare degli sprint in cui inserire le attività di ricerca più idonee per valutare l’efficacia, l’efficenza e la soddisfazione d’uso. Quelle più comuni in questa fase sono l’analisi dei log, i questionari e le interviste. Chiaramente, a ogni sprint di ricerca sarà abbinato uno sprint per l’implementazione delle modifiche.

Conclusioni
Appare chiaro, da quanto ho scritto, che per me lo sviluppo Agile modellato intorno allo User-Centered Design è un processo ben strutturato, che deve essere guidato con mano ferma per rispettare tempi e costi. Solo in questo modo il matrimonio risulterà duraturo e felice.

Nota finale
Al temine del suo intervento al RomeCamp, Alberto Mucignat mi diceva che lo sviluppo Agile ti permette di rispondere velocemente a cambiamenti di rotta, anche significativi, da parte del committente. Su questo sono d’accordo, ma voglio sottolineare, che in questo caso, la stessa agilità è richiesta a lui nell’adeguare il budget e far si che il progetto mantenga i giusti margini di profitto.

I commenti sono disabilitati.