Mischia: elementi tecnici in un arretrato gestito da un PO non tecnico?

Question

Se articoli tecnici come "Aggiornamento da v1 a v2" o "Incremento prestazioni di avvio" o "Modulo di accesso Refactor per ridurre la complessità del codice" vanno nel backlog del prodotto e, in tal caso, come dovrebbe essere possibile un proprietario del prodotto non tecnico stabilire la priorità rispetto ad altri elementi di backlog più funzionali?

Dovrebbe esserci un backlog separato per materiale tecnico? Dovremmo avere un ruolo di PO congiunto con due persone in grado di dare la priorità a cose funzionali e tecniche sul portafoglio di prodotti?

Answer 1

ho avuto successo con il doppio approccio arretrato:

1. backlog del prodotto è di proprietà del proprietario del prodotto. Contiene articoli a livello di storia (funzionalità) che vengono valutati dal team e quindi classificati in base al proprietario del prodotto. Questo processo di stima divide le storie in compiti più piccoli.

2. Il backlog del team è di proprietà del team di sviluppo. Contiene elementi a livello di attività che sono relativamente piccoli (possono essere completati all'interno di uno sprint). Possono essere collegati a storie come impedimenti: per completare la storia, è necessario completare prima i seguenti compiti tecnici. Possono anche essere indipendenti in modo che non siano necessari per qualsiasi storia in sé, ma restituiscono un debito tecnico per consentire una maggiore velocità in 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 SCRUM "vanilla" le attività tecniche che hai citato non andranno come storie separate.

Per me l'OP non tecnica non deve guardare le storie come "Aggiorna il server". Non è una storia aziendale, non è visibile all'utente finale, quindi è difficile stabilire la priorità se è formulata in questo modo. Le priorità dovrebbero essere assegnate in base al valore commerciale del lavoro. 'Aggiornamento' non significa molto. "Permettere connessioni più simultanee", "Ridurre i tempi di fermo" o anche "migliorare la velocità del team" potrebbe fornire informazioni molto più preziose a una persona non tecnica. Se non riesci a trovare una descrizione non tecnica, porsi una domanda sulla necessità dell'aggiornamento :)

La storia del "refactoring" è ancora più complicata. Ti sei chiesto perché è una storia? Il refactoring potrebbe essere svolto come un compito nella storia, ma raramente è una storia su se stesso. Quindi, se vuoi fare in modo che i login funzionino meglio o fornire più funzionalità che siano una storia, ma armeggiare sotto il cofano non conta come uno. Si prega di notare anche che il refactoring senza uno scopo commerciale potrebbe facilmente portare a una cosiddetta "placcatura in oro"

Suggerirei di fare le storie di "upgrade" come un picco con il "miglioramento delle prestazioni" e il "ri-fattore" i compiti per una storia d'affari pertinente.

P.S. Potresti trovare una buona discussione su questo argomento (principalmente nella terza parte di esso) nell'eccellente libro di Mike Cohn dal titolo "User Stories Applied: For Agile Software Development".

Answer 3

Concordo con la vista di guardare il beneficio business di qualsiasi storia tecnica e il monitoraggio sul principale backlog prodotto

penso che ci sono storie interni relativi alla velocità/capacità della squadra, che a volte sono più facilmente gestibili assegnando una certa capacità agli sviluppatori, specialmente quando il proprietario del prodotto non è interessato a dare priorità o gestire tali storie. E.g. assegna il 10% di capacità per testare il backlog di automazione (della regressione legacy), l'installazione del server CI, ecc.

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