Più realisti del re: l’Agile UX secondo gli sviluppatori

Nell’ordine Alberto, Gianandrea e Davide mi hanno segnalato questo articolo di Jakob Nielsen, tonicissimo guru della progettazione dell’esperienza utente (User eXperience), dell’usabilità e dello user centred design. Lasciando i commenti più specifici a chi di UX se ne intende assai più di me, ho letto con molto interesse il report di Nielsen, a valle delle molte esperienze e discussioni che ho vissuto al riguardo in questo 2009 che volge al termine e di cui hai potuto scorgere alcuni riflessi tra le pagine di questo blog.

Voglio condividere però il mio punto di vista, senza dubbio centrato sullo sviluppo agile, nel più ristretto ambito di soli due punti esposti da Nielsen.

Primo punto: risulta che il grado di soddisfazione dei partecipanti allo studio fosse leggermente più alto con metodi meramente iterativi piuttosto che anche agili. Trovo questo dato perfettamente in sintonia con quanto ho affermato più volte quest anno sul tema delle metodologie agili usate insieme allo user centred design. Gli interaction designer mancano ancora delle tecniche, degli strumenti – meno – e dei principi culturali – di più – per avere un approccio al proprio lavoro che li sostenga nell’abbandonare i propri semi-lavorati, i deliverable già creati. Quindi, pur percependo forte il valore dei processi agili, trovano ancora più confortevoli i metodi semplicemente iterativi, i quali, ovviamente, sono vissuti già come rivoluzionari da chi abituato a lavorare waterfall.

Secondo punto:

Developers rated the user experience impact on the deliverable’s quality at 4.3, whereas UX people rated it at 4.0 (again on a 1–5 scale, with 5 best). Developers said productivity increased somewhat with UX involvement (3.3), whereas UX rated this only slightly higher at 3.4.

La mia esperienza di progetti con un forte orientamento all’utente, con specialisti UX inseriti nel team, è stata altrettanto positiva. Io vedo l’attività degli interaction designer come un preziosissimo supporto alla scrittura delle user story e mi fa piacere vedere come questo valore sia percepito dagli sviluppatori in modo perfino più forte che dagli interaction designer stessi!

Ho imparato a ritenere la fase della scrittura delle user story una delle più cruciali – se non la più cruciale – per la buona riuscita di ogni progetto. Sei consapevole del valore di requisiti non solo ben espressi, ma anche già confezionati in un formato che supporti il team nella fase di sviluppo? Ti è chiaro come l’attività centrata sull’utente sia un grimaldello precisissimo per violare la serratura troppo spesso chiusa della riduzione razionale dello scope, del controllo del budget e, in ultima analisi, del successo del tuo progetto?

November 12 2009 | Dalle trincee | 3 Comments »

Convergenze

Antonio Bonanno. Cliente. Oggi, nel bel mezzo di una giornata di sviluppo agile con Extreme Programming:

ho capito che l’unica cosa da fare è segare le cose in più sennò non ci si capisce più niente

Potrete saperne di più all’AgileCamp2009, dove lui stesso terrà un talk dal titolo chiaro, chiarissimo: Il cliente agile.

Nel frattempo… quante soddisfazioni!

January 14 2009 | Dalle trincee | 1 Comment »

Lo user centered design ed il valore per il cliente nello sviluppo agile

Tempo fa promisi una risposta ad un post di Alberto in cui lui esponeva parte di alcune nostre elucubrazioni sulla differenza fra ciò che vale per l’utente e ciò che vale per il cliente. Finalmente ho avuto il tempo di… disegnare i diagrammi! :)

In buona sostanza il diagramma che preferisco contrapporre a quello da lui pubblicato è questo

La peiorità delle user story in base al valore per il cliente e al rischio

Peraltro lo stesso Alberto in un altro suo post discute anche questo approccio.

Nelle metodologie agili, ed in particolare in Extreme Programming, si prende come obiettivo il valore realizzato per il cliente – inteso come colui che possiede il sistema finale e ne finanzia lo sviluppo, mentre nella disciplina dello user centred design i bisogni, le volontà e le limitazioni dell’utente finale sono poste al centro dell’intero processo di progettazione.

Mentre si potrebbe pensare in un primo momento che gli interessi dell’utente siano sempre coincidenti con gli interessi del cliente, che immaginiamo tutti puntare ad ottenere un pubblico soddisfatto, un’analisi più approfondita mostra immediatamente che le cose non sono così semplici. Esistono cioè casi in cui il cliente ha degli obiettivi diametralmente contrapposti alle esigenze dell’utenza del sistema. I sistemi di e-commerce sono spesso contraddistinti da questa contrapposizione, mentre le community online vedono un maggiore allineamento fra interessi del cliente e dell’utente.

Nel diagramma sopra quindi, benché il valore per l’utente di una feature non sia mai trascurabile per calcolarne il valore per il cliente, abbiamo una rappresentazione troppo semplicistica della realtà che, effettivamente, viene a galla in fase di assegnazione delle priorità delle user story.

Direi quindi che questo diagramma possa essere considerato più fedele al vero

Le priorità delle user story in base al valore per l'utente e al rischio su un piano ortogonale al precedente comunque indicato

Come si vede il valore utente, se considerato, deve esserlo in maniera in linea di principio indipendente dal valore per il cliente o cmq in correlazione controllata ovvero consapevole.

I due piani ortogonali e il diedro da essi individuato

Quanto le due metriche di valore siano correlate tra loro è quindi dato, in questa rappresentazione, dall’angolo formato dai due piani individuati: il primo che pone in relazione le priorità delle user story con il valore per il cliente, il secondo che pone in relazione le priorità delle user story con il valore per l’utente. Minore l’angolo formato dai due piani, maggiore la concordanza tra le due assegnazioni di valore e la conseguente corrispondenza di assegnazione di priorità.

Quindi, in relazione ulteriore, possiamo porre la coincidenza di interessi tra clienti e utenti

La intersezione utente-cliente delle features va massimizzata

e arrivare ad una morale conclusiva: se il design delle applicazioni ancora soffre troppo spesso di rigidità di processo, mentre le metodologie agili non forniscono veri e propri strumenti per la progettazione macroscopica delle stesse applicazioni, il vero sforzo da compiere nei prossimi anni è quello di far convergere i due mondi, individuando metodologie che sappiano da una parte accogliere il cambiamento senza waterfalliane eredità, dall’altra produrre e sostenere la vision di ogni progetto.

Come a dire: ok, con le user story sappiamo cosa farci, ma una metodologia di spessore per scriverle non sarebbe bello averla? Con Luca lo scambio a tal proposito è nel vivo…

November 14 2008 | Esperti | 3 Comments »

User story: mai senza il cliente!

Più che un post uno sfogo. Voglio promettermi che non lascerò mai più scrivere user story in assenza del cliente o di un suo adeguato rappresentante! Non senza aver almeno protestato!

Si finisce sempre per buttare la prima stesura e rifare tutto da capo. Lavorare due volte per fare una cosa sola è uno spreco e, soprattutto, abbassa il morale del team.

Non devo farlo accadere più. Oh.

October 29 2008 | Tutti i miei sbagli | 2 Comments »

Priorità a Milano

Ciao! Ritorno a pubblicare sul mio blog dopo un’intensa estate di lavoro, purtroppo con brevissime ferie – sebbene intensissime – e il ritorno al lavoro per un settembre caldissimo.

Tra gli altri settembre mi ha portato anche sulla scena di un interessantissimo planning game da facilitare per un progetto basato a Milano la cui strategia è curata al momento da Alberto. Come quasi sempre in questi post riguardanti i primi passi di un progetto purtroppo non posso entrare nei dettagli, ma voglio cogliere l’occasione per darti al volo l’idea dell’atmosfera che caratterizza tipicamente queste nostre sessioni. continue reading »

October 07 2008 | Dalle trincee | No Comments »

Due giorni di sviluppo agile – Prima parte

Con estremo piacere ho avuto la fortuna all’inizio di questo luglio di avviare un progetto in ideato al fianco di persone che stimo moltissimo come Francesco Trucchia, Alberto Mucignat e Francesco Fullo Fullone.

Il progetto è molto interessante e purtroppo non potrò rivelarne i dettagli. Nonostante questa limitazione però ho ritenuto interessante documentare le fasi del processo di progettazione e sviluppo per rendere l’idea, l’atmosfera che caratterizza il nostro modo di lavorare. continue reading »

July 19 2008 | Dalle trincee | 2 Comments »

Individuare user story e task adatti al planning game

Una delle problematiche principali del software project management è l’ordinamento degli obiettivi e dei task relativi. Ci sono delle cose da fare prima e altre dopo, mentre nel frattempo dobbiamo essere in grado di dimostrare responsabilità da una parte e progressi concreti dall’altra. L’extreme programming non ci risparmia questa difficoltà, pur mettendo a nostra disposizione strumenti – come il planning game – atti ad analizzare queste problematiche e a sostenere le decisioni del team.

continue reading »

June 20 2008 | Esperti | No Comments »

User story e taglio dei problemi nel planning agile

Nello scorso aprile ho prestato la mia opera di coach agile per un team di sviluppo Ruby On Rails impegnato nella costruzione di un nuovo social network. Abbiamo avuto poche criticità, e sono piuttosto soddisfatto della qualità del project management lungo quelle 4-5 settimane di lavoro.

Ciò nonostante credo di aver commesso alcuni errori da cui imparare l’ennesima lezione.

Uno dei principi del planning agile è quello di alzare la priorità delle user story ritenute più rischiose in fase di stima. Questo perché sono quelle storie che celano più problemi in agguato e sono quindi le storie su cui avere feedback al più presto per avere il prima possibile occasione di ridefinire le stime, i tempi, il lavoro da fare e le scadenze.

Certe volte è difficile assicurarsi che le cose vadano così. I motivi possono essere molti e immagino di non riuscire nemmeno ad immaginarli tutti. Nella situazione in cui mi sono trovato recentemente – e che motiva questo articolo – gli impedimenti a questo tipo di organizzazione sono stati principalmente di due tipi:

  1. ostacoli legati al contesto politico in cui si muoveva il progetto
  2. ostacoli correlati alla propedeuticità tra storie

Le poche criticità che abbiamo dovuto affrontare sono state dovute a questo tipo di cause.
continue reading »

May 11 2008 | Tutti i miei sbagli | No Comments »