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

Nei nostri team Scrum utilizziamo un backlog, che contiene principalmente argomenti funzionali, ma a volte contiene anche argomenti tecnici. Il vantaggio di avere 1 backlog è che diventa facile scegliere gli argomenti per il prossimo sprint, ma ho alcune domande:

• In primo luogo, a me sembra più logico avere un backlog tecnico separato, in cui gli sviluppatori stessi possono aggiungere elementi tecnici puri, come: potremmo migliorare le prestazioni in questo metodo, questa classe manca di documentazione tecnica, ... Avendo un backlog, tutto gli sviluppatori devono sempre passare attraverso il proprietario del prodotto per aggiungere i loro argomenti al backlog, il che sembra un lavoro aggiuntivo e non necessario per il proprietario del prodotto.
• In secondo luogo, se si dispone di un proprietario del prodotto che si concentra solo sugli articoli puramente funzionali, gli articoli puramente tecnici (come la documentazione tecnica mancante, il codice che erode e deve essere sottoposto a refactoring, le classi che danno sempre problemi durante il debug perché non hanno una base stabile e dovrebbe essere riformattata, ...) alla fine dell'elenco finiscono sempre perché "non servono direttamente il cliente". Avendo un backlog tecnico separato e il tempo riservato in ogni sprint per questi articoli tecnici puri, possiamo migliorare le applicazioni funzionalmente, ma anche mantenerle all'interno.

Qual è l'approccio migliore? Uno o due arretrati?

Non sono un esperto, ma direi che puoi avere un solo arretrato per squadra. Il team deve decidere quali problemi sono urgenti e quali possono essere rinviati. Se si separano i problemi in tipi separati di pile, si va contro l'idea centrale che è al centro della mischia, ovvero che esiste un pool di problemi e ogni sprint su cui il team lavora su quelli più urgenti. Se (sotto) dividi i team potresti essere in grado di dividere i tipi di attività che sono rilevanti per loro, ma fondamentalmente dovresti creare team che lavorano in parallelo. L'urgenza / necessità è il decisore numero uno quando si tratta di pianificare lo sprint successivo. È possibile classificare le attività, ma ciò non dovrebbe ostacolare il processo decisionale.

Vorrei aggiungere la mia voce a coloro che raccomandano un backlog per prodotto. La creazione di un altro arretrato è una risposta razionale, ma in realtà sta solo evitando il problema principale: perché il Product Owner non dà la priorità agli articoli tecnici rispetto agli articoli di funzionalità? Dovresti concentrarti sulla risoluzione di questo piuttosto che aggirarlo. Puoi usare la tecnica dei 5 Whys , ad esempio, per cercare di arrivare al fondo delle cose.

Potrebbero esserci molte ragioni per cui l'OP 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. C'è una buona probabilità che si tratti di un problema di comunicazione e la soluzione a lungo termine è di lavorarci su e risolverlo - rimuovere l'impedimento.

Inoltre, ho un'altra domanda a cui pensare: perché il debito tecnico è sorto in primo luogo? Idealmente lavori come refactoring ecc. Dovrebbero avvenire all'interno delle storie funzionali e dovrebbero essere completati nello sprint. Non dovrebbero essere storie extra a sé stanti, altrimenti non hai un codice potenzialmente spedibile.

Quello a cui ti riferisci è comunemente chiamato "debito tecnico". A volte può essere difficile vedere come il lavoro del debito tecnico si adatta al processo di mischia, allo stesso modo in cui i difetti possono.

Quello che stai proponendo è simile a suggerire che ci sia anche un 'backlog di difetto' separato, suddividendo il backlog in 3.

Personalmente, non raccomanderei affatto di dividere l'arretrato del prodotto. L'idea del portafoglio ordini del prodotto è quella di rappresentare elementi di lavoro eccezionali . Da quel punto di vista, l'unica differenza tra una caratteristica e una voce di debito tecnico è che il requisito proveniva dal team di sviluppo, non dal cliente. È ancora un oggetto di lavoro e deve ancora essere gestito, inclusa la definizione di 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 attraverso lo stesso processo di QA di una funzionalità normale.

Concordo con Onno in quanto dovrebbe esserci un solo backlog per progetto. In caso contrario, il team sta praticamente prendendo in mano alcune decisioni che appartengono giustamente al proprietario del prodotto.

Anche gli articoli "puramente tecnici" devono avere un certo valore pratico per gli utenti (e quindi per il proprietario del prodotto) per essere idonei per l'arretrato di sprint. Spetta a te spiegare il vantaggio di questi al proprietario del prodotto e convincerlo del valore aggiunto che giustifica il costo. E questo processo ti costringe a riflettere su questi problemi e selezionare le modifiche tecniche che apportano il massimo valore al progetto con il minimo sforzo.

Concordo con tutte le risposte sopra. Nel fervore della realtà commerciale, l'OP continuerà a privilegiare le storie funzionali rispetto a quelle tecniche. Spesso per la frustrazione della squadra. Il team dovrebbe astenersi dalle storie tecniche senza alcun valore per l'utente (chi se ne frega di un'ottimizzazione, se la velocità non è un problema?) E imparare a vedere alcuni altri compiti tecnici come implicati dalle storie funzionali. Anche la "definizione di fatto" gioca un ruolo importante. Le restanti storie funzionali vanno nel backlog affinché l'OP abbia la priorità.

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

Ad esempio codice di refactoring: dovrebbe essere fatto quando avvantaggia lo sviluppo del prodotto. Non prima (il team non dovrebbe assumere in quale direzione si evolverà il prodotto) e non più tardi quando si è già trasformato in debito tecnico. Anche la revisione del progetto potrebbe far parte del DoD.

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

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

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

Riguardo al "codice che erode e dovrebbe essere riformulato", come afferma Patrick, credo che dobbiamo chiederci: quale area della funzionalità del sistema sta interessando quel codice? e qual è l'effetto a lungo termine sull'utente se non lo refattiamo ora?

Poi c'è l'argomento di "lasciare le cose leggermente migliori di come le abbiamo trovate" in modo da ridurre il debito tecnico a lungo termine e questo può essere fatto come parte delle piccole storie di ogni sprint senza un impatto eccessivo sul progetto più ampio?

Alla fine non vedo la necessità di due arretrati, questo apre l'opportunità di rallentare le esigenze correttamente prioritarie - ma c'è un bisogno di un product owner che sia educato nelle preoccupazioni degli impatti tecnici e abbia una forte capacità di identificare il vero valore così per scomporre le storie in verticale - Adobe offre una buona spiegazione sull'affettatura verticale .

No, non dovresti mai creare storie tecniche. Questo è un errore comune. Le storie devono riflettere i requisiti aziendali. Le cose tecniche non sono mai realmente per esigenze aziendali. Questo è il ruolo del maestro della mischia e del team per valutare tutti i compiti tecnici che dovranno fare per raggiungere l'obiettivo o la storia.

Se la tua storia riguarda la creazione di una schermata di accesso, ad esempio, dovrai considerare la creazione del database anche se non ancora creato.

Non vedo il problema di creare, con l'OP, attività in cui il team IT è l'utente. Se l'attività può essere compresa dall'OP e può essere valutata in termini di valore aziendale, allora sì, hai un modo per creare storie tecniche. Basta usare il sistema.