Love The Road - Como acabar com seu Débito Técnico (Agile Trends)

O tema da minha palestra foi como acabar com o seu débito técnico. E a mensagem que eu queria mostrar é que tem que ter várias mensagens, porque no Agiltrends a gente tem 20 minutos de palestra, são palestras extremamente curtas e tem que ser direto ao ponto.

Não existe débito técnico, o que existe é dívida técnica. A metáfora foi mudada no Brasil. Quando a gente vai na origem da Debit Metaphor, criada pelo Ward Cunningham, você entende que aquilo é uma dívida e não um débito. Você tem que pagar ou conviver com ela. E quem acha que tem como pagar, zerar a dívida técnica, essa é uma ilusão. Você não vai zerar a dívida técnica.

Eu uso a metáfora do jogo de Tetris. O Tetris nunca acabava. O teu objetivo era controlar o quanto mais próximo você estava de perder o jogo. Ou seja, teu objetivo era deixar o mais próximo do eixo X, do zero, zero barrinhas. Dívida técnica é a mesma coisa. Se você não controla, ela te mata, te torna teu software mais lento. Uma série de coisas acontecem: você tem um custo maior de manutenção de um software, com isso você para de entregar software e novas features. A necessidade é controlar a dívida técnica. Nunca vai ser possível zerar.

Mas daí eu uso três eixos de atuação: gerenciar a aquisição, gerenciar a visibilidade da dívida técnica e gerenciar o pagamento. Se você não faz em um dos três, você não trabalha com dívida técnica. O que a gente encontra, pelo menos quando eu passo em alguns times, é muita gente que gerencia só a visibilidade. Nunca paga. Nunca tem tempo de pagar a dívida. Ou seja, sempre está devendo. Tem gente que nem sabe o que é dívida técnica, nem sabe o que é gerenciar a visibilidade, e fica cavando mais dívida técnica, entregando mais software ruim com péssima qualidade. Precisa valorizar a qualidade, gerenciar a dívida técnica. É um meio para isso, para desenvolver.

Tem que parar de cavar o buraco, ou seja, parar de adquirir dívida técnica. Tem que pagar e tem que ter visibilidade. Senão nunca tem prioridade. A gente fala isso no Kanban: você não gerencia o que você não visualiza.

Quais são os indicadores que vão me dar um cheiro de que estou precisando começar a pagar dívida técnica? A gente pode pegar algumas ferramentas específicas que medem isso, tipo o SonarQ. Você vai ter um projeto brasileiro chamado Dr. Tools que vai medir isso. Eles fazem análise estática de código, ou seja, vão olhar o código fonte e mostrar o quanto está mais próximo de um código ideal, baseado em uma série de convenções, e o quanto está longe disso. Você começa a ter um número. Sem esse número, você está dirigindo igual sem velocidade. Você começa a falar: isso não pode crescer. Todas as próximas entregas, o time tem que manter aquele número de problemas para baixo. Você começa a criar esse jogo dentro de uma sprint, dentro da interação, se for Kanban.

Como que eu transformo isso num impacto de negócio para conseguir priorizar com o meu PO? A gente poderia falar de DoraMetrics, um conjunto de quatro métricas de DevOps que auxiliam a entrega de software, a velocidade de entrega de novas funcionalidades para o cliente. Isso fala de business. O tempo que eu levo para corrigir um bug até entrar em produção já é uma métrica que fala: você está com o fator de negócio parado, o cliente não está conseguindo operar. Quanto tempo leva para você corrigir isso e disponibilizar para ele? Quanto maior o tempo, tem coisas estranhas no meio, e essas coisas estranhas são as dívidas técnicas.

Tem um livro chamado Código Limpo. Ele é bem técnico, mas já na capa ele fala da quantidade de WTFs que existe dentro do código fonte. Quando você abre, você já sabe que aquilo não está bom, está sujo. Se um time usa Scrum e vai fazer a planning, o time começa a ver que vai ter que passar dentro de tal coisa no código fonte. A cara das pessoas dos devs já indica que aquilo não vai ser fácil. Então você pode colocar um fator de multiplicação na sua estimativa: vai demorar mais tempo porque não está bom. Isso tudo vai levar a um lead time maior. Não vai entregar em duas semanas, vai entregar em três, quatro. Tudo isso são indicadores importantes, são cheiros.

Uma dívida técnica fácil de ser priorizada, se o PO entender bem o risco que ele está correndo, é a de segurança. Se você consegue trazer visibilidade do quanto o software está vulnerável, o PO prioriza. Porque se houver uma invasão, o impacto disso é gigantesco: negócio, continuidade, imagem. Mas dívidas técnicas como refatorar um arquivo de mil linhas para reduzir para 500 não geram um impacto de negócio imediato. Mas se não cuidar, é igual escovar o dente todo dia. Uma hora gera problema e o buraco cresce.

É uma pergunta difícil. Geralmente eu escuto: qualidade é um valor da organização. Mas muitas das vezes não é vivido como valor de fato, é só um desejo. Quando chega a ideia do prazo, do custo, a qualidade morre. Aquele triângulo de ferro no projeto: nunca a qualidade sobrevive. Se for software, o software sempre sai barato e rápido, nunca é bom. Rápido e bom é difícil. É sempre difícil ter qualidade.

O fator é as pessoas técnicas falarem um pouco mais a linguagem do business. Dívida técnica não é uma métrica de negócio. Mas quando eu cheguei e falei: eu sei como aumentar a nossa produtividade em 10%. Os caras: como? Eu te explico tecnicamente, mas você não vai entender. Mas me dá algum tempo para começar a te mostrar. Quando eu uso realmente essas métricas mais organizacionais e deixo: você tem que cuidar do negócio, aqui dentro eu cuido, eu gerencio. E começo a mostrar que através dessas atitudes de qualidade eu posso melhorar a empresa, os indicadores. Aí a gente começa a falar que isso que eles estão fazendo é qualidade, tem que ser organizacional.

Você vai dar quase uma blefada de que realmente vai dar 10% de produtividade, mas vai mudar. É natural. Se você arrumar algumas coisas no seu processo produtivo, vai se tornar mais rápido. Deixar os itens de qualidade, como escrever código limpo, testes automatizados, tudo isso vai tornar mais rápido. E você vai começar a criar uma cultura.

Para você criar uma cultura de qualidade, você tem que ter aliados. Ter os seus aliados, pessoas que acreditam nisso, porque eles são seus promotores. Busque pessoas que não sejam os empurradores de qualidade, mas que vivam pelo exemplo. A qualidade você leciona se você influencia pelo exemplo, pela tua fala, pelo que você faz. Falar é fácil de qualidade, fazer é difícil.

Por que a Fórmula 1 consegue fazer um pit stop de um carro mega ultra caro em dois, três segundos? Porque todo mundo sabe suas responsabilidades, o seu papel. Tem um recurso disponível que é o pneu. O piloto sabe que ele tem que parar no lugar certo. Quando virou a plaquinha, ele sai correndo. Tem uma galera olhando dados, telemetria, dizendo agora é a melhor hora para trocar. É uma equipe. Talvez o piloto vai ganhar o troféu, mas é a equipe que ganhou. Todo mundo buscando isso porque todo mundo entende que o ambiente é competitivo. E se a gente trazer isso no mundo real, a gente vê um mundo competitivo. Isso é o diferencial que faz você ganhar uma prova ou não. Que tem equipes que têm um pit stop tão rápido e faz ganhar corrida. Que trabalha com dados, mentoria, e isso só se consegue com qualidade, com treino, com capacitação, com desenvolvimento de pessoas. A gente deixa o piloto voar.