In questi giorni sto leggendo il mio primo libro dedicato specificamente ai processi agili con particolare rilevanza verso l'implementazione XP: " The Art of Agile Development" di James Shore & Shane Warden. Libro che ovviamente consiglio.
Quando leggo testi di questo tipo, mi capita di trovare ragionamenti e modelli, che in modo 'quasi scientifico' rispondono o confermano alcune idee, sensazioni ed esperienze, che talvolta fanno parte delle discussioni quotidiane con i nostri colleghi e altre volte con i nostri diretti responsabili. (Peopleware da questo punto di vista è stato fantastico)
 |
Ho trovato molto utile ed interessanti le considerazioni che fanno Shore e Warden sul debito tecnico (Technical Debt) ed in particolare un illuminante riflessione sull'approccio "quick and dirty" cioè veloce e sporco. Non mi sento di criticare in generale le ragioni alla base di questa filosofia, per quanto mi riguarda però la osteggio quando possibile.
Infatti, quando veloce e sporco significa in fretta e fatto male allora accumuliamo debito tecnico, e al riguardo si potrebbero fare tante illustrazioni tratte dalla vita reale. Se trascuriamo la pulizia di una casa o alcuni lavori necessari di manutenzione, prima o poi ne paghiamo le conseguenze, con l'unica differenza che quando sviluppiamo software stiamo anche progettando e le conseguenze di un progetto veloce e sporco sono decisamente peggiori.
Infatti citando gli autori di "The Art of Agile Development" ... Technical debt is the total amount of less-than-perfect design and implementation decisions in your project. This include quick and dirty hacks intended just to get something working right now! ... The bill for this debt often comes in the form of higher maintenance costs ... Come è vero!
Gli autori evidenziano che XP ha un approccio maniacale al debito tecnico includendo pratiche che servono a controllarlo e a prevenirlo, come dire... una buona gestione finanziaria! :-)
|
In conclusione "quick and dirty" nell'eccezione peggiore è da non usare o da usare solo quando rimane davvero l'ultima risorsa.
Meglio invece un approccio "quick and dirty" XP-like (ovviamente è una forzatura ... i puristi di XP mi odieranno ;-)): iterazioni brevi (quick) con lo scopo di produrre versioni di software funzionanti, di qualità ed effettive senza concentrasi eccessivamente su dettagli di poco conto (dirty) con l'obiettivo di produrre nel minore tempo possibile software che permetta al nostro cliente di poter ottenere un immediato vantaggio competitivo. Quindi è certamente meglio "quick but right" cioè veloce ma corretto e funzionante.