Spiegare la differenza tra l'articolo arretrato prodotto e un'attività


22

Ho incontrato questa sfida un paio di volte e spero che qualcuno possa fornire alcuni riferimenti, formazione o consigli su come spiegare la differenza tra un articolo di arretrato del prodotto e un'attività in TFS.

Comprendo e ho spiegato che un articolo di arretrato del prodotto è il "cosa" e l'attività è il "come". Ho anche spiegato che il PBI è il requisito e il Task è come il requisito è soddisfatto.

Mi viene più volte incontrato sguardi vuoti e grattarsi la testa quando lo spiego. Sembra che gli ingegneri del software a cui spiego questo non possano fare la distinzione. È lo stesso per loro.

Credo che la mia altra sfida sia quella di non essere in grado di illustrare efficacemente perché è importante fare la distinzione.

Risposte:


27

"Product Backlog Item" è in effetti What, la funzionalità che deve essere costruita. L'attività descrive i passaggi che devono essere presi per arrivarci.

Molti team non sono abituati a scomporre in attività, ma costruiscono solo ciò che dice la specifica. Per queste persone è difficile vederle come due cose separate.

Forse un semplice aneddoto aiuterebbe:

Vedi gli articoli arretrati del prodotto come gli articoli sulla loro lista della spesa per le loro vacanze. Forse una "tenda", una "canna da pesca", una "preparazione dell'auto per il viaggio".

Le attività per l'elemento "tenda" sarebbero "Descrivi i requisiti della tenda", "Confronta le tende online", "Chiedi consigli agli amici con esperienza all'aperto", "Vai al negozio all'aperto", "Acquista tenda", "Installa tenda nel cortile di verifica completezza "," pacchetto tenda per viaggio "

I compiti per la canna da pesca saranno molto simili, ma i compiti per "preparare l'auto per il viaggio" sono probabilmente molto diversi: "Controlla i requisiti per gli stati / paesi sulla rotta desiderata", "acquista giubbotto di sicurezza", "sostituisci i contenuti scaduti dal primo soccorso kit "," ispezionare la ruota di scorta "," programmare un appuntamento con il garage per far controllare il motore "," andare al garage per far controllare il motore "," andare all'agenzia statale per acquistare il pass autostradale "," controllare l'assicurazione auto "

Ciò separa chiaramente la domanda su ciò che il proprietario del prodotto desidera da ciò che deve fare. A meno che, naturalmente, il proprietario del prodotto non si sia già scomposto in articoli utilizzabili nel Product Backlog, nel qual caso è necessario anche parlare con loro.

Come ho detto, per molti sviluppatori pensano di avere già abbastanza informazioni e sanno cosa fare, non vogliono scomporre i passaggi Cosa in Come, ci arriveranno quando ci arrivano. Quando inizi a parlare con loro del monitoraggio dei progressi 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 in che modo so che hanno davvero finito. Quando riescono a escogitare un sistema che funziona senza creare attività e funziona, allora va bene, ma le possibilità sono molto basse che in realtà possano farlo.

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 sarà compreso meglio, sarà utile passare agli strumenti. Senza la comprensione, gli strumenti non saranno di grande utilità e incontreranno molta resistenza.


Grazie per aver dedicato del tempo a scrivere questa risposta. L'aneddoto e il ragionamento che hai fornito mi aiuteranno sicuramente a spiegare meglio il concetto.
Brad J,

@jessehouwing E se il proprietario del progetto chiedesse esplicitamente di "controllare l'assicurazione auto". Che cos'è BacklogItem o Task?
Vladimir Nani,

Sembra una cosa operativa. Quindi sarebbe un compito. Ma come dà valore? "Assicurati che l'auto sia sempre garantita", potrebbe essere la storia?
jessehouwing,

8

Penso che Jesse abbia fornito un'ottima risposta. Sto semplicemente provando a renderlo, beh, più semplice (se possibile) :) L'articolo Product Backlog (o User Story, se preferisci) di solito è scritto in questo modo:

Come nuovo cliente desidero registrare i miei dati in modo da essere informato sulle nuove versioni dei prodotti

In una testa di sviluppatori questo può tradursi in:

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

Questi tre elementi sono i compiti.

Spero che sia d'aiuto.

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


2

Ecco come facciamo:

Il PBI:

  • è il requisito noto anche come "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 uno o più compiti.
  • È orientato al business e descritto in un linguaggio orientato al business / dominio che il cliente comprende.
  • È ciò che viene testato e accettato in User Acceptance Testing (UAT)

L'obiettivo:

  • È necessaria un'opera per materializzare il PBI (requisito)
  • Non qualcosa di cui parli con un cliente
  • Non compare sulla DPU perché non ne parli con i clienti
  • È stimato, ma ha le sue stime arrotolate nel PBI
  • È figlio di un unico requisito.
  • Può essere descritto (e spesso lo è) usando il gergo tecnico
  • Testato internamente e approvato dal test
  • Non accettato o testato separatamente dal cliente (non sanno di esistere)

-4

Tendo ad offrire questo quando viene chiesto: -

Un PBI o Story è qualcosa che più di una persona può aggirare.

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


1
Non credo che questa descrizione fornisca il quadro completo, ma posso vedere dove potrebbe aiutare a focalizzare la conversazione.
Brad J,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.