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.

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.

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

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

Dal momento che con ideato cerchiamo di adottare metodi agili nel nostro progetto produttivo di sviluppo di applicazioni per il web, la conferenza mi interessa molto.

Spero che ci siano momenti di confronto e di condivisione delle esperienze personali.

Il mondo dei metodi agili in Italia è un mondo relativamente giovane e ancora da sperimentare sotto molti punti di vista, ma il fatto che se ne inizi a parlare sempre di più e che aziende come sketchin organizzino questi eventi, fa comprendere che c’è interesse e movimento ed è questa la cosa fondamentale.

In ideato stiamo adottando l’XP (Extreme Programming) come metodo fin dalla nostra apertura, e sinceramente stiamo già dopo poco mesi traendo tutti i benefici che i metodi agili portano, come:

• coraggio e fiducia nel team;
• fiducia tra cliente e team;
• consegna del software in tempo;
• massimizzazione dei guadagni e minimizzazione dei costi per il cliente e per l’azienda stessa;

Ma, haimè non è tutto oro quello che luccica, infatti i metodi agili si adattano bene in situazioni nelle quali hai a disposizione, oltre che alle pratiche, anche gli strumenti per mettere in pratica tutte le metodologie.

Nella nostra linea di sviluppo di applicazioni per il web basate su framework di nuova generazione che rispettano tutte le regole dell’agile, come symfony e Zend Framework, il risultato è veramente ottimale.

Nella linea produttiva, invece di personalizzazione di software Open Source, ed in particola software CMS come WordPress, eZ Publish o Drupal, le cose un po’ si complicano, poichè ad esempio i software:

• sono difficilmenti testabili, sia a livello funzionale che unitario;
• sono difficilmente mantenibili una volta estesi poichè non realizzati su pattern conosciuti e su framework solidi;
• non si prestano ad essere estesi su sistemi di versioning, poichè il codice non è sempre ben separato;

Per un’azienda come la mia, customizzare software Open Source occupa una buona fetta dei ricavi, ma se non si riescono ad applicare le buone pratiche agili, alla fine più che un guadagno diventa un costo.

E tu, riesci ad applicare le metodologie agili nella customizzazione di software Open Source un po’ datato?