IAD Urbino 2017 – Conferenza 18 Novembre

Keynote: back to basics

Oggigiorno parliamo tutti di agilità. Nel bene e nel male, quasi tutti lavoriamo in realtà che adottano Scrum e le annesse pratiche agili: abbiamo a che fare con P.O., Scrum Master, sprint planning… Insomma, ci sentiamo sul pezzo. Ma siamo davvero sicuri di conoscere la filosofia agile? Perché non fare un passo indietro e rivedere tutti insieme i principi che ne stanno alla base?
That’s why Charlie Poole is here!

Charlie Poole è uno sviluppatore ed agilista della prima ora, con esperienze di programmazione in Cobol, C, C++, C# (a proposito di C#, il framework di unit test NUnit è opera sua 😊).
Fu grazie al mondo agile che, in occasione della prima conferenza sull’Extreme Programming tenutasi ad Alghero parecchi anni fa,  Charlie venne per la prima volta in Italia, innamorandosene. Da quella volta Mr. Poole ha visitato parecchie volte l’Italia, soggiornandoci anche per lunghi periodi; il nostro Bel Pese ha un posto speciale nel suo cuore, tanto da decidere di condurre il suo keynote in italiano! Ebbene sì, con nostro grande stupore, Charlie ha deciso di parlare tutti e 45 minuti a sua disposizione in italiano, non proprio una passeggiata se non siete abituati a parlare una lingua non vostra, per di più di fronte a qualche centinaio di persone. A lui il nostro plauso.

Ma torniamo al keynote. Qual è il cardine della filosofia agile quando lavoriamo ad un software?

Fornire valore al cliente

Secondo Charlie, il software di per sé non ha valore; noi sviluppatori non siamo artisti che produciamo qualcosa di tangibile, non dipingiamo quadri da esporre nei musei. Il software non è “bello”, non è qualcosa da ammirare: l’unico valore che produce è quello fornito al cliente, all’utilizzatore finale, per cui nel team (o “squadra”, come giustamente Charlie ha tradotto il termine) ogni membro deve essere consapevole del valore del prodotto sul quale sta lavorando, e anche come questo valore viene fornito dal software stesso. Charlie ci ha esposto quelli che secondo lui sono i punti da considerare per un ritorno alle basi delle pratiche agili.

Concentrarsi sul valore fornito al cliente

Come scritto prima, tutti noi sappiamo cosa vuol dire praticare Scrum, eXtreme Programming e le varie pratiche annesse. Ma la tendenza è quella di concentrarsi interamente sulle tecniche dimenticandosi dei valori. Ciò che è centrale sono i valori, non le tecniche. A tal proposito, Charlie ha creato un momento che ho ritenuto personalmente emozionante, facendoci ascoltare un piccolo estratto del brano La leva calcistica del ’68 di Francesco De Gregori: “Ma Nino non aver paura di sbagliare un calcio di rigore / Non è mica da questi particolari / Che si giudica un giocatore / Un giocatore lo vedi dal coraggio / Dall’altruismo e dalla fantasia”. Applausi da tutta l’aula magna 🙂

Per un giocatore, i valori sono la fantasia, l’altruismo, il coraggio. E per uno sviluppatore? Quali sono questi valori? Ne possiamo individuare molti, fra cui i classici 5 dell’eXtreme Programming: comunicazione, semplicità, feedback, coraggio e rispetto… Ma tutto sommato anche quelli proposti da De Gregori non sono così fuori luogo.

In particolare, Charlie si è concentrato su alcuni di essi, dei quali ogni membro del team dovrebbe avere la consapevolezza:

• Altruismo: ogni membro del team lavora per il team, il team lavora a sua volta per qualcun altro (cliente)
• Coraggio: conosciamo le capacità di ogni membro della squadra, per cui nessuna paura nel dover prendere decisioni
• Comunicazione: non soffochiamo la comunicazione, sia all’interno del team che soprattutto all’esterno; continuiamo a parlare con il cliente
• Estremismo: Kent Beck affermò che XP è un insieme di pratiche estreme; spesso si fa l’errore di adottare una versione moderata di pratiche agili. Sbagliato!

Riportare valori agili soprattutto quelli riguardanti il lavoro del team

Secondo Charlie è altrettanto importante la natura FRATTALE delle metodologie agili. L’agile è ripetitivo per sua definizione, con sprint planning e meeting giornalieri che si susseguonono con una certa frequenza; questa pianificazione iterativa è molto importante, permette di organizzare meglio il lavoro, e non cadere nella trappola di voler fare tutto e subito. E se in questi momenti di pianificazione considerassimo l’ipotesi di coinvolgere il cliente? Per Charlie è importante avere il cliente sul posto, magari  farlo collaborare per la definizione dei test di accettazione del software. Questo aiuterebbe a mantenere viva la comunicazione e la pianificazione del lavoro, in maniera tale da rilasciare sempre qualcosa che sia allo stesso tempo il più semplice possibile ma che fornisca valore al cliente.

Lo sviluppo dovrebbe essere guidato dai test: Test Driven Development. Tutti sappiamo cosa voglia dire, ma non sempre lo applichiamo. Idem per il refactoring del codice: sappiamo cosa voglia dire, ma dobbiasmo ricordarci che non deve essere fatto solo per “abbellire” il codice: non stiamo realizzando un quadro da esporre nei musei.

Cosa ha voluto insegnarci Charlie in questo keynote? Che va bene, anzi benissimo, adottare l’agilità nel nostro progetto, ma dobbiamo farlo con consapevolezza e coraggio, non dimenticandoci MAI i principi e le sue fondamenta.

Posso solo dire “GRAZIE CHARLIE!”, è sempre importante ricordare chi siamo e da dove arriviamo 😊

Roundtable

Non solo talk ma anche tavole rotonde in questa manifestazione. Dopo alcune domande introduttive sulle modalità operative e sulla storia delle varie comunità, Fabio Ghislandi, che fungeva da moderatore, ha formulato un quesito molto interessante: “Nel mondo dell’Agile da tempo si stanno affacciando tanti attori, più o meno validi: come fare a distinguere il fumo dall’arrosto?”.

Franco Lombardo, rappresentante di TDD Meetup Milano ha cercato di dare una risposta ragionando sui seguenti punti:

• Eccellenza tecnica: continuo esercizio tecnico su TDD e codice non può fare che del bene alla persona, sicuramente meglio rivendibile al cliente
• No alle certificazioni agili: una certificazione ottenuta con un corso di due giorni porta valore solamente all’azienda che la propone. Sì al corso, no alla certificazione
• Definition of failure: in contrapposizione alla “definition of done”, sarebbe utile poter sancire ufficialmente il fallimento di una attività di “agilizzazione”? Rendere dimostrabile il mancato raggiungimento degli obiettivi nell’operato di un consulente agile contribuirebbe non poco a distinguere il fumo dall’arrosto. Come suggerito da Charlie Poole nel suo keynote, estendiamo i test a tutte le fasi del processo.
• Il criterio del nonno: un criterio personale di Franco, ispirato a suo nonno coltivatore di viti ed ulivi. Gli è capitato di partecipare a sessioni, in giornate di conferenze agili, francamente imbarazzanti, da “abbracciatori di alberi”. In quelle occasioni suo nonno avrebbe espresso tutto il suo dissenso nella forma più colorita che potete immaginare 😊. E perché non farne un criterio di riconoscimento del fumo?

Kanban board step by step

Giulio, partner di Intré e CEO di Agile Reloaded, ha curato un talk decisamente interessante sulla kanban board, strumento conosciuto a chi pratica agile ma personalmente non del tutto chiaro. La modalità del talk di Giulio è stata a mio parere vincente…Non le solite slide ricche di sigle e definizioni, ma una vera kanban board che si arricchisce passo passo appunto 😊

Siamo partiti da una semplice constatazione: ogni team deve avere una sorta di lista della spesa, una TO-DO list. Di questa lista di cose da fare, mettiamo in IN PROGRESS le attività in corso e sotto la colonna DONE le attività terminate. Ma i task in progress possono essere suddivisi nei seguenti stati:

• Analyze
  • doing e done
• Work
  • doing e done
• Verifiy
• Done

Tutti i task in uno di questi stati rappresentano un costo, sono dei semi-lavorati; pensiamo alla metafora di un magazzino: sono dei work in “process” (o progress, come siamo abituati a dire). Bisogna quindi fare attenzione affinché non si accumulino le attività in lavorazione.

Ecco quindi che Giulio ci ha introdotto il concetto di WIP limit, o meglio work in process limit. Limitare il WIP è importante! Tornando alla nostra kanban, è bene fissare un massimo numero di attività per ogni stato… Mettere dei numerini. Ad esempio, “Analyze 2” vuol dire che ci devono essere massimo 2 attività (doing + done) nella fase di analisi. Con questo semplice sistema di limitazione dei WIP, capiamo come poter in caso gestire i tanto temuti colli di bottiglia, ricordando che… Sì, si può violare un WIP limit, ma è sempre meglio agire tenendo a mente il seguente principio: “STOP STARTING, START FINISHING”.

Giulio ha poi proseguito spiegandoci come tramite la kanban board si possano misurare i work in progress, magari contando il numero di attività in corso in un certo lasso di tempo. Alcune metriche sono:

• Lead time: tempo trascorso da quando prendo l’impegno su una certa attività (la sposto sotto analyze) a quando la verifico
• Customer lead time: tempo medio per un’attività dal punto di vista del cliente; magari il team sa che ci mette 1 settimana a completare un’attività, ma il cliente la vede effettivamente dopo 3 mesi

La kanban board, man mano si arricchisce, evidenzia diverse tipologie di attività, limiti e stati… A questo punto, perché non mettere in evidenza anche le persone? Giulio ha spiegato come creare un certo numero di avatar per ogni membro del team, così da posizionarli sulla kanban per capire come occupare nella maniera più efficiente possibile la forza lavoro di modo da evitare il più possibile colli di bottiglia…

Ma se dovessero capitare emergenze? Dopotutto, tanto nella vita quanto in un progetto, i problemi ci sono ed esistono per definizione 😊 Gestiamo quindi i problemi nella nostra kanban, magari facendole scorrere su di una sorta di linea preferenziale, e magari categorizzandoli (critical, urgent…)

Come si dovrebbe comportare quindi un team a fronte di un’urgenza?

• Task force: potrebbe unirsi e lavorare all’unisono sul problema
• Creare l’apposito cartellino urgenza e gestirlo magari assegnando l’avatar di una persona meno carica di lavoro rispetto alle altre

Giulio ha poi spiegato come poter utilizzare la kanban board con una granularità temporale più ampia, magari per capire l’andamento aziendale sui progetti per i prossimi mesi, o perfino per organizzare attività extra-lavorative 😊

Grazie Giulio, peccato tu abbia avuto solo 45 minuti perché avremmo volentieri ragionato assieme sulle potenzialità di questo metodo. Vi consiglio di consultare le sue slide – niente paura, sono tante, ma vi assicuro che le troverete semplici e divertenti.

Test automation done “right”

Avendo a disposizione in ogni momento 4 o 5 talk contemporanei, la scelta non è stata facile… Fortunatamente eravamo presenti “in forze” allo IAD e – pur non avendo il dono dell’ubiquità – possiamo raccontare qualcosa anche di talk che si sono svolti nello stesso orario 😉

In contemporanea al talk di Giulio, Wamika Singh presentava la sua prospettiva sul processo di Quality Assurance, partendo dalle lezioni imparate:

• scegliere gli strumenti giusti  – ad esempio imparando il dominio conoscendo gli utenti e le interazioni, valutando i mezzi per coinvolgere gli stakeholders
• automatizzare le cose giuste – sicuramente quelle di alto valore e per le quali il costo del test è basso, probabilmente anche tutte le altre di alto valore, meno tassativamente quelle di basso valore
• automatizzare nel modo giusto

Soprattutto quest’ultimo punto è interessante per i confronti che si possono fare con la propria situazione: stiamo seguendo la Ideal Test Automation Pyramid come descritta da Mike Cohn, o stiamo seguendo uno degli anti-pattern del testing (Ice Cream Cone, Cupcake)?

I terribili “guardiani della codebase”

Paolo D’Incau ha tracciato un inquietante profilo di coloro che ha soprannominato “guardiani della codebase”: persone tecnicamente eccellenti che lottano in maniera solitaria affinché il codice di un progetto mantenga i loro standard di qualità.

Sarà capitato a molti di sentirsi dire (o di trovarsi a dire) cose come “questo non si può fare, l’abbiamo già provato” o “cos’è questa schifezza?” riferite ad un progetto o un blocco di codice. Questi sono campanelli d’allarme di un problema che può mettere a rischio il progetto, l’azienda e la persona stessa.

Nel progetto è a rischio la collective ownership del codice, le persone perdono fiducia ed interesse, le nuove idee sono scartate a priori, e il “guardiano” funge da unica interfaccia verso il cliente.

L’azienda si trova ad avere un single point of failure (se il “guardiano” si ammala o peggio ancora cambia lavoro, il progetto si blocca), mantiene persone esperte e capaci su progetti vecchi e probabilmente poco redditizi, è impossibilitata a far scalare i team.

Infine il guardiano stesso è bloccato: con i suoi atteggiamenti si isola dal team, è stressato e poco stimolato, fino al punto di arrestare la propria crescita professionale.

Un quadro a tinte fosche… Ma Paolo ci ha rassicurato: c’è una luce in fondo al tunnel, e si può uscire dal circolo vizioso. Ha portato come esempio un “guardiano” che conosce molto bene: lui stesso (Colpo di scena!)

Inconsapevolmente, piano piano, si è trovato ad “innamorarsi” di un progetto in cui aveva dato il massimo, portandolo effettivamente a livelli di eccellenza, fino però a considerarlo più importante dei suoi compagni di squadra. Quando si è reso conto della deriva pericolosa, ha invertito la rotta, ripartendo dalle basi: le regole e i valori XP. Ha ripreso a collaborare, lavorando in pair programming, imparando a delegare e ritrovando tempo per sperimentare, aiutando la crescita altrui ma senza forzarla sul percorso seguito da lui stesso (ognuno deve trovare la propria strada), coinvolgendo i colleghi nelle discussioni col business, rendendosi facilitatore delle discussioni e lasciando spazi vuoti che gli altri potessero colmare.

Spunti di riflessione molto interessanti anche per una retrospettiva e un piccolo mea culpa personali: c’è un po’ di guardiano anche dentro di noi che dovremmo tenere a bada?

Let’s talk about the “I” in Agile

Se il talk di Giulio ha riguardato uno strumento, la kanban board, utilissimo per chi vuole lavorare in maniera agile, perché non dedicare del tempo anche al significato che assume la persona in contesto agile? L’Io nell’agilità… Ci avete mai riflettuto? Beh, Johan lo ha fatto per noi 😊

Agile è una parola che può essere utilizzata in vari contesti, comprende tante definizioni. E in un ambiente agile, magari in un progetto agile, ognuno di noi ha un ruolo (developer, P.O., scrum master) e svolge determinate azioni agili. Insomma, in un contesto agile ci sono compiti ben precisi da svolgere da ogni singola persona che copre un ruolo ben preciso Ma cosa funziona in un ambiente non agile? “If you want to know if a team is agile, just look at how they behave” – cioè per capire se un team è agile, bisogna vedere come lavora nel quotidiano. Ma attenzione, per quanto la filosofia agile si basi su un manifesto con determinati principi, va inteso come un PARADIGMA, non un DOGMA. Quindi ognuno di noi deve saper prendere sempre la decisione più corretta, che sia il più agile possibile. Come dice Wil Wheaton, Don’t be a dick !

Ma come possiamo fare a prendere decisioni migliori? Nella vita le scelte sono importanti, qualunque ruolo stiamo ricoprendo. Per un programmatore, la scelta di utilizzo di un if-else piuttosto che uno switch… è importante. Tutti noi, dal programmatore al manager, essendo parte della 4° rivoluzione industriale, con il software presente oramai ovunque nel nostro quotidiano, siamo responsabili in ogni azione che dobbiamo prendere.

Johan ci ha ricordato il principio del rasoio di Occam che nella sua forma più immediata suggerisce l’inutilità di formulare più ipotesi di quelle che siano necessarie per spiegare un dato fenomeno quando quelle iniziali siano sufficienti. Keep stuff simple! E’ importante che si abbia coscienza della differenza tra essere occupati ed essere produttivi. Se facciamo le scelte corrette, sicuramente saremo più produttivi (meno task ma più chiari, focus maggiore su singolo task…). Ma in un team agile, come nella vita, le persone devono essere incoraggiate a fare/prendere la scelta migliore. Magari dando loro una “spintarella” nella direzione corretta… come ce l’ha data Johan citandoci la teoria dei Nudge, grazie alla quale Richard Thaler ha vinto il premio Nobel in economia.

Grande Johan, e non lo scrivo perché sei un amico e un collega 😊, ma perché hai affrontato un talk a suo modo filosofico conducendolo con spirito e leggerezza. Il tutto parlando in inglese. Many many thanks Johan, chi avrebbe mai pensato che basta una spintarella per non fare la figura dello stolto e prendere la scelta agile giusta 😊
Per chi volesse consultare le slide dell’intervento, here you are.

Feedback wall

Per gestire una grande conferenza, ci vuole una parete grande! (per i più anzia… ehm, citazione di un famoso spot anni ’80 😊). Questo è stato il mio pensiero quando mi sono imbattuto nel feedback wall, per gli amici ” il muro dei commenti”, e cioè una serie di fogli uno sotto l’altro, uno per ogni talk, con accanto lo spazio per lasciare le proprie opinioni.

Quale miglior modo per lasciare la nostra critica (positiva o meno), se non con post-it verdi e fucsia da attaccare accanto al titolo del talk appena seguito? E’ stato interessante notare come man mano tale muro si riempisse di commenti, per lo più positivi! Un enorme B R A V A a Marta, una delle figlie di Fabio Ghislandi, per la realizzazione dei cartelloni 😊

Lightning talks à gogo

Al pomeriggio, una delle aule dell’Università è stata riservata interamente a una raffica di brevi talk da 15 minuti… ecco alcuni input che ci siamo portati a casa.

Don’t say you’re doing agile

Matteo ha ricordato una cosa che forse può apparire scontata, ma che a volte è facile perdere di vista: il metodo non è la soluzione.

Un “metodo” è qualcosa che promette risultati immediati (come l’ennesima dieta rivoluzionaria), ma un vero cambiamento invece richiede di concentrarsi sulle motivazioni e di intraprendere un viaggio verso il “perché” che ci spinge (come il volere perdere peso per sentirsi meglio nel proprio corpo).

Partendo da questa riflessione valida in generale, come possiamo tradurla nella pratica quotidiana del lavoro, soprattutto in ambienti che potremmo definire “anti-agili”? È semplice: invece di aspettare il benestare dall’alto per introdurre dei cambiamenti definendoli con nomi che a volte incontrano resistenza (sprint, prototipazione, team cross-funzionali, …), possiamo essere noi i motori del cambiamento, mostrando in prima persona un modo di lavorare diverso.

Senza bisogno di usare etichette per ogni caso, portare un esempio positivo ed indurre naturalezza può essere un potente mezzo per condurre verso una strada che riteniamo migliore, nel lavoro come nella vita.

Quando Scrum ti va stretto

L’esperienza di Andrea con Scrum è da lungo tempo positiva (non per nulla è consigliere di IAM), ma anche in un team che funziona bene, è sempre possibile trovare margini di miglioramento.

In particolare, il team di Andrea aveva la necessità di integrare nella propria attività dei momenti di crescita tramite studio e sperimentazione.

Un interessante aspetto della loro soluzione è stato l’adozione del popcorn flow come possibile mezzo di sperimentazione.

Il collante strategico durante lo sviluppo: continuous discovery

Alessandro ha raccontato il percorso del proprio team verso dual track agile, in cui il lavoro del team procede attingendo a due backlog paralleli: un Discovery track (con obiettivi di learning) ed un Delivery track (relativo ai deliverables del progetto).

Il discovery track permette al team di sviluppo di avere sempre chiaro lo scenario delle necessità del software che si sta sviluppando, consentendo di prendere decisioni corrette a vari livelli, fra le quali la scelta di popolare il backlog di delivery con le storie di maggior valore in ogni momento.

Ovunque Agile

“Agile ovunque è cercare il feedback per indursi al cambiamento intenzionale” – questa la conclusione di Paolo, che l’ha supportata con numerosi esempi.

Dal progetto di una macchina ecologica a quello di un caccia da guerra, dal cambiamento della propria alimentazione e stile di vita fino alla scrittura di un libro, le tecniche agili si possono applicare con successo in un gran numero di sfide.

Retrospettiva con gli Story Cubes

Rory’s Story Cubes: un giocattolo che stimola la creatività e l’interazione… Proprio le qualità che possono rendere eccellente il lavoro di un team ed in particolare una retrospettiva. Spiegando brevemente: si tratta di lanciare 9 dadi che riportano immagini di vario tipo, ed utilizzarle come spunti per costruire insieme un racconto. Il “raccontare per immagini” porta con naturalezza ad un coinvolgimento emozionale.

Simone ha esemplificato come sia possibile usare questo strumento in fase di sprint retrospective, creando insieme una storia che rappresenta alti e bassi dello sprint.

Il metodo può funzionare più o meno bene all’interno di un team.

Pro:

• rende più rilssato l’ambiente
• stimola i contributi di tutti (ognuno è tenuto a giocare)
• evita la “standardizzazione” della retrospettiva
• aiuta a far emergere i problemi
• la disponibilità di tre set di dadi (basic, voyage, actions) permette di adattare il gioco a diverse fasi della retrospettiva (ad esempio il set “actions” può essere più adatto quando si discute cosa si vuole cambiare dal prossimo sprint)

Contro:

• alcune persone possono non trovarsi a proprio agio con questo metodo più “creativo” del solito
• c’è una componente di casualità che può indurre una certa sfiducia
• non è facilmente replicabile con team numerosi o non co-locati

Molto interessante, sicuramente da provare!

UX, scrum… e gilde

Eccoci ad una delle sessioni più attese, una fra quelle a chiusura della giornata. Emanuele Mantovani, collega nonché Head of Design di Intré e di Thanks Design, ha voluto raccontare la sua esperienza in Intré, esperienza che da qualche tempo lo sta portando alla ricerca del miglior connubio fra Scrum e UX design.

Che cosa si intende per UX design? Un insieme di discipline per la progettazione di prodotti, fisici e digitali, incentrati sull’esperienza utente.

Emanuele, o meglio Ema 😊, ci ha spiegato cosa si intende per valore nel mondo della User eXperience.

• Utilità: il prodotto è davvero utile per l’utilizzatore finale?
• Usabilità: il prodotto è usabile?
• Piacevolezza: quanto è soddisfatto il cliente del prodotto?

E come lavora uno UX designer? Si pare da un’ipotesi iniziale, che deve tenere conto dei valori sopra citati nonché della fattibilità, e si arriva ad una sua valutazione, dove se ne testa la reale bontà ed efficacia.

Tornando al mondo agile, Emanuele ha poi spiegato quale possano essere le modalità per uno UX designer di lavorare con un team.

• UX designer esterno con waterfall: produce l’intero design del prodotto, che poi viene passato al team di sviluppo. Approccio molto rischioso, possono esserci dei vincoli tecnologici che porterebbero a change request per rifare parte del lavoro… Si dovrebbe tornare indietro nel processo. Questo porterebbe a dover generare ulteriore documentazione, e soprattutto non si può verificare la qualità del prodotto con gli utenti.
• UX designer esterno e parallelo: il designer lavora parallelamente al team di sviluppo, con una modalità “a chiamata” ovvero quando c’è bisogno di intervenire lato UX del prodotto. Rischioso perché il designer non è coinvolto nella pianificazione, portando a sottostime delle sue attività e anche ad una perdita del valore della UX.
• UX designer interno al team Scrum: lo scenario migliore in quanto il designer supporta il P.O. nelle scelte progettuali. Inoltre si avrebbe la possibilità di verificare costantemente con gli utenti ad ogni rilascio incrementale del prodotto.

Partendo da quest’ultimo scenario, Emanuele ha spiegato come l’iterazione non è design! Non va bene partire da un’idea o certezza di un P.O. che prima o poi porterà ad un qualcosa… Meglio invece che da un’idea si pensi ad una strategia che poi dovrà essere validata. UX e Scrum quindi 😊 Rispetto agli sprint del resto del team, il designer lavora con uno sprint di anticipo così da consegnare agli sviluppatori qualcosa di concreto, fattibile. Durante lo sviluppo ci  dovrà essere continua comunicazione tra designer e sviluppatore ed occorrerà trovare momenti di validazione con gli utenti di quanto prodotto.

Emanuele ha spiegato un po’ più nel dettaglio le fasi del lavoro del designer nei vari sprint, spiegando dapprima la fase di starting dove, assieme agli sviluppatori e al P.O. si identificano le finalità del prodotto e il target di riferimento e attraverso la user research si formulano le macro ipotesi. Allo sprint 0 invece lo UX team si dedica all’architettura informativa e alla creazione dei wireframe. Questo farà da bussola per tutto il team. Gli sprint successivi saranno dedicati allo sviluppo incrementale di UI, HTML, CSS.

Tutto molto interessante 😊, ma cosa c’entra quella “GILDA” nel titolo del talk? Nell’ultima parte del suo talk, Emanuele ha spiegato come grazie ad Intré ed alla opportunità che ha dato (e che continua a dare) di organizzazione in gruppi di studio chiamati GILDE, lui ed i suoi colleghi designer abbiano sviluppato un metodo progettuale denominato Design Eye , metodo che a tutt’oggi utilizzano in tutti i progetti nei quali sono coinvolti.

Aspettative ampiamente soddisfatte! Emanuele ha aiutato a fare luce sul misterioso mondo di quelli che spesso chiamiamo grafici…C’è molto di più 😊 Semmai voleste dare un’occhiata alle slide…

Conclusioni

Stanchi ma soddisfatti, ce ne torniamo ognuno alle nostre città e vite (sì, è arrivata gente da diverse parti d’Italia… e oltre), memori di aver goduto di una 2 giorni di conferenze molto ben organizzata e con talk di qualità. Un BIG THANKS a tutti i volontari di IAM, agli sponsor che hanno permesso la realizzazione dell’evento, all’Università di Urbino.

Ultimi ma non per importanza, vorrei girare un high five ai ragazzi della quarta liceo dell’istituto d’istruzione superiore Raffaello di Urbino, che hanno dedicato parte del loro weekend (e sappiamo tutti quanto importante possa essere un Sabato per un adolescente 😊) per la buona riuscita di questo evento.

Ai prossimi appuntamenti agili!