Antes de explicar o que é backlog, vamos falar um pouquinho sobre o início do desenvolvimento de uma aplicação.

Você já deve imaginar que um software não é criado do nada, certo? Afinal, antes de iniciar a codificação do sistema, a equipe precisa passar por um longo trabalho de definição do escopo, levantamento de necessidades do negócio e descrição de requisitos do sistema.

Fazendo uma breve comparação, essa fase de planejamento pode ser considerada um esboço, no qual os primeiros “rabiscos” do software são “desenhados”. Com o tempo, esses rabiscos são refinados e modelados, até que a aplicação tome a forma desejada.

O backlog é um dos principais insumos dessa etapa inicial da engenharia de software. Por meio dele, a equipe de desenvolvimento consegue visualizar todas as funcionalidades que a aplicação deverá ter e as tarefas que precisam ser feitas para que isso seja possível.

Quer saber mais sobre o assunto? Então veja os tópicos que preparamos para este post:

Fique com a gente e tenha uma boa leitura!

O que é backlog e qual a sua importância?

Em tradução literal, backlog significa acúmulo. No entanto, essa definição por si só não explica o que é backlog, certo? Isso acontece, pois é preciso entender como o termo é aplicado no contexto do desenvolvimento de softwares.

Na área da programação é muito comum que essa expressão seja associada às metodologias ágeis, especialmente o Scrum. Isso porque, nesse cenário, o termo backlog é usado pela equipe de desenvolvimento para se referir a uma lista de tarefas pendentes.

Por sua vez, essa lista nada mais é do que um repositório, no qual são elencadas todas as atividades necessárias para que os requisitos de um projeto sejam atingidos.

É nesse ponto que entendemos a importância do backlog. Afinal, ele funciona como um planejamento estratégico e ajuda a equipe de desenvolvimento a visualizar o caminho que será percorrido até a finalização do software, garantindo que o produto final esteja em conformidade com o que foi solicitado. 

Além disso, com o backlog, um objetivo grande (no caso, a criação de um software) é quebrado em várias tarefas pequenas, o que traz mais agilidade e produtividade para seu desenvolvimento, visto que a equipe tem um escopo de atividades bem definidas para trabalhar.

Quem são os responsáveis por administrar o backlog?

A administração do backlog é responsabilidade da equipe que está desenvolvendo o produto, incluindo a pessoa designada como dona do produto (Product Owner), na grande parte dos casos.

A equipe e Product Owner têm a responsabilidade de categorizar as tarefas em níveis de prioridade, prazo, entre outros, quanto estas forem dispostas para desenvolver o produto.

Dessa forma, constroem uma rotina chamada sprint backlog, baseada nessa primeira rodada de análise das tarefas. Contudo, o sprint backlog e o product backlog são conceitos diferentes e serão abordados nos próximos tópicos. 

Qual a relação entre Roadmaps e Backlogs?

Em resumo, os backlogs representam tudo o que a equipe poderia construir, enquanto os roadmaps indicam o que a organização priorizou.

Dito isso, um roadmap não é apenas uma lista de itens de backlog programados para cada lançamento futuro. Quando bem feito, o roadmap estabelece a priorização relativa e o tempo das principais tarefas a serem realizadas.

Assim, caso seja feita uma visualização de alto nível do roadmap, ela não listará itens específicos e detalhados de um item de backlog separadamente. Ao invés disso, a equipe do produto deve primeiro concordar com um roadmap. Depois dele ser preparado, o backlog serve como fonte para itens de desenvolvimento específicos.

As tarefas são mais benéficas para atingir os objetivos e metas de cada tema. Logo, as equipes de produto devem agendar as coisas mais prioritárias primeiro.

O que é product backlog?

Como o próprio nome indica, product backlog é uma lista de itens necessários para a criação do produto final. Esses itens podem incluir diversas coisas, como histórias de usuários, correções de bugs e adições de funcionalidades.

Para facilitar o entendimento, vamos ver um exemplo. Imagine que o produto final desejado é a implementação de um aplicativo de gestão de vendas. Nesse cenário, as pessoas usuárias da aplicação precisam realizar atividades como criar login, cadastrar produto, editar produto, lançar vendas, entre outras. 

Cada uma dessas atividades é uma tarefa que deve ser implementada pela equipe de desenvolvimento. Ou seja, é uma pendência que estará listada no backlog de produto. Contudo, é importante ressaltar que essa lista não é fixa. Pelo contrário, ela evolui à medida em que o software vai sendo criado e de acordo com as necessidades descobertas ao longo desse processo.

Outro detalhe importante é que o backlog de produto trabalha a priorização de tarefas. Por exemplo: a funcionalidade de cadastrar produto tem prioridade em relação a de editar produto, uma vez que a segunda depende da primeira, concorda? Mas existem outros critérios que interferem nessa priorização, como a necessidade de um cliente, a dificuldade de implementação e a urgência do feedback.

Para entendermos o conceito de priorização de tarefas, vamos observar a imagem a seguir: 

Nesse aplicativo de gestão de vendas, existem três tarefas prioritárias que são: fazer login, cadastrar produtos e lançar vendas. Essas três tarefas ficarão no topo da lista, conforme a foto acima, já que o product backlog considera a priorização das tarefas. As demais ficam no background e são executadas conforme as prioritárias são liberadas.

Quais os principais tipos de itens de um product backlog?

Estes 5 itens do backlog do produto orientam as equipes de desenvolvimento de produtos e, quando gerenciados corretamente, são a chave para agregar valor tanto para clientes, quanto para organizações:

1. Aquisição de conhecimento/pesquisa

A pesquisa é essencial quando você sabe muito pouco sobre como implementar um novo recurso ou deseja experimentar uma nova ideia. A equipe precisa reservar um tempo para adquirir o conhecimento necessário para iniciar o trabalho. 

2. Recursos

Um recurso (também conhecido como história de usuário) é uma funcionalidade distinta que a pessoa usuária precisa para agregar valor ao produto final. As solicitações de recursos podem vir das próprias pessoas usuárias finais, bem como de quem gerencia o produto, equipe de vendas, suporte, etc. Ou seja, quem quer que use o produto. 

A figura de Product Owner, nesse caso, acompanha essas solicitações para garantir que o mesmo continue a encantar quem já é cliente e atraia mais pessoas usuárias, se esse for o objetivo.

3. Bugs

Bugs e defeitos são problemas com um recurso já entregue. O número de defeitos ou bugs no backlog do produto depende do tipo de ciclo de desenvolvimento escolhido. As equipes ágeis testam defeitos no final de cada iteração, portanto, os bugs não tendem a sobreviver por muito tempo no backlog do produto. 

4. Trabalhos técnicos

O trabalho técnico deve ser feito para manter o produto e mantê-lo atualizado. Isso pode incluir qualquer coisa, desde atualizar seus bancos de dados até instalar um novo sistema operacional para a equipe de desenvolvimento. 

Esses tipos de itens do backlog do produto também são chamados “dívida técnica” porque, assim como a dívida financeira, eles podem causar problemas se permitidos. É aconselhável priorizar o trabalho técnico ao lado de recursos e defeitos. 

5. Spikes

Um Spike é uma investigação que ajuda a reduzir a incerteza de como um recurso pode ser entregue. Os spikes geralmente são corpos de trabalho com prazo determinado e devem alimentar o processo de refinamento do backlog. 

Um spike pode resultar na criação de um pequeno protótipo ou simplesmente em um documento detalhando o resultado da pesquisa realizada.

O que é sprint backlog?

Na área da programação, sprint backlog define um período de tempo pré-determinado durante o qual um conjunto de tarefas devem ser finalizadas — geralmente varia entre 1 a 4 semanas.

Dessa forma, o sprint backlog pode ser entendido como uma subdivisão do product backlog. Isso porque, em cada sprint, as tarefas com maior grau de prioridade são retiradas do product backlog e alocadas no sprint backlog para serem desenvolvidas naquele momento.

Vejamos um exemplo dessa subdivisão de tarefas do product backlog na imagem a seguir: 

Ilustração de uma sprint backlog

Ou seja, o sprint backlog seria a tarefa do product backlog dividida em pequenas ramificações. Por exemplo: tarefa de fazer login em um sistema. Para fazer login, eu preciso que o campo de senha não seja visível, que o e-mail seja válido, que só permita a entrada de pessoas autorizadas, que gere um token para cada sessão… Enfim, essas são apenas algumas das ramificações para uma tarefa de fazer login. 

É importante frisar que não existe um número máximo ou mínimo de atividades que podem ser alocadas em uma sprint. Essa definição fica a cargo da equipe de desenvolvimento, pois é preciso estimar quanto tempo será necessário para finalizar cada tarefa, a fim de determinar quantas atividades podem ser comportadas em um único ciclo.

O que é um backlog de manutenção?

O backlog de manutenção é uma maneira de priorização e organização do que deve ser feito, de forma que não sejam realizadas paradas repentinas e os processos funcionem de forma eficiente. 

Nesse caso, ele divide o trabalho que cada equipe precisa realizar. O backlog de manutenção pode ser considerado como indicativo para calcular a aptidão em seu grupo para finalizar as demandas pendentes. 

Para fazer esse cálculo, devemos utilizar a quantidade de pessoas-horas necessárias para realização de uma determinada tarefa e dividir pela quantidade de pessoas-horas de disponibilidade de sua equipe:

Cálculo de backlog

HH → quantidade de horas por pessoa (pessoas-horas)

Assim, se o resultado desse cálculo for igual a 1, significa que sua equipe está em dia com as tarefas e demandas. O gráfico que representa esse tipo de resultado é o seguinte: 

Gráfico ilustrando um resultado de cálculo de backlog que mostrou que a equipe está em dia com as demandas

Contudo, se o resultado for maior que 1, significa haver falta de mão de obra e sua equipe está tendo mais serviço do que ela realmente consegue fazer. O gráfico que representa esse tipo de resultado é o seguinte: 

Gráfico ilustrando um resultado de cálculo de backlog que mostrou que há sobrecarga de serviços na equipe

Qual a relação entre o Scrum e o Backlog?

O product backlog está contido em um framework utilizado para o desenvolvimento de aplicações chamado Scrum. Esse framework é um guia de boas práticas para o desenvolvimento e gerenciamento de projetos. A principal função dele é a de que sejam documentados de forma concisa as tarefas que vão aparecendo conforme o desenvolvimento de uma aplicação. 

Ou seja, dentre as boas práticas que estão no Scrum, uma delas seria a análise do backlog, seja ele para priorização de tarefas ou para dividir uma tarefa grandes em várias ramificações menores.

Como funciona o ciclo de vida de um backlog?

Em empresas que aplicam os conceitos de desenvolvimento ágil, é comum que o backlog seja visto como um escopo “vivo”. Em outras palavras, ele pode ser alterado e refinado para atender melhor às necessidades de quem vai utilizar o software ou para se adequar às mudanças de escopo do produto.

Para que isso aconteça, cada item da lista de pendências deve passar por todas as etapas do ciclo de vida do backlog. Explicamos brevemente quais são elas nos tópicos abaixo, confira!

Incluído

A etapa de inclusão é exatamente o que o nome diz. Nela, a necessidade levantada é incluída como uma tarefa a ser feita. Nesse momento, a descrição do item precisa ser feita de forma clara e precisa, pois é ela que vai guiar os próximos passos do desenvolvimento. Caso ela seja mal feita, é possível que a funcionalidade implementada não corresponda ao desejado.

Além disso, existem várias formas de se escrever a descrição dos itens. Normalmente, elas são feitas como histórias de usuário, mas também podem estar em forma de regra de negócio, requisito funcional, requisito não funcional e até em texto livre.

Refinado

Durante o processo de desenvolvimento, é comum que a equipe perceba que um item do backlog não está detalhado o suficiente. Nesse caso, é necessário refiná-lo para que ele seja especificado como uma tarefa única

Por outro lado, também acontece de haver a necessidade de refinamento devido à desatualização do item. Isso porque, do momento em que ele foi incluído no backlog até a etapa em que ele é levado para o desenvolvimento, podem ocorrer alterações nas necessidades do produto final que interferem nas funcionalidades já levantadas.

Priorizado

Como citamos mais acima, uma das funções do backlog é promover a priorização das tarefas mais importantes, garantindo que recursos de tempo e trabalho não sejam desperdiçados. Nesse momento, é importante entender quais itens trazem mais valor agregado para o negócio, pois eles deverão ter prioridade perante os outros.

Ademais, tais itens devem ter um bom nível de detalhamento, visto que serão os primeiros a serem implementados pela equipe.

Estimado

Após analisar a prioridade das necessidades do produto, é preciso haver uma estimativa de quanto esforço será necessário para a realização de cada item do backlog. Ou seja, nessa fase, avalia-se quanto tempo e quais recursos financeiros serão investidos durante o desenvolvimento.

Essa etapa é de extrema importância, pois ela pode interferir na ordem de prioridade das tarefas. Isso acontece, por exemplo, quando um item tem um grau de relevância alto e, ao mesmo tempo, apresenta um custo muito elevado para o momento. Nesse caso, ele pode perder sua prioridade.

O contrário também pode acontecer. Itens que, inicialmente, não trazem um grande valor para o negócio, podem ser priorizados pela equipe devido ao seu baixo custo de desenvolvimento.

Construído ou cancelado

Finalizadas as etapas anteriores, o item chega em seu estágio final, no qual ele está maduro o suficiente para ser desenvolvido. No entanto, antes de ser considerado concluído, é importante checar se:

  • O item foi detalhado o suficiente a ponto de ser visto como uma tarefa única;
  • Seu grau de prioridade está de acordo com o valor que ele gera para o negócio;
  • A descrição do item é compreensível para a equipe de desenvolvimento;
  • Sua estimativa de esforço de construção é coerente;
  • A implementação do item é tecnicamente viável para o momento.

Caso o item seja aprovado em todas as questões, ele pode ser encaminhado para a fase de desenvolvimento. 

Contudo, devemos lembrar que nem todos os itens alocados no backlog de produto são implementados. Afinal, ao longo da maturação da lista, muitos podem ser considerados inviáveis — tanto pelo custo quanto pelas dificuldades técnicas — e outros deixam de ser relevantes para o negócio passado algum tempo. Nesses casos, eles recebem o status de cancelado.

Saiba como refinar o seu backlog! (backlog grooming)

Imagine que você possua um jardim em sua casa, com muitos arbustos e até mesmo um lago que dá um excelente visual para a propriedade. Porém manter esse jardim limpo e bem cuidado, requer um cuidado especial. Caso não seja possível dispender tempo e dinheiro para realizar isso, o jardim virará uma selva.

O mesmo pode acontecer com o backlog, caso não sejam dados os devidos cuidados para as funcionalidades do sistema. Conforme o crescimento do backlog, ele pode se tornar algo completamente desorganizado. Nesse sentido, surgiu o conceito de Backlog Grooming para que o mesmo esteja sempre nos conformes.

A palavra grooming, traduzindo para o Português, significa manter arrumado, conforme a aparência. Nesse refinamento de backlog, ocorrem reuniões para aperfeiçoar o Product Backlog. Quando uma tarefa estiver próxima de ser finalizada, é necessário fazer esse tipo de reunião para garantirmos que podemos partir para a próxima etapa. 

Nessa reunião, equipe e Product Owner abordam os tópicos principais do backlog, podendo fazer perguntas de determinados comportamentos caso haja alguma interação do da pessoa usuária, como um clique em determinado botão, uma atualização da página, etc. 

Nem todas as questões precisam ser respondidas com todos os detalhes, pois a função de Product Owner nessa etapa é fazer os apontamentos necessários para que a equipe se sinta confiante. Além disso, deve verificar se esses tópicos abordados na estória da pessoa usuária estão adequados para uma próxima reunião de refinamento.

Além dessas perguntas que podem ser elaboradas numa reunião de refinamento, essa reunião também pode abordar os seguintes itens: 

  • Distribuir indicadores de prioridade nas tarefas; 
  • Remoção de itens obsoletos do projeto;
  • Mudar itens já existentes ou adicionar novas funcionalidades;
  • Divisão de estórias da pessoa usuária em pequenos problemas;
  • Ajustes nos prazos e estimativas, conforme necessário;
  • Dentre outros itens que envolvam organização e limpeza.

Quem participa desse tipo de reunião pode variar: pode ser a equipe toda envolvida no projeto ou apenas as pessoas desenvolvedoras, etc. Contudo, é primordial que a pessoa Scrum Master e a Product Owner estejam presentes nela.

Exemplo prático de aplicação de um Backlog!

Vejamos a seguir, um exemplo de algumas estórias de pessoa usuária para a construção de uma aplicação. O objetivo desse produto será permitir que a pessoa monte um pedido de massa conforme o desejado:

  • Produto escolhido: aplicação para uma loja de massas.
  • Descrição: aplicação que permita à pessoa consumidora montar e pedir sua massa preferida, de forma personalizada, escolhendo o tipo de massa, molho e adicionais.

Dividindo em prioridades, conforme a tabela a seguir: 

Prioridade altaPrioridade médiaPrioridade baixa
1. Tela de escolha da massa4. Tela de identificação do cliente6. Relatórios
2. Tela de confirmação do pedido5. Tela de monitoramento de entrega do pedido7. Tela de ajuda ao usuário
3. Tela de pagamento8. Tela de avaliação do produto

Os motivos das escolhas de priorização dos requisitos foram os seguintes: 

  • PRIORIDADE ALTA: interface de escolha da massa, tela de confirmação do pedido e tela de pagamento.

Motivos: priorização do serviço. Constituem a base do sistema e são partes fundamentais para lançar uma versão teste da aplicação.

  • PRIORIDADE MÉDIA: tela de identificação de cliente e tela de monitoramento de entrega do pedido.

Motivos: são telas que dependem da finalização das anteriores e oferecerão mais comodidade para a pessoa usuária.

  • PRIORIDADE BAIXA: relatórios, tela de ajuda e tela de avaliação do produto.

Motivos: a princípio, como são telas de feedback, não possuem ligação direta com o funcionamento do sistema. Dessa forma, serão acrescentadas apenas na fase final do projeto.

Por conseguinte, foram feitas as divisões dos sprints:

Sprint 1Sprint 2Sprint 3
Duração: 14/05/2022 – 14/06/2022Duração: 14/07/2022 – 14/08/2022Duração: 14/09/2022 – 14/10/2022
Requisitos (Prioridade alta):
Tela de escolha da massa.
Tela de confirmação do pedido.
Tela de pagamento.
Requisitos (Prioridade média):
Tela de identificação do cliente.
Tela de monitoramento de entrega do pedido.
Requisitos (Prioridade baixa):
Relatórios.
Tela de ajuda ao usuário.
Tela de avaliação do produto.
Metas:
1° semana: desenvolver a tela principal do sistema (tela de escolha).
2° semana: finalizar a tela de confirmação e pagamento, para que o cliente possa ter em mãos a base de sua aplicação e já possa lançar uma versão teste do sistema. 
Metas:
1° semana: desenvolvimento da tela de login do sistema.
2° semana: sincronização do sistema com o processo de entrega do produto.
Metas:
1° semana: desenvolvimento de base de dados para a criação de relatórios de venda e controle, aba de interação para auxiliar o usuário e tela específica para coleta de feedback sobre a aplicação e produto.
2° semana: fase final de desenvolvimento do software, revisão de requisitos e realização de testes.

Por fim, depois das reuniões de refinamentos, foram sugeridos três pontos de melhoria, listados a seguir: 

  1. Evitar a barreira de login, permitindo que a pessoa usuária navegue livremente pela aplicação e tenha que se cadastrar apenas se comprar algo.
  2. Adoção de um sistema de monitoramento de entrega semelhante ao dos Correios;
  3. Simplificação da tela de avaliação, limitando a apenas quatro pontos principais e três opções rápidas de resposta.

5 ferramentas para ajudar você com o backlog!

1. Trello

Tela da aplicação Trello

Em sua versão gratuita, o Trello permite a criação de até 10 quadros de controle de projetos, inclusão de pessoas, checklist, cards com data de entrega, criação de listas de afazeres para organizar os itens, etc. É uma ferramenta muito utilizada, pois, conforme mostra a imagem acima, podemos gerenciar o que ainda precisa ser feito, o que está sendo feito e o que já foi concluído. 

2. Mingle

Tela da aplicação Mingle

A versão gratuita do Mingle possibilita integração com código-fonte e presença de chat para conversar com as pessoas que fazem parte do quadro. Podem ser incluídas até 5 pessoas usuárias gratuitamente. Além disso, o mesmo também disponibiliza gráficos de indicadores de progresso, indicadores de previsão, etc. 

3. Asana

Tela da aplicação Asana

Em sua versão gratuita, o Asana permite a inclusão de até quinze pessoas por equipe. Seu painel contém uma área de pesquisa dos projetos e permite criar projetos, bem como tarefas de forma ilimitada para todas as pessoas que tiverem cadastro na plataforma. 

4. Wrike

Tela da aplicação Wrike


Em sua versão gratuita, o Wrike oferece integração com várias outras aplicações, tais como o Google Drive, Dropbox, OneDrive, etc.
Ele possui um aplicativo para ser utilizado em dispositivos móveis, tanto Android, quanto iOS. Além disso, permite que os arquivos sejam compartilhados e tem uma cota de 2 GB de armazenamento para as contas gratuitas.

5. MeisterTask

Tela da aplicação MeisterTask


Em sua versão gratuita, o MeisterTask inclui a criação de projetos e tarefas ilimitadas, bem como a adição de pessoas apenas em determinado quadro.
Possui um alto nível de customização dos projetos e tem um aplicativo para ser utilizado em dispositivos móveis, tanto Android, quanto iOS.

E o que é o backlog para quem não é da área de TI?

Não se preocupe se você não é uma pessoa da área de TI, pois esse conceito de backlog, pode ser utilizado em qualquer área.

Vamos imaginar um exemplo de caso que seria similar a uma atribuição de tarefas para qualquer tipo de pessoa, seja ela designer, estudante, etc.

Em um painel de helpdesk, por exemplo, geralmente, são atribuídos chamados conforme as solicitações das pessoas usuárias. Qualquer pessoa do atendimento pode pegar uma tarefa dentre esses chamados para resolver. Ou seja, conforme uma pessoa está resolvendo uma demanda e fica livre, ela pode se dirigir a essa listagem de chamados e pegar a que está no topo da lista para resolver.

Esse fluxo é similar uma “despensa de afazeres”: cada pessoa, quando estiver com tempo livre e com as outras tarefas já resolvidas, procurará outra tarefa da lista para cumprir.

Você pode utilizar esse conceito como um espaço para guardar ideias criativas a serem realizadas no futuro, como realização de viagens e projetos pessoais. Listando todos os lugares que deseja conhecer, por exemplo, essa listagem ficaria no seu backlog interno. Assim, conforme vai conhecendo os lugares e riscando dessa sua lista, você vê quais são os próximos destinos e pode se planejar melhor. 

Conclusão

A primeira coisa necessária para construir um bom software é uma lista que esclareça as necessidades do negócio e os requisitos que a aplicação deverá atender. O backlog é a ferramenta que mais auxilia nessa questão. Ter um bom backlog facilitará todo o ciclo de desenvolvimento.

O product backlog divide, nessa lista de tarefas, quais são as mais prioritárias a serem feitas e, o sprint backlog divide essas tarefas em ramificações menores para serem concluídas de forma gradual. Existem algumas plataformas que auxiliam no controle dessas tarefas, tais como o Trello, o Asana e o MeisterTask.

Gostou do conteúdo e quer continuar aprendendo? Então, aproveite a visita ao blog e saiba mais sobre o Scrum — uma metodologia ágil utilizada no gerenciamento de projetos de software!

0 Shares:
Deixe um comentário
Você também pode gostar