L'aggiornamento tecnico del debito / tecnologia dovrebbe essere programmato come una caratteristica (punti dati) o un lavoro di routine (dati senza punti)?

Risposta breve: pagare il debito tecnico è un lavoro ingrato. Non stai offrendo nuove funzionalità per gli utenti finali, quindi non viene indicato.

Risposta ufficiale:

Bugs and chores aren’t estimable by default

Feature stories are estimated because they contribute to business value. Bugs and chores are considered part of normal software product overhead—they emerge over time, and are continual overhead, an ongoing cost of doing business. Tracker’s automatic velocity calculation accounts for this as a built-in cost, and estimates how much business-valued work can be completed each iteration. This lets you focus your planning on business value, risk, and priorities. Therefore, bugs and chores in Tracker are not normally estimated. You can enable estimation for bugs and chores in Project Settings; however, we strongly discourage turning on bug and chore estimating. You cannot turn it off later if you change your mind.

https://www.pivotaltracker.com/help/articles/planning_with_velocity/#bugs_and_chores

Questo è il motivo per cui le storie classificate come bug e faccende non possono avere stime assegnate a loro con le impostazioni predefinite di PT, ma penso anche che spieghi perché non dovresti contare queste attività come caratteristiche solo per ottenere punti per loro.

In primo luogo, non penso che dovresti considerare una caduta di velocità come una penalità: è solo informazione. Forse era qualcosa di naturale, come una nuova persona che si univa al fatto che dovevi passare più tempo ad allenarti. Forse è stato qualcosa di inaspettato che ha ridotto la tua capacità (ad es. Malattia) o consumato extra (ad esempio il bug "fermare il mondo"). Forse non avevi valutato bene le caratteristiche, per qualsiasi motivo; questo è qualcosa da cui puoi imparare. O forse è perché hai deciso, come squadra, di dare la priorità a pagare un po 'di debito tecnico rispetto a fornire nuove funzionalità (e magari incorrere in maggiori debiti).

In secondo luogo, non è necessariamente un errore sostenere il debito tecnico. Non è ideale per incorrere in per errore , ma se decidi di farlo ad es. costruisci la cosa "veloce e sporca" ora sapendo che dovrai riordinare più tardi, ad esempio per ottenere più feedback da parte degli utenti o rispettare una dura scadenza, è una scelta deliberata che hai fatto come squadra e è OK.

Per sapere se qualcosa dovrebbe essere una caratteristica, una semplice regola empirica è: interessa gli utenti finali? Hai menzionato il miglioramento della SEO: è qualcosa a cui sono interessati? Prestazioni a cui potrebbero interessare, ma d'altra parte forse preferirebbero avere qualche nuova funzionalità rispetto alle stesse cose con poche centinaia di millisecondi rispetto al tempo di caricamento. Fai qualche ricerca: vai a chiedere loro cosa vogliono. Lascia che ti aiutino a stabilire la priorità su cosa è meglio dedicare il tempo del team.

Potresti decidere che le tue attuali scelte tecnologiche ti stanno trattenendo dall'erogare determinate funzionalità nel modo più efficiente che desideri, nel qual caso è perfettamente ragionevole spendere (ancora una volta deliberatamente) la migrazione di tutta o parte dell'applicazione a qualcosa di nuovo.

I believe all types of chore mentioned above, if done wisely, should improve team's velocity in future.

Qui sono assolutamente d'accordo con te, ma poi non sto ottenendo punti per questi conteggi doppiamente? Se stai facendo il lavoro in modo che tu possa fornire più funzioni in seguito, dovresti vedere la velocità più alta dopo che hai fatto, non mentre stai facendo esso.

Inoltre, cose come le revisioni del codice e il refactoring di base nel processo di consegna (ad esempio la parte "refactor" del ciclo TDD) dovrebbero già essere parte del lavoro in corso e quindi già incluse come parte della velocità complessiva del team.

Divulgazione : sono un Pivot, lavoro per Pivotal Labs a Londra, ma non nel team di Tracker.

Solo per essere contrarian, gestiamo bug e debito tecnico come qualsiasi altro PBI. In realtà, non abbiamo nemmeno un tipo "bug". Tutto è un PBI. Il nostro arretrato è ordinato in base al valore aziendale assegnato al PBI. Di conseguenza, un bug prominente rivolto all'utente che sta causando problemi avrà un alto valore aziendale assegnato, poiché rischi di perdere denaro con qualcosa del genere, e sarà probabilmente una delle prime cose fatte. D'altra parte, un bug che non ha molto impatto e non influenza la linea di fondo avrà un valore commerciale relativamente basso e potrebbe non essere corretto per un po '. Questo è un importante muro mentale che dovrebbe essere abbattuto: non tutti i bug dovrebbero essere risolti. Sembra sacrilegio, lo so, ma se lo sforzo richiesto per correggere il bug è più che il valore del business fixing che porterà, allora il ROI è negativo. Trattare tutto come un PBI ti dà la libertà di prendere questi tipi di decisioni empiriche senza essere distratto solo perché è un "bug".

Allo stesso modo, con il debito tecnico, c'è ancora molto in gioco un valore aziendale. Alcuni debiti tecnici possono essere sostenuti con costi minimi e possono rimanere a lungo termine, ma un certo debito tecnico ucciderà la tua attività nel tempo e quindi ha un valore aziendale molto elevato. La chiave sta di nuovo rendendosi conto che tutto è solo un PBI. Tutto va nel backlog e lavori sugli elementi di quel backlog in base al valore aggiunto all'azienda. Che si tratti di una funzionalità, di un bug o di un debito tecnico, è davvero irrinunciabile.

Questo ha anche il vantaggio di eludere completamente la tua domanda. Poiché tutto è un PBI, tutto contribuisce alla velocità. L'idea di fare un lavoro che non è realmente dimensionato e contato nella tua velocità è una specie di folle per me. In pratica stai creando un enorme buco nero nei tuoi dati empirici. La velocità è già una metrica piuttosto approssimativa, è una stima basata su una stima basata su ancora più stime. Aggiungi un gruppo di quantità variabile di lavoro non tracciabile, e ora il numero è quasi privo di significato. Tutto ciò che fa la tua squadra in uno sprint fa parte della tua velocità.