¶ Divida técnica / Débito técnico.
| Data de elaboração | 19/05/2021 |
| Responsável pelo estudo | Ancelmo Luiz (Assessor), Matheus Cruz (Assessor) |
| Equipe do estudo | Caveiras |
| Alvo | Divida técnica |
| Origem | Melhoria: Reduzir a divida técnica no processo de desenvolvimento |
| Objetivo | Explanar sobre divida técnica e débito técnico. |
| Observações | 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. |
¶ 1. 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.
¶ 2. 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:
-
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;
-
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:
- 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).
- 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:
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;
¶ 3. 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.
¶ 4. Referências
Um estudo empírico 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/
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.