Ovvero: quando possiamo misurare in maniera diretta i benefici economici che derivano dalla messa in produzione di una funzionalità, quando invece vi sono altri fattori esterni che influiscono sui ricavi, o quando il valore è intangibile.

Read the rest of this entry »

Un thread sulla mailling list del pomodoro mi dà lo spunto per scrivere questo post.

La domanda è: cosa misurare e su cosa concentrarsi per aumentare la velocità di un team?

Misuro e minimizzo i Pomodori (=effort) necessari per raggiungere un certo obiettivo, piuttosto che i giorni reali impiegati?

Personalmente non lo ritengo efficace. Meglio concentrarsi (e quindi misurare) altro:

• puntare ad aumentare e misurare la qualità del prodotto e del processo:
• significa minimizzare gli sprechi causati dal rifare o modificare quanto fatto in passato
• fare rilasci frequenti (minimizzare time-to-market):
• significa eliminare gli sprechi causati dall’avere pezzi in giacenza in magazzino
• migliorare la comunicazione con il cliente:
• significa eliminare gli sprechi causati da direzioni sbagliate
• dare una priorità alle storie esplicitandone il loro valore di business:
• significa eliminare gli sprechi su storie di poco valore
• valutiamo il miglioramento degli aspetti sopra esposti contro:
• ritorno di investimento
• soddisfazione del cliente e degli utenti finali
  

Cercare di massimizzare esclusivamente la velocità pura, porta a cercare scorciatoie, ad abbassare la qualità, a causare l’overload delle risorse (= sistema di code ad alto rischio, eccesso di stress, creatività ai minimi) e quindi a far decrescere nel medio-lungo termine la velocità stessa. Provare per credere.

Nello sviluppo del software come nel guidare un auto, è più importante saper sterzare, che andare veloci. — Ron Jeffries

Uno dei principi più importanti di XP, nonché uno dei valori fondanti, è: scegli la via più semplice.

Ad esempio, se ci si trova a dover scegliere tra due soluzioni, una che prevede un’infrastruttura più ampia, utile anche in futuro, ed una invece con un’infrastruttura ad uso esclusivo della business story attuale, XP guida nella scelta con l’euristica:

“scegli la soluzione più semplice, che non fa assunzioni sulle necessità future e che presuppone lo sviluppo solo dell’infrastruttura necessaria adesso, così da minimizzare il time-to-market e da non precludere alcuna strada futura”.

E’ l’essenza dello sviluppo iterativo.

La domanda ora è: scegliere in base a questa euristica, ottimizza il ritorno di investimento finale?

Nel corso di questo post per mezzo di un’analisi finanziaria comprenderemo in quali situazioni l’euristica XP è vincente rispetto ad una scelta con architettura up-front.

Read the rest of this entry »

Uno dei miei obiettivi del 2007 è migliorare la mia preparazione per quanto riguarda le mie nozioni di economia e finanza, applicate soprattutto all’informatica. Per fare questo ho cominciato a leggere un testo che mi è subito parso stimolante: “Software by Numbers: Low-Risk, High-Return Development“ di Mark Denne.

Di seguito la prima cosa che ho imparato:

Present Value of Future Money (PV):

Fornisce un’indicazione del valore attuale di un incasso futuro, assunto come certo. In altre parole, se ad esempio abbiamo la certezza (=nessun rischio) che tra 2 anni avremo un incasso di 2000 euro, e che tra 5 anni avremo un incasso di 5000 euro, possiamo confrontare questi incassi attualizzandoli con questa formula, assumendo un tasso di interesse “svalutativo” del 5%:

PV = 2000 / (1 + 5/100)^2 = 1814 Euro

PV = 5000 / (1 + 5/100)^5 = 3918 Euro

Questo significa che in questo caso è più conveniente attendere cinque anni per 5000 euro, invece che due anni per 2000 euro.

Portando questo esempio in campo informatico, su due ipotetici progetti, il Present Value of Future Money ci suggerisce (a parità delle altre condizioni) di preferire da un punto di vista finanziario il secondo progetto al primo.

Ho impostato la scaletta di quello che probabilmente sarà il mio intervento di apertura per la session:

• “Omogeneità di valori e imporre l’Agilità”

Chi segue la lista xp-it avrà notato la mia ignoranza in economia… :-O

Tuttavia sono convinto che per massimizzare l’efficacia del nostro lavoro, anche gli sviluppatori dovrebbere possedere almeno le nozioni di base, utili a creare una collaborazione molto stretta tra business-men e technical-men, nonché per farsi guidare dall’economic driver scelto misurandosi anche in tal senso. Del resto il manifesto Agile recita:

“Business people and developers must work together daily throughout the project”

Per questi motivi, mi aggrego a PierG che cita questo post, per colmare le mie lacune. Nei link che vi ho dato trovate i riferimenti alla wikipedia inglese, che sicuramente tratta in modo più completo l’argomento. Ad ogni modo volevo segnalare anche i seguenti link alla wikipedia italiana:

• Fatturato
• Ricavo
• Profitto
• ROI
• Utile

Credo che tutti abbiamo avuto questa esperienza: scrivere applicazioni che dopo x giorni si sono rivelate non più mantenibili, per le quali si impiegava meno tempo a riscriverle che a modificarle. Complice la tecnologia utilizzata, l’effort per riscrivere parti dell’applicazione  lasciava comunque il committente non contento dei nostri tempi di risposta e quindi del costo del software. In sostanza la bassa qualità del software prodotto si traduceva in alti costi di manutenzione.

La frustrazione provata in queste occasioni ci ha portato a chiedere: dove cercare la soluzione?

Sostanzialmente vi sono due strade opposte:

• addossare la colpa alla tecnologia utilizzata, e quindi cambiarla alla luce di questa affermazione
• cercare di migliorarci per costruire skill e capacità che ci permettano di non cadere nella trappola dell’applicazione zombie

Read the rest of this entry »

Nel mio aggregatore figura questo blog, che regolarmente presenta post molto stimolanti.

Un post del mese scorso riflette su come insegnare alle persone ad avere un approccio mentale rivolto all’eccellenza per mezzo del miglioramento continuo. Imparare ed insegnare ad essere sempre volti verso l’(auto)miglioramento è l’investimento più grande che si possa fare su se stessi o sulle persone che si gestiscono. Purtroppo le aziende che si concentrano su questo aspetto per liberare e far esprimere tutto il potenziale dei propri dipendenti, sono pochissime. Si preferisce “investire” su altro: controllo o totale mancanza di sistematicità.

Il miglioramento continuo ha un aspetto fondamentale: il fare. Solo attraverso l’azione è possibile migliorarsi: senza azione non c’è feedback e senza feedback non può esserci apprendimento.

Questa citazione (che traduco) chiude l’articolo:

“Il pessimista si lamenta del vento; l’ottimista si aspetta di poterlo cambiare; il realista aggiusta le vele.”

Per me questo significa: responsabilizzarsi ed essere proattivi.

qualche giorno fa mi sono trovato sul blog di luca grulla e ho risposto ad un suo articolo riguardante la stima agile delle storie.
poi luca mi ha mandato un email con le seguenti domande:
“come siete passati da stimare i task a decidere di che non era più utile e stimare solo le storie ?
quale è stato il passaggio che vi ha spinto in questa direzione ?“

per chi non ha letto l’articolo siamo passati da una situazione dove stimavamo solo i task in pomodori a stimare solo le storie in punti
(questa è solo l’ultima puntata del: “imparare a pianificare agile”, vi risparmio le altre)
un bel cambiamento insomma… qui sotto vi spiego il perchè di questa decisione. Read the rest of this entry »

Si sente spesso dire che per utilizzare una metodologia come eXtreme Programming, e molte delle sue pratiche (su tutte il TDD), è necessaria una disciplina maggiore che con altre metodologie. Penso che ci sia un fondamento di verità in questa affermazione. Tuttavia il De Mauro definisce la disciplina come (il grassetto è mio):

L’insieme delle norme che regolano il comportamento di un individuo, un gruppo, un ente; rispetto, obbedienza di tali norme: imporre, violare, mantenere la d., è incapace di d., non sanno osservare la d. | estens., dominio dei propri istinti, desideri e sim. suggerito da principi etici o religiosi: si impone una ferrea d. .

Il termine disciplina richiama quindi fortemente un altro termine: rigidità. Come è quindi possibile che un paradigma che si pone come obiettivo dichiarato quello della flessibilità anche del metodo stesso, richieda a chi applica tale paradigma, disciplina e rigidità? Read the rest of this entry »