Come si fa a sapere se c'è un debito tecnico nel progetto? Come misurare il suo volume? [duplicare]

Question

Come si fa a sapere se c'è un debito tecnico nel progetto? Come misurare il suo volume? [duplicare]

#1 da (2 voti)
#2 da (2 voti)

4

Diciamo che sono un nuovo ragazzo che viene al progetto, come faccio a determinare chiaramente se c'è un debito nel progetto? Cosa me lo mostrerà? Diciamo che esiste una certa quantità di TD in ogni progetto. Quindi la prossima domanda è: come misurarla? Come quantificare la quantità di debito tecnico? Senza ricorrere a metriche (come la copertura del codice, ecc.) Come può un "estraneo" vedere se la quantità di debito tecnico è grande o no?

Una domanda simile sarebbe: diciamo che gli sviluppatori stanno scrivendo un codice "sporco" che si risolve in un debito tecnico inconscio. Come si può determinare che l'importo del debito tecnico è improvvisamente aumentato nel progetto? Come potrebbe venire a vista?

technical-debt

posta Andrew 29.03.2018 - 10:52

fonte

2 risposte

Leggi altre domande sui tag technical-debt

Tell non chiedere a vs constructor che fa lavoro Library IO: utilizzare classi di interfaccia o callback?

score 2 · Answer 1

Mi piacerebbe seguire il seguente esempio di istinto:

Qual è la mia copertura di prova?
Esistono casi di test manuali per test aggiuntivi?
Che aspetto ha l'elenco dei bug?
Quanti bug pensano che le persone non siano nella lista degli errori?
Quanto è complicata la configurazione esterna?
Di quante applicazioni esterne dipende?
Quanto è stato aggiornato di recente?

Stai cercando:

Il 70% - 80% di copertura di prova può essere un buon segno.
Il rigore nei tester documentati è un ottimo segno e raro.
Gli elenchi di bug dettagliati, organizzati e aggiornati di recente sono validi.
Tutti i bug che conosciamo sono inseriti nell'elenco per processo.
Poco o nessuna configurazione esterna.
Meno è meglio. I database e le cache sono tipici. Più strumenti significano più rischio / potenziale per il debito.
Gli aggiornamenti recenti indicano nuove funzionalità o correzioni di errori. Vedi prove di errori nei log del repository?

È una chiamata istintiva, ma puoi capirlo in un giorno o due. È richiesto più lavoro per ulteriori dettagli.

score 2 · Answer 2

Ci sono davvero due modi per misurarlo, dal mio punto di vista, ognuno con dei limiti.

Misura direttamente usando gli strumenti

Strumenti di copertura del codice, difetto / bug backlog, dipendenze obsolete, ecc.

I vantaggi:

Misure dirette, obiettive e monitorabili
Può essere fuorviante se preso troppo alla lettera. Aumentare il conteggio dei bug da 1 a 2 non significa che il debito tecnico sia raddoppiato. Ma 200 bug aperti contro 100 bug aperti suggeriscono molto più debito.

Svantaggi:

Molto incompleto - ci sono molte forme di debito tecnico che questo manca.

Misurazione indiretta

In definitiva, il debito tecnico è tutto ciò che ostacola. Quindi possiamo definire il debito tecnico come cose che frenano la velocità di una squadra dall'essere più.

Quindi un modo indiretto per misurare il debito tecnico è ripagarlo e confrontare la velocità nel tempo. Se il debito tecnico viene ripagato, la velocità potrebbe diminuire temporaneamente, per poi risalire a un livello superiore rispetto a prima. Altrimenti, aumenterà gradualmente nel tempo.

Questo è indiretto perché non ti dice realmente quanto debito hai effettivamente in un determinato momento, ma ti mostra che stai migliorando o meno, il che è probabilmente alla fine quello che vuoi.