Nel corso dell’ultimo anno mi è capitato più di una volta di sentir parlare delle metodologie tradizionali – in contrapposizione a quelle agili – come di metodologie olistiche, in quanto imperniate sulla conoscenza completa dei requisiti di progetto.
Il ricordo della lettura di bellissimi libri anni fa e un breve ripassino sul concetto di olismo su Wikipedia rinforzano le mie diffidenze su questo uso del termine olistico.
Mi spiego: olismo significa concepire un sistema nella sua globalità e studiarne il comportamento e le reazioni emergenti non solo dalle sue singole componenti ma anche – e soprattutto – dall’interazione tra le parti stesse. L’approccio riduzionista – in diversi ambiti della scienza e della filosofia – si oppone a quello olistico e promuove la riduzione di un ente, di un concetto o di una metodologia alle entità più elementari possibili. La tendenza della scienza classica e, quindi, anche dell’ingegneria classica è sempre stato proprio quest’ultimo: cercare di conoscere l’intimo dettaglio perdendo di vista l’insieme, perdere di vista la foresta contemplando l’albero.
Negli ultimi decenni la nascita di nuove discipline scientifiche come la scienza della complessità hanno posto al centro dell’attenzione la necessità per la comunità scientifica di saper abbracciare anche un approccio olistico.
Nello sviluppo agile una serie di pratiche manageriali o ingegneristiche cerca di regolamentare alcuni dettagli della vita di un progetto software producendo come risultato globale – epifenomeno, direbbero alcuni – un successo dipendente dalla sinergia di quelle pratiche.
In questo riconosco olismo. Nel ben tristemente noto tentativo di raccogliere tutte le specifiche di un progetto software in un unico documento iniziale riconosco riduzionismo.
Intuisco una certa analogia fra il moto degli elettroni in un conduttore elettrico e il percorso che le user story fanno dalla loro scrittura al loro completamento.
Gli elettroni, se non è applicato un campo elettrico, si muovono per la sola agitazione termica e quindi il loro moto ubbidisce alle leggi della statistica e al principio di equipartizione dell’energia, secondo il cosiddetto moto browniano. Se applichiamo un campo elettrico il moto delle particelle resta caotico e non diventa affatto uniforme e rettilineo, ma la somma dei moti caotici presenta una deriva che costituisce per sé la corrente elettrica.
L’implementazione delle user story è soggetta, nostro malgrado, ad una certa caoticità di moto: scritta la storia il percorso alla completa realizzazione della feature descritta non è mai senza regressioni e, addirittura, per certi versi il destino di una user story non è mai certo, perchè la sua corretta implementazione può essere corrotta, dopo anche molti mesi, dall’integrazione nel nostro sistema di nuove storie.
I test automatici – come li conosciamo nel test driven development – danno a questo moto caotico un punto di soglia, di non ritorno. Una storia chiusa in un test non può più tornare indietro, perlomeno per gli aspetti caratterizzanti che ne abbiamo voluto testare. Come se lungo il conduttore in cui scorre una corrente elettrica avessimo installato un diodo, senza certo impedire agli elettroni di vagabondare in ogni direzione possibile all’interno del conduttore a livello locale, ma allo stesso tempo assicurandoci che ad un livello più globale la corrente scorra solo nella direzione voluta.
Le nostre user story, con l’applicazione rigorosa del test driven development, rimangono così naturalmente caotiche, ma soggette ad andare dalla scrittura all’implementazione certa senza regressioni impreviste.
L’ingegneria gestionale e dell’automazione costituisce un compendio enorme di tecniche e conoscenze sviluppate per razionalizzare e ottimizzare i più diversi processi industriali. Il project management agile, e lo stesso extreme programming, propongono in realtà tecniche prese in prestito da quel mondo riviste e corrette per adattarsi all’industria che ci riguarda più da vicino: quella del software. In questo articolo vediamo qualche esempio. continue reading »
![[del.icio.us]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/digg.png)
![[Facebook]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/facebook.png)
![[Google]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/google.png)
![[LinkedIn]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/linkedin.png)
![[Technorati]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/technorati.png)
![[Email]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/email.png)