Definição do escopo do projeto
Product backlog - modelo genérico (projeto web)
Atualizado em 7.2.2010Num projeto de software ou num projeto de web site, o product backlog é uma lista de requisitos que devem estar contemplados no produto final - podem ser funcionalidades ou não. O conteúdo desta lista é definido pelo product owner, representante do cliente no dia-a-dia do projeto, e é constantemente discutido pela equipe, que sugere o acréscimo ou a retirada de itens de acordo com o andamento do projeto.
Os requisitos do product backlog, ou user stories, podem contemplar funcionalidades como:
◊ Páginas personalizáveis pelos próprios usuários, de acordo com suas preferências de conteúdo e layout.
◊ Mala direta segmentada, organizada de acordo com as demandas dos usuários, com preparo de estrutura de informações, processos e tecnologias.
◊ Análise de estatísticas de acesso e de vendas, com uso de tecnologia específica.
Um site de comunidade, pode precisar de requisitos como:
◊ Lista ou fórum de discussão.
◊ Ferramentas de inserção de comentários e conteúdo, como nos blogs.
◊ Sistema de gerenciamento de conteúdo.
◊ Facilitação de criação de soluções coletivas.
Já um site de comércio pode precisar de requisitos relacionados à venda de produtos:
◊ Publicação de mostruário dos produtos com animações e perspectivas 3D.
◊ Ferramentas de busca inteligentes para localizar produtos.
◊ Ferramentas que favoreçam vendas cruzadas (cross-selling), oferecendo produtos relacionados aos que o cliente está comprando (como batatas fritas para o comprador de cerveja); ou vendas "de alto nível" (up-selling), apresentação de um produto melhor, localizando-o próximo a outro, mais popular. (Ver Cross-selling e up-selling)
◊ Programas adaptados ao oferecimento de promoções online e offline, campanhas de anúncios, blogs corporativos, em campanhas comerciais agressivas.
Os requisitos do product backlog também podem contemplar:
◊ Áreas da arquitetura da informação
◊ Características do layout da interface
◊ Características do conteúdo
◊ Funcionalidades de software e soluções tecnológicas (formatos das informações publicadas, configurações tecnológicas dos usuários, necessidade de bancos de dados, implementação de programas de autoria de páginas, imagens, vídeo, áudio, integração com ferramentas de gestão ou de CRM já existentes na organização).
◊ Características de usabilidade, acessibilidade e funcionalidades especiais.
■ Os itens da lista de tarefas (requisitos funcionais ou não) são selecionados baseados no valor que têm para o cliente. Os itens de maior prioridade e de execução mais imediata são mais detalhados, enquanto os que serão realizados em etapas posteriores não incluem as pequenas tarefas - que serão especificadas e detalhadas ao longo de cada iteração (sprint).
A lista do product backlog não precisa estar completa no início de um projeto, pois deve crescer na medida em que projeto evolui e seus objetivos vão ficando mais claros tanto para o "dono do produto" quanto para a equipe de projeto em geral.
Elementos do product backlog
■ Os requisitos do product backlog, ou user stories, são ordenados por prioridade. Isto é suficiente para cada ciclo (sprint) do projeto. Devem incluir, cada um:
◊ Uma identificação com número e/ou código, para que seja seja fácil referenciá-lo com precisão em conversas ou mensagens.
◊ Um título ou descrição sumária para a escrita no quadro de tarefas (taskboard).
◊ Valor de negócios (relativo, estabelecido pelo dono do produto, ou product owner) - estabelece a priorização dentro de cada iteração, ou etapa, ou ciclo do projeto.
◊ Uma descrição mais detalhada da funcionalidade ou aspecto a desenvolver.
◊ O número de pontos, ou a medida do esforço que a equipe vai empregar para a realização - não é definido pelo dono do produto, mas através de consenso da equipe de projeto.
◊ Teste de aceitação - Marcação do dono do produto se o produto de cada iteração foi aceito (a ser definido em cada uma).
Também a inserção de uma descrição resumida dos macro-processos de trabalho, ou principais user stories ajuda o cliente a entender como o projeto será realizado.
■ No início de cada ciclo, o dono do produto (product owner) seleciona os requisitos mais importantes do product backlog, gerando a selected backlog. Durante cada reunião de planejamento de ciclo (sprint planning meeting) este prioriza alguns itens do selected backlog e os submente à equipe. Esta equipe homologa a escolha e determina que items poderá realizar no ciclo (sprint).
Estes passam do selected backlog para o sprint backlog e cada item é dividido em uma ou mais tarefas, que então são divididas entre os integrantes do grupo.
■ Exemplo de modelo básico product backlog para projeto de site institucional. Planilha em formato xls, 25Kb.
Texto publicado em 11.1.2009.
Assuntos relacionados
► Mudanças do escopo
► Abordagens do escopo
► Elementos do Termo de Abertura do Projeto
► Atividades relacionadas (à articulação do escopo)
► Visão geral do escopo - modelo resumido
► Definição do escopo do projeto - amplitude e condições para a realização do projeto
► Objetivos do projeto (briefing) - consenso sobre metas
Bibliografia
► Livro: Subject to change - creating great products and services for un uncertain world, de Peter Merholz, Brandon Schauer, David Verba e Todd Wilkens. Sebastopol, CA: O´Reilly, 2008
► Product backlog (AgileSoftwareDevelopment.com, acesso em 11.1.2009)
Mais informação sobre o assunto (links externos)
► Collaborative agile inception, de Jeff Patton (AgileProductDesign.com, acesso em 12.1.2009)
► Twelve emerging best practices for adding UX work to Agile development, de Jeff Patton (AgileProductDesign.com, acesso em 12.1.2009)