A quale livello di elemento di lavoro il proprietario del prodotto ha la priorità in TFS?

3

Il nostro team sta esaminando il nostro processo Agile mentre guardiamo al passaggio al flusso di stile Kanban anziché a Sprint.

Una delle domande a cui abbiamo difficoltà a rispondere è

At what level (what type of Work Item) should the Product Owner be prioritizing at?

Nella nostra mente, scende a Feature o User Story (Bug) . Tuttavia, indipendentemente da quale scegliamo, stiamo assistendo a scenari in cui potrebbe causare problemi.

User Story

La nostra comprensione è che gli sviluppatori sempre lavorano al livello User Story . (Sì ... possono anche lavorare a livello di Task ma il punto più alto è Story.)

Ciò implica che Proprietario del prodotto è che invia e imposta la priorità User Stories e Bugs .

Tuttavia, è possibile che uno sviluppo possa scomporre una User Story in più storie a causa di pianificazione, divisione del lavoro con altri sviluppatori o qualche altra ragione.

In questo caso, il Product Owner potrebbe non interessare o persino confondersi con l'apparenza di queste apparentemente storie non correlate alla lavagna.

Funzione

In alternativa, potremmo fare in modo che il Product Owner funzioni al livello Feature , lasciando agli sviluppatori la possibilità di continuare a lavorare con User Stories .

Ciò significa che l'ordine di invio sta inoltrando e assegnando priorità a Features . Permetterebbe inoltre allo sviluppatore di creare più di un% diUser Story senza che il PO possa confondersi.

Il problema con questo approccio è la gestione di Bugs . Dal momento che i bug compaiono a livello User Story, in che modo l'ordine di priorità dei punti di interesse deve corrispondere a due diversi Boards ? Immagino che il bug possa essere inserito come Feature (con un child Bug esistente anche) ma sembra sbagliato.

Gruppo di funzionalità

Questa sezione potrebbe probabilmente essere presentata come una domanda separata, ma l'ho aggiunta perché il mio secondo approccio espone il problema ...

Forse "Caratteristica" è la parola sbagliata usata in TFS, ma nella mia mente un Work Item Feature sarebbe "particolare funzionalità in un'applicazione". Ad esempio, una funzione dal titolo " La possibilità di ordinare i risultati di ricerca ". Ad esempio, le User Story sotto possono essere " Ordina per campo ID " e " Ordina per ultimo campo modificato ".

Supponiamo che questa parte di funzionalità venga implementata e quindi qualche tempo dopo venga presentato un miglioramento intitolato " Ordina per nome ". Dovrebbe essere presentato come nuovo Feature ? In caso affermativo, come (e dovrebbe) essere correlato al% originaleFeature? Oppure dovrebbe essere inviato come User Story relativo all'originale Feature che provoca la riapertura della Feature chiusa?

In che modo questo influenza i bug? Un Bug dovrebbe essere associato all'originale Feature ?

Il Epics entrerà in gioco in tutto questo?

    
posta Jason 11.07.2018 - 23:26
fonte

3 risposte

1

Questa domanda trascende TFS, o qualsiasi altro strumento di sviluppo come Rational Team Concernt (IBM) o JIRA (Atlassian), solo per citarne alcuni.

Il Product Owner è la persona del "Big Picture" e dovrebbe dare priorità a Epics. Uno si arriva al livello Story, le dipendenze sulla funzionalità iniziano a guidare la priorità. Prendiamo ad esempio un progetto agile che sta costruendo un blog.

Potresti avere le seguenti Epiche:

  • Scrivi post di blog
  • Commentando i post del blog
  • Condivisione dei post del blog

La prima epica, per prima cosa è necessario scrivere post di blog, perché non è possibile commentare o condividere qualcosa che non esiste. Quindi è facile. Il Product Owner deve decidere quale delle altre due epiche è più importante dopo: Commentare o condividere.

Dopo che la decisione è stata presa, diciamo che il Product Owner termina con questo:

  1. Scrivere post di blog
  2. Condivisione dei post del blog
  3. Commentando i post del blog

Ok, quindi condividere i post del blog è più importante. Cosa è richiesto per fare tutto questo? Bene, lo racconti in storie:

  1. Scrivere post di blog
    • Aggiungi un nuovo post del blog
    • Aggiorna un post del blog esistente
    • Elimina un post sul blog
    • Mostra un post sul blog
  2. Condivisione dei post del blog
    • Condividi sul social network A
    • Condividi sul social network B
    • Condividi via e-mail
    • Condividi tramite permalink
  3. Commentando i post del blog
    • Aggiungi un commento
    • Segnala un commento per abuso
    • Elimina un commento
    • Modera un commento

Se ci concentriamo solo per un momento sulla prima epopea, aggiungiamo post sul blog. Abbiamo 4 storie che fondamentalmente ruotano attorno alle operazioni CRUD nel database. La priorità di queste storie inizia a essere chiara. Non puoi visualizzare, aggiornare o eliminare qualcosa finché non viene creato in primo luogo, quindi aggiungere un nuovo post è il n. Mostrare, aggiornare e cancellare un post del blog si basa solo sull'aggiunta di un post sul blog. Che cosa dovrebbe fare il team di sviluppo?

Chiedi al proprietario del prodotto di indicare quale desidera.

  1. Scrivere post di blog
    1. Aggiungi un nuovo post del blog
    2. Mostra un post sul blog
    3. Aggiorna un post del blog esistente
    4. Elimina un post sul blog

Le priorità si verificano su due livelli che richiedono l'input dal Product Owner:

  • Epics per vedere l'immagine grande
  • Storie per supportare il Big Picture e guidare per il prodotto minimamente vitale

Il proprietario del prodotto deve dare la priorità a Epics. A livello di storia, inizi a vedere sorgere dipendenze tra le storie. Questo aiuta a dare priorità alle storie per il team di sviluppo (non è possibile visualizzare qualcosa prima di crearlo). Altre storie con dipendenze semplici o nulle dovrebbero essere prioritarie dal Product Owner.

    
risposta data 12.07.2018 - 13:48
fonte
0

Direi che la definizione delle priorità dovrebbe chiaramente avvenire a livello User Story. Una User story è (per me) l'implementazione minima praticabile che è visibile e (tipicamente) utile per il proprietario del prodotto (se è più del minimo, considera la divisione verticale).

La suddivisione della storia utente durante lo sviluppo ha senso solo quando i pezzi risultanti sono ancora utili per il proprietario del prodotto. Altrimenti, i pezzi dovrebbero essere Attività.

Inoltre, la definizione delle priorità a livello di user story consente al proprietario del prodotto di ottenere alcune parti significative di una funzionalità molto prima rispetto al resto: può guardare simultaneamente a più funzioni e scegliere tra loro piccole storie di utenti per ottenere il più grande successo per il dollaro subito.

Nota: questo è ciò che ho compreso dai miei corsi di formazione e come lo gestiamo, con successo, da anni. Non è necessariamente " il modo di fare le cose ufficialmente", ma poi Agile significa per me che ogni squadra può aggiustare il processo come meglio crede, quindi non dovrebbe esserci un vero " modo ufficialmente concordato '.

    
risposta data 12.07.2018 - 05:04
fonte
0

Sia che si utilizzi TFS, Jira o qualsiasi altro strumento che fornisce semplicemente un contenitore per le storie degli utenti, il Product Owner e il team di gestione degli stakeholder possono dare la priorità a qualsiasi livello nel Backlog in base alle esigenze dell'organizzazione in quel punto. Quindi non sono limitati a ordinare solo Epics o User stories ma impiegherebbero più tempo a ordinare le storie degli utenti, poiché è il loro valore di guida e sono più granulari e dettagliati di Epics che probabilmente non avranno bisogno di essere aggiornati tutte le volte che il storie degli utenti.

I proprietari di prodotto non dovrebbero dare la priorità alle attività allegate agli user story perché le attività sono create e possedute dai team di sviluppo che fanno il lavoro e sanno meglio cosa deve essere fatto e come farlo per fornire una user story .

    
risposta data 15.07.2018 - 10:57
fonte