Il debito tecnico è una conseguenza delle decisioni prese sulla qualità del codice. È importante gestire il debito tecnico, ma anche non esagerare. Bisogna accettare che alcune cose vengano lasciate in sospeso o fatte male perché non sono una priorità. Alcune cose vale la pena farle male adesso, in modo da avere il tempo di farle bene in seguito. Quando decidete quali compiti sono urgenti e quali meno, usate stime di tempo fisse piuttosto che l’istinto o l’importanza percepita.
Sezione: Il debito tecnico è una conseguenza delle decisioni prese sulla qualità del codice.
Un’analogia comune per il debito tecnico è il mutuo. Allo stesso modo in cui si può accendere un’ipoteca sulla casa perché non vale la pena di pagare in contanti, si può contrarre un debito tecnico per ottenere qualcosa in fretta e poi pagarlo in seguito.
La differenza fondamentale tra questi due tipi di debito è che nel caso dei mutui ci saranno delle conseguenze tanto: se non li rimborserete completamente si può arrivare ad esempio alla perdita della casa o al pagamento di tassi d’interesse più elevati. Il debito tecnico non ha le stesse conseguenze: se non si risolvono i bug prima di rilasciare gli aggiornamenti del software o di aggiungere funzionalità, non succederà nulla di male (tranne forse qualche cliente insoddisfatto).
È importante gestire il debito tecnico, ma anche non esagerare.
È opinione comune che il debito tecnico sia una cosa negativa. Non è così. Il debito tecnico è semplicemente un atto di bilanciamento tra il costo della correzione di qualcosa ora e il costo della correzione in seguito. Si incorre nel debito tecnico quando si sceglie di lasciare qualcosa così com’è per far uscire il prodotto più velocemente, ma poi si paga per quella decisione in un secondo momento, dovendo tornare indietro e sistemare le cose in modo corretto.
La parola chiave è “scegliere”. Se state lavorando a progetti in cui non ci sono scadenze o requisiti rigidi per la qualità, allora l’assunzione di un debito tecnico potrebbe non avere alcuna importanza, o addirittura essere vantaggiosa! Ad esempio, se il vostro capo vi chiede di realizzare un’applicazione che consente di tenere traccia della rosa dei calciatori di una squadra di Fantacalcio (chiamiamola “Gestione del Fantacalcio”), potrebbe non essere preoccupante se prendete qualche scorciatoia durante la realizzazione di questa applicazione, perché non ci sono altri progetti in competizione fra di loro e nessun altro cliente potrà sentirsi trascurato. Ma se invece stessimo parlando di un software inerente le cartelle cliniche dei pazienti di un ospedale… beh, allora forse dovremmo pensarci due volte prima di cimentarci in qualche soluzione rapida e probabilmente errata!
Insomma, è sempre una questione di due pesi e due misure…
Bisogna accettare che alcune cose vengano lasciate in sospeso o fatte male perché non sono una priorità.
È impossibile fare tutto in una volta. Anche se fosse possibile, non sarebbe comunque una buona idea. Dovete accettare che alcune cose rimarranno incompiute o saranno fatte male perché non sono una priorità.
Questo non significa che dobbiate rinunciare ai vostri sogni e dunque accontentarvi della mediocrità: dovete solo dare la priorità a ciò che conta di più e lavorare prima su quelle cose. Se cercate di fare tutto in una volta, invece di concentrarvi su una cosa alla volta, allora niente sarà fatto abbastanza bene per le persone che contano: i vostri utenti!
Alcune cose vale la pena farle male adesso, in modo da avere il tempo di farle bene in seguito.
Ci sono cose che potete fare male adesso, ma che avrete il tempo di fare bene in seguito. Questo è un buon modo per iniziare un progetto. Ci sono molti esempi di questo tipo nello sviluppo del software:
- Si potrebbe iniziare scrivendo codice senza unit test o con una scarsa copertura dei test. A lungo andare questo renderà la vostra vita più difficile, perché ogni modifica romperà qualcos’altro e causerà molto più lavoro del necessario. Ma va bene così, perché alla fine i test verranno scritti e il vostro codebase diventerà migliore per questo!
- Si potrebbe anche iniziare utilizzando un’API non ancora stabile e magari una non ancora rilasciata? Il rischio è di dover riscrivere tutto quando l’API viene rilasciata; tuttavia, se non viene rilasciata (o non offre ciò di cui si ha bisogno), non c’è problema!
Quando decidete quali compiti sono urgenti e quali meno, usate stime di tempo fisse piuttosto che l’istinto o l’importanza percepita.
Quando decidete quali compiti sono urgenti e quali no, usate stime di tempo fisse piuttosto che il vostro istinto o l’importanza percepita.
- Non usate la vostra esperienza come guida: è troppo soggettiva. Utilizzate invece i dati storici per costruire una stima della durata di progetti simili in passato, e poi aggiustate per tenere conto delle nuove informazioni sul progetto attuale che potrebbero influenzarne la durata (come i bug nel codice).
Conclusione
In conclusione, il debito tecnico è un problema molto reale che può avere gravi conseguenze per il vostro prodotto e per il vostro team. Tuttavia, è importante non farsi prendere troppo dal tentativo di eliminare tutto il debito tecnico in una volta sola, perché questo può portare a un esaurimento e a una diminuzione della produttività nel tempo. Cercate invece di concentrarvi su un’area alla volta (come il miglioramento della qualità del codice o l’aggiunta di test), tenendo d’occhio anche le nuove opportunità che si presentano durante i cicli di sviluppo.
Dai un’occhiata ai nostri corsi e accelera definitivamente il tuo reparto IT!
