No início da minha carreira, enquanto gestora de produto associada recém-chegada, quando ouvi falar pela primeira vez de dívida técnica (também conhecida como dívida tecnológica), não tinha bem a certeza do que significava. Hilariante, pensei que se referia a um empréstimo que tínhamos contraído para comprar software de terceiros e usei este termo incorretamente, com toda a confiança, durante duas ou três semanas. Imaginem o meu embaraço quando os meus engenheiros me chamaram à parte depois da reunião diária para me corrigirem gentilmente!

Por isso, para nos poupar a todos alguns momentos de embaraço no trabalho e para nos ajudar a ganhar credibilidade junto dos nossos engenheiros, vamos explorar o que é a dívida técnica e porque devemos nós, enquanto gestores de produto, preocupar-nos com ela.

O que é a dívida técnica e quando se torna um problema?

O desenvolvimento de software consiste em equilibrar a amplitude das funcionalidades do produto com código de elevada qualidade. Pelo caminho, por vezes tomamos atalhos para acelerar o processo de desenvolvimento — estes atalhos são chamados dívida técnica ou dívida tecnológica.

Quando é que contrair dívida técnica é uma boa ideia e quando é que ela se transforma numa bomba-relógio? Para responder a esta pergunta, vamos começar por analisar a história da dívida tecnológica.

O que é a dívida técnica?

Ward Cunningham, a pessoa que cunhou o termo, compara a dívida técnica à dívida financeira — não há problema em pedir emprestado contra a velocidade e a estabilidade futuras, mas temos de pagar a dívida mais tarde. É um conceito que todas as equipas de desenvolvimento devem compreender e que todos os gestores de produto devem considerar ao tomarem decisões relativas ao produto.

A dívida tecnológica ajuda-nos a lançar produtos antes do previsto e a fazê-los chegar mais rapidamente às mãos dos clientes. No entanto, acabamos por ter de “amortizar a dívida”, investindo na qualidade da nossa base de código.

Idealmente, devemos decidir ativamente se queremos tirar partido da dívida técnica ou se queremos evitá-la. À semelhança da dívida financeira, não queremos ser surpreendidos por um custo imprevisto mais tarde!

Uma definição simplificada de dívida técnica

A dívida técnica (também designada por dívida de código em algumas equipas) refere-se ao custo implícito de um trabalho futuro de reformulação necessário quando se escolhe um atalho de curto prazo em vez de uma abordagem melhor, que demoraria mais tempo. É como pagar juros de um empréstimo — o custo da dívida técnica aumenta com o tempo.

Uma analogia que utilizo é fazer a barba. Se tiver pouco tempo e fizer uma barba rápida, provavelmente não será a barba mais perfeita de sempre e terei de voltar mais tarde para a aperfeiçoar.

O tempo e o esforço necessários para ambas as barbas — a barba inicial e a segunda barba de acabamento — serão, no total, superiores aos que seriam necessários se tivesse feito logo uma barba adequada.

Mas, por vezes, quando estamos a ficar sem tempo, temos de optar pela barba rápida!

Comparação entre dívida financeira e dívida técnica

Para tornar este conceito mais claro, vamos aprofundar um pouco a comparação entre a dívida financeira e a dívida técnica. Afinal, os gestores de produto precisam de compreender tanto os conceitos de finanças empresariais como os conceitos técnicos de programação!

Vantagens da dívida financeira: A dívida financeira permite obter alavancagem. Pedir dinheiro emprestado pode disponibilizar o capital necessário para investir em oportunidades de crescimento. Além disso, a dívida financeira permite o acesso imediato a recursos ou ativos sem exigir um pagamento inicial.

Desvantagens da dívida financeira: A dívida financeira implica vários tipos de custos. Os pagamentos de juros sobre a dívida financeira podem acumular-se ao longo do tempo, reduzindo a rentabilidade global. Além disso, não gerir corretamente a dívida financeira pode resultar em instabilidade financeira.

Além disso, a dívida pode limitar a flexibilidade financeira e impedir-nos de seguir determinados caminhos no futuro. E o incumprimento das obrigações financeiras pode prejudicar a reputação de uma organização.

Vantagens da dívida técnica: A dívida técnica permite um desenvolvimento inicial mais rápido do produto, ajudando a cumprir prazos apertados ou a aproveitar oportunidades de mercado. Além disso, à semelhança da alavancagem financeira, assumir dívida técnica pode reduzir os custos iniciais de desenvolvimento.

Desvantagens da dívida técnica: Tal como os juros se acumulam na dívida financeira, a dívida técnica aumenta à medida que são criadas funcionalidades adicionais ou efetuadas alterações com base nos atalhos existentes, tornando o desenvolvimento futuro mais complexo e dispendioso. Além disso, a dívida técnica resulta frequentemente numa qualidade de código abaixo do ideal, conduzindo a custos de manutenção mais elevados ao longo do tempo.

A dívida técnica pode dificultar a capacidade de um produto se adaptar às mudanças nas condições do mercado ou de incorporar novas funcionalidades. Além disso, uma dívida técnica não resolvida pode provocar falhas no sistema, vulnerabilidades de segurança ou problemas de desempenho, afetando a viabilidade do produto.

O que significa isto para nós? Bem, tanto no caso da dívida financeira como no da dívida técnica, o objetivo não é evitar completamente a dívida. Em vez disso, a chave está numa gestão prudente.

Embora algum nível de dívida seja estratégico para o crescimento, temos de monitorizar e gerir cuidadosamente a dívida para minimizar as consequências negativas a longo prazo.

Exemplos de dívida técnica

No domínio da engenharia de software, as equipas de desenvolvimento deparam-se regularmente com dívida técnica. Vamos analisar alguns dos exemplos mais comuns.

Código legado

Algumas equipas podem utilizar código legado desatualizado para disponibilizar rapidamente uma funcionalidade. Isto pode fornecer funcionalidade imediata, mas poderá exigir uma refatoração substancial mais tarde, especialmente à medida que são adicionadas novas funcionalidades. Tal como um manuscrito antigo, o código legado foi transmitido através de gerações de programadores, acumulando o peso da história.

Embora possa ter cumprido admiravelmente o seu propósito no auge, o tempo tende a desgastar a sua adaptabilidade e capacidade de manutenção. As interrupções e os erros em produção tendem a surgir quando dependemos demasiado de código legado!

Codificação rígida

A codificação rígida refere-se à prática de incorporar valores específicos ou constantes diretamente no código, em vez de utilizar definições configuráveis.

Embora esta abordagem possa permitir acelerar o desenvolvimento a curto prazo, frequentemente conduz a complicações mais adiante. Imagine um cenário em que um valor codificado de forma rígida, como um caminho de ficheiro ou um limite de tempo de espera, precisa de ser alterado numa base de código de grandes dimensões. Esta tarefa pode rapidamente tornar-se morosa e propensa a erros, comprometendo a capacidade de manutenção e a flexibilidade do software.

Para evitar este problema, os programadores devem optar por opções configuráveis, melhorando a adaptabilidade do seu código.

Duplicação de código

A duplicação de código ocorre quando fragmentos de código semelhantes ou idênticos aparecem em vários locais do projeto. Inicialmente, pode parecer um atalho conveniente, poupando tempo durante o desenvolvimento. No entanto, à medida que o software evolui e os requisitos mudam, manter a consistência e efetuar atualizações torna-se uma tarefa complexa.

A duplicação de código não só aumenta o risco de introduzir erros, como também multiplica o esforço necessário para futuras melhorias e correções de erros. A procura da reutilização do código e a eliminação de código redundante são princípios fundamentais para contrariar este problema.

Falta de documentação

A documentação serve como o fio condutor que ilumina o caminho para os programadores atuais e futuros. A ausência de documentação abrangente é semelhante a embarcar numa viagem complexa sem um mapa. Pode começar com a falta de comentários no código que expliquem a razão por trás de determinadas escolhas, ou evoluir para a ausência de manuais de utilizador e documentação da arquitetura do sistema.

Embora a fase inicial de desenvolvimento possa decorrer sem problemas, as consequências a longo prazo podem ser graves. A depuração torna-se uma tarefa enigmática, a transferência de conhecimentos entre os membros da equipa torna-se difícil e a expansão do projeto assemelha-se frequentemente à navegação por um labirinto às escuras. Adotar uma documentação rigorosa é o farol que ilumina o caminho a seguir no desenvolvimento de software.

Falta de testes automatizados

A ausência de testes automatizados é semelhante a navegar num barco sem verificar primeiro se tem fugas. Os testes automatizados (incluindo testes unitários, de integração e de regressão) são os guardiões vigilantes da qualidade e da estabilidade do código.

Quando são omitidos, as consequências podem não ser imediatamente visíveis. Inicialmente, o desenvolvimento pode avançar rapidamente e o software pode parecer funcional. No entanto, à medida que a base de código aumenta e evolui, começam a surgir problemas imprevistos. Os erros de regressão, em que funcionalidades que anteriormente funcionavam deixam de funcionar após novas alterações, tornam-se frequentes.

Sem testes automatizados que forneçam uma rede de segurança, a equipa de desenvolvimento tem de depender de testes manuais, um processo moroso e propenso a erros. Adotar testes automatizados desde o início garante um rumo constante no mar tumultuoso do desenvolvimento de software.

Qual é o papel da dívida técnica no desenvolvimento ágil?

Ah, o desenvolvimento ágil! As suas metodologias Scrum e os seus princípios do Manifesto Ágil abraçam a mudança e a rapidez. Mas onde se enquadra a dívida técnica? Afinal, a dívida técnica não é especificamente abordada nos documentos fundadores do desenvolvimento ágil.

Bem, eis uma analogia de Star Wars: a Millennium Falcon era submetida a manutenção contínua por Han Solo e Chewbacca para se manter em excelentes condições para as suas aventuras. Do mesmo modo, uma equipa de produto ágil gere a dívida técnica para manter a qualidade do software e permitir aventuras heroicas aos seus clientes! 

Como utilizar e gerir a dívida técnica

Nas equipas ágeis, existe a compreensão de que, por vezes, será contraída alguma dívida técnica para responder rapidamente às necessidades do negócio. Lembre-se de que contrair dívida técnica nem sempre é algo negativo. Martin Fowler, uma referência no desenvolvimento de software ágil, salienta que se trata de uma questão de compromissos. Poderá aceitar alguma dívida no início do ciclo de vida do produto de software para validar um conceito ou chegar mais rapidamente ao mercado.

A chave está em gerir a dívida técnica. A dívida técnica deve ser documentada na lista de pendências, priorizada e abordada em iterações futuras. Para que isto aconteça, os gestores de produto devem apoiar-se numa gestão de projetos sólida e precisam de ter uma boa compreensão do volume de dívida técnica acumulado até ao momento.

Quando é que a dívida técnica se torna um problema?

Quando as partes interessadas desconhecem a dívida técnica ou quando o processo de desenvolvimento depende fortemente de soluções alternativas, é nessa altura que os sinais de alarme devem começar a soar. Porquê?

1. É Invisível: Sem métricas ou revisões regulares do código, podem surgir vulnerabilidades ocultas.
2. Afeta a Experiência do Utilizador: Se os problemas subjacentes começarem a afetar a funcionalidade, não é apenas um problema dos programadores; é um problema empresarial.
3. Dificulta as Novas Funcionalidades: Os programadores presos a código de má qualidade são menos produtivos e a criatividade diminui.
4. Não Está no Roteiro: As equipas devem estar conscientes da dívida técnica e ter uma estratégia para a gerir. Não hesite em recorrer a webinars e recursos externos para estabelecer um plano de ação.

Como Medir a Dívida Técnica

Ao utilizarem ferramentas como as práticas de DevOps e a automatização, as equipas podem acompanhar a sua base de código e manter-se a par da dívida técnica acumulada até ao momento. Em seguida, reuni doze formas diferentes de acompanhar a dívida técnica.

Não tem de utilizar todas! Em vez disso, encare esta lista como um ponto de partida. Escolha uma ou duas para implementar no próximo mês, aproximadamente, e depois desenvolva gradualmente a capacidade da sua equipa para acompanhar e resolver a dívida técnica.

1) Análise Estática do Código: Ferramentas como SonarQube, ESLint ou FindBugs podem analisar automaticamente o código em busca de vários problemas, como a complexidade do código, anomalias no código e potenciais erros. Fornecem métricas quantitativas sobre a qualidade do código e a dívida técnica com base em regras e limiares predefinidos.

2) Cobertura do Código: Podemos avaliar quanto da base de código está abrangido por testes automatizados, medindo a cobertura do código com ferramentas como JaCoCo ou Istanbul. Uma cobertura de baixo código pode indicar uma falta de testes e uma potencial dívida técnica.

3) Revisões do Código pelos Pares: A realização de revisões do código pelos pares permite aos programadores identificar e discutir potenciais elementos de dívida técnica. Além disso, duas cabeças pensam melhor do que uma — é uma excelente forma de evitar padrões de código de má qualidade! As equipas podem utilizar listas de verificação ou orientações para avaliar a qualidade do código e documentar os problemas identificados. O número e a gravidade dos problemas encontrados nas revisões podem servir como uma medida qualitativa da dívida técnica.

4) Inspeções Manuais do Código: Os programadores e as equipas podem realizar inspeções manuais do código ou análises detalhadas para identificar áreas da base de código que possam beneficiar de uma refatoração. Este processo envolve frequentemente programadores experientes que reveem o código e documentam os problemas, uma vez que tendem a ter a melhor perceção da dívida de conceção técnica. 

5) Lista de Pendências da Dívida Técnica: Manter uma lista de pendências do produto ou uma lista de elementos de dívida técnica identificados é uma prática comum. Cada elemento da lista deve incluir uma descrição, uma avaliação do impacto e uma classificação de prioridade. A dimensão e a prioridade dos elementos da lista fornecem uma medida qualitativa da dívida técnica.

6) Acompanhamento de Erros e Problemas: A análise do processo de triagem de erros pode revelar a frequência e a gravidade dos problemas relacionados com a dívida técnica. Um número elevado de relatórios de erros ou a recorrência frequente dos mesmos problemas pode indicar uma dívida técnica subjacente.

7) Estimativas e Pontos de História: Ao planearem novo trabalho ou histórias de utilizador, as equipas de desenvolvimento podem estimar o esforço necessário para resolver elementos de dívida técnica. Esta estimativa de esforço, frequentemente apresentada sob a forma de pontos de história nas metodologias ágeis, quantifica o trabalho necessário para resolver a dívida técnica.

8) Métricas de Complexidade do Código: Métricas como a complexidade ciclomática, o número de linhas de código e a volatilidade do código podem fornecer informações sobre a complexidade e a facilidade de manutenção da base de código. Uma maior complexidade e alterações excessivas em determinadas áreas do código podem indicar dívida técnica.

9) Opinião dos Utilizadores: A opinião dos utilizadores e os pedidos de suporte podem destacar indiretamente a dívida técnica. Reclamações frequentes dos utilizadores sobre o desempenho, a fiabilidade ou o comportamento inesperado do sistema podem indicar problemas subjacentes que precisam de ser resolvidos.

10) Métricas de Testes Automatizados: A monitorização de métricas relacionadas com os testes automatizados, como o tempo de execução dos testes, as taxas de falha dos testes e os testes instáveis, pode ajudar a avaliar o estado da infraestrutura de testes e a identificar áreas afetadas pela dívida técnica.

11) Inquéritos e Entrevistas: A realização de inquéritos e entrevistas às equipas de desenvolvimento pode fornecer informações qualitativas sobre o nível percecionado de dívida técnica e o seu impacto na produtividade e na qualidade do código. Além disso, recolher a opinião das partes interessadas pode ajudar a perceber onde poderá ser necessário retrabalho.

12) Quadrante da dívida técnica: Uma ferramenta particularmente útil é o quadrante da dívida técnica apresentado por Martin Fowler. Categoriza as causas da dívida técnica em deliberadas vs. inadvertidas e imprudentes vs. prudentes, ajudando as equipas a compreender os compromissos.

Para além destas doze formas de medir a dívida técnica, não hesite em utilizar ferramentas de gestão de produtos para ajudar a gerir o acompanhamento e a resolução da dívida técnica da sua equipa!

Liquidar a dívida técnica

Falámos bastante sobre contrair dívida técnica, mas ainda não abordámos como a liquidar. Enquanto gestores de produto, é nossa responsabilidade orientar as nossas equipas na decisão sobre quando liquidar a dívida e quando contrair dívida técnica adicional.

Liquidamos a dívida técnica quando os engenheiros atualizam a base de código para resolver itens de dívida técnica identificados anteriormente. Isto pode incluir a reformulação de funcionalidades para as tornar mais eficientes, a implementação de testes automatizados ou a criação de documentação aprofundada sobre o código.

Uma das melhores formas de a reduzir é reservar tempo em cada iteração para reforçar a base de código e liquidar a dívida. Pense nisto como o pagamento mensal de um empréstimo hipotecário — quanto mais depressa conseguirmos reduzir o empréstimo, menos juros teremos de pagar no total!

Uma boa regra geral é a regra 80/20. Ou seja, dedicar cerca de 80% do tempo de cada iteração à criação de novas funcionalidades e 20% do tempo à priorização de investimentos e melhorias técnicas.

Ao planear a redução da dívida técnica, considere integrá-la adequadamente no seu roteiro do produto.

Considerações finais sobre a dívida técnica

Para concluir, gerir a dívida técnica não é apenas uma tarefa dos programadores. Os gestores de produto, as equipas ágeis e as partes interessadas do negócio desempenham um papel.

O objetivo final? Entregar um produto de software de elevada qualidade que cumpra os objetivos do negócio sem contrair uma dívida insustentável.

Por isso, quer esteja a aventurar-se nos mares profundos do desenvolvimento de software ou simplesmente a tentar compreender por que razão a sua equipa de desenvolvimento continua a falar de refatorização, compreender e gerir a dívida técnica é a bússola de que precisa.

E, quer esteja no início da sua carreira de produto, quer já seja um veterano experiente na gestão de produtos, quase sempre beneficiará de aprofundar a sua compreensão do jargão técnico.

Espero que evite cometer o mesmo erro que cometi no início da minha carreira — não dependa exclusivamente de pistas contextuais para adivinhar conceitos técnicos desconhecidos!

Em vez disso, dedique tempo a fazer pesquisa, consulte guias externos como estes e passe tempo com os seus engenheiros para reforçar conhecimentos valiosos.

Para obter mais informações e guias sobre gestão de produtos, não se esqueça de subscrever o nosso boletim informativo!