diferença entre Item do Backlog do Produto e Recurso nos tipos de item de trabalho do Team Foundation


111

Tenho uma pergunta sobre o Microsoft Team Foundation. No Visual Studio, Team Explorer, posso criar um novo item de trabalho. Os tipos de item de trabalho aqui são ditados pelo modelo de processo escolhido por sua equipe; Não tenho certeza de qual modelo de processo estamos usando. Em qualquer caso, no Team Explorer, quando eu quero criar um novo item de trabalho, recebo uma lista de tipos de itens de trabalho para selecionar, entre os quais estão "Item do Backlog do Produto" e "Recurso".

Percebi uma diferença entre os dois tipos relacionados à data de resolução alvo. Para um Item do Backlog do Produto, isso parece ser ditado pela data de término da iteração. Para um recurso, não é tão claro. Um recurso também está associado a uma iteração (e a data de término da iteração); no entanto, o recurso também tem um campo separado chamado "Data de destino". O texto de foco do mouse para a data alvo é "A data alvo para completar o recurso".

Devo escolher "Item do Backlog do Produto" ou "Recurso" como o tipo de item de trabalho para meus novos itens de trabalho? Qual a diferença entre os dois?

insira a descrição da imagem aqui


2
Para mim, o recurso é sobre "o quê" e o item de lista de pendências sobre "como".
oli

Respostas:


131

Parece que você está usando o modelo de processo Scrum. O site do TFS publicou algumas informações muito breves sobre itens e recursos do Backlog do produto e a ideia por trás da criação de um novo tipo de item de trabalho. http://www.visualstudio.com/en-us/news/2013-jun-3-vso.aspx

A diferença entre os dois se resume a qual granularidade você deseja trabalhar com seus itens de trabalho:

  • Os itens do backlog do produto são compostos por tarefas e têm esforço estimado.
  • Os recursos são compostos de itens do backlog do produto e têm datas definidas.

Não consegui encontrar nenhuma orientação oficial sobre quando usar Recursos vs. Itens do Backlog do Produto, mas criei minha própria orientação, na qual estou baseando esta resposta em ... http://www.nsilverbullet.net/2013/06/ 04 / features-help-us-plan-work-better-in-team-foundation-service-scrum-process /

Você deve criar um recurso ou um item do backlog do produto?

  • Se você acha / espera que o novo item de trabalho que irá criar caiba em um único sprint, você deve criar um Item do Backlog do Produto e então dividi-lo em tarefas para o seu sprint.
  • Se você acha / sabe que o novo item de trabalho não caberá em um único sprint, você deve criar um recurso e identificar todos os itens do tamanho do sprint que fornecem valor (itens do backlog do produto) em que o recurso pode ser dividido e usá-los quando planejando sprints futuros.

[Atualização 19/05/2014]

A Microsoft publicou mais informações sobre como usar os recursos e o conceito de portfólio ágil que foi implementado no TFS https://msdn.microsoft.com/en-us/library/dn306083(v=vs.120).aspx


5
A Microsoft agora divulgou informações adicionais sobre o uso de Recursos. visualstudio.com/en-us/get-started/… Infelizmente, os recursos do Visual Studio Online só estarão acessíveis para usuários com licenças avançadas. :-( visualstudio.com/en-us/get-started/try-additional-features-vs o preço será de US $ 60 por usuário / mês.
agilejoshua

Onde os bugs se encaixam nisso? Os bugs são intercambiáveis ​​com as tarefas?
Captain Sensible

1
@DiegoDeberdt - bugs não são intercambiáveis ​​com tarefas. Considere-os como existindo no mesmo nível de hierarquia dos PBIs ou potencialmente como filhos dos PBIs (se você optar por rastrear dessa forma - deixá-los como relacionados geralmente é vinculação suficiente). As tarefas podem ser filhas de bugs para rastrear o trabalho de desenvolvimento e teste com relação a eles.
StingyJack

2
Não consigo concordar com a abordagem "sprint múltiplo é um recurso". Deve ser usado como uma ponte (principalmente para rastreamento) entre fins mais técnicos e menos técnicos. Posso pensar que um recurso começa e termina em um sprint com dedicação e recursos suficientes. Mas o Feature é uma maneira fácil para a gerência etc. relacionar e entender o conteúdo técnico.
Beytan Kurt

Há uma nova página de orientação para o Visual Studio 2015, ALM> Trabalho> Escala> Gerenciamento de portfólio
JohnC

20

Como o TFS aplica uma estratégia de desenvolvimento ágil, acho que podemos dizer:

Feature = Epic, Backlog item = Story

O épico contém histórias semelhantes.


9
Sim, mas agora, eles adicionaram o Epics adequado, que contém recursos, que contêm itens de backlog ou bugs, os quais podem conter tarefas.
toddmo

1

Tive as mesmas dúvidas do OP e meu pensamento está alinhado com a resposta de @josant, o que é muito razoável para mim.

Por outro lado, estou usando o livro de Hundhausen [1] como referência para a adoção do TFS + Scrum.

Ele disse coisas como:

Um recurso é uma unidade discreta de funcionalidade que agrega valor ao usuário ou à empresa. Um PBI pode ser grande o suficiente para ter vários recursos.

e depois:

Um recurso pode ser dividido em vários cenários. Um cenário é uma narrativa que descreve um fluxo de trabalho ou sequência de etapas por meio do recurso que exerce um caminho para alcançar o resultado esperado.

e continua desenvolvendo essas ideias.

Para mim, Hundhausen parece estar falando sobre casos de uso [2], mas ainda acho sua proposta um tanto contra-intuitiva, nem parece que o TFS estaria guiando para este método de análise orbe que eu encontrei referenciado na literatura scrum que li.

Provavelmente é só uma questão de escolher uma convenção com a qual se sinta mais confortável e aderir a ela.

[1] http://www.amazon.es/dp/073565798X

[2] https://en.wikipedia.org/wiki/Use_case




1

Como outros disseram aqui:

  • Características: Nível Superior
  • Backlogs: um nível abaixo dos recursos (um recurso é feito de itens do backlog)

Lembre-se de que você pode VINCULAR itens de trabalho e exibi-los como uma Lista de árvore. Assim, você pode vincular um item do backlog a um recurso e, posteriormente, pode vincular uma tarefa a um item do backlog. Assim, você obtém uma boa lista de árvore hierárquica.


1

É assim que eu uso. Nos itens de ferramenta "Trabalho" -> "Backlogs", tanto "Recursos" quanto "Itens do backlog" são listados. Eu começo com recursos para que não haja itens pendentes nesse ponto. Eu adiciono os recursos selecionando Recursos no cabeçalho Backlog e adicionando o nome do recurso no formulário, salvando e fechando. À esquerda de cada Recurso adicionado recentemente, há um sinal + verde. Clique no sinal de mais e as opções de seleção aparecem. Escolha "Itens do backlog do produto". Ao abrir, digite o nome do item do backlog no campo superior, assim como em Recursos. Você está criando esses itens do backlog; não há pop-up. Preencha as outras informações conforme necessário, salve e feche. Depois de criar os itens do Backlog, clique no + verde nos Itens do Backlog recém-criados. Insira o nome do item de trabalho como você fez para os Itens do Backlog e os Recursos. Ao adicionar os itens de trabalho, inclua a sprint no campo de iteração e eles estarão na sprint quando você abri-lo. Nada disso está documentado em qualquer lugar que eu possa encontrar. Espero que esteja com detalhes suficientes.

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.