Francesco (cphp) Trucchia

Come citava la pubblicità dei pennelli cinghiali, “Per fare una grande parete, non ci vuole un pennello grande, ma un grande pennello“, ritengo che lo stesso slogan possa essere applicato oggi alle aziende che producono software. Si pensa che grandi team e aziende fortemente strutturate possano creare software migliori e in tempi brevi.

Beh questa è utopia.

Il software è fatto dalle menti delle persone: chiamale grafico, ingegnere, architetto, db specialist o semplicemente programmatore, ma quello che conta realmente non è l’etichetta ma la loro creatività.

Per fare un grande software bastano poche persone, eccellenti nella loro professione, fortemente motivate, coraggiose, curiose e in grado di comunicare tra loro. Sono questi alcuni degli ingredienti fondamentali di una ricetta che non può sbagliare.

Dall’altra parte nel team non può mancare il committente, colui che ha richiesto il software, sia esso un imprenditore, un utente, un product manager, un business analyst. Per fare un grande software ne basta anche solo uno, ma che ci sia, che sia anche lui farcito degli stessi ingredienti di professionalità, motivazione, coraggio, curiosità, capacità di comunicazione e soprattutto disponibilità.

Con queste due caratteristiche non avremo mai un software grande, pieno di bug che non fa quello che abbiamo chiesto, ma un grande software, fatto dagli utenti per gli utenti, un software pronto a cambiare quando richiesto, in grado di compiere i task per i quali è stato creato.

Come possiamo raggiungere questo obiettivo in un mondo di speculazione e fanta finanza… sinceramente non lo so, ma credo che un’eccellenza di professionisti e aziende italiane che in questo 2009 ho incontrato stiano iniziando a muoversi verso un mondo più sostenibile, più razionale e più vero, dove i vincitori sono sempre due, sia il cliente che il fornitore, per farlo stanno abbracciando la filosofia delle metodologie agili.

Questo è quello che il 2009 mi ha lasciato a livello professionale, questo è il progetto per il quale voglio impegnarmi nei prossimi anni.

Voglio regalare alle persone e alle loro aziende che mi hanno fatto crescere in questo 2009 un link alla loro professionalità. Ringrazio di cuore:

• Kea, Michele, Paolo, Fullo, Anto, Filo di ideato
• Antonio, Giorgio e Alessio di Digital Natives
• Alberto, Gianfilippo e Cristiano di Doralab
• Luca, Diana ed Alice di Sketchin
• Michele e Lorenzo di e-xtrategy
• il mio caro mentore Jacopo

Buon 2010.

Nasce anche nelle marche il primo XP User Group.

Gruppo dedicato allo studio ed approfondimento delle pratiche dell’eXtreme Programming e dei processi agili in genere con sede in Ancona. (The group is focused at investigation and review of eXtreme Programming practices and agile processes in general based in Ancona, Italy).

Ho deciso di iscrivermi anch’io e penso che il 2010 mi vedrà impegnato in questa bella iniziativa.

Anche quest’anno non potrò mancare all’Agile Day 2009 che si terrà a Bologna il 20 Novembre. Ho appensa saputo che i 400 posti disponibili sono già terminati e che hanno aperto una lista di attesa di 100 posti.

Italian Agile Day 2009!

Venerdi’ 20 Novembre 2009 si terrà a Bologna il sesto Italian Agile Day. Si tratta di una conferenza gratuita di un giorno dedicata alle metodologie Agili per lo sviluppo e la gestione dei progetti software rivolta agli sviluppatori, project leaders, IT managers, tester, architetti e coach che hanno esperienze da condividere o che iniziano solo ora ad interessarsi a queste tematiche. La giornata ha come obiettivo la conoscenza pratica, le esperienze sul campo e un attivo coinvolgimento di tutti i partecipanti. L’accesso è libero previa registrazione, i posti sono limitati. L’evento, per la quarta volta consecutiva, si auto-finanzierà.

In natura il cambiamento viene dimostrato dal confronto di due misure.

Ad esempio, se voglio dimostrare che il peso di un palloncino è diverso se riempito con acqua o con aria, eseguirò i seguenti passi:

1. peso in una bilancia il palloncino pieno di acqua
2. peso nella stessa bilancia il palloncino quello pieno d’aria
3. confronto i due pesi

se la differenza è diversa da zero, significa che il palloncino pieno d’acqua pesa di più del palloncino pieno d’aria:

Cambiamento = PesoPalloncinoAcqua – PesoPalloncinoAria

Questa dimostrazione è possibile grazie alla bilancia che è il nostro strumento di misurazione tarato sull’unita di misura del peso, il grammo.

Quindi se il palloncino è la nostra applicazione, l’acqua la nostra vecchia feature che deve essere sostiutita con l’aria, come faccio a dimostrare che il codice è cambiato se non riesco a misurarlo?

Con i test automatici.

Il test automatico è in grado di misurare il nostro codice e dimostrarne in maniera oggettiva il cambiamento.

E voi misurate il vostro codice? con quale unità di misura?

Leggendo per la mia prima volta il blog di Carlo, ho scoperto un sacco di interessanti post sulle buone pratiche di sviluppo e le sue esperienze personali con il mondo Java.

Leggendo tra i suoi post ho trovato un link al sito sourcemaking.com che non conoscevo. Il sito presenta una guifa completa ai Design Pattern, agli AntiPattern e al Refactoring, insomma un punto di riferimento da avere sempre sotto mano.