A expressão “tech debits” ou dívidas técnicas foi utilizada, pela primeira vez, por Ward Cunningham criando a analogia de que às vezes podemos fazer dívidas como, por exemplo, tomar algum dinheiro emprestado do banco, o que acumula juros e faz a dívida naturalmente crescer, mas que em algum momento precisaremos nos planejar para pagá-la.

Pra quem nunca teve contato com essa expressão, Martin Fowler escreveu nesse post em 2003.

Toda dívida gera juros (vide dívida técnica e juros composto) e existem algumas formas de lidar com a dívida. Neste artigo, vou listar algumas delas.

Parking Lot

Reserve uma área no quadro físico com uma quantidade limitada de espaços. Cada nova dívida deve ser registrada em um post-it e colocado em um destes espaços. Quando acabarem os espaços, o time não poderá fazer novas dívidas. O time precisará resolver algum dos itens antes de criar novas dívidas.

parking lot

Lane para dívidas

Crie uma nova lane no quadro físico do time. Apenas post-its de dívidas técnicas devem caminhar por esta lane. Estimule o time a sempre ter pelo menos um item caminhando nesta lane.

Esta abordagem torna fácil de perceber, visualmente, se o time está trabalhando em suas dívidas técnicas.

Esta forma ajuda a evitar que as dívidas se acumulem, porém o time pode acabar trabalhando em dívidas que não sejam tão valiosas.

Sprint de reforço

sprint-reforco

Sprint de reforço, ou Hardening Sprint, é uma sprint onde nenhuma feature nova é desenvolvida. O time trabalha apenas em melhorias no software como, por exemplo, refatoração, testes automatizados e melhorias de performance.

O post “Do We Need a Hardening Sprint?”, na Scrum Alliance, aborda um pouco sobre este tópico.

Eu diria que uma sprint de reforço é como usar o 13º pra pagar as dívidas. Você sabe que as dívidas estão lá, mas você espera uma oportunidade e gasta uma boa grana para quitá-las.

Limite de crédito

Imagine que o time tem um cartão de crédito com limite definido. Cada nova dívida técnica é uma compra neste cartão. Sempre que tiver uma oportunidade, “sobrar uma grana”, o time pode quitar uma parte desta dívida, como se adiantasse o valor do cartão de crédito. Se o time extrapolar o limite do cartão de crédito, ele não poderá mais fazer compras. Neste caso, o time precisa pagar o valor mínimo da fatura para voltar a usar o cartão de crédito.

pagamento-minimo

Realizar apenas o pagamento mínimo vai deixar o time eternamente pagando juros, ou seja, para cada nova feature vários ajustes serão necessários, retardando o time.

Assim como no cartão de crédito que precisa ser pago mensalmente, o time pode definir uma periodicidade para zerar a dívida.

Trabalhar com valores em dinheiro ajuda a manter a analogia clara. O time deve definir um valor em dinheiro para cada compra, um valor de limite para o cartão e quantos % do limite é o pagamento mínimo da fatura.

Esta forma, dá ao time flexibilidade para escolher pagar logo algumas das dívidas usando a capacidade que tem disponível e ainda o mantém constantemente preocupado em não estourar o limite, evitando que as dívidas se acumulem.

Atualização: Utilizando Inteligência artificial

Dá uma olhada no artigo: As dívidas técnicas receberam um grande desconto

Conclusão

Fazer dívidas pode ser uma opção para atingir um objetivo, mas é importante manter a saúde financeira. Pagar esta dívida recorrentemente garante juros menores. Mas não acompanhar as dívidas técnicas pode significar quanto vai pagar de juros ou a morte do seu software.

pagamento-recorrente

E você, está liquidando suas dívidas técnicas ou vai decretar falência?

Avelar Leão
Sobre o autor

Avelar Leão

Agile Expert e Trainer na K21

Trabalha com Métodos Ágeis desde 2009, atuou como disseminando práticas de engenharia ágil e como gestor tornou-se um evangelizador das práticas da Gestão 3.0 e coleciona variadas experiências na média gestão e na gestão de pessoas e equipes.

Artigos relacionados

Marcos Garrido, Sócio-fundador e Trainer na K21

Não é saber programar. Não é dominar prompts. Não é acompanhar o último modelo que saiu na semana passada. É saber tomar decisões. Quanto mais converso com as pessoas aqui na Nower/K21 e com os nossos clientes, mais tenho certeza…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

No texto “O caos invisível”, falei um pouco sobre a cultura do herói/heroína. Também já escrevi outros textos sobre o tema. Um deles com o meu colega Raphael Montenegro: “Paradoxo do Gestor Capitão Planeta”, que publicamos no final de 2020….

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Clique aqui para baixar PDF do Test Card 2.0 formato retrato PDF do Test Card 2.0 formato paisagem Imagem do Test Card 2.0 no formato retrato Imagem do Test Card 2.0 no formato paisagem Você trabalha com desenvolvimento de produtos….

Marcos Garrido, Sócio-fundador e Trainer na K21

O Usage-Driven Development (UDD) não é uma metodologia cheia de cerimônias e artefatos. É o nosso jeito, aqui na Nower/K21, de pensar produto na era da Inteligência Artificial (IA). E, como todo jeito de pensar, ele se sustenta em princípios:…