Matriz de Débitos Técnicos: como organizar as dívidas do time

Esta semana um dos times que facilito me procurou para ajudá-los a tomar algumas decisões sobre débitos técnicos. Basicamente, o time elencou alguns débitos, mas não sabe muito bem o tamanho ou como decidir o melhor momento para quitar o débito.

Antes de continuar, você sabe o que é um  débito técnico? Eu super curto a definição (e a abordagem) do Martin Fowler para o tema:

A dívida técnica é similar à dívida financeira. Assim como a dívida financeira, a dívida técnica exige o pagamento de juros. Estes vem na forma de esforço extra, que devem ser pagos em desenvolvimentos futuros por conta da escolha de um design mais rápido e de baixa qualidade. Nós podemos optar por continuar pagando estes juros ou quitar de uma vez a dívida fazendo uma refatoração, transformando um design de baixa qualidade em um design melhor. Apesar dos custos para saldar a dívida, ganhamos reduzindo os juros no futuro.

Além disso, existe uma divergência quanto ao termo mais adequado, quando se traduz do inglês: dívida ou débito técnico. O termo “débito” é relacionado a “um valor que foi retirado de uma conta”, enquanto “dívida” se relaciona a “algo que não foi pago e precisará ser pago no futuro”.

Gosto mais desta abordagem feita por Fowler por que, como uma dívida financeira, o time nem sempre adquire o débito técnico de propósito. Isso mesmo! Débito técnico não é bagunça! Já tive experiências com times em que o débito técnico era motivo de vergonha técnica.

E não é bem assim…

Os débitos técnicos nascem de decisões, baseadas nas restrições do momento do projeto. Como tudo na vida, decisões podem trazer benefícios; ou não. Ou podem trazer benefícios imediatos, mas que poderão se tornar um problema com consequências ruins no futuro.

Pensando na classificação de Steve McConnell para os débitos técnicos, agregada à classificação de Martin Fowler, chegamos à Matriz de Débitos Técnicos, uma ferramenta que pode ajudar o time em alguns aspectos:

1. Fazer o time acreditar que nem todo débito é ruim;
2. Ajudar o time a priorizar quais débitos pode absorver e quais dividirá o risco com o Product Owner;
3. Medir quais as formas mais usadas pelo time para adquirir débitos, auxiliando o Agile Coach a sugerir práticas para melhorar a “saúde financeira” do time.

clique para salvar

Débitos podem ser classificados como Deliberados ou Inadvertidos, de acordo com a intenção de causá-lo. Mas, pela perspectiva das decisões envolvidas, poderão ser categorizados em Prudentes e Imprudentes.

Ou seja, se formos colocar uma reação para o motivo da tomada de decisão, seria algo como:

Imprudente e Deliberado: "não temos tempo!"

Imprudente e Inadvertido: "o que estamos fazendo?"

Prudente e Deliberado: "vamos entregar e lidar com as consequências!"

Prudente e Inadvertido: "agora sabemos o que deveríamos ter feito!"

Não gosto de usar uma receita de bolo sobre qual das partes da matriz deve ser priorizada. Apesar de ter uma opinião pessoal sobre o assunto, prefiro que o time discuta e defina a ordem de priorização dos quadrantes.

Particularmente, prefiro que o time diga que “não sabe” o que está fazendo do que “não tem tempo”. Quando o time contrai dívidas por que não tem tempo de fazer algo com qualidade, algo mais profundo pode estar errado: estimativas podem estar incorretas, o time pode estar absorvendo a pressão (normal) do Product Owner para fazer mais em menos tempo ou demandas de última hora e até mesmo requisitos imaturos podem impactar nas atividades planejadas.

Da mesma forma, prefiro que o time tenha tempo de aprender novas técnicas que faça ver que o código pode ser melhorado, gerando necessidade de refatoração do que ter que lidar com consequências de maneira consciente. Não que seja um problema muito grande ter ciência dos débitos; mas existe uma linha tênue entre adquirir débitos por conta de não saber muito bem o que fazer e ter uma ideia, mas não ter tempo para estudar e resolver a questão.

Acredito muito na ideia de que entregar software com qualidade não é uma tarefa exclusivamente ligada a codar loucamente, como se não houvesse amanhã; é necessário ter tempo para o estudo e reciclagem. Pode parecer insano, mas esse é um investimento que traz ganhos em médio prazo.

Como um quadrante pode ter vários débitos, gosto de orientar o time a colocar os itens que classifica serem mais críticos mais próximos do centro. E eliminá-los primeiramente, quando chegar a vez do quadrante. Ou seja, quanto mais próximo do centro, mais urgente deverá ser o pagamento do débito. Assim, o time pode desenhar uma espiral na matriz e ir quitando as dívidas de acordo com esta escala. Gosto também da ideia de colocar nessa escala de espiral as variáveis “risco” e “valor para o produto” para ajudar na classificação. E, olha só: o time pode até optar por fazer várias espirais de quitação de débitos. Tudo depende da estratégia que decidirem seguir.

Veja, não estou falando de “fácil” ou “difícil”. Isso é uma armadilha para muitos times! Em hipótese alguma o time deverá priorizar o que quer que seja baseado em facilidade ou no que “é mais legal” de fazer. A essência de um time ágil é entregar valor, então, este é um mindset que deve estar no ar que o time respira.

Falando em essência de um time ágil, acredito que esta matriz deve ser pública para todos. Quem me conhece sabe o quanto gosto de quadros físicos! Mas aqui, o ponto é a transparência. O Product Owner precisa de transparência para confiar no time. E nada é mais certeiro para eliminar a confiança do que um time que varre seus débitos para debaixo do tapete, pois, acredite, algum dia, com certeza, algo vai levantar o tapete!

Não tem problema nenhum ter débitos. Débitos podem ser coisas boas! São oportunidades para aprender e melhorar o código e a entrega! Não tenha medo de expô-los! Muito mais que um Wall of Shame, acredito que estes sejam Waves of Evolution! Não é bacana e motivador pensar desta forma? 🙂

Se você gostou do conceito e quiser usar a Matriz, é só clicar na figura acima e salvar no seu computador. Quando utilizá-lo, deixe-me saber como foi a experiência! Super curto trocar experiências sobre o uso de ferramentas!

E você pode até transcender a ideia do uso da matriz para além dos débitos técnicos! Já imaginou que o seu time poderia usá-la, por exemplo, para classificar o que deu errado ou pode ser melhorado na Sprint? Ou até mesmo para tomar de volta para si o seu controle das finanças pessoais, fazendo um estudo de como você adquire dívidas!

Até a próxima! 😉