Liquidando Dívidas Técnicas

Avelar Leão, Agile Expert e Trainer na K21

Este post não tem tags.

Compartilhe:

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.

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?

Sobre o autor(a)

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

Após terminar de ler o livro Ruído de Daniel Kahneman, decidi reler alguns clássicos que não olhava há algum tempo. Dentre eles, Rápido e Devagar do mesmo autor e Pensando em Sistemas de Daniela Meadows. Não pude deixar de perceber…

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

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

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…

Após alguns anos desenvolvendo produtos e ajudando outras empresas a fazer tal, gostaria de listar com vocês alguns erros comuns que percebi ao longo dessa jornada. Olhando para as 4 Áreas de Domínio da Agilidade (Negócio, Cultural, Organizacional e Técnica)…