Ir para o conteúdo principal

Divida técnica / Débito técnico

INTRODUÇÃO

O processo de desenvolvimento de software não pode ser comprometido gerando custos ao longo do tempo, fenômeno que Ward Cunningham chamou de “dívida técnica” em alusão à dívida financeira. Cunningham afirma que “entregar código imaturo é como entrar em dívida. Um pouco de dívida agiliza o desenvolvimento contanto que ela seja paga de volta prontamente com reescrita”.

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.

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 pagá-la.

“Dívida” ou “Débito”?

O termo original em inglês cunhado por Cunningham, “Technical Debt”, pode gerar dúvidas ao ser traduzido para o português. A palavra “debt” é comumente traduzida para “débito” erroneamente, quando o correto é “dívida”, sendo “debit” a palavra correspondente a “débito”. De acordo com o dicionário Aurélio, porém, tanto “dívida” quanto “débito” possuem como definição “aquilo que se deve”. A palavra “débito” ainda cita “dívida” como sinônimo”.

Em termos de software, essa dívida cria a dificuldade de manutenção de código, gerando ainda mais atrasos e mudanças no produto final.

Como zerar?

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 controlá-la. Por exemplo, somente com o passar do tempo, cria-se esse tipo de problema 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 Plating1.

 

DESENVOLVIMENTO

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).

McConnell classifica a dívida técnica em dois grandes grupos:

  1. Não Intencional: Causada por trabalho de má qualidade, por exemplo, um design que se torna suscetível a erro ou um código escrito por um desenvolvedor júnior que escreve código ruim;


  2. Intencional: Causada por uma decisão consciente feita pela organização com o intuito de otimizar para o presente ao invés do futuro. É subdividida em dois tipos:

      1. Curto Prazo: Em geral ocorre reativamente, por questões táticas, por exemplo: atalhos identificáveis individualmente (como financiar um carro) ou vários pequenos atalhos (como dívida de cartão de crédito).

      2. Longo Prazo: Em geral ocorre pró ativamente, por motivos estratégicos.

Fowler define um quadrante que consiste em duas dimensões: imprudente/prudente e consciente/inconsciente, conforme ilustra a figura abaixo:

débito técnico.png

Dentro de cada célula há um exemplo do tipo de dívida associada. O quadrante separa problemas que surgem de imprudência das decisões que são feitas estrategicamente.

Como mensurar débito técnico

Embora o conceito de débito 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;

CONCLUSÃO

Portanto concluímos que a dívida técnica é um problema importante no desenvolvimento de software. O foco excessivo na entrega de funcionalidades relevantes para o cliente pode levar a uma situação que torna-se impraticável alcançar exatamente esse objetivo, à medida que crescem os problemas de implementação. E para minimizar tais fatos, estudos científicos buscam esclarecer e definir os limites da dívida técnica, bem como definir formalismos para aplicar em projetos de desenvolvimento de software iterativos, incluindo abordagens ágeis.


Fonte:

Um estudo empítico sobre a gerência de dívida técnica em projetos de desenvolvimento de software que utilizam SCRUM. Dissertação mestrado de Ciro Goulart dos Santos – 2015.

https://ezdevs.com.br/o-que-e-debito-tecnico-saiba-como-tratar/

ENVOLVIDOS
Ancelmo Luiz
Matheus Cruz


1 Gold Plating é o fenômeno de trabalhar em um projeto ou tarefa além do ponto de diminuir os retornos. Por exemplo: depois de ter cumprido os requisitos, o gerente de projeto ou o desenvolvedor trabalha para melhorar ainda mais o produto, pensando que o cliente ficará encantado em ver recursos adicionais ou mais polidos, em vez do que foi solicitado ou esperado. O cliente pode ficar decepcionado com os resultados, e o esforço extra do desenvolvedor pode ser inútil.

Voltar ao topo