Sono più di due decenni ormai, che nel mondo dello sviluppo software è stata introdotta la parola “Agile”, con il concetto di “programmazione agile” (durante la conferenza vedremo anche la differenza tra la “A” maiuscola nella parola e qualla minuscola e perché questa può essere importante). Più precisamente nel 1999 è stato coniato questo termine e venne redatto il “Manifesto per lo Sviluppo Agile di Software”.

E come ogni manifesto che si fa rispettare (ogni analogia politica è puramente intenzionale), anche questo manifesto è pieno di bei propositi, ma in pratica come viene attuato?

I metodi di sviluppo tradizionale (chiamati anche “a cascata”, “waterfall”, o “ingegneria del software”, ecc, ci sono diversi modi per chiamarlo, a proposito e a sproposito, dipende da chi parla dell’argomento e come lo vuole eticchettare) venivano messi in questione o apertamente condannati come inefficaci poichè, si diceva, portavano al fallimento dei progetti o - come minimo - alla lentezza e ai ritardi nella realizzazione dei prodotti software, vista sempre come un fallimento.

E’ dal primo momento, dalla redazione del “manifesto”, che l’“Agile” ha trovato dei ferventi sostenitori come anche degli acerrimi nemici. Ma, piano piano, ha fatto la sua strada, tanta strada, imponendosi in diverse aziende. Molti libri sono stati scritti (di nuovo, a proposito e a sproposito), molti corsi erogati e molte conferenze fatte. Fior di consulenti incravattati vanno tuttora in giro per le aziende dove il “sacro verbo” non è stato ancora diffuso e si offrono di portare l’azienda sulla “retta via”, dietro la giusta indulgenza, ovviamente, che l’azienda deve pagare per espiare i propri peccati. Sono stati creati anche dei corsi di certificazione, da pagare profumatamente, dove ai partecipanti viene rilasciato un certificato che attesta che per due giorni hanno diligentemente scaldato con il proprio fondoschiena la sedia nell’aula del corso. E per molte persone e aziende, l’“Agile” ormai è diventato una specie di dogma: non viene messa in questione, pena eterno rogo per i miscredenti.

Ma, togliendo dalla superfice la retorica e i dogmi, si viene a scoprire - sorpresa, sorpresa - che anche i progetti “agili” falliscono come falliscono i progetti sviluppati “a cascata”. Non è che allora, abbiamo impiccato il “colpevole” sbagliato? Non è che alla fine le ragioni dei fallimenti debbano essere cercate da qualche altra parte? Come anche le ragioni dei successi? Non è che per caso lì dove i progetti “agili” hanno avuto successo non è stato affatto il merito dell’“Agile”?

I sostenitori dell’“Agile” dicono, ovviamente, come anche nel caso di quell’altro “manifesto” più noto, che il manifesto “Agile” va benissimo, ma va cercato il colpevole per i fallimenti nel fatto che l’“Agile” non viene messo in pratica in modo corretto. Oppure come nel caso di una qualsiasi setta religiosa, se non sei guarito dal cancro o se non ti ricresce la gamba amputata, è solo perche non stai pregando in modo corretto, dunque la colpa è solo tua. Si arriva perfino a sostenere che se non si è seguita rigidamente questa o quella pratica “Agile”, allora vuol dire che non si può dire che il progetto sia stato sviluppato in modo agile (o “Agile”) e dunque non è l’“Agile” il colpevole. Controsenso? Per alcuni non lo è!

Però (e per fortuna) negli ultimi anni in molti programmatori sta crescendo anche la resistenza attiva contro questa miopia dogmatica e contro i malintenzionati o farlocchi che intenzionalmente la difondono. Se prima si erano limitati a scuotere le spalle dicendo “ognuno faccia come gli pare”, dopo essere stati costretti dalle proprie aziende a participarvi, cominciano a mostrare una certa insofferenza e ribellione. Tra gli stessi firmatari del “manifesto” (no, non facciamo nomi qui…) si sono levate delle voci di dissociazione da quella cosa che è diventata l’industria “Agile”. Come minimo, cercano di mitigare il problema cercando di aggiungere qualche chiarimento della propria posizione, reinterpretando retroattivamente il “manifesto”, senza dissociazione aperta.

A questo punto ci si impongono le domande: “Ma allora a chi credere?”, “Cosa fare?”, “Come fare?”, “C’è qualcosa che si salva dell’Agile?”, “E il nostro progetto che sta fallendo, ce la facciamo a salvarlo?”, “E come facciamo con i nostri ingenti investimenti?”

A queste domande cercherà di dare le (prime) risposte la nostra conferenza di quattro ore. E faremo parecchio uso di citazioni delle fonti (comunemente ritenute) autorevoli, compresi anche alcuni dei firmattari del manifesto.