Rispondere ai cambiamenti
Poco fa, mentre attendevo l’inzio del Trofeo Birra Moretti, ho letto un post su UgiDotNet di Francesco Carucci dal titolo “L’ideale e’ minimizzare al massimo i cambiamenti”.
Riporto una parte:
L’ideale per me e’ Keira Knightley che si lava, non rompe mai le balle e ama solo me… ma non credo che accadra’ e allora perche’ sperarci?
In quindici anni che programmo non ho mai visto un progetto durante il quale le richieste fossero fisse, le feature necessarie non cambiassero mai, si sapesse in anticipo tutto cio’ che era necessario scrivere e come risolvere ogni problema, con richieste precise e circostanziate descritte nel dominio della soluzione.
Non e’ mai successo e allora perche’ sperarci?
Il primo pensiero che mi è venuto in mente è che sembra un ottimo spot per i metodi agili. Alla fine se si legge il manifesto un punto fondamentale è - cito testualmente - “Responding to change”.
Siamo tutti d’accordo che una buona progettazione, con un’analisi ben fatta, un’architettura ben definita, un design preciso, etc., sia il massimo, ma se per cercare di ottenerlo ci si irrigidisce con il rischio di non accontentare il cliente e allungare i tempi di sviluppo all’inverosimile, allora forse il gioco non vale più la candela.
Intendiamoci, non sono un fan sfegatato dei metodi agili, certi approcci li ritengo eccessivi, ma penso che buona parte della filosofia che vi sta dietro sia da abbracciare sempre e comunque. Come faceva notare Francesco, visto che tutti sappiamo che è impossibile riuscire ad arrivare a LE specifiche, nel senso di immutabili e precise, allora cerchiamo di arrivarci ma senza intestardircisi sopra e preparandosi mentalmente a quello che inevitabilmente avverrà.
O per riprendere l’esempio di Francesco, visto che difficilmente usciremo con Keira, proviamoci pure ma prepariamoci anche alla possibilità di uscire con qualcun’altra 
