Ieri con Luca abbiamo seguito alcuni interventi nella traccia “UX Design” del Web 2.0 Expo. Quello che mi ha colpito ed interessata di più è stato lo speech sull’agile design & development tenuto da M. Jackson Wilkinson di Viget.
Il problema emerso è che nei processi di sviluppo tradizionale (waterfall) i momenti di confronto e verifica sono estremamente scarsi e portati verso gli ultimi step con conseguenza che in caso di errori o cambiamenti nel progetto i costi ed i tempi di correzione sono estremamente alti.
Dal punto di vista puramente teorico ogni processo funziona, ma nella realtà nessuno crede più nelle favole e sappiamo benissimo che l’essere umano non è una macchina a stati finiti che funziona a step. In un team infatti le persone pensano in momenti diversi alla soluzione, ai requisiti, al design, all’implementazione… in un ciclo infinito di percorsi mentali personali (ogni uno ha il suo)… senza poi contare l’influenza dei problemi personali che non restano mai fuori dalla porta.
Quello che si può dunque notare nella realtà è che tipicamente i processi non prevedono la possibilità di fallire o di adattarsi al cambiamento che avviene giorno per giorno. A questo punto bisogna anche aggiungere il fatto che partner, clienti, fornitori, consulenti, … coinvolti in esterno nel progetto quasi mai sono in grado di sincronizzarsi con le tempistiche.
Da queste riflessioni sono nati e si sono evoluti processi sempre più agili che puntano a far crescere ed evolvere a piccoli passi il progetto tentando di gestire al meglio qualunque influenza.
Le principali caratteristiche sono:
- iteratività
- adattabilità
- cooperatività
- rapidità
- puntare a qualità ed obiettivi
Nella pratica si tratta di processi in cui il team di marketing, design e sviluppo cooperano tutti assieme (nello stesso luogo fisico e tempo) a costruire il progetto seguendo cicli iterativi che vanno da 1 a 4 settimane (in pratica 2 o 3) dove si progettano ed implementano una serie limitata di funzionalità. Questo vuole dire che in tempi rapidi si può testare su utenti o avere un confronto diretto con il cliente.
A livello di tempistiche questo tipo di processo richiede 3/4 cicli per rilasciare la prima versione e un numero potenzialmente infinito per arrivare a quella perfetta (bisogna chiaramente definire con il cliente il livello di qualità desiderato).
Chiaramente il primo ed il secondo ciclo riflettono ancora un po’ le caratteristiche dei modelli a cascata, giusto per porre le basi dei requisiti/desiderata, del design e della tecnica.
Dal punto di vista aziendale vi è un’organizzazione del lavoro completamente orientata all’obiettivo del singolo ciclo, il che significa che un team leader che stimola l’assegnazione dei task e delle milestone alle persone (modello GTD), coordina giornalmente le attività di confronto quotidiane e controlla che le persone siano responsabilizzate sulla qualità del lavoro e il rispetto delle tempistiche.
Personalmente apprezzo questo tipo di approccio sui progetti in quanto si basa sul continuo confronto e la crescita costante del prodotto/servizio. Sono comunque dell’idea che ogni processo vada adattato secondo le proprie realtà in quanto anche l’agile richiede tempi e risorse a volte poco sostenibili nella realtà del mercato locale.
Feed RSS 
