In Scrum, dovresti dividere il backlog in un backlog funzionale e in un backlog tecnico oppure no?

Non sono esperto, ma direi che puoi avere solo un backlog per squadra. Il team deve decidere quali problemi sono urgenti e quali possono essere posticipati. Se si separano i problemi in tipi separati di stack, si va contro l'idea centrale che è al centro della mischia, che è che c'è un pool di problemi e ogni sprint il team lavora sul più urgente di essi. Se (sotto) dividi le squadre potresti essere in grado di dividere i tipi di compiti che sono rilevanti per loro, ma fondamentalmente stai creando gruppi che lavorano in parallelo. Urgenza / necessità è il decisore numero uno quando si tratta di pianificare il prossimo sprint. Puoi classificare le attività, ma ciò non dovrebbe intralciare il tuo processo decisionale.

Vorrei aggiungere la mia voce a coloro che raccomandano un backlog per prodotto. La creazione di un altro backlog è una risposta razionale, ma in realtà evita il problema principale: perché il Product Owner non deve dare la priorità agli articoli tecnici rispetto agli elementi delle funzionalità? Dovresti concentrarti sulla soluzione di questo piuttosto che lavorare intorno ad esso. Ad esempio, potresti utilizzare la tecnica 5 Whys , per provare ad arrivare al fondo delle cose.

Potrebbero esserci molte ragioni per cui l'ordine di acquisto non dà la priorità ai problemi tecnici. Ad esempio, forse il team tecnico non sta spiegando il costo a lungo termine (in $$$) di non affrontare il debito tecnico. Forse è qualcos'altro completamente. Ci sono buone probabilità che si tratti di un problema di comunicazione e la soluzione a lungo termine è di lavorarci sopra e risolverlo - rimuovere l'ostacolo.

Inoltre, ho un'altra domanda su cui riflettere: perché il debito tecnico è sorto in primo luogo? Idealmente il lavoro come il refactoring, ecc. Dovrebbe accadere all'interno delle storie funzionali ed essere completato entro lo sprint. Non dovrebbero essere storie in più a parte loro, altrimenti non hai codice potenzialmente spedibile.

Ciò a cui ti riferisci viene comunemente chiamato "debito tecnico". A volte può essere difficile vedere come il lavoro del debito tecnico si inserisce nel processo di mischia, nello stesso modo in cui i difetti possono.

Quello che stai proponendo è simile a suggerire che ci sia anche un "backlog di difetti" separato, dividendo il backlog in 3.

Personalmente, vorrei non difendere del tutto il backlog del prodotto. L'idea del backlog del prodotto è rappresentare gli elementi di lavoro in sospeso. Da quella prospettiva, l'unica differenza tra una caratteristica e una voce di debito tecnico è che il requisito è venuto dal team di sviluppo, non dal cliente. È ancora un elemento di lavoro e deve ancora essere gestito, inclusa la priorità rispetto ad altri elementi di lavoro. Ciò è particolarmente vero se l'elemento del debito tecnico richiede un test, nel qual caso dovrebbe passare esattamente lo stesso processo di controllo qualità di una funzione normale.

Sono d'accordo con Onno nel senso che dovrebbe esserci un solo backlog per progetto. Altrimenti, il team sta fondamentalmente prendendo in mano le decisioni che appartengono giustamente al proprietario del prodotto.

Anche gli articoli "puramente tecnici" devono avere un qualche valore pratico per gli utenti (e quindi per il proprietario del prodotto) per essere idonei allo sprint backlog. È tuo compito spiegare il vantaggio di questi al proprietario del prodotto e convincerlo del valore aggiunto che giustifica il costo. E questo processo ti costringe a pensare a questi problemi e selezionare i cambiamenti tecnici che apportano il massimo valore al progetto con il minimo sforzo.

Sono d'accordo con tutte le risposte sopra. Nel calore della realtà commerciale, l'OP continuerà a dare priorità alle storie funzionali rispetto a quelle tecniche. Spesso per la frustrazione della squadra. Il team dovrebbe astenersi da storie tecniche prive di valore per l'utente (chi si preoccupa dell'ottimizzazione, se la velocità non è un problema?) E imparare a vedere alcune altre attività tecniche come implicite nelle storie funzionali. Anche la "definizione di fatto" gioca un ruolo importante. Le restanti storie funzionali vanno nel backlog per l'ordine di priorità.

es. Documentazione tecnica: la disponibilità della documentazione tecnica (ove applicabile) è un articolo tipico che appartiene al D.O.D. E quindi, l'aggiornamento è IMPLICITO con ogni storia funzionale.

es. Codice di refactoring: dovrebbe essere fatto quando avvantaggia lo sviluppo del prodotto. Non prima (la squadra non dovrebbe assumere in quale direzione evolverà il prodotto) e non più tardi quando si è già trasformata in debito tecnico. Anche la revisione del design potrebbe far parte del DoD.

Sono d'accordo con MelR. Se c'è qualcosa di "tecnico", dobbiamo guardare perché lo stiamo facendo - o anche a breve e lungo termine causa ed effetto (per l'utente) ?.

Ho visto molti backlog in cui i cosiddetti 'compiti tecnici' possono essere facilmente scritti in un modo di valore aziendale.

Anche le attività tecniche sono spesso il risultato di storie frammentate di grandi dimensioni, in quanto può essere il modo più semplice per rompere le cose. Ma questo può causare iterazioni più lente di vero valore aggiunto (o opportunità di feedback) o, ancora peggio, il fallimento degli sprint.

Riguardo al "codice che erode e dovrebbe essere refactored" come cita Patrick, credo che dobbiamo chiederci: quale area della funzionalità del sistema è quella che influisce sul codice? e qual è l'effetto a lungo termine sull'utente se non lo rifattiamo ora?

Poi c'è il tema di "lasciare le cose leggermente meglio di come l'abbiamo trovato" in modo da ridurre il debito tecnico a lungo termine e può essere fatto come parte delle piccole storie in ogni sprint senza troppa influenza sul progetto più ampio ?

In definitiva, non vedo la necessità di due arretrati e questo apre un'opportunità per rallentare le esigenze opportunamente prioritarie - ma c'è bisogno di un proprietario del prodotto che sia educato alle preoccupazioni degli impatti tecnici e abbia una strong capacità di identificare vero valore in modo da suddividere le storie verticalmente - Adobe offre una buona spiegazione su affettatura verticale .