Compilar e gerenciar a lista de pendências do produto

Artigo
06/10/2015

Por Mitch Lacey. Proprietário da Mitch Lacey & Associates, Inc, uma empresa de consultoria especializada em adoções e melhorias baseadas em Agile e Scrum.

Janeiro de 2012

Neste artigo, Mitch Lacey explica a importância de uma lista de pendências do produto, descreve o que torna uma boa lista de pendências e fornece algumas melhores práticas para criar e manter sua lista de pendências.

Aplica-se a

Gerenciamento de ciclo de vida do aplicativo; O Team Foundation Server (TFS)

Neste artigo:

Introdução
A lista de pendências do produto
- Histórias de usuários
- Estimativa
- Priorização
Lista de pendências de um produto ativo
- Grooming

Uma lista de pendências do produto é uma lista priorizada de todos os recursos e funcionalidades necessários para concluir um projeto. No TFS, você deve gerenciar sua lista de pendências de produto usando os itens de trabalho. Sua escolha de tipos de item de trabalho variarão de acordo com o modelo de processo usado para criar seu projeto de equipe. Para saber mais sobre modelos de processo e os tipos de item de trabalho oferecem suporte, consulte Trabalhar com artefatos de projeto de equipe, escolher um modelo de processo.

Uma boa lista de pendências do produto está no coração de qualquer equipe de agile de bom funcionamento e apresenta as seguintes características:

É priorizada para garantir que a equipe compile os recursos mais importantes primeiro.
É estimada pela equipe para fornecer ao proprietário do produto clareza e permitir responder a questões como “Quando essas histórias estarão prontas?”
Inclui todo o trabalho necessário para concluir o projeto.
É um documento ativo, em constante mudança e evolução para refletir as realidades atuais do projeto.

Uma boa lista de pendências do produto não significa automaticamente um bom software. No entanto, a falta de uma boa lista de pendências do produto frequentemente resulta em software incompleto que não atende aos requisitos dos clientes e das partes interessadas.

Gerenciar a lista de pendências do produto é um trabalho de período integral. Técnicas simples podem ajudar a transformar o que pode ser um processo que causa sobrecarga e demorado em um processo interativo e iterativo que cativa efetivamente membros da equipe, clientes e partes interessadas. É essencial, portanto, aprender técnicas sólidas para ajudar a compilar, priorizar e manter sua lista de pendências do produto.

A lista de pendências do produto

A lista de pendências do produto é uma lista mestre priorizada e ativa de todos os recursos e funcionalidades necessários para concluir um projeto. Listas de pendências do produto geralmente incluem histórias de usuários de requisitos (por exemplo, requisitos), bugs, tarefas de pesquisa (picos) e melhorias de engenharia. Esses itens são estimados em unidades abstratas que geralmente são chamadas de pontos de história.

Listas de pendência do produto incluem todo o trabalho necessário para o projeto e evoluem com o tempo. Sendo assim, contêm não apenas os novos recursos de um produto mas também correções de bug e pesquisa—qualquer coisa que tomará o tempo da equipe. Todo trabalho que a equipe realizará deve partir da lista de pendências 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 possuem uma melhor visão do trabalho restante e reduz surpresas de última hora.

No início de qualquer projeto, é improvável haver uma boa lista de itens de lista de pendência do produto limpa e bem definida pronta para ser estimada e priorizada. Ao invés, é provável haver uma pilha de cartões de nota de história e, talvez, uma especificação funcional ou duas. Como proprietário do produto, é sua tarefa colocar essa bagunça em algum tipo de ordem para a equipe poder começar a estimar a lista de pendências.

Histórias de usuários

A primeira etapa é converter todas as ideias e notas em histórias de usuário, que expressam a funcionalidade desejada pelo usuário final (o que o software deveria fazer), mas não os detalhes de implementação (como criar o software que atenda a esses requisitos). O título de cada história de usuário segue o formato, “Como <usuário>, desejo <funcionalidade> para <motivo>.”

Um exemplo de uma placa de história

Como a própria lista de pendências, cada história de usuário evolui com o tempo. Ao longo do curso do projeto, sua equipe priorizará e estimará essas histórias, incluirá informações detalhadas e as dividirá em histórias menores ou as excluirá. Aquelas que forem colocadas em sprints são implementadas e entregues aos clientes.

Para saber mais sobre histórias de usuário, consulte Criar sua lista de pendências e Criar um storyboard de suas ideias usando o PowerPoint.

Após converter todas as ideias e notas em histórias de usuário, será a hora de estimar e priorizar.

Estimativa

Por definição, estimativas são imprecisas. No entanto, é possível ficar muito melhor em criar estimativas relativamente precisas com tempo, prática e a participação da equipe inteira. A primeira etapa é reunir a equipa para fornecer estimativas sobre os itens da lista de pendências do produto. Quando a equipe estima cada história, é dada uma estimativa de tamanho relativa com uma unidade de medida abstrata, chamada de ponto de história.

Estimativas são essenciais por duas razões:

Ajudam a responder a pergunta, “Quando estaremos prontos?”
Ajudam o proprietário do produto a determinar a prioridade de cada item.

Estimativas dão ao proprietário do produto e à equipe uma ideia do custo de uma história específica, o que, por sua vez, ajuda o proprietário do produto a priorizar as histórias relativas uma à outra. Quanto maior a estimativa do item, mais caro será para implementar em termos de tempo e recursos. Portanto, um item que pode ter estado alto na lista de desejos de um proprietário de produto poderá cair em prioridade caso venha com um alto custo.

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

Após a equipe estimar todas as histórias, será a hora de priorizar.

Priorização

Todas as listas de pendências do produto são priorizadas em termos de valor de mercado e risco. O proprietário do produto compara cada item da lista de pendências com outros para determinar sua prioridade relativa. Para isso, o proprietário do produto considera o tamanho de cada item, o valor de mercado e qualquer risco associado. Itens são armazenados em ordem decrescente de prioridade. Itens de alta prioridade aparecem no topo ou perto do topo da lista de pendências e itens de prioridade inferior residem no fim ou perto do fim da lista. As equipes escolhem o trabalho para o próximo sprint a partir dos itens de prioridade mais alta, de modo que os itens mais importantes serão concluídos primeiro.

Nem todos os itens na lista de pendências têm o mesmo tamanho. Alguns podem ser concluídos em um sprint, mas outros são tão grandes que a equipe não tem certeza sobre o que está envolvido ou quanto tempo levará para implementá-los. Isso é normal. Conforme os itens se movem para perto do topo da lista de pendências, a equipe os tornará menores e mais concentrados para todos entenderem melhor o trabalho que assumirão nos próximos sprints.

Assim como na estimativa, priorizar a lista de pendências inicial do produto pode ser desafiador. Como equilibrar efetivamente demandas concorrentes de partes interessadas, enquanto considera o produto final, riscos e custos? Por sorte, existem diversas técnicas que tornam a tarefa mais fácil, incluindo Jogos de Inovação e Pesagem Relativa. Consulte Priorização e Limpar e estimar a lista de pendências para saber mais sobre essas e outras técnicas.

Independente da técnica de priorização escolhida, é necessário ordenar o trabalho para garantir que a equipe compile recursos que conferem maior valor aos negócios, às partes interessadas e aos clientes. Se o trabalho não for priorizado, será aumentado o risco de entregar histórias de usuário de prioridade inferior ao invés de prioridade superior e histórias de usuário incompletas quando recursos e agendas mudarem.

(Para obter mais informações sobre a natureza de itens de lista de pendências, consulte Criar sua lista de pendências e Trabalhar com pendências de portfólio).

Lista de pendências de um produto ativo

O descrevi até agora concentrou em partir do zero até uma lista de pendências do produto estimada e priorizada. Diferente de um documento de requisitos, listas de pendências do produto não são criadas no início do projeto e deixadas em uma gaveta. Ao invés, a lista de pendências do produto evolui, expandindo e contraindo com as realidades do projeto. Alguns itens da lista de pendências do produto se tornarão irrelevantes e deverão ser removidos. Outros subirão até a superfície e deverão ser divididos em histórias menores. Novas histórias de usuário serão incluídas, estimadas e priorizadas conforme requisitos adicionais surgirem.

A equipe e as partes interessadas estão envolvidas na criação e no gerenciamento da lista de pendências do produto, porém, o proprietário do produto possui a responsabilidade final sobre ela. O proprietário do produto deve garantir que a lista de pendências está limpa, priorizada e atualizada para que os clientes e a equipe tenham uma visão clara do plano de trabalho para a liberação do projeto. Mesmo após o projeto estar em ritmo total, os proprietários do produto ainda terão bastante trabalho para manter a lista de pendências em forma:

Incluindo e priorizando novas histórias
Solicitando à equipe para estimar novas histórias e reestimar histórias antigas conforme elas são mais bem entendidas
Revisando novas histórias de usuário com a equipe para dividir itens conforme necessário
Reunindo com clientes e partes interessadas para revisar e incluir requisitos

Qualquer um poderá incluir itens na lista de pendências do produto a qualquer momento, porém, apenas o proprietário do produto poderá priorizá-los. O proprietário do produto também é o único que pode atribuir uma prioridade a uma história. Todos os outros membros da equipe e as partes interessadas devem deixar a prioridade em branco ao incluir uma história, mesmo se estiverem usando uma ferramenta eletrônica que solicita essa informação.

Quando uma história é incluída, o proprietário do produto fará uma avaliação preliminar da prioridade com base no seu entendimento sobre ela. Ele discutirá a história com seu criador para melhor entendê-la e para poder responder às perguntas da equipe. Em uma hora pré-determinada durante cada sprint, o proprietário do produto se reunirá com a equipe para discutir novas histórias e colaborativamente estimá-las para poder priorizar com maior precisão em relação a outras histórias na lista de pendências. Esse processo é chamado de grooming da lista de pendências.

Grooming

O grooming da lista de pendências do produto, conforme mencionado anteriormente, deve ocorrer regularmente.

Em Scrum, a equipe deve passar 5%-15% do tempo de cada sprint em atividades de grooming. A equipe deve entender o que está por vir e o que está mudando para poder dividir qualquer história grande que estiver subindo em prioridade, estimar qualquer história que for criada e fazer algum design emergente e planejamento para próximas histórias. Para garantir que isso ocorra, o proprietário do produto e a equipe devem, durante cada reunião de planejamento de sprint, reservar algum tempo durante esse sprint para realizar o grooming da lista de pendências juntos. Para saber mais sobre planejamento de sprint, consulte Planejamento de sprint e Trabalhar em prazos menores.

Durante um sprint de duas semanas, gosto de ter essa reunião durante a segunda semana. Isso dá ao proprietário do produto tempo suficiente para ter conversas significativas com os clientes e as partes interessadas, obter um entendimento das mudanças nos negócios e clarificar histórias de usuário e histórias que são novas ou estão subindo em prioridade. Também é uma hora lógica durante o sprint para começar a antecipar os próximos sprints. Você pode decidir quando realizar a reunião. O importante é permitir tempo suficiente durante o sprint para concluir atividades de grooming.

Durante uma reunião de grooming típica, o proprietário do produto apresenta o que há de novo, o que mudou e seu plano para os próximos sprints. Além de estimar novas histórias e dividir histórias que devem ser concluídas logo, a equipe aproveita o tempo durante essa reunião para revisar a arquitetura atual do sistema e para planejar ou fazer o design dos próximos recursos. Durante esse processo, estimativas de histórias mudam com frequência e novas histórias tendem a aparecer conforme histórias maiores são divididas em histórias menores.

Esse processo parece simples, mas pode ser um pouco difícil. Para ajudar a executar as coisas com facilidade, o proprietário do produto deve estar preparado para responder a perguntas. Conflitos podem resultar se, por exemplo, o proprietário do produto estiver planejando realizar uma história no próximo sprint, mas não poder fornecer a clareza de que a equipe precisa para fornecer uma boa estimativa. Se isso ocorrer durante suas reuniões de planejamento de sprint, o ScrumMaster deverá treinar o proprietário sobre quais informações deverá trazer dos clientes e das partes interessadas para a equipe.

No final de cada reunião de grooming, o proprietário do produto deve publicar as mudanças para as partes interessadas e os clientes para todos poderem ver o que há de novo, o que está por vir e o plano de liberação atualizado.

Uma boa lista de pendências do produto ajuda a garantir que o software compilado possui os recursos mais importantes conforme identificados em suas conversas com clientes e partes interessadas, e definidos em suas histórias de usuário. Para criar e manter uma boa lista de pendências do produto, é necessário estar ativamente envolvido com o grupo de partes interessadas/clientes e a equipe regularmente—em todo sprint.

Compilar uma boa lista de pendências não garante um bom sistema, mas a falta de uma boa lista de pendências quase certamente garantirá que você terá um sistema que não fará o que os clientes pedirem. Em outras palavras, não manter a lista de pendências atualizada quase sempre resultará em falha do projeto.

Ser proprietário do produto é um trabalho de período integral e a lista de dependências é sua responsabilidade. Leve a função a sério. Mantenha a lista de prioridades do produto em bom estado—seus clientes agradecerão.