Débito técnico, causas e consequências
O conceito de débito técnico tem seu uso mais comum no desenvolvimento de software, mas tem sua origem no mercado financeiro quanto aos efeitos dos juros sobre operações de empréstimos ao longo prazo.
Mas afinal, o que é o débito técnico no desenvolvimento de software?
Do inglês technical debt, o débito técnico diz respeito aos resultados de ações tomadas pelas equipes de desenvolvimento para agilizar a entrega de uma funcionalidade ou recurso do projeto e que por algum motivo precise ser refatorado no futuro.
Principais causas do débito técnico
Atalhos
Pegar um atalho no desenvolvimento de software significa que o seu código alcança apenas o mínimo de requisitos para ser aceito no processo. Ninguém pode negar que em algum momento os gerentes podem fazer algum tipo de concessão e permitir pegar um atalho. Dada a pressão para se realizar uma entrega a tempo, os atalhos podem ser tentadoras e perigosas opções a serem tomadas se não atentarem para as consequências.
Bibliotecas e frameworks (desatualizados)
Todos os desenvolvedores usam códigos que eles mesmos não escreveram (graças à comunidade e a cultura de código aberto ao redor do mundo). Utilizamos bibliotecas e frameworks para tornar a construção de software mais fácil, mais rápida e mais eficiente em termos de custo. Isso também cria um desafio: manter o código de terceiros. Os desenvolvedores podem ter vários tipos de problemas com uma biblioteca, como: documentação incompleta, falta de respostas pelo mantenedor e respostas desdenhosas.
O projeto pode ser mal mantido ao longo do tempo e representar problemas para a manutenção ou expansão da própria funcionalidade envolvida. Manter o suporte pode ser um grande problema quando o proprietário do projeto não vai na mesma direção que seu desenvolvedor deseja que ele vá. O que parecia eficiente e proveitoso no início pode criar bloqueios na trilha do desenvolvimento a longo prazo. A substituição ou revisão de tais componentes pode levar meses e criar um entrave no desenvolvimento das funcionalidades do seu produto.
O projeto pode ser mal mantido ao longo do tempo e representar problemas para a manutenção ou expansão da própria funcionalidade envolvida. Manter o suporte pode ser um grande problema quando o proprietário do projeto não vai na mesma direção que seu desenvolvedor deseja que ele vá. O que parecia eficiente e proveitoso no início pode criar bloqueios na trilha do desenvolvimento a longo prazo. A substituição ou revisão de tais componentes pode levar meses e criar um entrave no desenvolvimento das funcionalidades do seu produto.
Desenvolvimento de novos produtos
Você está ansioso para construir esse novo recurso assassino. Seus desenvolvedores apontam que sua atual capacidade de produção não está realmente pronta para receber toda essa magia.
E para ser honesto com suas partes interessadas, você realmente não tem certeza se esse recurso é ou não um recurso assassino. Geralmente, temos a tendência de ir por atalhos (veja o ponto inicial) ou fazer alguns hacks de código para fazer acontecer sem grandes investimentos iniciais de desenvolvimento. Você promete a todos que esses atalhos serão gerenciados no futuro quando esse recurso der algum retorno e puder pagar suas contas.
Sim! Sem contar que seus desenvolvedores provavelmente precisam de mais recursos de hardware. Esses servidores brutos não escalam, então você precisa ir para a nuvem com o Amazon AWS ou algo similar. Criando ainda mais desafios de implantação e migrações.
Serviços de terceiros
Nós vivemos em um mundo totalmente interligado e as tecnologias ainda mais. Um oceano de APIs parceiras precisam se comunicar entre si e o nosso sistema está incluído na lista.
Em algum momento bem inoportuno, seu parceiro lhe enviará um e-mail dizendo: "Estamos melhorando nosso sistema e vamos depreciar a API xpto. Deixaremos de apoiá-los a partir da data X".
Você não terá outra escolha, então coloque isto em seu backlog e planeje o tempo de atualização e siga em diante.
Como determinar o montante da dívida técnica
Não existe uma fórmula mágica para calcular o volume da dívida técnica. A razão é muito simples: para cada implementação ou mudança no sistema podemos ter diferenças no tempo, ou nos recursos necessários. Mas nem tudo está perdido, podemos traças alguns passos para calcular a dívida técnica:
Passo 1: Crie um épico no SCRUM para calcular a dívida.
A fim de criar visibilidade, crie um épico para a dívida técnica. Coloque aqui todas as histórias sobre as dívidas até então levantadas. Se ela se aplica a uma feature específica, você também apenas anexar as histórias de dívidas específicas à epopeia daquela feature. Anexar uma história a vários épicos garante que você possa ter uma visão total do débito e uma visão do débito ao nível de features a qualquer momento.
Passo 2: Spikes primeiro depois as histórias
Como a dívida técnica está dentro de seu sistema e, principalmente, em um nível técnico mais profundo, você precisará definir/clarificar a dívida real a fim de criar histórias. Histórias que não são 100% claras para sua equipe, nunca devem passar de um sprint.
Então, o que você faz? A resposta é: criar Spikes. Eles se parecem com histórias, mas sem pontos de história. Em vez disso, eles têm um tempo definido alocado (ex. 5 horas para investigar X) e seu principal objetivo é investigar para esclarecer o que precisa ser feito. O resultado de um Spike é uma história.
É importante se livrar de todos os Spikes o mais cedo possível. Você e sua equipe precisam esclarecer a escala completa da dívida e estimá-la na primeira sessão de planejamento que se aproxima. Todos os pontos estimados da história combinados darão a você o número total de dívidas.
Passo 3: Faça ajuste em seu roteiro, considere os prazos.
O próximo passo é planejar a dívida para execução a curto prazo e incorporar a redução da dívida técnica no roteiro de longo prazo. Em resumo, parecerá que você estará pagando a sua dívida de empréstimo ao banco.
Não se deixe enganar, você sempre criará dívidas. O monitoramento de sua dívida não é um exercício único, mais como uma etapa que sempre acontece dentro do DNA de sua operação.
Passo 4: Comunique aos interessados
O último passo é a comunicação. Agora que todas as dívidas técnicas foram mapeadas e incorporadas em sua operação, é hora de se comunicar com suas partes interessadas. O grupo mais importante será a alta administração, já que eles estão pagando a conta desta dívida. O mais importante é explicar como isto afetará a organização e, mais importante ainda, seus clientes. Um segundo ponto a se comunicar seria como isto afetará a velocidade do desenvolvimento do produto.
Não é preciso aborrecê-los com toda a história do "o que é dívida técnica". Basta explicar os pontos-chave para que eles saibam a que você está se referindo em comunicações futuras.
