il post di Riccardo mi ha dato l'occasione per riflettere su un disagio che sento presso le aziende che intendono iniziare o già utilizzano i metodi agili.
Credo che la questione sia dovuta alla differenza della situazione delle aziende italiane, formate soprattutto da PMI, rispetto a quelle anglosassoni.
In generale ho visto l'interesse ad utilizzare alcune pratiche agili (soprattutto l'introduzione dei test e la continuous integration) in situazioni dove è presente quello che io chiamo il cowboy programming.
Sostanzialmente una situazione di quasi totale anarchia dove la pratica più utilizzata è il code and fix. In queste realtà le pratiche agili vengono viste come una burocratizzazione del processo e non uno snellimento.
Molti articoli che ho visto in rete invece mostrano i vantaggi dei metodi agili rispetto al waterfall. Il waterfall è l'esatto opposto del cowboy programming e quindi il metodo agile, in questo caso, viene visto come una sburocratizzazione del processo.
La parola burocrazia ha un'accezione negativa in Italia per i motivi che tutti conosciamo, ma è fondamentale per il funzionamento di qualunque organizzazione compresa un'azienda di sviluppo software.
Schematizzando con un grafico questi concetti potrei ipotizzare che nessuna burocrazia sia un danno e quindi un beneficio negativo, analogalmente a troppa burocrazia.
Un altro luogo comune è quello di considerare le pratiche agili come un silver bullet: cioè necessarie e sufficienti a portare a compimento con successo un progetto. Mi spiace, ma si possono seguire tutte le pratiche agili e fallire.
Il motivo è dovuto alle precondizioni affinchè un progetto abbia successo come ad esempio le competenze degli sviluppatori, ecc. Analogamente un progetto software puo' avere successo anche senza usare nessuna pratica agile.