Archive for the 'Esperti' Category

La maggioranza ha sempre ragione. O no?

Un intervento di Gabriele Lana sulla mailing list XP nazionale mi convince oggi a pubblicare questa draft in agguato da qualche mese tra i miei post in sospeso.

Gabriele fa riferimento nella sua mail al rigore di un processo, all’autorità all’interno di un team e alle buone pratiche scrivendo:

Durante il primo stadio dell’apprendimento (di qualsiasi cosa) si
devono seguire delle regole per non farsi male e per non fare male,
non c’è molto spazio per la democrazia, se fossi sotto i ferri e ci
fosse un team di medici pronti ad operarti vorresti che per democrazia
vincesse il “per questa volta non ci laviamo le mani prima di
operare”?

Leggere queste righe mi ha fatto subito pensare che avevo intenzione da un po’ di parlare di buone pratiche e di processi di decisione nei gruppi facendo riferimento al dottor Ignác Fülöp Semmelweis, noto come il Salvatore delle madri. continue reading »

June 02 2009 | Visione agile | No Comments »

Consegnare manovrabilità, non più software.

Un breve post per riassumere e condividere con te una riflessione che mi diverte in questi giorni.

Negli ultimi decenni i marchi più famosi hanno capito che può essere molto remunerativo mettere in atto il cosiddetto attitude branding ossia l’estensione della percezione pubblica del marchio – il brand – fino a rappresentare non più il solo prodotto inizialmente identificato ma un sentimento più ampio, talvolta spinto fino a costituire un sincero senso tribale di appartenenza. Ecco quindi che vediamo il marchio usato ora su un paio di scarpe, ora su un orologio e ora per dare il nome ad un campionato di calcio. In ogni senso, quindi, vediamo il logo trascendere il prodotto iniziale e rappresentare qualcosa di più astratto, un vero e proprio modo di essere. Se hai letto No Logo di Naomi Klein – o altri reportage simili – sai cosa sto cercando di comunicarti in breve: le grandi multinazionali non vendono più un prodotto – la scarpa – la cui riconoscibilità è garantita dal logo – accessorio; bensì vendono un’identità – il brand – utilizzando come supporto la scarpa – accessorio.

Bene, in questi ultimi tempi mi sto convincendo del fatto che un team agile non deve pensare di vendere semplicemente software. Mi sembra sempre più chiaro che un team agile debba acquisire una mentalità più alta in cui si senta elemento chiave di un processo che miri a consegnare manovrabilità, nel senso cirilliano del termine. Una mentalità che ponga la possibilità di cambiare direzione come il vero prodotto.

Tutto questo si ottiene sicuramente partendo dal basso, da ogni riga di codice, non va dimenticato, mai. Ma, considerando che manovrare per il cliente significa reagire agli stimoli del mercato, il mantra di ogni team deve diventare questo: non consegno più un software – il prodotto – la cui manutenibilità è garantita da un design flessibile – accessorio; bensì vendo manovrabilità – il prodotto – utilizzando come supporto il software – accessorio.

E tu? Oggi consegnerai al tuo cliente righe di codice o manovrabilità?

May 24 2009 | Visione agile | 2 Comments »

Requirements rodeo

Sai quando si parla di valore per l’utente, no? Hai presente quando senti uno sviluppatore lamentarsi del cliente poco lean, vero? Ti è capitato di pensare che sviluppatori e designers avessero molti problemi in comune, ricordi?

Bene.

Ora ridici un po’ su.

Saputo da Sketchin che l’ha saputo da Chiara Fox che l’ha saputo da AdFreak.

January 22 2009 | Visione agile | No Comments »

La vera agilità: passare dalle regole ai principi

Un post molto interessante di Jurgen Appelo mi ha ricordato un applet che avevo visto già alcuni anni fa, tangibile e lampante esempio dell’ordine che può emergere dal caos in base a poche regole ad un primo sguardo insufficienti a creare strutture tanto coese. La morale del post è: basta dirigere i progetti, i gruppi di lavoro, le situazioni complesse in base a regole da applicare caso per caso, cominciamo a definire solo dei vincoli e lasciamo che tutto si auto-organizzi. Cosa ha a che vedere con lo sviluppo agile tutto ciò?

continue reading »

December 18 2008 | Visione agile | 2 Comments »

Socrate era agile

Mi piace pensare, lavorare e scrivere questo blog in base ad un sano principio di multidisciplinarietà: amo stabilire ponti fra concetti apparentemente distanti, scovando pattern in giro e costruendo quelli che nella scienza delle reti vengono chiamati legami deboli tra piccoli mondi culturali. Oh parbleu!!! L’ho appena fatto! Beh, lo sto per rifare tirando in ballo Socrate. continue reading »

November 22 2008 | Visione agile | 6 Comments »

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 »

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 »

Extreme programming e domain driven design

Ieri ho partecipato al primo giorno del phpDay 2008, in attesa di pubblicare con Francesco il nostro workshop oggi pomeriggio. Giornata divertente come ogni anno mi aspetto che sia, resa più frizzante dalla richiesta improvvisa di Fullo di aiutarlo a riempire un buco venuto improvvisamente a crearsi nell’agenda della giornata. Pensavo di fare un talk veloce sulle metafore fisiche con cui mi capita di descrivere (o di veder descritti) i processi agili, poi però Francesco mi ha dato l’idea migliore – parlare del Domain Driven Design – che ho poi deciso di integrare con riferimenti all’extreme programming.

Il domain driven design è una metodologia di modellazione del software che parte dal presupposto per cui gli sviluppatori devono nel tempo distillare una sempre maggiore porzione di conoscenza di dominio nella struttura del codice scritto, conoscenza che proviene dal contributo degli esperti di dominio, tipicamente il cliente.

Un obiettivo fondamentale di questo processo è quello di creare un ubiquitous language che sia condiviso tra team di sviluppatori ed esperti di dominio, che si rifletta fino in fondo alla scelta dei nomi delle classi, dei metodi, delle interfacce e delle strutture relazionali tra oggetti, in modo da

  • rendere più affidabile il design dell’applicazione
  • rendere più semplice la partecipazione del cliente alla progettazione stessa

Il che già di per sé sembra fortemente propedeutico per la pratica extreme programming denominata customer on site che richiede al cliente di essere presente direttamente – o per delega – presente presso il team di sviluppo del progetto di cui è committente.

Ma se poi andiamo a fondo nell’apprendimento del domain driven design scopriamo anche il concetto di continous learning e di new insight che riflettono il fatto che gli sviluppatori, man mano che vivono all’interno di un progetto, ne assimilano i concetti di dominio fondamentali e sono perciò portati a modificare il codice per riflettere questo incremento di conoscenza. Il libro di Eric Evans fornisce molti utilissimi consigli per ottenere codice che sia facile da manutenere e far crescere, ma per noi agilisti è chiaro che vengono alla mente i concetto di design emergente e, ancor di più, di refactoring.

Extreme programming quindi ci fornisce delle pratiche che, se seguite con attenzione, ci permettono di modificare il codice senza timore, di tenerlo pertanto aderente alla realtà di dominio e quindi di perseguire il continous learning senza attriti ed ostacoli di sorta.

È chiaro quindi come il domain driven design possa essere propedeutico alle pratiche agili, ma anche come extreme programming possa esserlo per l’incremento di conoscenza del dominio che una modellazione domain driven presuppone.

May 24 2008 | Esperti | 1 Comment »

Antibiotici e test driven development

Uno sviluppatore con cui ho terminato oggi un’importante fase di un progetto web mi ha detto:

[…] Io diffido di chi propone un rimedio come panacea di tutti i mali. Nei progetti open source che vedo utilizzare i test automatici io vedo ancora liste di bug lunghissime.

Affermazione che equivale più o meno a dire:

Ritengo gli antibiotici un immenso bluff. Sono decenni che vengono impiegati e ci sono ancora milioni di malati in ogni parte del mondo

Ok, ci ammaliamo ancora tutti e ancora ovunque, ma rinuncereste agli antibiotici?

Gli antibiotici non ci regalano l’immunità totale, ma hanno abbattuto l’impatto dei batteri sulle nostre vite. I test automatici non sono una panacea, ma abbattono il tempo speso a fare debugging – che è sempre tempo perso, poiché non è passato a creare valore ma a verificarlo.

April 29 2008 | Visione agile | 1 Comment »

« Prev - Next »