Nel post precedente ho parlato di come gli obiettivi con il supporto delle metriche siano uno strumento fondamentale per motivare le persone e per percorrere la strada del miglioramento continuo in modo serio e duraturo.

Volevo qui brevemente chiarire l’importanza di avere non solo obiettivi raggiungibili in quanto fortemente legati alla propria area di pertinenza, ma allo stesso tempo di validare quanto fatto sulla base di obiettivi di più alto livello.

E’ necessario infatti un meccanismo che permetta di non scambiare il mezzo per il fine, ma che invece validi i risultati ottenuti rispetto all’obiettivo finale: fare business! L’Agilità infatti altro non è che un’altra via per fare business in modo più efficace.

E’ infatti pericoloso cercare ottimizzazioni locali, sperando in questo modo di ottimizzare l’intero sistema: la teoria dei vincoli è lì a dimostrarcelo.

L’idea è quindi quella di avere un obiettivo (e quindi una metrica che ne dia il feedback) di natura economica/business che guidi il miglioramento dei processi e dei prodotti, e una serie di metriche dette “diagnostiche” che permettano di identificare i colli di bottiglia e misurare il miglioramento a fronte di azioni volte a migliorare i singoli problemi su processi e prodotti. Tali metriche diagnostiche per loro natura saranno temporanee, e moriranno nel momento in cui il problema sarà risolto, o si sia deciso di conviverci.

La difficoltà maggiore risiede come avrete intuito nell’inventarsi una metrica di business efficace e soprattutto verificabile anche da chi agisce su processo e prodotto.

Per chi voglia approfondire il discorso, consiglio questo paper che ho trovato molto utile ed illuminante, e che ha ispirato questo post.

Conosciamo bene l’importanza del feedback con il cliente da parte di chi sviluppa software, e quali siano gli strumenti per aumentare tale feedback.

Anche dal punto di vista del miglioramento continuo del processo e dell’efficacia delle pratiche è molto importante ricercare un feedback frequente. Il problema è: in che modo accorgerci se stiamo migliorando nell’efficacia delle soluzioni intraprese, o se invece stiamo regredendo? Altra domanda importante che si lega alla precedente: quali obiettivi porre al team o al project manager, valutabili su base oggettiva al fine di stimolare nel modo corretto ed efficace team e manager?

Read the rest of this entry »

A volte quando parlo di agilità mi rendo conto di inviare un numero eccessivo di messaggi, lasciando che il messaggio principale si perda tra tutti gli altri: la riduzione dei costi per il committente e quindi una maggiore competività per il fornitore! Ecco riassunto questo aspetto in sei punti fondamentali:

• Possibilità di stabilire un tetto di spese limitato perché negoziato frequentemente e monitorato su base costante.
• Forte riduzione del rischio che il cliente si ritrovi in mano funzionalità che non utilizzerà MAI o molto raramente –> in questo modo risparmia un sacco di soldi, infatti è qui che si registrano gli sprechi più incredibili.
• Garanzia che il cliente spenderà soldi solo per ciò che realmente gli serve nel momento in cui viene rilasciato (non ciò che gli serviva sei mesi fa)!
• Il cliente non attende il termine del progetto (tipicamente quindi mooolto a lungo) per cominciare a vedere un ritorno dell’investimento fatto, ma ogni settimana è in grado di misurare il ritorno economico delle nuove funzionalità rilasciate!
• Possibilità per il cliente di decidere in ogni momento di far cambiare completamente rotta al progetto: se sono cambiate le condizioni “ambientali” rispetto al documento di analisi di un anno fa, perché continuare su quella strada?
• Con un approccio agile, i diritti del committente diventano questi!

Read the rest of this entry »

Riporto tre link ad una discussione molto interessante che sta scorrendo su Internet relativamente al tema di cui sopra ed in particolare riguardo una delle pratiche fondamentali dell’extreme programming: il Test Driven Development e lo stress posto sui test. Penso sia degno di una lettura sia da parte degli agili-scettici, sia da parte di chi invece si ritenga un agilista.

In particolare il sasso è stato gettato dal seguente post:

Carlo Pescio critica il TDD

Le risposte di agilisti di primo ordine quali Marco Abis (tra i comments del post) e soprattutto Francesco Cirillo non si sono fatte attendere:

Francesco replica I

Francesco replica II

Anche se i post non sono brevissimi consiglio vivamente una lettura, non ve ne pentirete!

P.S.: purtroppo la discussione in alcuni tratti ha preso una piega un po’ troppo polemica…penso comunque rimangano ottimi spunti di riflessione.