I punti del debito tecnologico dovrebbero essere contati nella velocità di una squadra?

Velocity è definito come "numero di unità di lavoro completate in un determinato intervallo". Per implementare un'unità di lavoro, in genere si dispone di una parte esistente di software e si aggiunge del nuovo codice e / o si modifica un codice esistente. Quando la parte esistente del software contiene un sacco di debito tecnico, e devi affrontarlo per attuare un cambiamento, ci si aspetterebbe di aver bisogno di più tempo per completare un'unità di lavoro. D'altra parte, la creazione di nuovo debito tecnico avviene spesso in attesa di aver bisogno di meno tempo per completare un'unità di lavoro nello sprint attuale.

Quindi ciò che viene misurato qui dipende sempre dal team e dal codice effettivo (e probabilmente dall'intera organizzazione che lo circonda). Non c'è niente come una "velocità della squadra" assoluta.

Tuttavia, se la tua domanda è se ci dovrebbero essere unità di lavoro che riguardano solo la rimozione del debito tecnico, e se dovrebbero essere contate allo stesso modo delle unità di lavoro per i requisiti aziendali, allora dovrebbe essere ovvio che mescolare queste due cose potrebbe darti un'idea sbagliata sulla reale velocità di sviluppo della tua squadra. In realtà, devi decidere da solo se vuoi misurare la velocità con cui lavora il tuo team o quanto velocemente il tuo team è in grado di offrire nuovo valore aziendale. Secondo la mia esperienza, la maggior parte dei clienti preferisce pagare per il valore aziendale che ottengono.

Un modo per vedere la velocità è considerarlo come "la quantità di lavoro che può essere completata in un dato periodo di tempo". Supponendo che la riparazione del debito tecnico sia un lavoro reale, dovrebbe essere conteggiato.

Devi ricordare che la velocità è solo uno strumento per aiutarti a lavorare meglio. Se l'aggiunta di un debito tecnico a te velocity ti aiuta, fallo. Se non lo fa, non farlo. L'unico motivo per tenere traccia delle velocità per aiutarti a pianificare meglio. Se ignori il lavoro che effettivamente fai, ciò non aiuta IMHO.

Direi di non contare il debito tecnico nella tua velocità. Tuttavia, come sviluppatore, a differenza di un manager inesperto, sai che ding significa che potrebbe ottenere arbitrariamente più o meno lavoro fatto a seconda di quanto debito aggiungi o rimuovi quella settimana. Quindi tenerne conto durante la pianificazione.

Se il tuo software si trova in uno stato negativo, richiedendo due giorni alla settimana per gestire il debito tecnico per l'anno successivo, o se hai sviluppatori disordinati che creano debito a un ritmo elevato, prendi in considerazione questo e la tua velocità diminuisce dovrebbe nella situazione.