Quali sono gli elementi chiave cruciali nella registrazione del debito tecnico?

Question

Sto istituendo un registro dei debiti tecnici presso l'Ufficio e voglio renderlo uno strumento abbastanza completo.

Quali sono le informazioni chiave che dovremmo registrare?

Answer 1

Prima di tutto, si desidera mantenere il proprio registro molto semplice, altrimenti l'overhead di mantenere il registro impedirà alle persone di utilizzarlo e sprecare più tempo rispetto alla risoluzione effettiva del debito tecnico che era destinato a risolvere ... ..

Se si decide di andare avanti, io suggerirei di tenere un semplice registro che è un/semplice database/foglio di calcolo file flat Google con i seguenti campi:

• nome modulo/component
• Descrizione di quanto n eeds da correggere (potresti avere un elenco di categorie ma penso che anche questo necessiti di un text one-liner)
• Tempo di risoluzione stimato in giorni (sarei propenso a insistere su un numero intero di giorni, altrimenti le persone avranno la tendenza ad avviare la registrazione banalmente piccole cose)
• quale sviluppatore sorta l'obbligazione (e ha fornito la stima del tempo fix)
• che proiettano l'obbligazione è sorta su (qualsiasi implicitamente, che il responsabile del progetto è responsabile)

Le regole sono le seguenti:

• Gli sviluppatori dovrebbero essere trasparenti in merito al debito tecnico. Se uno sviluppatore deve sostenere un debito tecnico a causa delle pressioni del progetto, lo sviluppatore dovrebbe aggiungerlo al registro con il tempo stimato di riparazione.
• I project manager sono responsabili per il debito tecnico che hanno accumulato (cioè hanno fatto pressione sugli sviluppatori per prendere scorciatoie?). Dovrebbero essere in grado di giustificare una solida giustificazione commerciale per il debito totale accumulato e proporre ciò che dovrebbe essere fatto per risolverlo.
• Se non viene rilevato alcun debito tecnico, il codice dovrebbe essere di ottima qualità e superare eventuali revisioni del codice pertinenti. Se si nota il debito tecnico, lo sviluppatore ottiene un "lasciapassare" per qualsiasi cosa venga notata (la revisione potrebbe invece considerare utilmente l'accuratezza della registrazione del debito e le idee su cosa dovrebbe essere fatto per correggere).
• Gli sviluppatori devono fornire stime attendibili per il tempo di correzione. Se dicono che ci vorranno due giorni per rifattorizzare l'architettura, allora non dovrebbero sorprendersi se hanno due giorni per sistemarlo in un secondo momento ....

Penso che questo approccio creerà un buona dinamica generale - gli sviluppatori hanno la responsabilità di essere trasparenti e pensare a come risolvere il debito tecnico, i project manager/leader aziendali devono fare i trade-off ma è chiaro che i costi del debito sono di loro competenza, i migliori sviluppatori e architetti otterrà i complimenti per il completamento dei progetti difficili mantenendo anche il debito tecnico sotto controllo.