Metodologie agili in azienda e Agile Camp 2009
Con grande felicità, sono stato invitato a partecipare sabato prossimo all’Agile Camp 2009: il primo barcamp italiano dedicato alla progettazione e allo sviluppo Agile.
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?
A causa dell’influenza, domani non ci potrò essere!!! Che peccato.
Sì, è possibile farlo. È possibile essere agili anche lavorando su sistemi di terze parti, anche su sistemi legacy, anche su progetti di customizzazione.
Quando parli di framework “che rispettano tutte le regole dell’agile” sei sulla borderline del fraintendimento di base e, se non ti conoscessi molto bene, penserei che ti stesse sfuggendo il vero senso dell’agile. Invece lavoriamo insieme da anni e so che tu vivi lo sviluppo agile mooooolto più consapevolmente di tanti altri e quindi mi limiterò solo a ricordarti, come si fa a cena con con un amico che non segue bene la dieta
, di rileggere il manifesto agile e i principi, pensando a cosa è possibile fare per attuarli sul software di cui parli.
Le pratiche permettiti di abbandonarle, abbi il coraggio, e copia/inventa altri modi di essere agili davvero.
Non puoi fare test di unità perché non ci sono oggetti da testare? E allora impara bene Selenium una volta per tutte.
Non puoi estendere un progetto OS? E allora committa sul trunk della community principale.
Sii aggressivo, ti sarà accanto qualcuno ad aiutarti. Io in prima linea!
L’obiettivo è sempre uno solo: trasformare una situazione rigida e improduttiva in un’oasi di redditività flessibile.
Delle pratiche alla fine… chi se ne importa!
Ciaoooo!!!
p.s. mancavi all’AgileCamp2009!
Direi che il tuo commento, rispecchia ovviamente tutto ciò che penso al riguardo. Anch’io credo che sia meglio essere agili con flessibilità, piuttosto che adottare tutte le pratiche ma senza buoni risultati, magari per problemi legati al codice e non al programmattore.
Per quanto riguarda l’essere aggressivo, purtroppo ci sono aziende che si definiscono OS che essendo però molto rigide o troppo poco, fanno fatica spesso a revepire i consigli utili o le commit utili dall’esterno.
Comunque si, Selenium è già un buon inizio per creare test funzionali.