Dívida técnica em código de software

Olá pessoal, tudo bom?

O artigo de hoje está relacionado as dívidas técnicas no código de software. Definição? Quais os pontos principais? Veja na continuação

Dívida Técnica – definição

O termo dívida técnica foi definido por Ward Cunningham e descreve a dívida que a equipe de desenvolvimento assume quando escolhe um design ou abordagem fácil de implementar no curto prazo mas com grande impacto negativo no longo prazo. Nesse artigo, Martin Fowler, sugeriu a seguinte definição para dívida técnica:

A dívida técnica é similar à dívida financeira, ou seja, exige o pagamento de juros. Estes 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.

Além disso, nesse outro artigo, Martin Fowler, também cita também os exemplos de classificação da dívida técnica, como um cruzamento de 2 conceitos básicos, de Prudencia, quando o time de desenvolvimento entende o conceito de dívida técnica e como utilizá-lo e o conceito de Consciência, quando o time de desenvolvimento sabe que está gerando dívidas técnicas. Isso dividido em um quadrante com esses conceitos:

 

 

• Imprudente e proposital: O time não tem tempo para o design e utiliza uma solução rápida e com pouca preocupação com a qualidade;
• Prudente e proposital: O time precisa entregar o produto agora com todas as limitações conhecidas e assume de maneira pró-ativa as consequências para futuras correções.
• Imprudente e negligente: O time não tem consciência dos princípios básicos de design e então nem sequer imagina a bagunça que estão adicionando;
• Prudente e negligente: 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.

 

Desta forma, possuir dívidas técnicas em um projeto é inevitável e sendo considerado como uma expectativa. A chave está em ter certeza de que o time não está introduzindo novas dívidas negligentemente, o que contribuem para bagunçar o código e tornando muito difíceis, ou até mesmo impossíveis, de serem “quitadas”.

 

Entendendo a Dívida Técnica

Utilizando a analogia feita pelo Martin Fowler, vamos imaginar uma dívida financeira, com juros simples (para simplificar a explicação) e assim correlacionar para entender os efeitos de uma dívida técnica em um projeto de software. Suponha uma unidade de medida para o valor (funcionalidades novas, melhorias de performance entre outros) do software que estamos entregando, algo hipotético. Essa medida vamos chamar de “F”.

Assim com essa medida, vamos pensar em um time que é capaz de entregar 100 F por semana. Porém “excepcionalmente” essa semana existe uma funcionalidade muito importante que deve ser entregue, a qual necessita que sejam entregues 150 F. O que fazer? O time pega um empréstimo, utilizando POG, para que o time consiga entregar os 50 Fs a mais necessários nessa semana atípica. Compreendido até aqui?

Nas semanas seguintes o time continua com a meta de entregar os 100 F por semana. Porém um empréstimo foi contraído, e está começando a cobrar os juros. Então o time não consegue desenvolver com o mesmo desempenho, pois a gambiarra feita na semana excepcional está com problemas no design, bugs e outras coisas que fazem com que a atenção do time também esteja focada nessa funcionalidade muito importante. Suponha que isso custe 20% dos F entregues nessas semanas, entregando apenas 80 F de funcionalidades novas.

Se esse pagamento de juros continuar por 3 semanas custando 20% por semana, por exemplo, a sua dívida técnica terá custado 60 Fs e você emprestou somente 50 Fs para utilizar a mais naquela semana excepcional. Com esse simples ponto já estamos percebendo que não está valendo a pena ter se endividado no começo.

Percebeu que se em algum momento você não quitar a sua dívida técnica a sua geração de valor em software fica comprometida? E a situação é muito pior quando mesmo já tendo uma dívida técnica resolvemos contrair mais um empréstimo. Assim a dívida aumenta, e chega num determinado momento em que simplesmente não entregamos mais valor, mas somente ficamos pagando juros em uma gigantesca bola de neve.

Curva do Pânico

Observe a Figura 01. Aqui existem dois pontos ou você já passou por isso, ou está passando. Infelizmente, projetos de software tem grande tendência a entrar na Curva do Pânico e assim sacrificar a qualidade.

Uma pressão pelo aumento da produtividade inicia-se quando o time percebe que precisa adiar a entrega por algum desses motivos:

• Erros na estimativa
• Pressão por um prazo menor
• Falta de habilidade/conhecimento do time
• Juros da dívida técnica acumulado
• Entre outros motivos

Adicionar mais pessoas, normalmente vistas como meros recursos no projeto, costuma não funcionar, afinal de contas a lei de Brooks já dizia:

“nove mulheres não geram um bebê em um mês”.

É fato que os novos integrantes “caem de pára-quedas” na equipe e precisam de tempo para aculturamento dentro do projeto. Trabalhar mais horas por dia pode funcionar, aumentando de forma efetiva a produtividade. Mas esta não é uma situação sustentável, desgasta a equipe que acaba sacrificando ainda mais a qualidade e gerando mais dívida técnica.

Optar conscientemente por menos controle de qualidade pode funcionar a curto prazo, mas ao longo do tempo, o acúmulo de juros da dívida técnica, fatalmente, implicará em novos atrasos e mais pânico.

Ao contrário disso, será que não poderíamos negociar com o cliente? Se não for uma opção mexer no prazo, podemos negociar o escopo. Priorizar as funcionalidades mais importantes, que agreguem valor de negócio e retirar/simplificar funcionalidades menos importantes.

Por outro lado, se precisarmos contornar a qualidade para ter um benefício imediato, contraindo dívida técnica, temos que ter bem claro em nossas mentes (e na do cliente): será necessário pagar essa dívida o quanto antes, de preferência já na próxima iteração.

finally {

Em futuros artigos veremos como utilizar à qualidade de software ao nosso favor.

Duvidas ou sugestões? Deixe seu feedback! Isso ajuda a saber a sua opinião sobre os artigos e melhorá-los para o futuro! Isso é muito importante!

Até a próxima!