O que é debito técnico? Saiba como tratar

Desenvolvimento

O que é débito técnico?

Débito técnico (ou dívida técnica) é um conceito no desenvolvimento de software que representa o custo implícito de uma implementação/solução pensada somente no agora, em vez de usar uma abordagem com melhor qualidade porém que levaria mais tempo.

O débito técnico pode ser comparado a uma dívida financeira, que, quando você não a quita, vai pagando os juros ao longo do tempo, acarretando ainda mais dificuldade em paga-la.

Em termos de software,o débito técnico cria a dificuldade de manutenção de código, gerando ainda mais atrasos e mudanças no produto final.

Como zerar o débito técnico

Não dá, isso mesmo, se você acha que a solução dos seus problemas é acabar com todo o débito técnico do seu projeto, você está enganado. A dívida técnica é inevitável e, portanto, sempre irá existir, cabendo a nos somente controla-la. Por exemplo, somente com o passar do tempo, cria-se um débito técnico pois o código acaba envelhecendo.

Se você ou seu time está na luta para não ter débito técnico, saiba que isso é ruim, e é chamado de Gold Plating.

Motivos do surgimento de um débito técnico

  • Prazos fora da realidade
  • Falta de conhecimento técnico
  • Escolha de tecnologia inadequada
  • Passar do tempo
  • Falta de uma metodologia de desenvolvimento iterativa (sem feedback e teste do cliente)

Tipos de débito técnico

Existem 4 tipos de débito técnico, podemos classificá-lo da seguinte maneira:

  • Imprudente intencional: “Sabemos do problemas mas não vamos resolver!”
  • Imprudente não intencional: “Trabalhar com uma nova linguagem de programação”
  • Consciente intencional: “Temos um prazo X, precisamos entregar com esse problemas, depois corrigimos”
  • Consciente não intencional: “Agora que entregamos o projeto sabemos como deveríamos ter feito.”

Como mensurar débito técnico

Embora o conceito de débito técnico seja subjetivo, existem diversas maneiras de mensurá-lo, sendo elas:

  • Duplicação de código
  • Cobertura de testes
  • Fragilidade de builds
  • Linhas de código comentadas
  • Complexidade ciclomática
  • Coesão do código

Como tratar

Aqui na ez.devs nós utilizamos a metodologia Kanban, dessa maneira nós sempre colocamos uma porcentagem de tarefas para tratamento de débito técnico na semana, com isso sempre temos algo entregável e tratado na semana (ou quinzena).

Se você trabalhar com SCRUM, pode deixar alguns pontos de folga, para que no final da SPRINT o time possa puxar alguns itens de correção de débito técnico.

Em último caso, você pode criar uma SPRINT ou uma Release apenas com correções de débito técnico. Nós particularmente não gostamos disso, pois não tem geração de valor real para o cliente final, por isso é sempre bom mesclar.

Débito técnico x Startups

Quando falamos de startups sempre estamos falando de testar hipóteses, dessa maneira, muitas empresas acabam aceitando – até demais – o débito técnico em prol de lançarem seus produtos o mais rápido possível no mercado. Para falarmos sobre isso, precisamos dividir as startups em duas etapas:

Antes do product-market-fit

Nesse momento, o objetivo principal da startup é validar seu modelo de negócio, e sim, nessa fase é muito importante lançarmos o MVP o mais rápido possível. Aqui um pouco de débito técnico vale a pena, desde que esteja no quadrante “Consciente e intencional”, é muito importante decidir o que será deixado de lado para que em um futuro próximo possa ser tratado sem muitos problemas. Nesse momento, especialistas e desenvolvedores podem fazer a diferença.

Escalando

Nessa fase é importante evitar ao máximo o débito técnico, e inclusive, matar alguns débitos da fase anterior. Nesse momento surgirão problemas de performance, usabilidade, arquiteturas que são frutos de dívidas passadas.

O máximo de cuidado aqui é pouco, pois como dito anteriormente, quanto mais débito deixarmos, mais difícil é dar manutenção no projeto.

A partir daí precisamos ser mais exigentes em relação a qualidade do nosso código, defina padrões, faça ainda mais testes, tudo o que for necessário para garantir um alto nível de qualidade.

E você? Tem problema de manutenção de código no seu projeto? Consegue negociar as pessoas para que sua equipe tenha tempo de tratar o débito técnico do projeto? Conta pra gente aqui nos comentários.

Entre com seus dados para a ligação.