Mi riallaccio al post di Felice Be an owner not a tenant per aggiungere una considerazione sullo sviluppo Iterativo, uno dei fondamenti dei processi agili. Il terzo punto dell’agile manifesto infatti cita

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Uno degli aspetti più importanti del rilasciare frequentemente e dell’approcciare uno sviluppo iterativo è la possibilità di valutare in maniera abbastanza obiettiva i cambiamenti introdotti nel team, sia di metodologia sia di tecnologia.

Nei progetti classici in cui ad esempio abbiamo uno scheduling di 6 mesi, in cui il team adotta alcune nuove tecnologie/metodologie, al termine del progetto è solitamente difficile dire cosa abbia funzionato e cosa no. Al contrario, in un approccio iterativo, come in SCRUM, la possibilità di fare una retrospettiva per ogni iterazione da un forte vantaggio al team.

Come detto da Felice, l’adottare un processo goal-driven ci rende non affittuari, ma proprietari ed è quindi normale cercare il miglioramento continuo, introducendo appunto nuove tecnologie/procedure. Grazie ad uno sviluppo iterativo il team ha frequenti punti di feedback dove si può valutare in maniera più obiettiva se il cambiamento introdotto ha aiutato o meno a raggiungere i goal dell’iterazione.

Supponiamo infatti di introdurre una nuova tecnologia nel proprio team, ad esempio un motore di indicizzazione come Elastic Search, perché ad esempio gli strumenti di analisi full-text e di ricerca del motore utilizzato di database non permettono più di raggiungere i goal previsti. Al termine della prima iterazione, il team può in maniera obiettiva dire se questa adozione ha giovato o meno, considerando comunque che ogni nuova tecnologia richiede tempo per essere appresa al meglio. Al termine della prima iterazione il team può quindi dare un primo giudizio sulla tecnologia ed iterazione dopo iterazione raffinare la consapevolezza sull’utilità o meno di ES nel proprio progetto, valutandolo sulla base di quanto è stato di aiuto al team nel raggiungimento del Goal.

L’aspetto interessante è che negli sviluppi Agili, l’introduzione di nuovi strumenti, come Elastic Search, solitamente viene fatta perché alcune User Story richiedono l’uso di strumenti specifici, oppure è emerso nelle retrospettive passate che gli strumenti attuali non sono più cosi utili per il raggiungimento dell’obiettivo.

Comparate questo modo di lavorare con una gestione waterfall, in cui ad esempio si allocano 6 mesi di tempo e si introducono molte nuove tecnologie nel team, perché si pensa che siano utili e agevoleranno il raggiungimento degli obiettivi. I rischi che si corrono sono molti, tra cui: non essere in grado al termine di capire correttamente quali tecnologie/metodologie hanno funzionato e quali no, oppure accorgersi nel mezzo del progetto che una tecnologia è completamente insufficiente e non adatta. Mentre in uno sviluppo Agile al termine di ogni Iterazione il team è pronto a mettere in discussione e modificare il modo di lavorare, in un waterfall questo non viene fatto e una scelta sbagliata ad inizio progetto solitamente si ripercuote pesantemente su tutto il team.

Gian Maria.