Sviluppo Agile e User Centered Design, ovvero Agile UX

Questo articolo è in risposta a quanto scritto da Sefano qui.

Innazitutto credo fermamente che la metodologia agile sia applicabile a progetti Web, e concordo con quanto scritto da Stefano sul fatto che questa vada adattata, essendo il contesto e gli attori differenti.

Il team degli sviluppatori nell’agile classico viene sostituito dal team nella sua interezza, dal team agile UX: programmatori, web writer, information interaction designer, graphic designer, SEO specialist, …

Quando si pensa a chi è il constraint sul progetto, il collo di bottiglia, si deve pensare a tutto il team, non solo ai programmatori.

Per quanto riguarda la “pubblicazione” del sito, anche nella metodologia Agile classica si fa riferimento al MMF: Minimum Marketable Features, ovvero il minimo insieme di funzionalità che il prodotto deve avere prima di essere lanciato sul mercato. Non è vero che dopo il primo sprint si ha sempre un qualcosa che possa diventare pubblico. Anzi. Nell’Agile UX questo corrisponde al minimo set di funzionalità che rendono un sito pubblicabile, anche se in versione alpha o beta.

Per quanto riguarda la progettazione dell’architettura dell’informazione ritengo sufficiente una mappa del sito e dei flowchart che mostrino quali sono le azioni da fare per portare a compimento i processi/task principali. Fatte queste, per ogni sprint si creano wireframes e mock-up da condividere con il team e con il cliente. L’approvazione del cliente è determinante. Mock-up ben fatti salvano un sacco di tempo al team e permettono di fare test di usabilità. Non importa che il cliente veda del software funzionante quando può avere un prototipo che fa la stessa cosa. In questo mi dissocio dall’approccio Agile che dice “niente documentazione solo software funzionante”, ma non perchè sia contrario all’idea, ma perchè semplicemente lo scenario qui è diverso.

Il coinvolgimento del cliente, anche 30 minuti alla settimana, è fondamentale e irrinunciabile. E’ col cliente che si fa il planning game, che si introducono nuove storie, ed eventualmente se ne tolgono altre, perchè tutto il lavoro deve essere fatto in un timebox ben determinato. Al cliente bisogna spiegare che per ogni nuovo story point che entra nel progetto ne deve uscire uno tra quelli già pianificati (magari senza spaccare il capello…).

Per quanto riguarda i test di usabilità parafrasando Jakob Nielsen si può dire che è comunque sempre meglio testare un utente 10 minuti che non testare affatto. Credo che 10 minuti li si possa trovare tutti.

Grazie Stefano per l’ottimo articolo!

Due colleghi in pair programming