Explicando a diferença entre o Item do Backlog do Produto e uma Tarefa


22

Eu já enfrentei esse desafio algumas vezes e espero que alguém possa fornecer algumas referências, treinamento ou conselhos sobre como explicar a diferença entre um Item de Backlog do Produto e uma Tarefa no TFS.

Entendo e expliquei que um Item do Backlog do Produto é o "O quê" e a Tarefa é o "Como". Também expliquei que o PBI é o requisito e a tarefa é como o requisito é atendido.

Sou visto repetidamente com olhares em branco e cabeça coçando quando explico isso. Parece que os engenheiros de software aos quais explico não podem fazer a distinção. É tudo a mesma coisa para eles.

Acredito que meu outro desafio é que não sou capaz de ilustrar efetivamente por que é importante fazer a distinção.

Respostas:


27

O "Item de lista de pendências do produto" é realmente o quê, a funcionalidade que precisa ser criada. A tarefa descreve as etapas que precisam ser seguidas para chegar lá.

Muitas equipes não são usadas para se decompor em tarefas, apenas constroem o que as especificações dizem. Para essas pessoas, é difícil vê-las como duas coisas separadas.

Talvez uma anedota simples ajude:

Veja os itens do Backlog do produto como os itens da lista de compras para as férias. Talvez uma "barraca", uma "vara de pescar", um "carro preparado para a viagem".

As tarefas do item "barraca" seriam "Descrever os requisitos da barraca", "Comparar barracas on-line", "Obter conselhos de amigos com experiência ao ar livre", "Ir para a loja de rua", "Comprar barraca", "montar barraca no quintal para" verifique se "," empacota a barraca para viajar "

As tarefas para a vara de pesca serão muito semelhantes, mas as tarefas para "preparar o carro para a viagem" provavelmente são muito diferentes: "Verificar requisitos para estados / países na rota desejada", "comprar colete de segurança", "substituir o conteúdo vencido dos primeiros socorros kit "," inspecione o pneu sobressalente "," agende uma consulta com a garagem para verificar o motor "," vá para a garagem para verificar o motor "," vá para a agência estadual para comprar o passe da estrada "," verifique o seguro de carro "

Isso separa claramente a questão do que o proprietário do produto deseja e do que ele precisa fazer. A menos que o proprietário do produto já tenha se decomposto em itens acionáveis ​​no Backlog do Produto, nesse caso, você também precisará conversar com eles.

Como eu disse, para muitos desenvolvedores, eles acham que já têm informações suficientes e sabem o que fazer, não querem decompor as etapas O que fazer em Como, chegarão lá quando chegarem lá. Quando você começar a conversar com eles sobre como acompanhar o progresso do sprint, melhorar as estimativas, acompanhar o trabalho que foi esquecido durante o planejamento do sprint e outros itens relacionados às melhorias profissionais, pergunte a eles como eles e sua equipe saberão onde podem melhorar e como sei que eles realmente terminaram. Quando eles podem criar um sistema que funciona sem criar tarefas e funciona, tudo bem, mas as chances são muito baixas de que eles realmente possam.

Antes de tentar trabalhar com o TFS e as ferramentas ágeis, sua equipe precisará entender como tudo isso funciona. A melhor maneira é fazê-los trabalhar com uma placa de papel, visível a todos no piso de trabalho. Mais tarde, quando o processo for entendido melhor, a mudança para as ferramentas ajudará. Sem o entendimento, as ferramentas não serão muito úteis e encontrarão muita resistência.


Obrigado por reservar um tempo para escrever esta resposta. A anedota e o raciocínio que você forneceu definitivamente me ajudarão a explicar melhor o conceito.
Brad J

@jessehouwing E se o proprietário do projeto pedisse para "verificar o seguro de carro" explicitamente. O que é BacklogItem ou Tarefa?
Vladimir Nani

Parece uma coisa operacional. Então seria uma tarefa. Mas como isso dá valor? "Garanta que o carro esteja sempre garantido", pode ser a história?
Jesshouwing

8

Eu acho que Jesse deu uma ótima resposta. Simplesmente vou tentar torná-lo, bem, mais simples (se possível) :) O Item do Backlog do Produto (ou História do Usuário, se você preferir) geralmente é escrito assim:

Como novo cliente, desejo registrar meus dados para ser informado sobre os lançamentos de novos produtos.

Na cabeça de um desenvolvedor, isso pode se traduzir em:

  1. Crie um formulário de registro
  2. Gravar dados de registro no banco de dados
  3. Enviar email para o novo cliente para confirmar seu registro

Esses três itens são as tarefas.

Espero que ajude.

- Torne o mais simples possível, mas não mais simples (Einstein)


2

Veja como rolamos:

O PBI:

  • é o requisito conhecido como "o quê"
  • é sobre isso que você fala com um cliente .
  • É o que aparece na Atualização diária do projeto (DPU) para o sprint ..... novamente porque a DPU está voltada para o cliente.
  • É sobre isso que o cliente falará e se referirá em termos de estimativas e orçamento.
  • Pode incluir uma ou mais tarefas.
  • É orientado para negócios e descrito em linguagem orientada para negócios / estilo de domínio que o cliente entende.
  • É o que é testado e aceito no UAT (User Acceptance Testing)

A tarefa:

  • É um trabalho necessário para materializar o PBI (requisito)
  • Não é algo que você fala com um cliente
  • Não aparece na DPU porque você não fala sobre eles com os clientes
  • É estimado, mas tem suas estimativas acumuladas no PBI
  • É filho de um e apenas um requisito.
  • Pode ser descrito (e geralmente é) usando o jargão técnico
  • Testado internamente e assinado por teste
  • Não aceito ou testado isoladamente pelo cliente (eles não sabem que existem)

-4

Costumo oferecer isso quando solicitado: -

Um PBI ou uma história é algo que mais do que uma pessoa pode dar a volta.

A Tarefas é algo que apenas uma pessoa pode pegar.


1
Não acho que essa descrição forneça uma imagem completa, mas posso ver onde isso poderia ajudar a trazer algum foco para a conversa.
Brad J
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.