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
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! 😉

Anúncios

Marcelo L. Barros

Olá! Sou um cara criativo, curioso e detalhista, que, cada dia, mais se vê interessado em desvendar os mistérios desse "bicho gente"! Comecei minha carreira profissional em 1996, sou formado em Processamento de Dados pela FATEC de Santos. Naquela época tudo o que eu queria ter na minha frente era um computador e uma desafiadora regra de negócio, que se transformaria no melhor programa possível. Mas as coisas mudam! Concluí que quem faz software com qualidade são as pessoas e não as máquinas. Hoje, minha MISSÃO é ajudar pessoas e times a alcançarem seus objetivos, pois acredito que o sucesso pessoal e profissional está ligado a três pilares: FELICIDADE, MOTIVAÇÃO e SENTIDO. Como faço isso? 💡 MOTIVANDO pessoas, fazendo-as enxergar o 💡 SENTIDO das suas ações, que traz 💡 FELICIDADE por fazerem a diferença em suas vidas, suas empresas. Sou formado em Coaching pelo ICC e escrevo artigos sobre Métodos Ágeis, Comportamento, Inovação e Coaching. Vejo no lúdico a forma mais profunda de aprendizado. Procuro sempre conduzir reuniões de forma criativa, que tragam algum tipo de aprendizado aos participantes, seja por meio de dinâmicas de grupo ou jogos em equipe. Neste quesito, desenvolvi um jogo, a "Feijoada Ágil", para ensinar conceitos sobre trabalho em equipe. Se você, como eu, também acredita que eu posso te ajudar, deixe-me saber! Vamos tomar um café e, quem sabe, juntos podemos MUDAR O MUNDO!

2 comentários

  1. Obrigada por compartilhar, excelente análise.
    Acredito que seja importante considerar que o aumento da quantidade de software mal projetado cria muitos riscos para o projeto.
    É um assunto muito quente, e maior é a incerteza sobre adoções que realmente resultam em qualidade do software.
    A falta de diretriz de como fazer o levantamento dessa divida seja talvez o nosso maior desafio.
    Abraços Isa

  2. Que ferramenta bacana e simples!

    Realmente os posts do Marcelo são show, este cara faz um trabalho formidável ao compartilhar seu conhecimento com outros times.

    Galera, vamos compartilhar(sempre citando a fonte, claro). Eu vou compartilhar no meu blog num post em Janeiro/2017.

    Parabéns Marcelo e pessoal do Agile Momentum!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s