Scrum: articoli tecnici in un arretrato che è gestito da un PO non tecnico? [chiuso]

Question

Nel caso di articoli tecnici quali "Aggiornamento sever da V1 a V2" o "Aumentare le prestazioni di avvio" o "modulo Refactor login per ridurre la complessità del codice" andare dentro al backlog del prodotto e se sì, come dovrebbe un proprietario del prodotto non tecnico in grado dare la priorità loro vs altri oggetti backlog più funzionali?

Dovrebbe esserci un backlog separato per materiale tecnico? Dovremmo avere un ruolo PO congiunta con due persone che potrebbero dare la priorità roba funzionale e tecnica sul backlog prodotto?

Answer 1

Ho avuto successo con il doppio approccio arretrato:

1. backlog del prodotto è di proprietà del proprietario del prodotto. Esso contiene gli elementi di livello Story (caratteristiche) che vengono stimati dalla squadra e poi la priorità da parte del proprietario del prodotto. Questo processo di stima divide le storie più piccole mansioni.

2. arretrato della squadra è di proprietà del team di sviluppo. Esso contiene gli elementi a livello di attività che sono relativamente piccoli (può essere completato entro uno sprint). Essi possono essere collegati a storie per esempio come impedimenti: per completare la storia, i seguenti compiti tecnici devono essere completate prima. Possono anche essere indipendenti in modo che essi non sono necessari per qualsiasi storia di per sé ma ripagare una parte del debito tecnica per consentire una maggiore velocità nel futuro.

(Su alcuni grandi programmi multi-progetto che ho avuto anche arretrati di programma che contengono elementi epico di livello, di proprietà e priorità da un team di gestione del programma, per essere diviso per le storie in arretrati di prodotti più avanti.)

Answer 2

Di solito nel 'vanilla' MISCHIA i compiti tecnici che hai citato non andrà storie separate.

Per me il PO non tecnico non dovrebbe essere guardando le storie come 'Aggiornare il server'. Non è una storia di lavoro, non è visibile per l'utente finale per cui è difficile dare la priorità se è formulata in questo modo. Le priorità devono essere assegnati in base al valore di business del lavoro. 'Aggiornamento' non significa molto. 'Permettere connessioni simultanee di più', 'La riduzione del tempo di inattività' o anche 'migliorare la velocità di squadra' potrebbe fornire informazioni molto più prezioso per una persona non tecnica. Se non è possibile trovare una descrizione non tecnica porsi una domanda sulla necessità di aggiornamento:)

La storia 'di refactoring' è ancora più complicato. Forse ti chiedi perché è una storia a tutti? Refactoring potrebbe essere fatto come un compito nella storia, ma raramente è una storia su se stessa. Quindi, se si vuole fare il lavoro migliore login o fornire più funzionalità che è una storia, ma armeggiare sotto il cofano non conta come uno. Si prega di notare, inoltre, che il refactoring senza uno scopo commerciale potrebbe facilmente portare a un cosiddetto 'doratura'

Vorrei suggerire di fare le storie 'aggiornare' come un picco con il 'prestazioni migliorare' e 'ri-factor' essendo i compiti per una storia di business rilevante.

P.S. Si potrebbe trovare una buona discussione su questo argomento (per lo più nella parte 3 di esso) nel libro eccellente da Mike Cohn chiamato " User Stories "noreferrer" Applied: Per Agile Software Development "

.

Answer 3

Sono d'accordo con l'opinione di guardare il beneficio business di qualsiasi storia tecnica e il monitoraggio sul backlog prodotto principale

Io credo che ci siano storie interni relativi alla velocità / capacità della squadra, che a volte sono più convenientemente gestiti assegnando una certa capacità di sviluppatori, soprattutto quando il proprietario del prodotto non è interessato a dare la priorità o il gestore di quelle storie. Per esempio. assegnare la capacità del 10% per l'automazione di test arretrato (di regressione legacy), configurazione del server CI, ecc

Sì, tutto può certamente essere espresso in termini di business, ma parte di esso dovrebbe essere considerato "il modo in cui abbiamo bisogno di fare il nostro lavoro" dove c'è fiducia tra Product Owner e la squadra che la squadra farà il miglior uso della capacità assegnato per questo.