Riporto qui dal WIKI c2 la definizione di successo di un progetto Software. In particolare mi interesserebbe sentire da voi la vostra esperienza riguardo i punti 4,5,6. Ad esempio: li avete come obiettivi o credete che non debbano riguardare il team di sviluppo? E’ possibile secondo voi raggiungerli? Quali strumenti adottate per facilitarvi? Come riuscite ad ottenere del feedback sul raggiungimento degli stessi? In che modo collaborate con il business per raggiungerli?
Particolarmente affascinante e motivante il punto 6: non accontentiamoci di consegnare piu’ valore di quanto costiamo, ma cerchiamo di organizzarci in modo da consegnare quanto piu’ valore sia possibile con le risorse a disposizione!

There are increasingly broad ways to judge the success of a software project.

1. Works well enough to be used.
2. Can be maintained and improved.
3. Does what the stakeholders want.
4. Provides value to the organization.
5. Provides more value than it cost.
6. Provides more value than any other use of its resources could have.

Success at each level trumps failure at the previous level, so an unmaintainable piece of software that isn’t usable but still provides value to the organization has achieved level 4. An example of this is a piece of demo-ware that’s used to get a round of funding and thrown away afterwards. For most software, though, success at lower levels is necessary to achieve success at higher levels. For a project to be minimally successful, it has to achieve level 5. Developers doing ExtremeProgramming focus on levels 1, 2, and 3. They count on the customer to attend to levels 4, 5 and 6. Other methodologies focus on level 3, too. In fact, they didn’t even say much about levels 1 and 2. They count on the programmers and the stakeholders to achieve the other levels. And we all know how that turns out: lots of projects that don’t even function, or can’t be maintained. The neat thing about XP was that it brought levels 1 and 2 into the equation.

With XP, software is actually getting built and is maintainable. But the picture won’t be complete until we bring levels 4 and 5 in as well. If we truly want to be excellent, we need to include level 6.

Eccoci di nuovo ad un’altra giornata Agile italiana!

Quest’anno cade il 23 Novembre e una delle novità è che si terrà a Bologna.

Il programma è molto interessante, con svariati Experience Report e la partecipazione di uomini-agili del calibro di Francesco Cirillo e Tim Mackinnon, co-ideatore tra le altre cose dei Mock objects.

Per vostra fortuna quest’anno non cercatemi come speaker nel programma : conto comunque di disturbare Simone mentre parla dello split delle Storie.

Altra bella novità è la disponibilità di uno spazio nel quale si potrà improvvisare delle Track Open Space durante la giornata per continuare a discutere di sessioni concluse o per proporne di nuove.

Che dire? Vi aspetto!!!

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 »

In questi primi mesi trascorsi in GM Technologies sono accadute molte cose interessanti. Il tempo per parlarvene è stato poco, complici anche il caos post-trasloco e le corse per uffici amministrativi. Spero di riuscire a riassumere con una serie di post alcune delle cose che ritengo piu’ importanti.
Uno degli aspetti sul quale siamo in cammino verso il miglioramento è la tecnica del Pomodoro.

Inizialmente in GM si adottava un Pomodoro per team.

Vantaggi:

• ritmo comune a tutto il team
• pause sempre in comune, che significa guardarsi tutti insieme un video su YouTube, scambiarsi informazioni sul progetto, etc
• diminuzione delle interruzioni causate da altre coppie in “pausa rumorosa”

Svantaggi:

• molto spesso il passo di una coppia non è il medesimo di quello delle altre, questo puo’ dare origine a due comportamenti che violano la base della tecnica:
• la coppia entra nel pomodoro quando gia’ partito da qualche minuto
• la coppia cambia il proprio passo, tenendo un ritmo per lei non efficace
• lo svantaggio precedente porta ad una misura dei pomodori effettatuati poco attendibile (miglioramento piu’ difficile)
• quando un’interruzione non viene gestita da una coppia, si rompe il Pomodoro di tutte le coppie?

Read the rest of this entry »

Questo è il mio ultimo giorno in Reply.

In questi tre anni oltre che ad incazzarmi varie volte , ho avuto la fortuna di lavorare con persone molto valide, su tutti vorrei nominare e ringraziare Tom. La nostra collaborazione sempre cristallina e aperta al miglioramento, mi ha fatto crescere molto e mi ha regalato oltre che soddisfazioni professionali, anche un’amicizia sincera.

Ora inizio una nuova avventura, non solo professionale, ma anche di vita. Da aprile Simone mi avrà nel suo team in GM Technologies a Lugano. Di questo sono molto contento, per la stima umana e professionale che nutro verso di lui e perché ho visto un gran team molto omogeneo e di cui condivido valori e principi: le premesse sono ottime e sono convinto verranno sviluppate alla grande.

Non mi resta che chiedervi di rimanere sintonizzati, se vi va, su questi schermi: cercherò di tenervi aggiornati ed annoiarvi come ho sempre fatto: la strada è nuova, ma la bussola è la medesima!

Fate una passeggiata al lago!

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 »

Con un ritardo degno dei peggiori progetti, metto qui alcune delle foto che Gabriele ha scattato all’Agile Day 2006, al quale sia io che Simone abbiamo partecipato coordinando alcune sessioni.

Simone, Francesco…ed il mio pomodoro, nella sessione sul Pomodoro.

[notare come il “rosso Pomodoro” la faccia da padrone: la scritta sulla lavagna è rossa, il pomodoro è rosso, il logo XP sulla camicia di Francesco è rosso, il pennarello nella mano di Francesco è rosso e…..persino gli occhi di Simone sono rossi! ]
Read the rest of this entry »

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 »