ALM, un approccio pratico alla gestione del Debito Tecnico

Il problema del “Debito Tecnico” è spesso trascurato durante le normali fasi del ciclo di sviluppo, anche se (come abbiamo detto nel post specifico), nel medio periodo, porta ad una rincorsa continua della manutenzione correttiva a scapito di quella evolutiva.
Come possiamo approcciare praticamente il problema?
In un contesto Agile, il Technical Debt dovrebbe emerge ed essere affrontato in ogni Iteration Meeting, in modo da capire repentinamente quali azioni intraprendere. In alcuni casi estremi il momento adatto per discuterne potrebbe essere addirittura il Daily Meeting, anche se questo tende a destabilizzare le attività previste per la specifica iterazione e rischia di annullare il vantaggio di un approccio “time boxed”, spostando il focus su un approccio Lean che, però, richiede una forte maturità del Team.
Restando, quindi, nella prima ipotesi, l’idea è quello di inserire, quando se ne ravvisa la necessità, una short-iteration qui ribattezzata: CTBi, ovvero Clean Technical Debt Iteration.
Questa iterazione breve (metà di quella standard adottata), consente di stabilizzare quando realizzato e far rientrare nel computo della Velocity, e dei relativi diagrammi di Backlog, anche le User Story che non si sono precedentemente riuscite a chiudere e che, quindi, hanno un peso 0 sulle stime.
Facciamo un esempio pratico: siamo nella situazione illustrata dalla figura seguente in cui l’Iterazione 2 è temporalmente conclusa (il framework Agile adottato è Disciplined Agile Delivery), ma la prima User Story non è completa!

cbt dashboard

User Story non completata

Attenzione: il Valore creato è 0, nonostante la User Story sia stata parzialmente completata. Questo perché la stima della Velocity (Story Point o Ideal Day, medio termine) è legata al Valore prodotto è non ai task (stima in ora, breve termine) realizzati.
Ma è corretto considerare completamente nullo il contributo della User Story? Probabilmente no, per questo possiamo, dopo una serie di iterazioni che presentano casi simili, creare una CTBi in cui spostare le User Story incomplete.
Questo approccio consente di evidenziare anche visivamente la presenza di un “ritardo” e di gestirlo con una modalità di recupero in modo da evitare la tentazione di ignorare la cosa: “ma tanto si tratta di poca roba”.
Essendo la CTBi una short-iteration, la Velocity stimata avrà un peso più alto (rapporto Story Point/Time) rispetto a quella standard, permettendo di valorizzare quanto era stato già completato e di ottenere una media più realistica nell’istogramma che rappresenta la Velocity per iterazione.
Chiaramente si tratta di un approccio “una tantum” che non deve diventare sistematico. Se il Team non riesce mai a completare le User Story all’interno dell’iterazione, vuol dire che esiste un problema diverso da affrontare, ad esempio: incapacità di stimare correttamente la complessità relativa delle attività, sottodimensionamento, lacune tecnologiche, ecc.
Ma l’approccio CTBi enfatizza la trasparenza del Team, spingendolo a ragionare ancor di più sui problemi, e aiuta a diminuire l’ampiezza del Cono di Incertezza nelle stime di progetto.

Comments are closed.