Desenvolver e gerenciar a lista de pendências de produto

Por Mitch Lacey.Proprietário, Mitch Lacey & associados, Inc, uma empresa de consultoria especializada em adoções e aprimoramentos de agile e scrum.

Janeiro de 2012

Neste artigo, Mitch Lacey explica a importância de uma lista de pendência do produto, descreve o que faz uma boa lista de pendência e fornece algumas práticas recomendadas para a criação e a manutenção de sua lista de pendência.

Aplica-se a

Gerenciamento do ciclo de vida do aplicativo; Team Foundation Server

Neste artigo:

  • Introdução

  • A lista de pendências do produto

    • Histórias de usuários

    • Estimando

    • Priorização

  • Uma reserva de produto ativa

    • Preparação
  • Conclusão

Uma reserva do produto é uma lista de prioridade todos os recursos e funcionalidades necessários para concluir um projeto.Um retorno de bom produto está no núcleo de qualquer equipe ágil e funcionando corretamente e tem as seguintes características:

  • Ele é priorizado para garantir que a equipe compile os recursos mais importantes primeiro.

  • É estimado pela equipe para dar clareza ao proprietário do produto e permite-lhe responder a perguntas como "Quando estes artigos serão feitos?"

  • Ele inclui todo o trabalho necessário para concluir o projeto.

  • É um documento ativo, constantemente alterando e evoluindo para refletir as realidades atuais do projeto.

Um retorno de bom produto não garante automaticamente um bom software.No entanto, a falta de uma boa lista de pendências do produto frequentemente resulta em um software incompleto que não atende aos requisitos de seus clientes e participantes.

Gerenciar a lista de pendências do produto é um trabalho de tempo integral.Técnicas simples podem ajudar a alterar o que pode ser um processo extenuante e demorado em um processo interativo e iterativo que envolva efetivamente os membros da equipe, clientes e partes interessadas.É essencial, portanto, aprender técnicas sólidas para ajudá-lo a criar, priorizar e manter a sua lista de pendências do produto.

A lista de pendências do produto

A lista de pendências do produto é uma lista mestra ativa, prioritária, de todos os recursos e funcionalidades necessárias para concluir o projeto.As reservas do produto geralmente incluem as histórias dos requisitos do usuário (por.. exemplo,) requisitos bugs, tarefas de pesquisa (pontos) e aprimoramentos de engenharia.Esses itens são avaliados em unidades abstratas geralmente chamadas de pontos da história.

As listas de pendências do produto incluem todo o trabalho necessário para o projeto, que evoluirá ao longo do tempo.Como tal, não contêm somente os novos recursos para um produto, mas também correção de erros e pesquisa - tudo que tomará o tempo da equipe.Qualquer trabalho que a equipe fará deve vir do retorno do produto: é a porta da frente do projeto.Se a lista de pendências do produto inclui todo o trabalho, o proprietário do produto, a equipe, e o gerenciamento têm uma imagem melhor do trabalho que permanece e reduz surpresas de última hora.

No início de qualquer projeto, é improvável que você tenha uma boa lista de itens de reserva do produto bem definida e limpa pronta para ser estimada e priorizada.Em vez disso, é provável que você tenha uma pilha de cartões de observações de artigo e talvez uma ou duas especificações funcionais.Como proprietário do produto, é seu trabalho ordenar esta confusão de modo que a equipe possa começar para estimar a reserva.

Hh765980.collapse_all(pt-br,VS.110).gifHistórias de usuários

A primeira etapa é converter todas as ideias e observações em histórias de usuário, o que expressa a funcionalidade desejada pelo usuário final (o que o software deveria fazer), mas não os detalhes de implementação (como criar um software que atenda aos requisitos.)O título de cada história de usuário deve seguir o formato “Como um <user>, desejo <functionality> de modo que <reason>”.

Um exemplo de uma placa de história

Como a lista de pendência do produto próprio, cada artigo do usuário evoluirá ao longo do tempo.Ao longo do projeto, sua equipe priorizará e estimará essas histórias, adicionará informações detalhadas a elas e as dividirá em histórias menores ou as excluirá completamente.Aqueles que são trazidos em sprints são implementados e enviados para seus clientes.

Para ler mais sobre as histórias de usuário, consulte Criar ou adicionar à lista de pendências de produto e Esboços seqüenciais de um Item de lista de pendências usando o PowerPoint.

Após converter todas as ideias e anotações em histórias de usuário, é hora de estimar e dar prioridade.

Hh765980.collapse_all(pt-br,VS.110).gifEstimando

Por definição, a estimativa é imprecisa.No entanto, você pode se tornar muito melhor na criação de estimativas relativamente precisas com o tempo, prática, e participação de toda sua equipe. A primeira etapa é reunir a equipe para fornecer estimativas sobre os itens de lista de pendências do produto.Quando a equipe estima cada artigo, eles oferecem uma avaliação de tamanho relativo com uma unidade de medida abstrata, chamado ponto de história.

As estimativas são essenciais por dois motivos:

  1. Eles ajudam a responder a pergunta, “Quando nós seremos feitos?”

  2. Eles ajudam o proprietário de produto a determinar a prioridade de cada item.

As estimativas fornecem ao proprietário do produto e à equipe uma ideia de um custo de uma determinada história, que por sua vez, ajuda o proprietário do produto a priorizar as histórias em relação umas as outras.Quanto maior a estimativa do item, mais cara será implementar em termos de tempo e recursos.Portanto, um item que pode ter sido de grande importância na lista de desejos de um proprietário do produto pode diminuir em prioridade se vier com um alto custo.

A equipe pode usar o Planning Poker, o Big Wall ou outras técnicas para estimar o trabalho em termos de pontos de histórias.Para obter mais informações sobre as técnicas de estimativa e uma lição rápida em pontos de história, consulte Estimativa e Limpar e estimar a lista de pendências.

Depois que a equipe estimou todas as histórias, é hora de dar prioridade.

Hh765980.collapse_all(pt-br,VS.110).gifPriorização

Todas as reservas do produto são priorizadas em termos de valor de negócio e risco.O proprietário do produto compara cada item da lista de pendências com os demais, a fim de determinar sua prioridade relativa.Para fazer isso, o proprietário do produto considera o tamanho de cada item, o seu valor para o negócio, e qualquer risco associado.Os itens são, então, classificados na ordem decrescente de prioridade.Os itens de alta prioridade aparecem em ou próximo à parte superior do retorno do produto e os itens de prioridade inferior residem em ou próximo à parte inferior.As equipes escolhem o trabalho para o próximo sprint entre os itens de prioridade mais alta, para que os itens mais importantes sejam concluídos primeiro.

Nem todos os itens da lista de pendências são do mesmo tamanho.Alguns podem ser concluídos em um só sprint, mas outros são tão grandes que a equipe não tem certeza do que está envolvido ou quanto tempo levará implementarem.Isso está OK.Conforme os itens se movem mais próximo à parte superior do retorno, a equipe os tornará menor e mais focalizado para que todos compreendam melhor o trabalho que abordarão nos próximos sprints.

Como com a estimativa, dar prioridade à reserva do produto inicial pode ser desanimadora.Como você equilibra efetivamente as demandas do participante de competência, enquanto considera os riscos e custos do produto final?Felizmente, existem diversas técnicas que facilitam a tarefa, incluindo jogos de inovação e a relevância relativo.Consulte Priorização e Limpar e estimar a lista de pendências para obter mais informações sobre essas e outras técnicas.

Seja qual for a técnica de priorização que você escolher, você deve ordenar o trabalho para garantir que a equipe compila os recursos que fornecem a maioria do valor para os negócios, participantes e clientes.Se você não priorizar o trabalho, você aumenta o risco de entregar artigos do usuário de prioridade inferior, ao invés dos artigos do usuários maiores e incompletos quando os recursos e as programações são alterados.

(Para obter mais informações sobre a natureza de itens de retorno, consulte Criar ou adicionar à lista de pendências de produto e Planejamento ágil e iterações).

Uma reserva de produto ativa

O que eu tenho descrito até agora centrou-se em partir do nada a uma reserva estimada e priorizada do produto.Ao contrário dos requisitos, o documento e as reservas do produto não são criadas no início do projeto e deixadas em uma prateleira.Em vez disso, a lista de pendência do produto evolui, expandindo e reduzindo com as realidades do projeto.Alguns itens do backlog do produto vão se tornar irrelevantes e precisarão para ser removidos.Outros surgirão e precisarão ser divididos em histórias menores.À medida que requisitos adicionais forem surgindo, novas histórias de usuário serão adicionadas, estimadas e priorizadas.

A equipe e as partes envolvidas estão comprometidas com a criação e o gerenciamento da lista de pendências do produto, mas o proprietário do produto tem a responsabilidade final sobre ele.O proprietário do produto deve garantir que a lista de pendências esteja limpa, priorizada e atualizada, de modo que os clientes e a equipe tenham uma imagem clara do plano de trabalho para a versão do projeto.Mesmo depois que o projeto esteja completamente encaminhado, os proprietários do produto ainda têm muito trabalho para fazer para manter a reserva de produto em forma:

  • Adicionando e priorizando novas histórias

  • Solicite para a equipe estimar novas histórias e estimar novamente as antigas, conforme são compreendidas melhor

  • Examinando próximas histórias de usuários com a equipe para dividir itens conforme o necessário

  • Reunião com clientes e participantes para revisar e adicionar requisitos

Qualquer um pode adicionar itens à reserva do produto a qualquer momento, mas somente o proprietário do produto pode priorizar.O proprietário do produto também é o único que pode atribuir uma prioridade a uma história.Todos outros membros da equipe e os participantes devem deixar uma prioridade vazia ao adicionar uma história, mesmo se estiver usando uma ferramenta eletrônica que solicita essas informações.

Quando um artigo é adicionado, o proprietário do produto fará uma avaliação preliminar de sua prioridade com base na sua compreensão.Discutirá a história com o criador para melhor compreendê-la, para que possa, por sua vez, responder as perguntas da equipe.Em um horário predeterminado durante cada sprint, o proprietário do produto encontrará a equipe para discutir novos artigos e para estimar em conjunto de modo que ele possa priorizar mais precisamente em relação à outras histórias na reserva.Esse processo é chamado de "preparando a lista de pendências".

Hh765980.collapse_all(pt-br,VS.110).gifPreparação

A lista de pendências do produto deve ser revisada regularmente, como mencionado anteriormente.

No scrum, a equipe deve gastar de 5 a 15% do seu tempo em cada sprint nas atividades de preparação.A equipe deve compreender o que está por vir e o que está mudando, para poder dividir qualquer história grande que esteja subindo em prioridade, estimar todas as histórias que está sendo criadas, e fazer algum design ou planejamento emergente para as próximas histórias.Para garantir que isto aconteça, o proprietário do produto e a equipe, durante cada reunião de planejamento de sprint, reservaram algum tempo durante essa sprint para preparar junto a reserva.Para ler mais sobre o planejamento de sprint, consulte Imprimir planejamento e Planejar uma iteração.

Durante um sprint de duas semanas, como gostaria de realizar esta reunião na segunda semana.Isso fornece o proprietário do produto tempo suficiente para ter conversas significativas com clientes e os participantes, obtém um entendimento das alterações no negócio, e para esclarecer as histórias de usuário e as histórias que são novos ou subir na prioridade.É também um tempo lógico durante o sprint iniciar para antecipar os próximos sprints.Você pode decidir quando realizar a reunião.O importante é permitir tempo suficiente durante a sprint para concluir as atividades de preparação.

Durante uma reunião de preparação típica, o proprietário do produto apresenta o que há de novo, o que foi modificado e seus planos para os próximos sprints.Além de estimar novos artigos e a divisão das que devem ser concluídas em breve, a equipe leva tempo durante esta reunião para analisar a arquitetura atual do sistema e planejar ou projetar recursos programados.Durante esse processo, as estimativas de história geralmente mudam e as novas histórias tendem a aparecer como histórias maiores divididas em histórias menores.

Esse processo parece simples, mas pode exigir um pouco de esforço.Para ajudar a executar ações suavemente, o proprietário do produto deve estar preparado para responder perguntas.O conflito pode seguir se, por exemplo, o proprietário do produto estiver planejando que uma história seja realizada no próximo sprint, mas não pode fornecer a clareza que a equipe precisa para oferecer uma boa avaliação.Se isso acontecer durante as reuniões de planejamento do sprint, o ScrumMaster deve treinar o proprietário do produto quanto às informações que ele deve trazer a partir dos clientes e participantes para a equipe.

No final de cada reunião de preparação, o proprietário do produto deve publicar as alterações para os participantes e clientes para que todos possam ver o que há de novo, os próximos e o plano de versão atualizado.

Um retorno de bom produto garante que o software criado tenha os recursos mais importantes como identificados em suas conversações com clientes e participantes e definidos nas histórias do usuário.A fim de criar e manter uma boa lista de pendências do produto, você precisa permanecer ativamente envolvido com o participante/grupo do cliente e a equipe em uma base normal - a cada sprint.

Criar uma boa reserva não garante um bom sistema, mas a falta de uma boa reserva irá assegurar quase totalmente que você tenha um sistema que não faça o que os clientes solicitaram.Em outras palavras, não mantendo a lista de pendência atualizada quase sempre resultará em falha do projeto.

O proprietário do produto é um funcionário de tempo integral, e a lista de pendências é de sua responsabilidade.Usa a função seriamente.Manter a lista de pendência do produto em um bom estado - seus clientes agradecerão.

Consulte também

Conceitos

Comece como equipe

Planejamento ágil e iterações

Solicitação e comentários de Stakeholder processo por meio do acesso da Web da equipe

Acompanhar o trabalho e gerenciar o fluxo de trabalho

Outros recursos

Levante-se e executando com uma instalação de Servidor único o tutorial []

Diretrizes de Processo e Modelos do processo para o Team Foundation Server