Se conosco il significato della parola “Agile” nel mio settore, lo devo in primissima battuta a Lorenzo Massacci, che sta facendo un enorme sforzo insieme alla sua azienda per passare da un metodo di lavoro prevalentemente classico (“a cascata”) a quello agile. Dato che lavoro con loro per quanto riguarda il design dell’interfaccia e l’usabilità dei progetti web, Lorenzo ha investito diverso tempo anche con me e mi ha invitato a partecipare a due eventi: il 18 novembre a e-xtrategy incontra xpug Marche e il 20 a Bologna all’Agile Day 2009. Per me sono stati due occasioni importanti, quindi mi scuso se questo post sarà un po’ lungo.

e-xtrategy incontra xpug Marche.

Le slide dell’incontro potete trovarle qui: http://www.slideshare.net/extrategy/extrategy-incontra-xpug-marche. Ho iniziato a mettere nella mia lista dei desideri anobiiana un paio di libri e dovrò fare un bello sforzo per imparare anch’io a usare questo metodo fin dall’inizio di un nuovo progetto. Da quando e-xtrategy lavora così, uno dei punti critici è rapportarsi con professionisti esterni che non possono muoversi negli stessi modi. Se voglio migliorare la qualità del mio rapporto con loro e in generale con chi sviluppa software, è indispensabile che provi a fare anch’io questo salto. A me sembra che un approccio agile costituisca un cambiamento radicale per l’azienda e il cliente. In questi primi mesi, nel mio piccolo ho potuto toccare con mano alcuni dei molti aspetti positivi di questa metodologia (le slide di e-xtrategy sono molto esaurienti in questo senso). Per ora trovo che l’ostacolo più difficile sia quello culturale, perché la fiducia tra cliente e fornitore diventa fondamentale per portare avanti un progetto, in modo proficuo per entrambi.
Intanto, ho trovato diverse slide in cui si parla di agile design e user experience:
http://www.slideshare.net/Cennydd/getting-real-about-agile-design-arial
http://www.slideshare.net/pieterj/agile-design-the-fabrique-way
http://www.slideshare.net/alicetoth/ixdaagileforweb

Agile Day 2009.

Quella di quest’anno è la sesta edizione dell’Agile Day. Ho approfittato di una giornata di ferie per salire in macchina con Lorenzo e Giorgio e fare la mia prima presenza all’evento. Ho seguito le sessioni più teoriche, perché nelle altre i programmatori e gli sviluppatori parlavano una lingua segreta, per me :)

Ho ascoltato Peter Stevens, Antonio Brandolini, Jacopo Romei, Francesco Fullone e Cristiano Rastelli. Ho avuto qualche perplessità sul discorso iniziale di Stevens, dovrei leggermi bene il manifesto agile per capire a fondo le esperienze di Jacopo e non ho le capacità di capire la profonda conoscenza di php di Fullone. Perciò ammetto che ho trovato più adatte a me le presentazioni di Brandolini e di Rastelli, che mi hanno regalato qualche perla di saggezza, valida anche fuori da questi contesti.

(visto quello che scriverò tra un po’ in merito al discorso di Rastelli, l’espressione di Lorenzo in questa foto mi sembra particolarmente adatta :D)

Il problema della qualità è tornato più volte durante la giornata e Antonio Brandolini ha tentato di analizzarlo insieme al pubblico, durante la sua presentazione “Possiamo fare di meglio” (che personalmente mi ha molto divertito). Antonio ha portato diversi esempi pratici in cui noi per primi non abbiamo fiducia e non diamo il meglio. Mi hanno colpito due punti della sua presentazione:

• la semplicità è una risorsa: “Le persone fuggono la complessità come la peste. Provate a entrare nel dettaglio di una discussione e, tempo 30 secondi, avrete perso il vostro pubblico”.
• la qualità non è contrattabile: quando si sa scrivere del buon codice, non si può pensare di abbassarne la qualità per stare dentro a un preventivo. … e questo posso dire che vale un po’ per tutte le professioni.

Brandolini cede la parola al pubblico.

Ho notato che spesso il discorso sulla qualità si è intrecciato con quello dell’usabilità del software. In una pausa tra i vari talk, ne abbiamo discusso un attimo con Lorenzo e Francesco Trucchia (che ho avuto il piacere di conoscere personalmente).

Nella sua mezz’ora di presentazione, Cristiano Rastelli ha detto diverse cose che sento molto vicine:

• nonostante il gran numero di metodi e strumenti utili, il lavoro del grafico ha bisogno di un momento di respiro perché l’idea giusta può venire anche sotto la doccia. Paper prototying, wireframing, tecnica del pomodoro e… l’ultimo che ho sentito ieri dal blog di Jacopo Romei è il Pair Design. Io credo che tutti questi strumenti possano andare bene, ma c’è un momento in cui il designer deve raccogliere i pensieri e immaginarsi lo stile, il gusto, i colori, l’appeal grafico dell’interfaccia. E in quel momento non ci sono pomodori che tengano: un’idea può venire in 5 minuti come dopo due giorni di pausa. Per me, questi momenti “sacri” sono la fase di ricerca e la prima bozza di homepage (e se qualcuno mi interrompe proprio lì…). Dopo che ho avuto il mio tempo, posso discutere con tutti, sistemare, rivedere, aggiustare. Si può anche ritoccare la grafica, avendo il rispetto e la fiducia per l’occhio neutrale che ha una seconda persona. Lo abbiamo fatto in questi giorni con Ale, davanti alla pagina coming soon per Dolcevita. Man mano che lavoravo alla grafica, Ale mi anticipava vari suggerimenti, risparmiandomi tempo e correzioni.
• più che le persone, si possono controllare i processi che seguono. Con questa perla, Cristiano mi ha riportato davanti agli occhi queste slide che avevo visto durante un breve e interessantissimo talk all’IA Summit 2009 di Forlì. È qui che vedo il futuro (meglio, il presente) in cui ci stiamo muovendo e la logica con cui si possono pensare le nuove interfacce, grazie ai nuovi device e alle nuove tecnologie.

Cosa mi resta.

Il mondo degli sviluppatori mi atterisce – lo confesso. Quando i discorsi tornano a essere “umani” e non “informatichesi”, mi rimane la sensazione di uno sforzo incredibile da parte loro, e cioè tradurre in un linguaggio comprensibile, usabile e utile una cosa che è del tutto misteriosa, come il codice, il design di un sistema, un software. A una figura come la mia, gli sviluppatori chiedono di trasformare i loro software in sistemi piacevoli e facili da usare, per non mandare in fumo gli sforzi fatti. Ho visto che esistono molti, moltissimi tools e metodi già pronti, devo solo scegliere quali usare e come. Il viaggio che ho iniziato mi sembra quello giusto. Il mio unico timore è quello di infilarmi troppo profondamente in un discorso tecnico, strozzandomi con le procedure e perdendo di vista la creatività, che è e resta il cuore del mio lavoro. Se voglio stare al passo, la soluzione resta sempre quella: un pezzetto alla volta, provare gli strumenti e poi selezionarli, prendere confidenza con quelli più adatti a me, e… ascoltare, lavorare, spiegare, studiare.