Ho aggiunto un paio di storie utente che affrontano alcuni debiti tecnici sulla mia scheda Pivotal Tracker. Devo considerarli come caratteristiche (mantenendo il mio livello di velocità) o come lavoretti / bug (abbassando la mia velocità)? Capisco che non farà alcuna differenza nel lungo periodo se ho fatto l'una o l'altra in modo coerente, ma ogni volta che aggiungo una storia di debito tecnico devo prendere la decisione.

Alcuni pensieri:

• In realtà non sono bug, non rompono nulla
• Gli utenti non hanno richiesto nulla in quanto si tratta di un'implementazione di basso livello che non li influenza, ma faciliterà lo sviluppo a lungo termine
• Se si definisce caratteristiche come le storie che aggiungono valore agli utenti, oltre a) che non come gli utenti non vedere alcun beneficio diretto, ma poi b) lo fanno perché fanno sì che lo sviluppo futuro / manutenzione possibile, che fa un valore aggiunto, proprio adesso no

Non sto decidendo se svolgere effettivamente il lavoro o quando pianificarlo, ma solo cosa sapere cosa dovrei chiamare debito tecnico nel mio strumento di gestione del progetto e perché.

È una caratteristica.

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

È definito, pianificato e monitorato come qualsiasi altra funzionalità.

Se l'implementazione di questa funzione non è sufficientemente preziosa (per il cliente o per te) per essere programmata, questo è un problema diverso.

Il debito tecnico (rimborsare) non è una caratteristica , poiché il cliente non è qualificato per prendere decisioni al riguardo . Soprattutto il cliente non può decidere quando è finito, e inoltre il cliente dipende totalmente da te per spiegare i vantaggi. Ritiene che ci sia un debito tecnico e spetta a te decidere come risolverlo e quando hai finito. Il debito tecnico sta influenzando la tua (futura) velocità, non la percezione del software da parte dei clienti. Se non ci fosse debito, saresti più produttivo. E la velocità che hai misurato finora è sbagliata, dal momento che avresti dovuto impiegare più tempo a mantenere il codice in forma.

Penso che dovresti comunicarlo con il tuo cliente, ma non è qualcosa sotto il loro controllo. Potresti dire qualcosa del genere: 'Finora abbiamo preso alcune scorciatoie, che dovremo correggere. Ciò significa che la nostra velocità diminuirà un po 'nelle prossime iterazioni, ma questo per garantire che a lungo termine abbiamo software gestibile. "

Continuare a lavorare sulla funzionalità del cliente aiuterà anche a concentrarti sul miglioramento del software per il cliente, invece che diventare una sorta di esercizio accademico per trovare il design perfetto (questo è qualcosa con cui a volte faccio fatica personalmente).

IMHO un compito per eliminare il debito tecnico non è sicuramente una caratteristica. Potrebbe essere spinto nel reparto "bug", ma estenderebbe la definizione dei termini, poiché di nuovo non comporta cambiamenti comportamentali osservabili dagli utenti.

Lo definirei semplicemente un compito di manutenzione. In qualsiasi progetto di sviluppo, ci sono molte di queste attività, come l'impostazione dell'ambiente di sviluppo / test, l'assemblaggio dei dati di test, l'unione delle filiali in SCM ecc. costi e tasso di bug a lungo termine.

Potrebbe non essere necessario gestirli come attività separate (a meno che non siano enormi e / o non si abbia alcuna pressione per implementare nuove funzionalità in questo momento). Di solito potrebbe essere meglio identificare quando una nuova funzionalità richiede refactoring / scrittura di unit test ecc. E gestirli come parte dello sviluppo della nuova funzionalità. Questo può essere più semplice da spiegare sia alla direzione che agli utenti finali (se vogliono sapere su cosa trascorri il tuo tempo). Aggiornamento: Inoltre, aiuta gli sviluppatori a concentrarsi anche sul valore del refactoring. È facile lasciarsi trasportare dal refactoring per il gusto del refactoring, quindi concentrarsi sul valore aggiunto che un refactoring specifico apporta dal punto di vista del cliente è utile per IMHO.

Lo definirei un improvement.

Non è un bug perché nulla è rotto.

Né una caratteristica perché il refactoring non sarà una richiesta del tuo cliente. (perché funziona!).

La maggior parte dei sistemi di tracciamento supporta un tipo di problema improvementper impostazione predefinita, altrimenti è possibile modificarli comunque.