Débito Técnico? Dívida Técnica?

Dívida Técnica é uma metáfora* criada por Ward Cunningham, ele conta que em um projeto de desenvolvimento de um software financeiro ele utilizou esta metáfora para explicar o contexto. Ele disse para o chefe dele da época: “Se nós fracassarmos em fazer com que o nosso software esteja alinhado com o que nós entendemos como a maneira adequada de pensar a respeito dos nossos objetos financeiros, então nós vamos esbarrar em desentendimento e isto irá reduzir a nossa velocidade como se estivéssemos pagando juros de um empréstimo”.

[link com a fonte original e um video em inglês]

Metáforas é um conceito muito importante dentro de eXtreme Programming (XP) que muitas vezes é esquecido ou tratado como coadjuvante.

Características da Dívida Técnica

Dado as minhas experiências, eu escrevi algumas observações sobre Débito Técnico:

  • É inevitável, ele sempre vai existir
  • Não é passível de comparação entre produtos, projetos, repositórios..
  • Se não for pago, o débito tende a aumentar com o tempo
  • É “subjetivo”
  • Não é um número
  • Não é uma medida

Eu vejo como sendo um indicativo de quão fácil ou quão difícil é desenvolver novas funcionalidades e/ou dar manutenção/sustentar a uma determinada aplicação.

Não ter Débito Técnico é ruim. Isto se chama Gold plating.

Causas da Dívida Técnica

Algumas causas de se acumular Débito Técnico:

  • Upfront design (BDUF – geralmente é associado ao modelo Waterfall/Cascata)
  • Gambiarras
  • Deliberadamente sacrificar a qualidade para entregar na data
  • Implementar funcionalidade que não havia sido prevista
  • Falta de conhecimento técnico
  • Complexidade
  • Escolha de tecnologia/ferramenta/plataforma inadequada
  • Passar do tempo: código envelhece e apodrece

[exemplo: dependências, frameworks e bibliotecas exigem atualizações, softwares descontinuados e outros]

Quadrantes da Dívida Técnica

Basicamente, podemos classificar a Dívida Técnica em 4 tipos distintos:

  • Imprudente e Intencional: “Sabemos do problema, não vamos resolver”
  • Imprudente e Não Intencional: “Trabalhar com uma nova linguagem de programação”
  • Consciente e Intencional: “Dado nosso deadline, vamos entregar com o problema e depois corrigir o problema”
  • Consciente e Não Intencional: “Agora que entregamos o projeto, deveríamos ter trabalhado utilizando Métodos Ágeis”

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. Por exemplo: trabalhar com uma nova tecnologia ou um novo framework que o time não possui conhecimento vai fazer com que o resultado provavelmente não seja tão aderente e benéfico quanto deveria ser.

quadrantes débito técnico dívida técnica

 

[fonte original quadrantes do débito técnico do Martin Fowler]

Aspectos Mensuráveis do Débito Técnico

Alguns exemplos, de aspectos que podem ser mensurados ao longo do desenvolvimento de um software:

Embora existam muitos outros aspectos, mesmo que todos os exemplos acima e os não citados sejam mensurados nada disso garante que a Dívida Técnica será baixa. Ferramentas automatizadas são passíveis de retornar “Falsos Positivos” (exemplo: uma ferramenta automatizada identificando um padrão ou problema que na realidade não é um problema).

 

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s