Scritto il 23/11/2008 a proposito di WebDev - 10 Commenti
Ringrazio tutti quelli che sono venuti al mio intervento su Agile UX al RomeCamp2008.
Ecco le slide e il video del mio intervento, grazie all’ottimo lavoro di Dolmedia e Il Cannocchiale.
Grazie a tutti per l’attenzione e per la discussione che è nata alla fine dell’intervento.
Tag: agile, agile ux, romecamp2008, User experience, ux, uxd
Mi chiamo Alberto Mucignat, vivo a Roma e faccio lo User Experience Designer, ovvero mi occupo di progettare siti e servizi web efficaci e facili da usare.
Per questo ho fondato Doralab, azienda che si occupa di progettazione della user experience, user-centered design e usabilità.
Nel tempo libero mi dedico alla natura: arrampico, vado in mtb e mi piace esplorare posti sconosciuti.
Contatto Skype: alberto.mucignat
Mail: [email protected]
- Prima di scrivermi leggi qui
- Scambio link, no grazie!
Seguimi su Twitter
Segui i post del blog (feed rss)
10 commenti ↓
Ciao Alberto,
ti faccio una domanda che avrei voluto fare se fossi stato li ad ascoltare il tuo intervento.
Che differenza c’è tra l’AGILE UX e l’extreme programming (XP). 2 comandamenti dell’XP recitano che bisogna sviluppare insieme al cliente e rilasciare molti prototipi dell’applicazione. In sostanza è la stessa cosa che afferma l’AGILE UX!?
Ciao,
Paolo
lo user-experience design è nato per prototipare e comunicare il design, prima che il software.
oggi infatti non si tratta (solo) di sviluppare software, ma anche di riuscire a rendere visivamente delle operazioni spesso complesse, per questo sono nate discipline come l’architettura dell’informazione, l’interaction design, il visual design, etc.
agile ux cerca di mettere assieme le due discipline, ovvero il design e lo sviluppo, che prevedono appunto competenze e attività diverse.
Incredibilmente affranto ancora 3 giorni dopo l’evento, non credo mi perdonerò mai di essere arrivato tardi per questo talk.
Ho visto il video e ho solo un paio di considerazioni, da aggiungere alle mille già fatte insieme e alle tremila che faremo in futuro:
- la questione sui software di gestione progetto credo sia… come dire… una falsa questione: nei sistemi di gestione progetto seri io posso dare visibilità diverse ad artefatti diversi per ogni diverso utente, quindi chi non ha bisogno di – per esempio – svn non lo vedrà e chi ne avrà bisogno lo vedrà. E così per tutte le altre features. Quindi non accolgo con favore la duplicazione dell’ambiente di gestione, che sto peraltro sperimentando su un progetto in questo momento e trovo davvero fastidiosa (“dove stava quella info? di qua? di là? boh”) oltre che in opposizione ad uno dei miei principali valori di progetto: la trasversalità dell’informazione. Che poi basecamp in quel poco che fa sia certamente il migliore, è un altro discorso… al limite allora: cosa aspettano a farne uno strumento completo???
- il team separato e distribuito è un’aberrazione dei nostri tempi, sempre e cmq. Il fatto che si siano individuati strumenti anche molto potenti per mitigarne gli effetti negativi sulla vita di un progetto – e sai quanto io stesso li usi – non toglie nulla ad uno dei pochi valori positivi che decenni di industria della proprietà intellettuale ci hanno insegnato: tutti insieme, al limite separati solo da un muro fra due stanze diverse, è meglio. Sempre.
In entrambi i casi lo spirito è lo stesso: comunicare, comunicare, comunicare; feedback, feedback, feedback.
Ciao!
jacopo, mi spiace che lavorando assieme tu non abbia ancora chiaro quale sia il problema di un software
il problema non è quello di avere o no delle features, di potere o meno configurare un software come si vuole. questo è possibile farlo da tempo immemore su moltissimi sw. il problema semmai è di avere qualcosa di orientato agli utenti che lo utilizzano. e non è solo un fatto di usabilità, ma di “strategia del sw” che, mi rendo conto, è un concetto sfuggente, ma importante.
la soluzione ipotizzata (duplicazione dei sw) è appunto a favore di due esigenze degli utenti: quella di gestire la comunicazione tra team e cliente e quella di gestire la comunicazione all’interno del team di sviluppo. se ci fosse la possibilità di avere tutto in un’unica piattaforma con una “strategia sw” intelligente, ti direi che va bene, ma oggi non c’è. e siccome viviamo in un mondo reale dobbiamo essere pragmatici.
il mio consiglio in questo caso è: siccome un software omnicomprensivo alla fine rischia di riportare la comunicazione alle email (!), preferisco utilizzare 2 software, anche se il team deve fare uno sforzetto. per me, in questo caso, vince il cliente, perchè un errore di comunicazione all’interno del team è facilmente risolvibile, mentre un errore di comunicazione (o di percezione) col cliente può portare a problemi irreparabili.
ripeto: non sono convinto che sia una soluzione giusta: anche per me sarebbe importante avere un unico “punto di comunicazione”, ma se alla fine il risultato è che l’utente più importante non lo utilizza, allora io sono per cambiare strumento.
sul team unico, in un’unica stanza, tutti assieme dall’inizio alla fine, sono daccordo in linea di massima, ma fino a un certo punto:
1. un esterno, spesso e volentieri, porta un punto di vista diverso, più “fresco”, che non solo è importante, ma è NECESSARIO per la salute di un progetto
2. non viviamo in un mondo ideale, quindi se la realtà sono i team distribuiti non possiamo prescindere da questo, anzi diventa una “condizione di contorno” che quindi dobbiamo affrontare non dicendo “vorrei il mondo ideale”, ma chiedendoci: “come la gestisco?” (era questo il senso della mia domanda).
cmq è sempre un piacere discutere con te, magari anche dal vivo, se la prossima volta arrivi puntuale (ok ok, non te lo dico più
aggiungo un’ultima cosa. la mia esperienza è che il team di sviluppo spesso sceglie un software dicendo “questo è quello che ci serve perchè fa tutto”, ma la spiegazione vera è che fa sicuramente quello che serve al team di sviluppo (svn, trac, tasks, etc), con in più alcune funzionalità di comunicazione (che però difettano nell’approccio alla comunicazione, nella strategia), che vengono configurate in fretta e senza troppa accuratezza.
forse il punto è proprio (solo) questo.
Concordo e ribadisco: Basecamp è insuperabile.
Concordo e ribadisco: se il team NON PUÒ essere co-locato allora t’arrendi.
“Le guerre si vincono con l’esercito che hai non quello che vorresti” (cit. Napoleone Bonaparte)
Se il problema dell’esternalità dei contributi è vero… beh…. cambia collaboratori!!!
Scherzo.
Sono _io_ un tuo collaboratore! 
Scherzi a parte, mi chiedo solo che danno farebbe agli utenti “cliente” se solo gli utenti “sviluppatore” vedessero qualche tab in più nel menu di navigazione di Basecamp (per esempio)? Quello che non vedi esistere di fatto… non esiste! E quindi verrebbe rispettato il Principio del Minimo Set di Funzionalità.
Ciao ciao.
si, sul minimo set mi pare che ci siamo. il mio dubbio è che un sw nato per fare una cosa (o nato da sviluppatori) è poco orientato (strategicamente) alla comunicazione, in ogni caso.
ma questa è materia per un altro post, l’importante è che per ora ci siamo chiariti
ps: napoleone docet, quella massima è mia da tempo.
[...] proposito del problema “usare 2 software di PM anzichè uno“, interessante questo SpringLoops che integra svn, i task, etc (e nell’etc c’è [...]
[...] Entrambi i punti li avevo toccati nella mia presentazione su agile ux a Roma. [...]
[...] (slide 12) è quello di iniziare con una fase di discovery (quella che in passato, nel mio talk su Agile UX, avevo definito “Iteration 0″) che aiuti a creare un embrione del prodotto. Questa [...]