Se você é ou já foi desensenvolvedor de software, é bem provável que
já tenha deparado com uma funcionalidade praticamente impossível de se
dar manutenção, tamanha era a falta de qualidade do código. Em alguns
casos, daria mais trabalho reorganizar e padronizar a estrutura, e somos obrigados a refazê-la toda gerando um
grande desperdício de tempo e dinheiro.
Em poucas palavras isso é a dívida técnica, mas já que precisamos de uma definição embasada na teoria, segue abaixo a que Martin Fowler sugeriu:
A dívida técnica é similar à dívida financeira. Assim como a dívida financeira, a dívida técnica exige o pagamento de juros. Este vem na forma de esforço extra, que devem ser pagos em desenvolvimentos futuros por conta da escolha de um design mais rápido e de baixa qualidade. Nós podemos optar por continuar pagando estes juros ou quitar de uma vez a dívida fazendo uma refatoração, transformando um design de baixa qualidade em um design melhor. Apesar dos custos para saldar a dívida, ganhamos reduzindo os juros no futuro.
A dívida técnica pode ser classificada da seguinte forma:
- Imprudente e intencional – O time não tem tempo para o design e utiliza uma solução rápida e com pouca preocupação com a qualidade.
- Consciente e intencional – O time precisa entregar o produto agora com todas as limitações conhecidas e assume de maneira pró-ativa as consequências.
- Imprudente e não intencional – O time não tem consciência dos princípios básico de design e então nem sequer imagina a bagunça que estão adicionando.
- Consciente e não intencional – Isso é verdade para times com excelentes arquitetos. Eles fornecem uma solução que agrega valor ao negócio, mas depois de completar a solução, eles entendem que a abordagem de design poderia ter sido melhor.
Podemos dizer que possuir dívidas técnicas em um projeto é inevitável e sendo considerado como uma expectativa. O que deveríamos almejar é sempre ter Dívida Técnica nos quadrantes verdes abaixo. Estes, são os quadrantes onde temos consciência sobre assumir um risco que pode gerar um impacto no futuro. Embora os quadrantes azuis não sejam inevitáveis, eles representam e abordam fatores que nem sempre são facilmente compreendidos.
Origem e causa
Muitas vezes a dívida técnica tem origem em fatores externos ao software. Algumas vezes esses fatores são intransponíveis, mas outras vezes eles produzem efeito simplesmente pela demora em responder prontamente.
Uma vez que a dívida técnica não é um problema opcional, a melhor abordagem talvez seja procurar entender e identificá-la o quando antes. Assim, é importante identificar algumas de suas causas para que possam ser tomadas ações de redução ou mitigação antecipadamente. Abaixo estão algumas das causas mais comuns para a geração de dívida técnica:
- Definição Insuficiente
- Pressão do Negócio (Político/Legal)
- Lacuna de Entendimento sobre Dívida Técnica
- Alto Acoplamento
- Ausência de Suíte/Kit de Testes
- Falta de Documentação
- Falta de Colaboração
- Desenvolvimento Paralelo
- Postergação da Refatoração
- Ausência de Padronização
- Falta de Conhecimento
- Falta de Empenho e/ou Motivação
- Liderança Fraca em Tecnologia
- Especificação de “Último Minuto”
Conclusão
Não existe solução definitiva para o "problema" da dívida técnica,
porém é possível diminui-la ao máximo, atacando as principais causas e
origens.
Sugiro que faça uma análise do seu contexto de trabalho e comece elencando as causas
mais comuns. Ordene as que exigem menor esforço para solução nos primeiros lugares e comece a agir o mais rápido possível, de forma a já diminuir a criação de novas
dívidas.
Aos poucos, você e sua equipe, terão mais tempo e poderão (e deverão)
fazer as próximas implementações para as causas mais demoradas e complexas seguindo
a ordem de sua análise.
Qualquer dúvida ou sugestão, poste nos comentários.
Mãos à obra e boa sorte.
Referências
https://agilecoachninja.wordpress.com/2016/03/08/debito-tecnico-divida-tecnica/
https://artesoftware.com.br/2019/02/10/divida-tecnica/
