No gerenciamento de projetos ágeis, o backlog do produto desempenha um papel fundamental, pois ele é o repositório central de todas as necessidades, requisitos e funcionalidades que compõem o produto a ser desenvolvido. Abaixo, iremos explorar alguns aspectos desse artefato, desde as histórias de usuário até os épicos e temas. Veremos como criar e refinar os itens do backlog, garantindo que a equipe esteja alinhada com os objetivos e as expectativas dos stakeholders.
Antes de explorarmos o backlog do produto, é importante entender alguns conceitos essenciais relacionados a ele.
Requisitos funcionais e não-funcionais
A construção de um software é a junção de várias fases de desenvolvimento não apenas técnico, mas também de planejamento e estratégia. Saber o que é fundamental baseado nos problemas que o sistema vai resolver pode fazer a diferença em uma ferramenta de sucesso ou outra que está defasada. Entender os requisitos funcionais e não funcionais pode fazer a diferença.
Requisito é uma condição que se deve satisfazer para alcançar um objetivo.
Requisito funcional: Define uma função de um software ou parte dele. Ele é um conjunto de entradas, seu comportamento e sua saída. Envolve cálculos, lógica de trabalho, manipulação e processamento de dados e etc.
Requisito não-funcional: São relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, disponibilidade, segurança e tecnologias envolvidas.
Onde coletar requisitos?
- Wireframes
Ilustrações básicas da estrutura e componentes de uma página ou aplicativo. Geralmente são o primeiro passo no processo do design, após a concepção mental.
- Mockups
Geralmente focam sobre os elementos de design visual do site/aplicativo. São muito próximos ou idênticos ao design final efetivo e incluem todos os gráficos, tipografia e outros elementos da página. São apenas arquivos de imagem.
- Protótipos
São layouts semi-funcionais das páginas e servem para dar um preview de maior fidelidade do site/aplicativo real. Essa fase antecede a programação da lógica de negócios enquanto ele não pode ter todas as funcionalidades , geralmente dão aos clientes a capacidade de interagir com os elementos e simular a forma que o produto irá trabalhar. Eles podem ou não incluir elementos de design finalizados.
- Personas
As histórias de usuário devem ser escritas de acordo com a visão do usuário final, existem diversas técnicas que ajudam a entender melhor esse usuário. A mais utilizada é a criação de personas, elas são modelos descritos de usuários criados de dados de pesquisa que nos fornecem uma forma de entender como os usuários se comportam, pensam o que desejam e porque. É a transformação de todos os dados que você conseguiu através da pesquisa de campo em um personagem fictício.
- Histórias de usuário
São descrições simples de funcionalidades ou requisitos do sistema vistas do ponto de vista do usuário final. Elas capturam o que o usuário deseja fazer com o sistema e por quê, ajudando a equipe de desenvolvimento a entender melhor as necessidades e expectativas dos usuários. As histórias de usuário são uma parte fundamental do desenvolvimento ágil de software, pois ajudam a equipe a entender as necessidades dos usuários e a criar funcionalidades valiosas. A técnica INVEST é uma excelente abordagem para garantir que as histórias de usuário sejam bem definidas e efetivas. Vamos dar uma olhada mais detalhada nos critérios do acrônimo INVEST:
1. Independent (Independente): Cada história de usuário deve ser independente das outras. Isso significa que elas podem ser desenvolvidas e entregues separadamente, sem depender de outras histórias.
2. Negotiable (Negociável): As histórias de usuário devem ser flexíveis e sujeitas a discussão. Elas não devem ser rígidas ou prescritivas, permitindo que a equipe colabore e ajuste os detalhes conforme necessário.
3. Valuable (Valiosa): Uma história de usuário deve trazer valor ao usuário final ou ao cliente. Ela deve resolver um problema real ou atender a uma necessidade específica.
4. Estimable (Estimável): Deve ser possível estimar o esforço necessário para implementar a história. Isso ajuda a equipe a planejar adequadamente e alocar recursos.
5. Small (Pequena): As histórias de usuário devem ser pequenas o suficiente para serem completadas em uma iteração ou sprint. Isso facilita o acompanhamento do progresso e a entrega contínua.
6. Testable (Testável): A história de usuário deve ser testável. Isso significa que deve ser possível verificar se os critérios de aceitação foram atendidos por meio de testes.
Épicos e temas
Épicos são grandes histórias de usuários que compõem o backlog do produto e que ainda não foram decompostas. São histórias de usuário abrangentes, que são divididas em menores e depois se tornam tarefas. Se não cabe em uma sprint é um épico, se consigo decompor em 2 ou mais histórias é um épico. Os temas são coleções ou conjunto de histórias de histórias de usuário que estão relacionados e podem ser agrupadas. Juntos eles definem uma meta de negócio específica. Essa junção de temas é apenas uma forma de organizar melhor o trabalho.
Como criar o backlog do produto?
O backlog do produto é uma origem única dos requisitos do produto que precisam ser entregues, bem como todo entendimento necessário para se atender a esses requisitos, produzir funcionalidades e por fim, entregar um produto completo, incluindo mudanças e evoluções em produtos já existentes.
Ele é referenciado no Guia do Scrum como um artefato. Seu principal objetivo é garantir a transparência, uma vez que a partir dele podemos ver as suas funcionalidades previstas, qual a sequência de entrega, a quantidade de esforço necessária para isso e etc. O dono do produto é o responsável por manter todo o backlog do produto, principalmente porque este é um documento vivo e nunca estará completo, evoluindo à medida que o produto e o ambiente em que ele será utilizado se desenvolvem. Por isso, é possível afirmar que enquanto existir um produto, o backlog deste produto também existirá.
Os itens do backlog do produto serão então ordenados com base em seu valor, de forma que quanto maior for o valor de um item, mais cedo ele será entregue pelo time Scrum. Como os itens localizados na parte superior do backlog do produto serão entregues mais cedo, eles também serão mais detalhados e claros em comparação com os demais itens. Cada item do backlog do produto deve conter uma estimativa de trabalho. Essas estimativas são elaboradas exclusivamente pelos desenvolvedores e são usadas para que se possa avaliar a quantidade de itens que serão comprometidos em uma Sprint. O time Scrum pode adicionar detalhes, estimativas e novos itens ao backlog do produto durante todo o projeto, o que é normalmente chamado de refinamento do backlog. Seu formato é parecido com a imagem abaixo:
Tipos de itens do backlog do produto
O backlog do produto contém um número de itens e cada item descreve um bloco de construção da solução final. De forma geral, existem três possibilidades de se definir um item do backlog do produto:
- Especificação do requisito: O escopo tradicional é definido com termos técnicos claros para desenvolvedores, mas incompreensíveis para clientes, baseado na arquitetura do software e nos relacionamentos entre componentes. Métodos ágeis evitam essa abordagem por ser técnica demais e incluir detalhes de arquitetura desconhecidos no início do projeto.
- Caso de uso: É baseado no entendimento do que o usuário precisa em uma linguagem mais simples e descreve em detalhes um cenário de utilização do software com todas as ações possíveis que um usuário pode ter, bem como os retornos possíveis que o software deve dar a partir de cada uma dessas ações.
- Histórias de usuário: São semelhantes aos casos de uso, mas focam nos objetivos do usuário sem detalhar todo o comportamento. Enquanto casos de uso descrevem interações impessoais entre usuário e sistema, as histórias de usuário são mais simples e pequenas, omitindo detalhes de implementação. Isso as torna preferidas por exigir pouca manutenção e não se tornarem rapidamente obsoletas.
Técnica DEEP
Essa técnica ajuda a manter o backlog do produto organizado e adaptável. É um acrônimo para detalhado, estimado, emergente e priorizado. O backlog deve ser detalhado o suficiente para garantir clareza, mas sem exageros. Os itens próximos de serem executados precisam de mais detalhes, enquanto itens futuros podem ter menos. Cada item deve ter uma estimativa de esforço para facilitar o planejamento e refinamento contínuo, ajudando o produto a se adaptar às mudanças. A priorização é crucial, colocando os itens mais importantes no topo, variando conforme o contexto, mas sempre visando gerar valor para clientes e empresas.
Definição de preparado ou ready
Os requisitos de maior prioridade no backlog do produto são mais detalhados, enquanto os de menor prioridade têm informações básicas. É um erro acreditar que apenas definir uma história de usuário basta para os desenvolvedores criarem a funcionalidade. O dono do produto deve detalhar os itens até atingirem o conceito de "ready", significando que têm informações suficientes para serem desenvolvidos. Cada organização ou time define essa preparação, que pode incluir diagramas, rascunhos de interface e homologações. O refinamento do backlog é contínuo, com o dono do produto idealmente trabalhando uma sprint à frente, mas evitando detalhar muito antecipadamente para não criar documentação desnecessária. Requisitos não detalhados devem ser evitados nas sprints, mantendo a dinâmica de atualização do backlog.
Reunião de planejamento do backlog do produto
Exemplo de agenda para a criação o backlog do produto
Abertura
- Scrum Master revisita propósito, estrutura e agenda da reunião.
Visão do Produto
- O dono do produto relembra a visão do produto para alinhar expectativas.
Principais Funcionalidades
- Lista de funcionalidades desejadas elaborada pelo dono do produto e partes interessadas.
- Técnicas de priorização de itens do backlog do produto: Modelo de Kano, Moscow, Monopoly, Scorecard e entre outras.
Priorização de Itens
- Dono do produto e cliente identificam itens mais prioritários.
- Diversas técnicas de priorização serão discutidas.
Estimativa de Itens do Backlog
- Time estima macro a quantidade de esforço para itens priorizados.
- Foco nas duas ou três próximas sprints.
Dependências e Preocupações
- Identificação de riscos, dependências, impedimentos e desafios.
- Elaboração de plano de riscos ou plano de ação, se necessário.
Encerramento
- Retrospectiva para avaliar pontos positivos e melhorias da reunião.
Refinamento do backlog do produto
O refinamento do backlog é um processo contínuo, diferente dos eventos time-boxed do Scrum, e é de responsabilidade do dono do produto. Esse processo envolve atualizar, adicionar detalhes, novas estimativas, reordenar e priorizar itens do backlog. Os itens refinados, ou "ready", estão prontos para a Sprint. Embora o dono do produto priorize, os desenvolvedores são responsáveis por estimar o esforço dos itens, participando de sessões de refinamento quando necessário. Em geral, os desenvolvedores dedicam cerca de 10% do tempo da Sprint ao refinamento. A principal diferença é que o refinamento não é um evento formal, mas uma atividade contínua.
Spikes
São exercícios de prova de conceito usados em projetos de alto risco e incerteza, onde requisitos, recursos ou tecnologia são desconhecidos. Spikes permite que a equipe investigue problemas ou riscos, e podem ser histórias de usuário ou um conjunto delas. Eles podem ser desenvolvidos na primeira iteração do projeto para avaliar sua viabilidade. O principal benefício é identificar falhas ou inviabilidade logo no início, evitando gastos desnecessários e promovendo o conceito de "falha rápida"
Dando continuidade ao assunto sobre gerenciamento de projetos ágeis, no próximo texto exploraremos um tópico crucial: estimativas de trabalho. Essas estimativas são essenciais para planejar e alocar tarefas em sprints, garantindo que a equipe possa entregar valor de maneira eficiente.
Top comments (0)