Leggendo l'interessante transcript della "Agile Chat" postata da Emanuele mi sono venuti in mente una serie di considerazioni che vorrei condividere con tutti, in modo da poter avere un feedback su queste idee che tra poco andrò a descrivere e che mi sembrano il "clou" della problematica.
Per chi non volesse leggersi tutto il transcript, basta sapere che un dei punti fondamentali affrontati nella chat è stato quello di "come far applicare le metodologie agili ai team e quindi farle capire ed apprezzare anche ai manager/boss/responsabili".
Leggendo il transcript mi è venuto in mente di partire dal presupposto contrario, e chiedermi perchè è tanto difficile introdurre tali metodologie. Se fossi un manager il mio timore sarebbe dovuto al fatto che la metodologia agile non mi da "sufficiente sicurezza" di poter portare a compimento un progetto entro tempi ragionevoli (notate che non sto dicendo entro i tempi prestabiliti, ma semplicemente ragionevoli, assumendo quindi che qualche rallettamento dovuto all'adozione di una nuova metodologia - diversa rispetto a quelle classiche - sia naturale).
Partendo da questo assunto, il problema quindi si sposta sulla necessità di poter "provare" in modo inconfutabile che tale metodologia sia quantomeno in grado di portare a compimento il progetto in suddetti tempi ragionevoli. In pratica dobbiamo dimostrare che funziona ed è applicabile.
Oggi come possiamo fare questo? Semplicemente portando al responsabile che mostra una certa diffidenza una certa quantità di progetti che tramite l'utilizzo di metodologie agili hanno avuto successo. Anche facendo questo però non sempre si riescie...perchè le metodologie agili, con il suo Refactoring, TDD e via dicendo danno una sensazione di "inconcludenza". Non di rado alcune persone mi hanno fatto osservare che secondo loro il refactoring è paragonabile a un continuo fare-e-disfare che non è produttivo. Capisco questo punto di vista: è piuttosto naturale; il fatto di "vedere" i propri sviluppatori continuare a fare "continue correzioni" dà sicuramente meno sicurezza al manager piuttosto che un progetto su carta dettagliato al millesimo. Certo poi magari il primo riescie ad essere portato a termine ed il secondo no, ma non è questo il punto. Noi lo sappiamo, il problema è farlo sapere a chi di dovere.
Posto che secondo me questa "inerzia sociale" dovuta al fatto che i responsabili di progetto attuali (o superiori) sono (mediamente) di qualche generazione più vecchi di noi avrà una sua naturale fine...il problema che se ne delinea, dal mio punto di vista, è che NON ESISTE UNO STRUMENTO FORMALE PER DIMOSTRARE CHE L'UTILIZZO DI OOD + METODOLOGIE AGILI SIA FUNZIONANTE! (Ok magari ho scoperto l'acqua calda...è da un pò che ci penso...oggi ho avuto il coraggio di scriverlo 
)
L'unico "strumento" che attualmente abbiamo sono le nostre od altrui esperienze, ma non possono purtroppo essere definite "formali", ossia dimostrabili inconfutabilmente, in modo rigoroso e ripetibile. Da qui la mia considerazione: fino a quando qualcuno (magari qualcuno di questo UG ) non riuscirà a creare un metodo formale (e quindi matematico / logico) che ci permetterà di dimostrare che il nostro progetto può funzionare sulla carta (relativamente alla modellazione OO della nostra necessità) e creerà una metodologia formale di applicazione delle regole che l'approcio agile definisce attualmente su quel progetto, non credo potremo mai risolvere il problema del dover convincere un responsabile che l'approcio agile sia quello corretto. A meno di non aspettare il ricambio generazionale completo del personale.
A questo punto chiedo: non sentite anche voi questa "mancanza"?