Spiegazione della differenza tra Product Backlog Item e un'attività

17

Mi sono imbattuto in questa sfida un paio di volte e spero che qualcuno possa fornire alcuni riferimenti, formazione o consigli su come spiegare la differenza tra un Product Backlog Item e un'attività in TFS.

Comprendo e ho spiegato che un Product Backlog Item è il "Cosa" e il Task è il "Come". Ho anche spiegato che il PBI è il requisito e il compito è come il requisito è soddisfatto.

Ho più volte incontrato sguardi fissi e grattando la testa quando spiego questo. Sembra che gli ingegneri del software che spiego non possano fare la distinzione. Per loro è lo stesso.

Credo che l'altra mia sfida sia che non sono in grado di illustrare in modo efficace perché è importante fare la distinzione.

    
posta Brad J 11.07.2013 - 16:23
fonte

4 risposte

26

La "Product backlog Item" è in effetti il Cosa, la funzionalità che deve essere costruita. L'attività descrive i passaggi da seguire per arrivarci.

Molti team non vengono utilizzati per decomporsi in attività, ma semplicemente costruiscono quello che dicono le specifiche. Per queste persone è difficile vederle come due cose separate.

Forse un semplice aneddoto potrebbe aiutare:

See the Product Backlog Items as the items on their shopping list for their vacation. Maybe a "tent", a "fishing rod", a "prepare car for travel".

The Tasks for the "tent" item would be "Describe tent requirements", "Compare tents online", "Get advice from friends with outdoor experience", "Go to outdoor shop", "Buy tent", "setup tent in backyard to verify completeness", "pack tent for travel"

The Tasks for Fishing Rod will be very similar, but the tasks for "prepare car for travel" are probably very different: "Check requirements for states/countries on desired route", "buy safety vest", "replace expired contents from first aid kit", "inspect spare tire", "schedule appointment with garage to have engine checked", "go to garage to have engine checked", "go to state agency to buy highway pass", "check car insurance"

Ciò separa chiaramente la domanda su ciò che il product owner desidera da ciò che devono fare. A meno che il product owner non sia già decomposto in elementi utilizzabili nel Product Backlog, nel qual caso è necessario parlare con lui.

Come ho già detto, per molti sviluppatori pensano di avere già abbastanza informazioni e sanno cosa fare, non vogliono decomporre le istruzioni su come fare, ci arriveranno quando arriveranno. Quando inizi a parlare con loro del monitoraggio dello sprint, del miglioramento delle stime, del monitoraggio del lavoro che è stato dimenticato durante la pianificazione dello sprint e di altri elementi che hanno a che fare con miglioramenti professionali, chiedi loro come loro e il loro team sapranno dove possono migliorare e come sanno che sono davvero fatti. Quando riescono a trovare un sistema che funzioni senza creare attività e funzioni, allora va bene, ma le probabilità sono molto basse che possono effettivamente.

prima di provare a lavorare con TFS e gli strumenti agili, il tuo team dovrà capire come funziona tutto questo. Il modo migliore è farli lavorare con un cartone, che è visibile sul piano di lavoro a tutti. Più tardi, quando il processo è compreso meglio, il passaggio agli strumenti aiuterà. Senza la comprensione, gli strumenti non saranno di grande utilità e incontreranno molta resistenza.

    
risposta data 11.07.2013 - 17:44
fonte
3

Penso che Jesse abbia fornito un'ottima risposta. Sto semplicemente cercando di renderlo, beh, più semplice (se possibile) :) Il Product Backlog Item (o User Story, se preferisci) è solitamente scritto in questo modo:

Come nuovo cliente Voglio registrare i miei dettagli In modo che venga informato delle nuove versioni del prodotto

In un capo di sviluppatori, questo può tradurre in:

  1. Crea un modulo di registrazione
  2. Scrivi i dati di registrazione nel database
  3. Invia email al nuovo cliente per confermare la registrazione

Questi tre elementi sono i compiti.

Spero che ti aiuti.

- Rendilo il più semplice possibile ma non più semplice (Einstein)

    
risposta data 11.07.2013 - 22:36
fonte
2

Ecco come procediamo:

Il PBI:

  • è il requisito alias "il cosa"
  • è ciò di cui parli con un cliente .
  • È ciò che appare sul Daily Project Update (DPU) per lo sprint ..... di nuovo perché la DPU è rivolta al cliente.
  • È ciò di cui il cliente parlerà e farà riferimento in termini di stime e budget.
  • Potrebbe comprendere una o più attività.
  • È orientato al business e descritto nel linguaggio di stile di business / dominio che il cliente comprende.
  • È ciò che viene testato e accettato in User Acceptance Testing (UAT)

L'attività:

  • È richiesto un pezzo di lavoro per materializzare il PBI (requisito)
  • Non è qualcosa di cui parli con un cliente
  • Non viene visualizzato sulla DPU perché non ne parli con i clienti
  • È stimato ma ha le stime arrotolate nel PBI
  • È figlio di uno e un solo requisito.
  • Può essere descritto (e spesso lo è) usando il gergo tecnico
  • Testato internamente e firmato dal test
  • Non accettati o testati separatamente dal cliente (non sanno che esistono)
risposta data 13.07.2016 - 04:29
fonte
-2

Tendo a offrirlo quando ti viene chiesto: -

Un PBI, o Story è qualcosa in più di cui una persona può aggirare.

Un compito è qualcosa che solo una persona può prelevare.

    
risposta data 23.03.2015 - 15:59
fonte

Leggi altre domande sui tag