Sant’Antonio, le giuste priorità e ‘getting things done’

Tra una catena di Sant’Antonio, una proposta per un gruppo Facebook e un po’ di spam di routine oggi ho ricevuto questa storiella:

Un professore, prima di iniziare la sua lezione di filosofia, pose alcuni oggetti davanti a sé, sulla cattedra. Senza dire nulla, quando la lezione iniziò, prese un grosso barattolo di maionese vuoto e lo riempì con delle palline da golf. Domandò quindi ai suoi studenti se il barattolo fosse pieno ed essi risposero di sì.

Allora, il professore rovesciò dentro il barattolo una scatola di sassolini, scuotendolo leggermente. I sassolini occuparono gli spazi fra le palline da golf. Domandò quindi, di nuovo, ai suoi studenti se il barattolo fosse pieno ed essi risposero di sì.

Il professore, rovesciò dentro il barattolo una scatola di sabbia. Naturalmente, la sabbia occupò tutti gli spazi liberi. Egli domandò ancura una volta agli studenti se il barattolo fosse pieno ed essi risposero con un sì unanime.

Il professore tirò fuori da sotto la cattedra due bicchieri di vino rosso e li rovesciò interamente dentro il barattolo, riempiendo tutto lo spazio fra i granelli di sabbia. Gli studenti risero!

“Ora”, disse il professore quando la risata finì, “vorrei che voi consideraste questo barattolo la vostra vita. Le palline da golf sono le cose importanti; la vostra famiglia, i vostri figli, la vostra salute, i vostri amici e le cose che preferite; cose che se rimanessero dopo che tutto il resto fosse perduto riempirebbero comunque la vostra esistenza.”

“I sassolini sono le altre cose che contano, come il vostro lavoro, la vostra casa, l’automobile. La sabbia è tutto il resto, le piccole cose.”

“Se metteste nel barattolo per prima la sabbia”, continuò, “non resterebbe spazio per i sassolini e per le palline da golf. Lo stesso accade per la vita. Se usate tutto il vostro tempo e la vostra energia per le piccole cose, non vi potrete mai dedicare alle cose che per voi sono veramente importanti.

[...]

Un po’ come le feature marginali o addirittura inutili che occupano tempo e testa degli sviluppatori al posto delle core feature. Un po’ come assegnare sempre la priorità più alta ai task che promettono una conclusione più immediata tentati dalla possibilità di sembrare più produttivi.

Un po’ come rinunciare alla gallina oggi per l’uovo domani.

p.s. ho scoperto che odio la retorica un po’ new age delle catene di Sant’Antonio…

September 10 2009 | Visione agile | 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 »

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 »