Débitos Técnicos são Bugs à Espreita
Débitos técnicos são causas-raiz potenciais de bugs que ainda não aconteceram
Quanto mais acompanho o esforço de times e projetos em melhorar a qualidade de suas entregas, mais me surpreende a existência, quase ubíqua, de backlogs de débitos técnicos. Mas o que mais me chama a atenção, na verdade, é que a própria informação de que esses backlogs existem precisa ser obtida com uma certa insistência — os débitos técnicos acabam tão misturados à “paisagem” de um projeto de desenvolvimento de software que, muitas vezes, acabam sendo esquecidos.
Bem, em primeiro lugar, talvez usar o termo “backlog” seja excessivo: “backlog” pressupõe uma lista de itens minimamente organizada, documentada, e, idealmente, priorizada. O que acontece, na prática, é que a “lista” está apenas na cabeça de integrantes do projeto, e aí temos já um dos principais problemas. Daí derivam perguntas importantes, como, por exemplo: qual é o tamanho desse “backlog”? Quais itens deveriam ser resolvidos imediatamente? Quais itens têm maior complexidade? Quais débitos técnicos têm maior interdependência com artefatos?
Do ponto de vista de Quality Assurance, é importante sublinhar que os débitos técnicos são basicamente causas-raiz de bugs que ainda não aconteceram; mais do que isso, são a causa-raiz de bugs complexos, que vão levar um tempo considerável para serem resolvidos, e que, muito provavelmente, podem disparar muitos defeitos regressivos, aumentando o custo financeiro de um projeto (porque basicamente estamos falando de um grande esforço de retrabalho) e a percepção dos stakeholders. Não é incomum módulos completos (e complexos) de uma aplicação serem construídos a partir de um código-base repleto de débitos técnicos. E, quando estes débitos técnicos resolvem “acordar”, causando problemas funcionais, problemas de escalabilidade e performance degradada, dentre outros, o time se depara com uma necessidade de refatoração enorme, com efeito cascata, basicamente gerando um “novo” projeto que, originalmente, não estava nos planos de ninguém.
As gambiarras e band-aids que vão sendo colocados embaixo do tapete viram um bicho de sete cabeças.
É claro que, especialmente em projetos ágeis, muitas vezes débitos técnicos são uma solução de compromisso entre os objetivos de um ciclo de entrega e a excelência do código e da aplicação sendo desenvolvidos. Até aí, tudo bem. O problema é quando esses débitos técnicos vão sendo deixados para trás, e quando ninguém faz nenhum acompanhamento.
Bem, eu sempre advogo que Quality Assurance não é apenas a respeito de testes. Bons engenheiros de Quality Assurance são muito mais do que meros testers. Na verdade, arrisco dizer que, em 2025, algumas atividades de Quality Assurance são tão ou mais importantes do que testar. Nesse espírito, os engenheiros de QA devem ser os responsáveis por dar visibilidade, organizar, priorizar e acompanhar a correção de débitos técnicos.
Uma solução interessante para a gestão dos débitos técnicos é criar mecanismos ativos para monitorar continuamente o acúmulo desses débitos ao longo do desenvolvimento.. Por exemplo, perguntar, ao final de cada ciclo:
Geramos débitos técnicos neste ciclo? (Esta é uma pergunta importante, e é interessante estimular os desenvolvedores a refletirem, especialmente considerando a tendência dos débitos técnicos de se “esconderem”.)
Qual é a complexidade dos débitos técnicos que geramos?
Qual é o impacto previsto dos débitos técnicos que geramos?
Qual é a estimativa de esforço de correção desses débitos técnicos?
Por que “decidimos” gerar esses débitos técnicos? (A resposta aqui nos ajuda a investigar se este processo de decisão realmente está se baseando em compromissos razoáveis.)
Com as informações acima, os engenheiros de QA podem começar a gerar um backlog “real” de débitos técnicos. Esta ação nos ajuda a termos a habilidade de responder, a qualquer momento do projeto, qual é a dimensão (em itens, em esforço, em complexidade) do nosso backlog de débitos técnicos. Mais do que isso, ajuda a atribuir um senso de urgência à solução dos débitos técnicos, não deixando que eles fiquem esquecidos e escondidos na memória dos desenvolvedores. Um backlog de débitos técnicos que seja bem estruturado também pode apoiar o planejamento de ciclos de desenvolvimento em que ao menos uma parte do capacity da equipe seja direcionada à solução dos débitos.
Um ponto importantíssimo também é que, quando o engenheiro de qualidade começa a “tomar conta” dos débitos técnicos, isso pode aumentar a eficiência dos testes: estamos aqui falando de testes caixa-branca que podem justamente tentar “arrancar” os band-aids dos débitos técnicos, aumentando a chance de os efeitos colaterais serem descobertos precocemente, e estimulando os desenvolvedores a melhorarem suas práticas e a planejarem melhor suas soluções.
Está na hora de olharmos para a gestão de débitos técnicos como uma atividade chave no ciclo de desenvolvimento de software, de modo a conseguirmos minimizar o impacto de cada item, e, principalmente, de maneira a melhorarmos nosso processo de decisão quando precisarmos decidir por soluções de compromisso que envolvam o balanço entre velocidade e excelência. Com a palavra, os engenheiros de Quality Assurance!