Era da un bel po' di post che non facevo il punto sulla mia malsanità mentale informatica. Vediamo se si riesce a recuperare...
Da circa un annetto, per "colpa" dei soliti noti, mi sto arrovellando il cervello in particolar modo sugli aspetti di "metodologia di gestione della soluzione" e di "progettazione di una soluzione", quindi la maggior parte delle considerazioni ruoterà su questo e su un paio di "IMHO" su NHibernate.
Essendo tanto tempo che non mi fermo a fare il punto, sono anche tante le considerazioni, percui credo che la cosa migliore sia di affrontare un argomento alla volta.
Metodologie di gestione della soluzione e dello sviluppo
Devo dire che in questi due anni ho visto crescere sempre più l'attenzione verso varie "metodologie".
Rimane sicuramente indimenticabile la prima metà dell'Agile Day 2005, in cui sono riuscito a dare un nome ed a trovare una corrispondenza "là fuori" a tante abitudini, principi e valori su cui ho sempre puntato in modo spontaneo.
Impatto simile lo aveva avuto anche la precedente sessione di Lorenzo su MSF, anche se in quel caso i punti in comune con quelle che erano le mie abitudini risultarono decisamente minori (e comunque non ho ancora imparato a festeggiare come si deve dopo la conclusione con successo di una commessa!!).
Poi il primo contatto (teorico) con l'XP... Qui da un buon sviluppatore ci si aspetterebbe una frase tipo "e fu subito amore" ed invece purtroppo non è così.
La cosa che però mi fa piacere è che forse però, dopo un anno di scervellamento, ho capito perchè non è scattata la scintilla.
eXtreme Programming
Le due sessioni di apertura agli Agile Day 2005 e 2006 (ancora un grazie a Nicola, PierG e Luka) mi sono entrate in testa, le ho ruminate ed alla fine, dopo aver provato a verificarle sulla mia attività, forse sono riuscito a capirle!
L'XP è una metodologia estrema di nome e di fatto. Il suo enorme valore aggiunto IMHO consiste nel fatto che cerca di dare una risposta (funzionante!!!) a casi di esigenze estreme, con tempi di consegna estremamente ridotti, necessità di altissima qualità (ma questo IMHO dovrebbe valere per TUTTI i sw) e con un legame team/cliente estremamente forte già in partenza per differenti motivi.
Non mi dilungo sul significato di queste affermazioni (a meno che non interessino qualcuno, ovviamente), ma questo mi ha fatto capire che fare XP perchè "fa figo" o va di moda, secondo me è semplicemente sbagliato!
L'XP è così straordinario proprio perchè, in piena metodologia agile, trasforma un grosso problema in una grande opportunità e cioè facendo perno sull'estrema necessità, tende a spazzare via le debolezze dell'interazione umana.
Se manca questo perno, IMHO esistono due possibilità: a differenza dei collaboratori che si possono selezionare o quantomeno "indirizzare", o si ha la fortuna di avere sempre clienti "d'oro" (a me fortunatamente è capitato in più di una occasione con grandi risultati) oppure si rischia di sbattere il muso o quantomeno di non ottenere realmente grandi vantaggi!
Per cui... promosso l'XP, ma solo nei casi che lo richiedano ed in un certo senso lo giustifichino!
Ovviamente questo non significa che nelle altre commesse si debba per forza ignorare del tutto l'XP...
Promossi a pienissimi voti ed in ogni caso, invece, i principi ed i valori delle metodologie di sviluppo agile.
Microsoft Solution Framework
Purtroppo non sono andato oltre la sola sessione di Lorenzo per mancanza di tempo, ma devo dire che ho la stampa delle sue slides più "significative" sempre a portata di mano. Quando ho qualche incertezza le consulto: a volte non mi si accende niente, altre volte invece mi danno un po' più di sicurezza in qualche decisione.
Di base però il problema nell'adottare "veramente" MSF è che la mia collaborazione, anche su progetti "più grandicelli", non supera mai le 3-4 persone. Quindi le utilizzo come semplice "spunto".
Team System
Altro campo in cui le sessioni di Lorenzo la fanno (giustamente) da padrone. Ho apprezzato le sessioni e i webcast che ho seguito, ma avendo un team piccolo e distribuito geograficamente dubito fortemente che la spesa sia affrontabile senza certezze, percui ho dovuto abbandonare.
Dalle poche prove che avevo fatto con le demo (client+server) devo dire che comunque mi è piaciuta molto la gestione dei sorgenti e molto meno la "frammentazione" della suite, che (se non ho visto male) utilizza SharePoint per la gestione della soluzione.
Molto bello anche il tool (DSL) di progettazione di un'applicazione distribuita. Sarebbe bello che fosse solo un punto di partenza, comunque per me è stato sicuramente un ottimo spunto.
Comunque non avendo approfondito a dovere non mi sembra sensato esprimere veri giudizi.
Quindi...
...sono ancora orfano di un tool che gestisca come si deve le mie soluzioni e per ora l'unica strada che riesco ad immaginare è quella di iniziare a creare qualcosa di nuovo, facendo tesoro delle esperienze fatte fin'ora in merito.
So che è quasi follia, ma se razionalmente è l'unica strada percorribile, quantomeno ci si può provare.
Segue (si spera) nei successivi due posts.