Piu’ volte su questo blog ho parlato di quanto sia importante la qualità per abbattere i costi totali.

Con questo post voglio riflettere piu’ nel dettaglio per comprendere quando una soluzione comoda e magari poco elegante possa avere senso. Inoltre quando paga rifattorizzare una soluzione dal forte grado di accoppiamento tra le componenti?

Di seguito un piccolo sunto del paragrafo “When to refactor” di “Refactoring, improving the design of existing code“:

• Regola dei tre strikes: “la prima volta implemento la piu’ semplice, la seconda volta, consapevole della duplicazione, duplico, la terza volta che faccio qualcosa di simile, rifattorizzo”
• Quando si fixa un bug: codice piu’ chiaro e/o si migliora la testabilità
• Quando una nuova funzionalità deve innestarsi in codice poco chiaro: migliorare la comprensibilità per diminuire il rischio di interventi non corretti
• Quando rende piu’ veloce implementare una nuova funzionalità: migliorare la malleabilità

Alla base del refactoring vi è l’idea di minimizzare il costo di cambiamenti futuri non con una previsione degli stessi, ma creando un design che per la sua semplicità sia in grado di essere modificato e reso pronto a qualsiasi cambiamento con poco sforzo. L’effort di tali modifiche (aka mosse di Refactoring) rimane relativamente basso se e solo se il design è mantenuto ragionevolmente semplice. La pratica del TDD a questo fine è un arma molto potente.

Sappiamo tuttavia che anche con un processo scope-oriented e con un team Agile, molto spesso ci si trova ad avere applicazioni o zone dell’applicazione con del debito tecnico. In questi casi cercare di scontare quel debito di design seguendo unicamente le linee guida sopra elencate per la mia esperienza non è efficace. Spesso in presenza di un forte debito tecnico ereditato dal passato, i refactoring sarebbero molto, troppo estesi. Dire semplicemente facciamoli a piccoli passi non mi aiuta molto: servono delle euristiche che tengano conto del contesto e dei particolari vincoli di risorse.

Read the rest of this entry »

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 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.

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

Ormai sono rientrato a lavorare da due settimane e (purtroppo) sto lavorando da solo. Solitamente il ritorno dalle vacanze e la mancanza di un compagno portano a poca concentrazione e soprattutto a vagare con la mente su vari task, arrivando spesso a fine giornata con la sensazione di aver “sprecato un giorno”. Questi aspetti uniti al desiderio di tracciare in modo più preciso il tempo speso sulle storie e ad un metodo sistematico per migliorare le stime mi hanno portato alla prima esperienza con la pratica del Pomodoro ideata da Francesco Cirillo. Read the rest of this entry »

Scrivere software di qualità è molto difficile, e tale difficoltà non solo è legata naturalmente alla complessità del dominio, ma anche a fattori più “umani” quali la comunicazione all’interno del team soprattutto quando composto da elementi di esperienza e formazioni eterogenee.

Una serie di tool ci viene in soccorso per monitorare continuamente la qualità del codice che stiamo scrivendo, e se unita alla pratica di Continuous Integration (ad esempio per mezzo di CruiseControl), permette di controllare continuamente e su base regolare se tutti i componenti del team stanno scrivendo software al di sotto degli standard di qualità prefissati. Prevenire problemi di comprensibilità e mantenibilità del codice, affrontandoli per tempo, è possibile rendendo visibili nel workspace le misure di queste caratteristiche, per mezzo di Big Visible Charts o di una Ambient Orb, cioè di una sfera che, comandata da un task di Ant, a seconda della qualità del codice si colora di verde o di rosso acceso.

I seguenti tool di controlli statici del codice permettono di tenere gli occhi ben aperti su questi aspetti:

• CPD (con PMD): identifica le duplicazioni del codice della nostra applicazione da parte degli sviluppatori più ansiosi o meno accorti; comunichiamo abbastanza?
• CheckStyle: verifica che le Code Convention vengano rispettate
• Metrics: riteniamo la programmazione ad oggetti una chimera o ci impegnamo a fondo per comprenderla?
• Clover: stiamo scrivendo abbastanza test?

Articoli:

• Automation for the People: continuous inspection

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 »