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 »

Stimare la project velocity alla prima iterazione – Prima parte

Circostanza frequente: team agile approntato, progetto intrapreso secondo la metodologia preferita (extreme programming o scrum o entrambe o…), hai terminato di stimare le user story, hai assegnato le dovute priorità insieme al resto del team e ora devi approntare un release plan che permetta di capire per quanto ne avrete. “Facile!” esclama il giovane agilista, “Basta prendere la somma degli story point e dividerla per la velocity del progetto!”. Senza dubbio corretto in linea di principio – e comunque non è mai così semplice nella pratica – ma soprattutto: alla prima iterazione che valore di velocity userai? Tu e il tuo team non avete mai lavorato su questo progetto, non hai dati retrospettivi su cui contare. E quindi? Affiderai tutto al caso?

Assolutamente no, ci sono delle tecniche per (aiutarci a) sciogliere questo nodo e voglio illustrartene qualcuna.

continue reading »

October 16 2008 | Esperti | No 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 »

Workshop su extreme programming al phpDay 2008

Ieri finalmente il workshop su extreme programming tenuto al phpDay 2008 insieme a Francesco Trucchia. Un’esperienza fantastica, in compagnia di persone splendide, con un’ottima partecipazione e un’enorme soddisfazione per noi.

Nei prossimi giorni farò un resoconto più dettagliato – completo di foto e filmati delle fasi più accese del planning game che abbiamo simulato, ma certamente ringrazio fin d’ora Francesco, il direttivo del Gr.u.s.p. e Fullo, che ci ha messo davvero nelle condizioni di operare al meglio per la buona riuscita del workshop.

Un ringraziamento finale va a tutti i partecipanti. Vederli chiusi in cerchio giocando al planning game è stata una vera soddisfazione, davvero non speravamo in un tale coinvolgimento di tutti.

Al prossimo phpDay!

May 25 2008 | Eventi | 6 Comments »

Agile planning: un punto di vista ingegneristico

L’ingegneria gestionale e dell’automazione costituisce un compendio enorme di tecniche e conoscenze sviluppate per razionalizzare e ottimizzare i più diversi processi industriali. Il project management agile, e lo stesso extreme programming, propongono in realtà tecniche prese in prestito da quel mondo riviste e corrette per adattarsi all’industria che ci riguarda più da vicino: quella del software. In questo articolo vediamo qualche esempio. continue reading »

April 25 2008 | Esperti | 1 Comment »