È da diverso tempo che con alcune persone parlo di come l’esperienza d’uso e lo sviluppo debbano trovare più relazioni intorno al concetto di “agilità”.

Specialmente con Jacopo negli ultimi tempi ci siamo confrontati sugli aspetti più disparati (processo, metodi, strumenti) e alla fine siamo giunti alla conclusione che l’ideale è allargare la discussione a tutti

Per questo motivo siamo lieti di annunciare che (probabilmente) il primo barcamp del 2009 sarà il primo dedicato alla progettazione e allo sviluppo agile: l’AgileCamp 2009

La data prevista è il 17 gennaio e la sede è quella di Sketchin, siete tutti i benvenuti

Sono appena arrivato a San Francisco e ho colto l’occasione del viaggio per riflettere un po’ su un intervento sull’agile design che ho seguito durante il Web 2.0 Expo di New York.

Seguire un design e uno sviluppo agile è il modello che ritengo in assoluto più affascinante per chi punta alla qualità. Un processo rapido e focalizzato al risultato che permette specialmente nel nostro settore di creare prodotti innovativi e funzionali in un modello crescente.

Insomma una vera e propria panacea per molti progetti dal punto di vista teorico ma che nasconde a mio vedere una serie di inconvenienti dal punto di vista della sostenibilità nel nostro mercato sud europeo.

Il punto è che i processi agili richiedono il coinvolgimento di figure di alto livello che collaborano tra di loro in periodi contigui di forte concentrazione.

Questo significa ottenere in tempi brevi prototipi o prime versioni funzionali del prodotto dalla qualità eccelsa e perfettamente in tempo per il mercato, ma, significa anche bloccare completamente interi team di progettazione e sviluppo per tempi medio-lunghi (si parla di avere prodotti pronti al lancio in 2 cicli / 4 settimane ma completi e di ottima qualità dopo qualche mese).

Non è da nascondere che nel nostro mercato non sempre si punta alla qualità e che i clienti chiedono spesso una chiusura del progetto in tempi brevi e con costi contenuti.

Questo cozza nella pratica di tutti i giorni con la pratica definita precedentemente e succede così che chi fa “agile” si trova strozzato in pochi cicli, in tempi impossibili o semplicemente deve affrontare più progetti “mediocramente” perchè non ha i fondi per affrontarne uno “seriamente”.

Alla fine il risultato è sempre lo stesso: il prodotto è incompleto o di scarsa qualità

La domanda che dunque mi pongo è bisogna cambiare la mentalità della clientela/mercato portandola a comprendere i vantaggi di questi processi oppure identificare nuove strade che intermedino il tutto?