O primeiro passo é admitir: existe dívida técnica no seu sistema. Seja por decisões estratégicas para acelerar um lançamento e ganhar mercado, seja por mudanças tecnológicas ou novas práticas que pedem que código antigo seja revisitado.

Em praticamente todas as empresas que já trabalhei, existia (e imagino que ainda exista) algum tipo de dívida técnica. Em algumas, para não falar todas, presenciei o cabo-de-guerra entre a equipe técnica, desejando tratar esses itens e defendendo o porque são importantes, e os responsáveis pelo produto, promovendo a criação de novas features.

Neste post eu vou te dar pelo menos um bom motivo para pagar dívidas técnicas, deixar uma dica de quando fazê-las e uma sugestão de como priorizá-las.

Porque fazer

Facilidade de manutenção, ganho de performance, compatibilidade com novas tecnologias, diminuir o tempo que o time gasta lidando com os sintomas dessa dívida técnica (e claro, o tempo que seu time passa lidando com esses sintomas, ele está perdendo de fazer novas features, que melhorariam seu time-to-market)… Existem vários ótimos motivos pra investir esforço e resolver a causa raíz, mas eu vou falar só de um.

Quando todos argumentos se esgotarem e ainda assim ficar a impressão de que “isso é capricho de desenvolvedor”, ainda vale a pena. Por quê? Pela satisfação dos seus funcionários.

Qualquer empregador vai falar que achar mão de obra especializada é difícil. Será que não vale incluir um item no seu backlog pra manter um bom empregado?
Você ralou para achar um especialista, e agora que o encontrou, negligenciar a opinião dele pode gerar insatisfação.

Recentemente conversei com um gerente de produto de uma startup, e ele disse que uma das perguntas da entrevista que passou era: “se um desenvolvedor ameaçar sair caso um item X não seja desenvolvido, o que você faz?”
Segundo ele, várias respostas estariam certas na linha de entender esse item X, mas existe uma resposta errada: “é só um desenvolvedor, eu deixo sair”.

Talvez você não seja surpreendido com um funcionário falando isso explicitamente, mas ligue seu radar se a equipe reclamar muito de dívida técnica. Às vezes isso já é um indicativo da infelicidade desses profissionais e currículos podem já estar sendo disparados para outras empresas.

Quando fazer

Se você leu a seção acima e ficou convencido, ou já começou o texto com a intenção de lidar com dívida técnica, a partir daqui eu posso te ajudar.

Aceitar que vamos trabalhar com dívida técnica não significa que vamos parar tudo e ficar semanas focados nesses itens.

Importante: estou considerando aqui que os “juros” dessa dívida técnica estejam sob controle. Se não estamos fazendo nada da dívida e seria apenas uma melhoria para o processo, essa sugestão se aplica. Agora, se você tem um incêndio, talvez você precise de um plano de ação mais agressivo, incluindo talvez parar e trabalhar apenas na dívida técnica.

No universo do Scrum, o termo “hardening sprint” é usado para designar uma sprint inteira dedicada a consertar bugs e resolver dívidas técnicas. Deixo claro que por mais que o termo seja usado, o Scrum desaconselha totalmente essa prática, sugerindo por exemplo, considerar uma parte do esforço da sprint para tratar esses itens.

Recentemente estive com um time que tinha uma quantidade considerável de dívida técnica e, por alguns meses, até se dedicaram a trabalhar apenas nelas. Foi um período de insatisfação tanto das pessoas desenvolvedoras, quanto das pessoas de produto. Com o tempo, eles voltaram ao desenvolvimento de features, e o backlog de dívida técnica ficou parado, onerando capacity do time com pequenas demandas originadas das mesmas. Eles não trabalhavam com Scrum, nem nenhuma outra metodologia/framework. Existia, porém, um quadro tipo kanban (k minúsculo aqui).

A solução então para garantir que dívida técnica seria endereçada sem paralisar totalmente a entrega de features foi usar limites de WIP (Work in Progress).

O time não utilizava Kanban, nem limites de WIP (e nem era algo para se implantar no momento), mas chegamos num combinado:
Em qualquer dado momento, existirá um item de dívida técnica no quadro do time, sendo trabalhado.

Essa estrutura garantiu que existia um espaço para trabalhar em resolver dívida técnica, e tranquilizou stakeholders no sentido de mostrar que não iríamos “parar tudo” para trabalhar nesses itens.

Dependendo do tamanho do seu time e da sua necessidade, esse limite de WIP pode ser diferente de 1.

Essa ideia pode ser adaptada para um time com Kanban propriamente dito, com a criação de uma raia dedicada e limite de WIP considerando o tipo de demanda da “dívida técnica”.

Como priorizar

Não é só porque garantimos um espaço pra resolver itens de dívida técnica que não precisamos priorizá-las.

Se foi trazida a necessidade de fazer, é porque vamos ganhar alguma coisa, e se estamos falando de valor, podemos priorizar de alguma forma.

Dívida técnica, por natureza, não é algo que vai gerar valor para seu cliente ou usuário, pelo menos não diretamente – se gera valor, deveria estar com o resto do backlog para priorização. Como priorizar, então?

Dado esse dilema, achei na literatura referências à matriz GUT. Em resumo, avalia-se o backlog em Gravidade, Urgência e Tendência. Cada item recebe uma nota nessas três categorias, e o problema com somatória mais alta seria o mais prioritário. Porém isso não me atendia.

A maioria dos problemas não tinham gravidade mensuráveis, e urgência era só quando a bomba estourava. A tendência era uma incógnita.

Usei então a estrutura de BVP: Business Value Points. Seria a definição de critérios que faziam sentido para o time, com pesos ponderados.

Note que esses critérios só fazem sentido para a equipe que estava trabalhando comigo. Você pode usá-los como referência, mas pergunte-se se refletem totalmente a necessidade do seu time.

Existe um critério nessa lista ligado à valor monetário, mas seu peso é o menor, dado que os itens aqui não tem a natureza de impactar financeiramente a empresa, mas ainda assim pode ser relevante (até como desempate).

Daí, foi só jogar os itens e ver o resultado dado a média, considerando os pesos (dados fictícios):

O time então pegou o primeiro item da lista e começou a desenvolvê-lo.
Durante as cerimônias de planejamento, a matriz é revista e atualizada, para que assim que o item em WIP for finalizado, puxarmos o próximo.

Achou que este artigo te ajudou? Tem problemas com dívida técnica e não cobrimos aqui? Deixe nos comentários!