In
relazione al mio post precedente, ho deciso di rispondere con un nuovo post (per motivi di
visibilità e di spazio) ai feedback veramente interessanti di Davide, Antonio, Claudio e
Luca.
@Davide
Post molto
interessante! Visto che hai notato anche tu un corrispettivo matematico
dell'approcio Agile (approcio che si ritrova esattamente indentico - come
principio di base - nella modellazione dei db attraverso la Normalizzazione) ti
rimando ad un mio post di qualche tempo fa: http://blogs.ugidotnet.org/nettools/archive/2006/12/20/60861.aspx sono curioso di sapere che ne pensi.
Innanzitutto ti ringrazio per i
complimenti...ricambio, per l'ottimo lavoro che stai portando avanti con Ugiss,
veramente molto utile!!!
Ho letto il tuo post, ma sinceramente non credo sia
così semplice 
e forse nemmeno possibile 
definire univocamente un metodo matematico che
possa dimostrare la maggiore funzionalità di uno sviluppo agile rispetto ad
un approccio, diciamo così, classico.
Nel campo agile ho ancora poca
esperienza e quindi sono poco attendibile, ma per quel poco che ho potuto vedere
e toccare con mano, in relazione al tuo post, posso solamente dire, per rimanere in ambito
pseudo-matematico 
, che la buona riuscita di un progetto che si basa
sulle metodologie agili, necessita, ancor più (IMHO) di un progetto che si basa
sulla metodologia "tradizionale", di condizioni al contorno (leggi competenza,
esperienza...) molto forti. La variabilità di queste condizioni al contorno e la
loro non facile definizione sono quei parametri aleatori che, secondo me, non
permettono di identificare quel formalismo che "stai" cercando...
Purtroppo
, almeno per ora, credo che per dimostrare i benefici
di un approccio agile, il modo migliore sia quello di portare ad
esempio casi reali di progetti "ben riusciti"...cosa che per altro
gran parte di noi sta già facendo!!!
@Antonio
Mi piace l'idea delle approssimazioni successive, anche
se, mentre in matematica c'è un unica soluzione nel design sono numerose e non è
così immediato capire quale sia la migliore.
L'esperienza di diversi anni di
programmazione senza TDD può essere sia uno svantaggio che un vantaggio, lo
svantaggio è nella fatica di entrare nell'ottica di essere guidato dai test nel
design dell'applicazione, in quanto pensi di conoscere già qual'è la soluzione
migliore; il vantaggio è quello di possedere un bagaglio di conoscenze che ti
permettono di non commettere le ingenuità di un principiante.
Io ormai non
riuscirei più a farne a meno del TDD e vedere un'applicazione senza test mi dà
la stessa impressione di girare in macchina senza cinture e cioè di correre un
rischio inutile, ma è un discorso personale e non è detto che se vale per me
valga per tutti.
Concludo incoraggiandoti nell'apprendimento del TDD vedrai
che ti porterà molti frutti.
Condivido buona parte del tuo feedback...il fatto
che nel design ci siano più soluzioni "ottime", è uno dei presupposti per i
quali ritengo che una forte dose di esperienza porti ad una più celere e
corretta individuazione/definizione della soluzione cercata. Prendendo come
assodato il concetto che, anche definendo come punto di partenza un design
lontano da quello ottimale si converge comunque verso la soluzione ottima
(attenzione!!! ho scritto si converge e non si ottiene), la
possibilità di individuare, già a priori, un buon punto di partenza, abbatte il
numero di "sessioni" di refactoring e quindi incrementa la produttività.
Ti
ringrazio per l'incoraggiamento e lo estendo a tutti...TDD ti cambia la vita,
provatela!!!
@Claudio
"per rendere
veramente agile lo sviluppo di un'applicazione tramite TDD deve esserci una
considerevole dose di esperienza"
IMHO il TDD è un ottimo modo per
conoscere/capire/digerire il paradigma OO
Assolutamente sì...l'iteratività dell'approccio
agile, o meglio del TDD, permette di stabilire a che livello di granularità la
nostra applicazione si spinge nell'utilizzo del paradigma OO, dell'utilizzo dei
pattern e così via. Spostare sempre un po' più in là il livello di granularità
(non oltre un certo limite, ovviamente) permette di approfondire e sviscerare il
paradigma OO in tutti i suoi aspetti.
@Luca
"E' l'esperienza che ci permette di partire da un punto già
"prossimo" alla soluzione ottimale"
Su questo non concordo: il punto è
l'esperienza che accumuli durante il primo tentativo e le nuove info che nel
frattempo diventano disponibili.
Quindi direi piuttosto "sbagliando si
impara". Se poi aggiungi che il bersaglio è per sua natura mobile (l'80% di vita
di un software consiste in evoluzioni e mutamenti) la "soluzione ottimale" cessa
di esistere.
Per evitare equivoci, forse è meglio fare una
distinzione tra esperienza generale ed esperienza specifica.
Cosa voglio dire?
E' molto semplice...con esperienza generale (che è quella a
cui faccio riferimento nel mio post precedente) intendo proprio la conoscenza e
l'assimilazione che ognuno di noi ha del paradigma OO. Una buona
conoscenza/esperienza dei design pattern, per esempio, ci permette di
individuare a priori i casi in cui è necassario utilizzare uno State piuttosto
che un Abstract Factory o piuttosto che nello specifico non è necessario nessun
pattern, evitandoci inutili complicazioni.
L'esperienza specifica invece è
quella relativa al caso in esame e comprende la conoscenza dell'ambito
applicativo nel quale ci si sta muovendo. E' questo genere di esperienza che,
nelle approssimazioni successive dovute al refactoring, cresce e si
definisce insieme all'architettura dell'applicazione.
Condivido per altro,
che il bersaglio è per sua natura mobile, ma non che la soluzione ottimale cessa
di esistere...al massimo si sposta!!!
Un ringraziamento a tutti, comunque, per avermi
dato la possibilità di riflettere ulteriormente su questo argomento!!!
Ciao a
tutti 
...sovvertiamo le gerarchie...
powered by IMHO 1.3