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 »

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

Ultimamente si parla spesso di BDD, aka Behoviour Driven Development. Cosa è il BDD? Altro non è che il TDD rivisto nel linguaggio utilizzato, per fornire maggiore focus verso le specifiche.

I più navigati con il TDD infatti, sanno bene che la T di Test è un po’ fuorviante, dal momento che in realtà ogni metodo di test dovrebbe riflettere una specifica, ed ogni classe di test, avendo in comune i metodi di setUp e di tearDown, dovrebbe incapsulare un preciso stato (o il contesto) dell’oggetto/i sotto test. A questo si può arrivare “meccanicamente” rimuovendo le duplicazioni tra i test e cercando l’estrema chiarezza dei test stessi.
Questo modo di vedere il TDD ha vari vantaggi, tra i quali, manco a dirlo, il ridurre il gap tra la dichiaratività delle specifiche (dettate dal customer), e la loro implementazione imperativa. In altre parole ridurre la distanza tra il mondo degli sviluppatori (e tester) e quello degli esperti del dominio del quale i primi vogliono essere a supporto.

Venendo ad un po’ di codice Read the rest of this entry »

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.

vi porto un’altra esperienza (fin troppo)concreta.
è appena successa e non è - in effetti - niente di nuovo; però bisognerebbe ogni tanto sentirne una perchè ritengo che faccia bene
(un po’ per riderci sopra e un po’ per non abbassare la guardia).

ovviamente non posso svelare i “segreti” aspetti del business, cercherò comunque di rendere l’idea…

comincia così:

“c’era una volta una ditta nella quale si seguivano tanti bei principi agili…
però qualcuno tramava nelle tenebre…”

Infatti alcune “operazioni di business una-tantum” (a volte anche due-tantum ) venivano svolte in modo “selvaggio“. Read the rest of this entry »

Rendere possibile un design incrementale è sicuramente uno dei maggiori benefici dei test di unità scritti alla TDD. Infatti un design incrementale passa da un continuo refactoring del codice ed è proprio qui che i test ci vengono in soccorso, fornendoci il coraggio ed il feedback necessario per migliorare costantemente il codice.

Un’applicazione con un alto indice di copertura arriva tipicamente ad avere almeno un ratio di 1:2 tra test statements e code statements. Questo significa aver scritto un client della nostra applicazione che come tutti i client risentirà in modo più o meno pesante delle modifiche del server. E’ chiaro quindi che se non si prestano le dovute attenzioni alla struttura delle API come dei test stessi, i test potrebbero diventare il boomerang del refactoring, trasformandosi in una zavorra al cambiamento invece che incoraggiarlo ed esserne a supporto.

Read the rest of this entry »

Stavo leggendo i commenti ad un post di Enri riguardo al pomodoro quando la seguente frase di Paolo Dona mi ha fatto riflettere:
“Per mia esperienza posso dire che mi ci vogliono dai 30 ai 45 minuti per entrare nel ‘flow’ produttivo, quindi gli intervalli da 25 minuti non so se mi bastano.”

La mia prima reazione è stata: “Ovvio che non riesci a entrare nel ‘flow produttivo’, è uno dei motivi che ci spinge a usare il pomodoro!“.
Però - vista così - la frase sembrerebbe essere controproducente; si vuole forse evitare di essere produttivi?

Sicuramente no, in effetti però dubito seriamente di quel “flow produttivo” che non si può interrompere (alias “flow-non-disturbarmi-altrimenti-perdo-tutto”).

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

Ultimamente in TV c’è una pubblicità che mi piace molto: la pubblicità della Mostra Internazionale d’Arte Cinematografica di Venezia. La frase cardine della promozione, che credo appenderò in ufficio è la seguente:

E’ il desiderio di qualità che ci ha sempre permesso di sognare.

Stamattina ho letto inoltre un post di uno dei miei blog preferiti: AgileAdvice. Il post si intitola Quality is Not Negotiable (consiglio vivamente una lettura) ed affronta il tema della qualità come condizione irrinunciabile ed imprescindibile ad un processo efficiente che minimizza gli sprechi e che voglia ottenere il massimo dal business di cui è a supporto. In caso contrario ci si ritrova ogni 2-3 anni a dover ricostruire da capo sistemi e prodotti, o nel caso migliore (si verifica raramente) a dover fermare la produzione per lunghi periodi di tempo al fine di rimettere ordine in un prodotto mal costruito e di bassa qualità. Mi viene in mente uno dei cardini del Toyota Production System e di tutta la filosofia del Lean Manufactoring: in ogni momento ogni componente del team ha il diritto di fermare la produzione se nota un artefatto di bassa qualità ed in questo caso la produzione non riprende fino a quando tale difetto non sia stato risolto e non se ne siano comprese le cause. Questa continua ricerca di qualità e la responsabilizzazione di ogni sviluppatore garantisce che il mostro venga ucciso in poco tempo quando ancora piccolo e non quando avendo raggiunto dimensioni ciclopiche un suo abbattimento renderebbe necessario un dispendio di forze (=soldi) molto alto; per non parlare degli ingenti danni che tale mostro avrà compiuto durante la sua crescita.

Una delle armi più efficaci in mano agli sviluppatori per identificare il prima possibile questi difetti è l’enfasi su brevi cicli Test Sviluppo Refactoring, in Toyota come nello sviluppo del software.

Per applicare questi brevi cicli e per continuare a sognare il team non può permettersi compromessi, e non deve accettarli da parte dell’organizzazione e del management: sareste disposti a calpestare la vostra dignità e a vivere senza sogni?