Sempre ouvimos falar de Backlog quando lidamos com desenvolvimento de software. Seja no contexto de projetos, sustentação ou demandas, sempre alguém fala sobre isso.
Mas o que podemos entender como Backlog?
Há alguma classificação na literatura de Engenharia de Software a respeito disso?
É um conceito aplicável apenas na produção de software?
Para alguns parece algo irrelevante, mas não é. Afinal, qualquer software nasce de um backlog, mesmo que seus criadores não saibam disso! 🙂
Conceituando
Acho que a melhor tradução para backlog é Acúmulo. Mas acúmulo de que? Depende do contexto onde o termo é aplicado.
Uma pilha de pratos numa pia pode ser considerado um backlog de pratos para lavar, por exemplo.
Na prática, um backlog é um acumulado de “serviços”, uma pilha de itens a fazer, solicitados por alguém com base em suas necessidades/desejos, que devem ser entregues a quem solicitou depois que forem produzidos.
Finalidade na Produção de Software
Um backlog é um conceito aplicado na maioria das industrias de manufatura, ou seja, em empresas que produzem algo, em série ou não.
Em projetos de software a finalidade de um backlog é ser um repositório de requisitos que deverão ser desenvolvidos e entregues a seus demandantes, em algum momento no tempo.
Um item do backlog (ou um requisito), após estar devidamente preparado – mais à frente veremos sobre Definição de Pronto – é retirado do backlog e levado para ser desenvolvido.
/* Um backlog mal escrito às vezes é pior que não ter nenhum backlog. Não saber “para onde ir” demanda esforço para se buscar a direção. Mas ter como definição a “direção errada” é pior ainda, pois somente se descobrirá isso quando percorrido o caminho, e aí o desperdício é fatal. */
Como surge um backlog de software?
Quando falamos em desenvolvimento de software temos dois contextos possíveis: o software já existe ou será criado do zero.
Quando o software já existe, o backlog aplica-se na evolução do seu escopo, onde novas necessidades vão surgindo dos seus usuários, e com o passar do tempo, vão sendo materializadas em novas funcionalidades e funções.
Ou, ainda neste contexto, algumas necessidades novas podem se tratar de alteração de escopo (funcionalidades já existentes que precisam sofrer mudanças) ou pode haver a exclusão (também alteração de escopo) de funcionalidades existentes.
Ambas as opções são comuns no dia a dia, pelo fato de que software é algo que muda muito rápido, e parte de seu escopo se torna obsoleto na mesma velocidade (pelo mesmo motivo).
Quando o software ainda não existe, ou seja, haverá um projeto para sua criação (será criado “do zero”), o backlog é um dos primeiros insumos que pode ser utilizado na definição do escopo.
/* Nem todos os itens originalmente contidos num backlog serão escopo “de fato” do software. É comum itens serem excluídos/cancelados do backlog, e outros itens sofrerem muitas alterações antes de serem levados para construção. Em empresas/equipes onde a cultura de backlog é mais madura, isso é mais comum. Em empresas com cultura incipiente ocorre o grave erro de achar que, uma vez incluído um item no backlog, ele obrigatoriamente deverá se implementado. Isso gera muito desperdício de recursos. */
Ciclo de Vida
Um backlog é algo que pode ser temporal ou atemporal.
Temporal significa que será produzido em momento específico, utilizado e “jogado fora”, sem utilidade após seu escopo ser materializado em software.
Aplica-se quando fazemos um backlog especificamente para um projeto, por exemplo, onde uma vez concluído o trabalho de desenvolvimento, o backlog acabou.
Atemporal significa que será criado e produzido enquanto o software existir, e servirá como um repositório “vivo” de desejos dos usuários do software, constantemente alterado e refinado, tendo itens entrando na fila, itens saindo da fila e indo para desenvolvimento, e itens sendo excluídos/cancelados da fila sem ir para desenvolvimento.
/* O contexto “atemporal” é comum em empresas ágeis que enxergam o software como produto. Neste caso, enquanto o produto existir, seu backlog também existirá. Mais sobre isso pode ser visto aqui, em “Product Backlog”. */
Estamos falando de uma lista de itens, onde cada item é um desejo do usuário que utiliza (ou utilizará o software).
Para cada item do backlog existe um ciclo de vida padrão recomendado que deve ser aplicado (podendo ser customizado conforme a necessidade de cada empresa).
Cada item de um backlog sempre deve ser:
- Incluído
- Refinado
- Priorizado
- Estimado
- Construído (ou Excluído/Cancelado).
Vejamos abaixo um pouco sobre cada um dos momentos citados acima.
Inclusão
Um item é incluído no backlog quando trata-se de uma funcionalidade ou função ainda não existente no software.
Neste momento o nome (ou descrição) do item deve descrever ao máximo sua finalidade com exatidão e clareza, pois pouco se faz com um item de backlog genérico (isso costuma causar muitos problemas e desperdício de recursos).
Uma vez que foi levantado junto ao usuário sua necessidade/desejo, isso será descrito como um item do backlog.
Isso pode ser escrito de várias formas, por exemplo: como uma Estória (ou História) de Usuário, um Requisito Funcional, um Requisito Não-Funcional, uma Regra de Negócio, ou em texto livre mesmo.
Abaixo dois exemplos, um em formato de Requisito Funcional e outro em formato de História de Usuário:
- Requisito Funcional: Incluir um filtro para listagem de clientes pessoa física que possuem saldo acima de R$ 10 reais para envio de e-mail marketing com oferta de produtos Classe A.
- História de Usuário: Eu, enquanto Analista de Marketing Digital, quero poder filtrar os clientes pessoa física que possuem saldo acima de R$ 10 mil para enviar para eles e-mail marketing com oferta de produtos Classe A.
Refinamento
Os itens de um backlog nem sempre estarão no nível de detalhe necessário para serem desenvolvidos sem que assuma-se grandes riscos de desperdício de recursos (retrabalho, por exemplo).
Ainda, os negócios das empresas mudam muito rápido.
E no tempo entre a inclusão do item no backlog e seu momento de entrar para desenvolvimento, as necessidades podem ter mudado, sendo necessário refletir sobre o conteúdo do backlog (ou seja, seus itens).
Sempre que possível, preferencialmente com apoio de alguma rotina que defina periodicidade para isso (se for contexto de produto), ou em momentos específicos do ciclo de vida do projeto (antes do item ser retirado do backlog para ir para desenvolvimento), ele deve ser refinado.
/* Uma prática comum é o “anotar para não esquecer”. Isso se dá quando o Analista inclui o item no backlog após uma reunião com um usuário, após lembrar de um desejo já informado não incluído como item etc. Isso é bom pois sabemos como a vida é corrida, mas quando isso ocorre geralmente o detalhe do item está muito raso, e se não for refinado, ou será reprovado por um desenvolvedor e não será construído, ou então gerará desperdício de recursos se for construído, pois vai demandar ajustes depois. */
Priorização
Sem uma priorização adequada, o desperdício de recursos é garantido. Aqui podemos ver sobre isso, é assustador.
Um backlog é composto por “n” itens, mas quais devem ser feitos primeiro, quais podem esperar, quais realmente nem precisam ser feitos?
A priorização deve ser feita sempre orientada ao valor gerado ao negócio a partir do desenvolvimento do item.
Os itens com maior prioridade são os que devem ser mais detalhados (todos devem, mas para os mais prioritários este trabalho devem ser feitos primeiro).
Os itens com maior prioridade vão para o início da lista, pois serão os primeiros a irem para desenvolvimento, por serem os mais importantes.
Para entender um pouco melhor sobre priorização, aqui podemos ver sobre Priorização de Requisitos, e aqui podemos ver sobre Backlog de Produto, onde falamos um pouco sobre priorização também.
Estimativa
Uma vez incluído o item, refinado e priorizado, tem que haver uma estimativa de esforço (homem/hora) para se ter uma noção de quanto custará (em dinheiro e tempo) o desenvolvimento do item, antes dele ser enviado para construção.
Alguns itens antes costumam ter uma prioridade alta para o negócio, ser algo importante, mas quando se reflete sobre o custo de fazê-lo, sua prioridade pode mudar, e isso é natural (algo tipo: “vai ficar tão caro, que vou deixar para depois”).
O inverso também pode se aplicar: um item com baixa prioridade dada pelo negócio, quando se reflete sobre o custo de fazê-lo mostra-se muito viável economicamente, e então, sua prioridade muda e ele vai para “o início da fila” (algo tipo: “já que será barato, vamos fazê-lo primeiro”).
/* É natural, e até óbvio em vários casos, que em “tempo de backlog” é difícil se ter uma estimativa assertiva sobre o esforço necessário para sua produção. Mas isso não pode ser desculpa para não se ter uma ideia a respeito. O backlog é o norte do desenvolvimento. */
Construído (ou Cancelado)
Uma vez incluído o item, refinado, priorizado e estimado ele fica maduro, então ele precisa sair do backlog e: ir para desenvolvimento (no momento certo) ou ser excluído (ou cancelado, caso seja necessário manter histórico) do backlog.
Itens que são excluídos geralmente são itens que depois de algum refinamento do backlog mostraram-se inviáveis tecnicamente, caros demais, importantes mas sem orçamento para fazer (em detrimento de outros itens mais prioritários) ou então com o passar do tempo se mostraram não mais relevantes em função de mudanças no negócio.
Definição de Pronto
Um backlog, como citado no início deste post, é o principal insumo para desenvolvimento de um software.
Mas não significa que, havendo o backlog, há o que desenvolver.
Tem que haver uma forma de “dar aceite” no backlog, para depois de dado o aceite, jogar os itens para construção.
Quando este “aceite formal” não existe, prazo/esforço/custo estouram, e o retrabalho é quase algo normal.
Algumas coisas tem que ser checadas antes de um item do backlog ser considerado maduro para ir para construção, como:
- O item está claro o suficiente para ser entendido pela equipe?
- Está corretamente priorizado conforme o valor que gera para o negócio?
- Sua estimativa possui coerência com a realidade?
- Foi feito ao menos um refinamento do backlog?
- O item é viável tecnicamente, ou seja, é possível de ser implementado no sistema?
- O item possui algum nível de atomicidade, ou seja, é palpável, dá para ser entendido como uma única necessidade, ou deve ser quebrado em diversos itens?
Respondida estas e outras perguntas pertinentes, e as respostas sendo “ok”, então deve-se considerar o item “pronto”, ou “preparado” para ser desenvolvido.
Backlog x Scrum
Os profissionais de software ligados nas tendências mais recentes costumam associar o conceito de backlog apenas a modelos de processo que adotam Scrum. Mas isso não se aplica.
Na produção de software o conceito de backlog pode ser aplicado quando se usa qualquer modelo de processo, até mesmo Waterfall.
No Scrum temos o conceito de Backlog de Produto e Backlog de Sprint. Na parte final deste post temos uma definição de cada um dos tipos citados.
Mas podemos ter um backlog no formato de Lista de Requisitos, por exemplo. Ou até mesmo, em uma Lista de Tarefas.
O importante é ter este insumo maduro, para errar menos no desenvolvimento do software.
Concluindo
Um backlog maduro sempre será insumo de qualidade para o desenvolvimento do software. Se assim não for, problemas ocorrerão.
Aqui falamos de Backlog sem apego a método, modelo de desenvolvimento ou cultura da empresa.
Penso que independente de como o backlog será feito (em termos de formato) e de como o software será feito (se ágil ou tradicional, se tecnologia A ou B), tendo o devido cuidado com esta lista de desejos, como é o primeiro insumo do ciclo de vida da produção de software, as coisas tendem a dar mais certo.
Havendo dúvidas, sugestões ou críticas, fique à vontade para discutirmos aqui nos comentários, ok?
Abraço!