La tua squadra del cuore fa il suo esordio in serie A. Sai già che soffrirai, perché sventura vuole che sia una piccola provinciale: onesti mestieranti del pallone che nulla hanno a che vedere con gli strapagati fuoriclasse delle big del campionato. La tua squadra deve scendere in campo col coltello fra i denti, correre 6 volte più del normale per colmare con la fisicità dei suoi atleti la differenza tecnica che la separa dalle formazioni più quotate. Con tutti i limiti del caso: condizione atletica messa a dura prova, infortuni più probabili, calciatori in affanno e scarsa lucidità.
I team di sviluppo corrono gli stessi rischi quando sono chiamati a modificare progetti software complessi. Ad esempio, ogni ritocco del codice in una classe comporta la revisione di altre parti del codice, l’aggiornamento della documentazione e l’avvio di nuove fasi di test. Tante attività che spesso, a causa di tempi di lavoro ristretti, non vengono completate come dovrebbero. Lo sviluppatore statunitense Ward Cunningham ha coniato l’espressione Debito tecnico per indicare questo sfasamento:
“Il debito tecnico è il lavoro che deve essere ancora fatto per poter considerare totalmente completata una singola attività di sviluppo. Quando si inizia una modifica ad un progetto software, spesso devono essere apportate altre modifiche coordinate in altre parti di codice, nella documentazione ecc… Le modifiche richieste, ma non completate, sono considerate debito tecnico, che dovrà essere pagato prima o poi in futuro”.
Il nostro team di sviluppo da Serie A ha comunque tutte le potenzialità per mettersi al pari delle squadre più blasonate e rilasciare software dalle grandi prestazioni. Un buon inizio è comprendere quali siano le fasi più deboli del ciclo produttivo di un software – progettazione, analisi, architettura, sviluppo, test – e analizzare con obiettività gli effetti negativi sul rilascio finale.
Debito tecnico, le cause
Cosa ci rende, dunque, meno competitivi e più deboli in fase di rilascio?
Mancanza di visione di insieme
Il team di sviluppo lavora a compartimenti stagni, per cui tasselli di codice e problemi comuni che potrebbero essere standardizzati e condivisi vengono duplicati o gestiti di volta in volta in maniera diversa. Il Debito nasce dall’utilizzo di strumenti che non agevolano la manutenzione del codice in chiave scalabile e coerente.
Progettazione avventata
L’ansia di dover assecondare le richieste dei clienti induce PM e commerciali a stimare tempi di rilascio troppo ristretti rispetto alla mole di lavoro effettivamente necessaria. Il Debito è causato da mancanza di tempo o affanno per rincorrere le scadenze impossibili.
Analisi superficiale
Si dedicano all’analisi tempi e risorse insufficienti a dissipare ogni dubbio o ambiguità su tutti i workflow dell’applicazione da realizzare. Il Debito è pari al tempo che il team leader e gli sviluppatori devono investire per trovare soluzioni o analizzare processi tralasciati in precedenza.
Documentazione insufficiente
Al kick off di un nuovo progetto, o in una fase successiva, la documentazione fornita da chi ci ha preceduto è parziale o totalmente assente. Il Debito nasce dal tempo necessario per ispezionare il codice e l’architettura del software, le classi, gli oggetti.
Poca esperienza dei membri del team o poca collaborazione senior/junior
(Troppi) sviluppatori junior non sono adeguatamente supportati da colleghi senior, rallentando sia l’apprendimento di conoscenze più approfondite sia i tempi di rilascio. Il Debito si ripercuote sulla qualità del software, sullo slittamento dei tempi, sull’aumento esponenziale dei costi e sull’autostima dell’intero team.
Sottodimensionamento della fase di test
L’assenza di tool per il testing o la volontà di rilasciare in collaudo o produzione senza un’adeguata attività di ricerca dei bug aumenta esponenzialmente la possibilità di consegnare applicazioni instabili. La percezione del Debito cresce all’aumentare delle segnalazioni.
Debito tecnico, gli effetti
Quando si comincia un progetto con il piede sbagliato è molto difficile riprendere la strada maestra. Per tamponare le falle di un’applicazione instabile o mal progettata, gli sviluppatori corrono ai ripari con patch a cerotto che possono sì funzionare, ma con una pesante incognita sulla loro resistenza futura. Un po’ come pretendere di mantenere a galla un transatlantico inchiodando delle travi di sughero negli squarci dello scafo mentre affonda.
L’ombra del Debito tecnico pende su ogni team di sviluppo. Non una scure, non una minaccia ma una condizione cronica e prevedibile. A meno che non si lavori nel Dream Team, negli Harlem Globtrotters dello sviluppo, tutti abbiamo esperienza di clienti che vogliono le modifiche pronte per ieri, di rapporti tesi fra PM, analisti e sviluppatori, di chi scrive codice originale in maniera brillante e chi, al contrario, fa semplicemente qualche copia e incolla dai forum online.
Come ridurre il più possibile il Debito tecnico? È possibile eliminarlo all’origine? Ne parliamo prossimamente su questo blog… stay tuned.
E come sempre… c’mon, let’s code!
