Retrospectiva de Dívida Técnica

Encontre, priorize e planeje o pagamento da sua dívida técnica

Experimente esta apresentação ao vivo retrospectiva

Origens da Dívida

Quais áreas do código acumularam dívida técnica?

O módulo de autenticação de usuários está complexo demais e difícil de manter por causa de vários hacks e gambiarras acumulados ao longo do tempo.
Temos muito código duplicado em vários componentes que deveria ser refatorado em utilitários compartilhados.
Muitos dos nossos modelos de dados principais são fortemente acoplados, então qualquer extensão ou mudança de funcionalidade corre o risco de causar regressões.
Impactos e Riscos

Como essa dívida técnica está afetando o time e o produto?

Fazer o onboarding de novos desenvolvedores é muito difícil por causa da complexidade e da falta de documentação em algumas áreas.
Vivemos apagando incêndio e não conseguimos entregar funcionalidades novas num ritmo razoável por causa da instabilidade causada pela dívida.
Nosso processo de deploy é frágil e propenso a erros, o que gera problemas e quedas frequentes em produção.
Priorização

Quais áreas de dívida devem ser atacadas primeiro?

Deveríamos começar pelo módulo de autenticação, já que ele é uma dependência central que afeta várias partes da aplicação.
Melhorar a cobertura de testes dos componentes mais instáveis daria uma base sólida para as próximas refatorações.
Atualizar o frontend para a versão mais recente do React deveria ser prioridade máxima, para aproveitarmos as melhorias de desempenho e os novos recursos.
Plano de Ação

Como podemos tratar a dívida priorizada de forma sistemática?

Vamos reservar 20% de cada sprint para os itens de dívida de alta prioridade, começando pela refatoração do módulo de autenticação.
A cada duas semanas, teremos um dia dedicado a 'amortizar a dívida', com melhorias incrementais de acordo com a priorização.
No próximo trimestre, um desenvolvedor sênior vai se dedicar integralmente a liderar a redução da dívida técnica.

O que é uma Retrospectiva de Dívida Técnica?

A Retrospectiva de Dívida Técnica é uma sessão focada em que o time mapeia a dívida no código ou no sistema, entra em acordo sobre quanto ela está custando e decide o que pagar primeiro. A sessão termina com um plano com responsáveis e prazos. Dívida técnica é o acúmulo de atalhos e soluções pouco ideais em um código. Parte dela surge quando se escolhe a entrega de curto prazo em vez da qualidade de longo prazo, parte vem de lacunas de entendimento e parte de refatorações que foram sendo adiadas. Se ninguém cuidar dela, cada mudança fica mais lenta e mais arriscada. O quadro tem quatro colunas. Em Origens da Dívida, as pessoas apontam as áreas problemáticas específicas: módulos emaranhados, código duplicado, falta de testes, frameworks desatualizados. Impactos e Riscos trata do efeito dessa dívida na entrega, na qualidade, no onboarding e no moral do time. Priorização ordena os itens por impacto, esforço e importância. Plano de Ação transforma os itens principais em trabalho com responsáveis, prazos e acompanhamentos, como reservar uma parcela fixa de cada sprint para pagar a dívida. Faça essa retrospectiva mais ou menos a cada trimestre, ou sempre que o time sentir que a dívida está atrasando o trabalho, para que ela continue visível e pequena.

Formato da Retrospectiva de Dívida Técnica

Origens da Dívida

Quais áreas do código acumularam dívida técnica?

Peça às pessoas que sejam específicas sobre o tipo de dívida e onde ela está: code smells, problemas de arquitetura, falta de testes, dependências desatualizadas.

Impactos e Riscos

Como essa dívida técnica está afetando o time e o produto?

Converse sobre o custo real da dívida: entregas mais lentas, bugs que os clientes percebem, onboarding sofrido, desenvolvedores frustrados. Custos concretos ajudam a justificar o pagamento da dívida.

Priorização

Quais áreas de dívida devem ser atacadas primeiro?

Ordene os itens de dívida por impacto, esforço e quanto eles bloqueiam outros trabalhos. Uma matriz rápida de impacto versus esforço ajuda o time a chegar a um acordo.

Plano de Ação

Como podemos tratar a dívida priorizada de forma sistemática?

Monte um plano concreto: quem faz o quê, até quando e quando vocês vão acompanhar o progresso. Decidam quanto da capacidade de cada sprint vai para o pagamento da dívida.

Quando utilizar esta análise retrospectiva

  • Quando o código fica mais difícil de manter e evoluir a cada mudança.
  • Quando o time passa o tempo apagando incêndio e as novas funcionalidades vivem atrasando por causa da instabilidade.
  • Quando o onboarding de novos desenvolvedores é lento porque algumas áreas são confusas ou não têm documentação.
  • Quando manutenção e correção de bugs tomam mais tempo do que o trabalho novo.
  • Quando os desenvolvedores se frustram com as mesmas áreas problemáticas sprint após sprint.

Perguntas sugeridas para quebra-gelo

  • Se o nosso código fosse um prédio, como ele seria e por quê?
  • Qual foi o seu encontro mais engraçado ou mais doloroso com dívida técnica?

Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →

Ideias e dicas para sua reunião de retrospectiva

  • Mantenha a conversa sem culpados. Todo código acumula dívida; a questão é o que fazer com ela agora.
  • Garanta que as pessoas não técnicas presentes entendam o que é dívida técnica e por que ela importa para a entrega.
  • Priorize a dívida por impacto, esforço e importância em vez de tentar resolver tudo de uma vez.
  • Defina prazos, responsáveis e acompanhamentos regulares para o plano não empacar.
  • Reserve uma parcela fixa de cada sprint ou ciclo para pagar a dívida.
  • Automatize lint, testes e partes da revisão de código para que entre menos dívida nova.

Perguntas frequentes

O que é uma retrospectiva de dívida técnica?
É uma reunião focada do time para descobrir onde a dívida técnica se acumulou, discutir quanto ela está custando, definir o que tratar primeiro e planejar como pagá-la.
Quando fazer uma retrospectiva de dívida técnica?
Faça uma quando perceber entregas mais lentas, bugs recorrentes ou um monte de atalhos herdados de decisões passadas. Muitos times também a fazem com uma frequência fixa, como uma vez por trimestre, junto com as retrospectivas de sprint de sempre.
Como priorizar a dívida técnica na retrospectiva?
Avalie cada item por impacto, esforço e importância em vez de atacar tudo de uma vez. Depois, transforme os itens principais em um plano de ação com responsáveis e prazos.
Quem deve participar de uma retrospectiva de dívida técnica?
Os desenvolvedores que trabalham no código, mais o product owner ou quem define as prioridades. Se a pessoa que decide o que vai ser construído não estiver presente, o plano raramente ganha espaço na sprint.
Quanto tempo devemos dedicar ao pagamento da dívida técnica?
Não existe um número certo. Muitos times reservam uma parcela fixa de cada sprint, o que mantém o pagamento constante em vez de esperar por uma sprint de limpeza que nunca chega.

Modelos relacionados

Processo de Desenvolvimento de Produto

Dê um passo atrás das sprints e revise como vocês constroem produtos.

Retrospectiva de Correção de Bugs

Descubra por que os bugs acontecem e evite que voltem

Retrospectiva de DevOps

Revise implantações, incidentes e passagens de trabalho entre dev e ops.

Retrospectiva de Code Review

Deixe os code reviews do seu time mais rápidos e úteis

Pronto para conduzir essa retrospectiva?Experimente esta apresentação ao vivo retrospectiva