Modelo de Framework para Priorização de Dívida Técnica

Resumo: Critérios de Priorização

• Conhecimento do Código. Quão familiarizado está com o código?

• Severidade. Como afeta a funcionalidade ou desempenho do software?

• Dependência e Escala. Quantos componentes dependem dessa parte do código? A escala da arquitetura de software impactada.

• Custo de Resolução. Quantos story points custaria resolver o problema de dívida técnica?

Pontuação Total = (Conhecimento + Severidade + Dependência) – 3 * Custo

Leia também 5 Dicas para Priorizar Dívida Técnica.

• Resumo: Critérios de Priorização
• O que é dívida técnica?
• Exemplos de Dívida Técnica
• O problema da dívida técnica
• Critérios de Priorização de Dívida Técnica
  • Conhecimento do Código
  • Severidade
  • Dependência e escala do sistema
  • Custo de resolução
• Personalizar descrições de critérios
• Critérios inadequados para avaliação de dívida técnica
  • Não usar: Valor de Negócio ou Experiência do Utilizador
  • Não usar: Ocorrência
  • Não usar: Idade do Item
• Cálculo da pontuação de prioridade para problemas de dívida técnica
• Recolher itens para o backlog de dívida técnica
  • Dica 1. Criar uma secção dedicada no gestor de tarefas
  • Dica 2. Usar um formato consistente
  • Dica 3. Fornecer uma descrição clara
  • Dica 4: Usar a Frequência de Alteração de Código para recolher dívida técnica descoberta
  • Dica 5: Analisar automaticamente o código quanto a Lentidão e Vulnerabilidades
• Conclusão

O que é dívida técnica?

Dívida técnica é um termo metafórico usado no desenvolvimento de software para descrever o trabalho de desenvolvimento extra que surge quando código que é fácil de implementar no curto prazo é escolhido em detrimento de opções mais robustas ou escaláveis que podem demorar mais tempo. Refere-se ao custo de tomar atalhos ou escrever código não otimizado para manutenibilidade, extensibilidade ou fiabilidade a longo prazo.

Exemplos de dívida técnica incluem escrever código espaguete que é difícil de ler e compreender, usar bibliotecas ou frameworks desatualizadas que já não são suportadas, não documentar código ou testes, e negligenciar a realização de manutenção ou atualizações regulares.

Exemplos de Dívida Técnica

Problemas Típicos de Dívida Técnica:

1. Usar tecnologia desatualizada ou descontinuada: Usar tecnologia antiga ou não suportada pode resultar em problemas de compatibilidade e vulnerabilidades de segurança.

2. Qualidade de código fraca: Código que é difícil de ler, compreender e manter pode resultar em bugs, diminuição da produtividade e aumento do tempo de desenvolvimento.

3. Falta de documentação: Não documentar código, processos e requisitos pode dificultar a compreensão do software por futuros programadores, levando ao aumento do tempo de desenvolvimento e custos mais elevados.

4. Testes insuficientes: Ignorar ou adiar testes pode resultar em bugs não detetados, vulnerabilidades de segurança e insatisfação dos utilizadores.

5. Falhas no design da arquitetura: Projetar software com uma arquitetura subótima ou não planear a escalabilidade pode levar à dívida técnica à medida que o software se torna mais complexo e desafiante de manter ao longo do tempo.

Exemplos do que NÃO é considerado dívida técnica:

1. Adiar deliberadamente trabalho que não é crítico para o projeto ou que pode ser concluído mais tarde.

2. Tomar decisões informadas para usar um atalho para cumprir um prazo ou entregar um protótipo rapidamente.

3. Escolher intencionalmente implementar uma solução menos que ótima que ainda é aceitável para os objetivos do projeto.

4. Decidir usar uma tecnologia ou ferramenta específica apesar das suas potenciais limitações com base em trade-offs com outros fatores como tempo, custo e requisitos de negócio.

5. Realizar tarefas de manutenção de rotina que não melhoram significativamente o software.

O problema da dívida técnica

O principal problema com a dívida técnica é que pode acumular-se ao longo do tempo, tornando mais difícil adicionar novas funcionalidades, corrigir bugs ou manter a base de código.

• As funcionalidades demoram mais tempo a desenvolver

• Mais Bugs

É sempre um trade-off entre melhorar o código e adicionar novas funcionalidades.

Critérios de Priorização de Dívida Técnica

Considerando estes critérios, pode criar um sistema de priorização que ajuda a identificar e resolver dívida técnica nos itens do gestor de tarefas para maximizar o valor de negócio e minimizar o risco.

Sinta-se à vontade para adicionar, modificar ou reescrever o nome e descrição dos critérios para melhor compreensão pela equipa.

Para cada critério, estamos a usar a escala de avaliação da Sequência de Fibonacci como a mais adequada para estimativa de story points.

Board hi.ducalis.io com os critérios de priorização de dívida técnica

Conhecimento do Código

É a compreensão e familiaridade da equipa de desenvolvimento com a base de código em que estão a trabalhar. Inclui a capacidade de compreender e navegar pelo código, bem como a compreensão da estrutura do código, padrões de design e melhores práticas usadas no projeto.

O conhecimento do código é crítico para uma equipa de desenvolvimento porque impacta diretamente a capacidade de escrever e manter código de alta qualidade de forma eficiente. Equipas com mais conhecimento de código podem trabalhar mais rapidamente e com precisão.

Em resumo, o conhecimento do código é um componente crucial do conjunto de competências de uma equipa de desenvolvimento e impacta diretamente a qualidade e eficiência do trabalho.

• 1: Autor. Eu escrevi essa parte do código—posso manter e explicá-lo.

• 2: Mantenedor. Trabalhei com esse código—sem dúvidas sobre como funciona.

• 3: Acessível. Posso perguntar ao meu colega e ler a documentação sobre isso.

• 5: Documentado. Não trabalhei nisto. Temos alguma documentação sobre isso.

• 8: Compreensível. Não trabalhei nisto mas aprendi como funciona sem esforço significativo.

• 13: Desafiante. Preciso de tempo significativo para descobrir como funciona. Não trabalhei nesse código, mas posso contactar alguém que trabalhou ou encontrar documentação.

• 21: Nunca ouvi falar disso. Ninguém na equipa conhece esse código, ou vão sair em breve.

Severidade

A severidade do Impacto: Determinar quanto o problema de dívida técnica afeta a funcionalidade ou desempenho do software. A severidade do impacto pode ser alta, média ou baixa, e isto pode ser usado como critério para priorização.

• 1: Sem impacto algum.

• 2: Cosmético: Impacto superficial em alguns componentes locais. Pode ser resolvido no futuro quando recursos e tempo estiverem disponíveis.

• 3: Menor: Funciona bem, mas podemos melhorar. Pode ser resolvido no futuro quando recursos e tempo estiverem disponíveis.

• 5: Construtor: Atrasa a produtividade, torna o código menos manutenível ou impede a adição de novas funcionalidades. Pode ser resolvido mais tarde quando os recursos permitirem.

• 8: Bloqueio. Bloqueia melhorias ou atualizações adicionais a um componente do software. Deve ser resolvido em breve para prevenir que surjam problemas significativos.

• 13: Major. Bloqueia e quase quebra múltiplos componentes de software. Cria riscos adicionais ou atrasos no projeto.

• 21: Crítico. Torna o software inutilizável ou cria alto risco se não for resolvido.

Dependência e escala do sistema

Quantos componentes dependem dessa parte do código? A escala da arquitetura de software impactada:

• 1: Trivial. Pode ser ignorado pois pode ser resolvido a qualquer momento.

• 2: Local menor. Está contido num único método, classe ou função. Pode violar princípios SOLID—sem impacto significativo na qualidade geral do software.

• 3: Local moderado: Impacta múltiplos métodos, classes ou funções. Também pode ser mais difícil de modificar sem causar consequências não intencionais.

• 5: Global. Contido numa única aplicação ou serviço mas envolve violações SOLID em subsistemas num sistema mais extenso que se espalha para áreas aparentemente não relacionadas. Também pode incluir desajuste entre camadas de abstração, problemas de pontos de integração e acoplamento forte. Esta dívida não impacta os consumidores da aplicação ou serviço, mas é sentida ao modificar o próprio serviço.

• 8: Global major. Impacto mais significativo e generalizado na qualidade do software. Pode envolver múltiplos subsistemas e impactar toda a aplicação ou serviço. Também pode ser mais difícil de modificar sem causar consequências não intencionais.

• 13: Sistémica. Espalha-se por múltiplas aplicações, infraestruturas ou equipas. Envolve numerosos serviços partilhando um armazenamento de dados, alto acoplamento em diferentes contextos delimitados e um forte desajuste entre implementações técnicas e lógica de negócio. Dívida sistémica é insustentável a longo prazo e requer atenção imediata.

• 21: Crítica. Representa um risco significativo para a qualidade geral do software e pode impactar a estabilidade e fiabilidade do sistema.

Custo de resolução

Quantos story points custaria resolver o problema de dívida técnica?

• 1: Sem esforço

• 2: Custo baixo: 10% da duração do sprint.

• 3: Moderado: 20% da duração do sprint.

• 5: Significativo: Meio sprint

• 8: Alto: Um sprint

• 13: Muito alto: Mais de um sprint, mas menos de dois sprints. Recomendado dividir em múltiplos itens.

• 21: Proibitivamente caro. Sem ideia agora de como lidar com isso. Dois sprints e mais.

Personalizar descrições de critérios

Não se esqueça de que as melhores descrições de critérios são mais fáceis de compreender pelos colegas de equipa. Quanto mais específicas forem as descrições de critérios e escala — melhor para o processo de priorização. Especifique durações de sprint, explicações de dependências, definições de bloqueios e significado de conhecimento de código. Leia mais sobre edição de descrição de critérios.

Personalizar Descrições de Critérios

Critérios inadequados para avaliação de dívida técnica

Valor de negócio, ocorrência, idade e impacto na experiência do utilizador são critérios não fiáveis para avaliar dívida técnica.

Não usar: Valor de Negócio ou Experiência do Utilizador

Fatores como qualidade de código, documentação, cobertura de testes e arquitetura de software raramente têm correlação direta com métricas de negócio como receita. Estes fatores afetam a capacidade da equipa de desenvolvimento de fazer alterações eficientemente e a qualidade geral, fiabilidade e escalabilidade do software.

Uma das razões mais populares para não manter a dívida técnica é avaliá-la na receita potencial.

Não usar: Ocorrência

Considerar a probabilidade de o problema de dívida técnica ocorrer novamente no futuro. Dívida técnica não é um bug que pode ocorrer novamente. Não desperdice tempo a prever o futuro.

Não usar: Idade do Item

Pode parecer uma ideia evidente e direta refatorar bibliotecas antigas mais cedo. Mas porquê gastar tempo nisso se o código funciona bem e não atrasa ou cria vulnerabilidades? A idade não deve ser o critério de priorização.

Cálculo da pontuação de prioridade para problemas de dívida técnica

Como habitualmente, precisamos de equilibrar os pesos dos critérios para a estratégia correta de definir prioridades nos itens de dívida técnica. Por defeito, temos peso -2. Quanto menos recursos de desenvolvimento tiver na equipa — mais negativo o peso deve ser.

Configuração de peso para o critério 'Custo'

A fórmula final é bastante simples:

Recolher itens para o backlog de dívida técnica

Em "Essential Scrum: A Practical Guide to the Most Popular Agile Process," o autor Ken Ruben usa três categorias para definir dívida técnica: dívida técnica descoberta, conhecida e direcionada.

• Dívida técnica descoberta é dívida técnica que a equipa de desenvolvimento não sabia que existia até ser exposta durante o uso ou manutenção de rotina do produto. Por exemplo, ao adicionar uma nova funcionalidade ao software, a equipa pode descobrir uma solução temporária que foi adicionada ao código há anos e deixada inalterada, resultando em comportamento inesperado. Dívida técnica descoberta também pode ser causada por 'deterioração de bits,' que ocorre quando o código se deteriora ao longo do tempo, alterando a sua função e usabilidade.

• Por outro lado, dívida técnica conhecida é dívida técnica da qual a equipa de desenvolvimento já tem conhecimento e pode ver no software. Exemplos de dívida técnica conhecida incluem qualidade de código fraca, falta de documentação ou testes insuficientes.

• Finalmente, dívida técnica direcionada é dívida técnica conhecida que a equipa de desenvolvimento escolheu resolver num sprint ou lançamento específico. Isto pode envolver reformular código, melhorar documentação ou aumentar a cobertura de testes para reduzir a dívida técnica e melhorar a qualidade do software.

Ao compreender os diferentes tipos de dívida técnica, as equipas de desenvolvimento podem priorizar os esforços e trabalhar para resolver a dívida técnica de forma a minimizar o impacto na manutenibilidade e fiabilidade a longo prazo do software.

Dica 1. Criar uma secção dedicada no gestor de tarefas

É essencial ter uma propriedade para separar itens de dívida técnica de outros itens como bugs ou funcionalidades. Use uma etiqueta/tag especial, tipo de item ou componente. Deve sempre ter a opção de ver o backlog completo com todos os itens e filtrá-lo por tipo.

Dica 2. Usar um formato consistente

Use um formato consistente para registar problemas de dívida técnica, como uma user story ou uma tarefa na ferramenta de backlog. Isto ajudará a identificar e priorizar facilmente problemas de dívida técnica.

Dica 3. Fornecer uma descrição clara

Forneça uma descrição clara do problema de dívida técnica, incluindo o impacto na base de código, o esforço estimado necessário para o resolver e quaisquer potenciais riscos ou consequências.

Dica 4: Usar a Frequência de Alteração de Código para recolher dívida técnica descoberta

Frequência de Alteração de Código é a frequência com que são feitas alterações à base de código de um sistema de software.

Pode ser usada para avaliar a saúde e qualidade de um projeto de software e identificar potenciais problemas e riscos. Permite avaliar o impacto, identificar áreas de alto risco e tomar decisões informadas sobre alterar a base de código.

• A alta frequência pode indicar atualizações frequentes, melhorias, instabilidade ou erros.

• A baixa frequência pode indicar falta de manutenção ou evolução, levando à dívida técnica e outros problemas.

Altamente recomendado assistir à palestra de Adam Tornhill sobre esta ideia, "

."

Dica 5: Analisar automaticamente o código quanto a Lentidão e Vulnerabilidades

Existem muitas ferramentas para análise de código. Experimente e envie os problemas encontrados para o backlog do gestor de tarefas.

1. Code Scene — Uma ferramenta para visualizar, compreender e melhorar o software relativamente a código, conhecimento e pessoas por trás dele. Faça melhorias baseadas em recomendações automatizadas, priorizadas e acionáveis.

2. SonarQube: Uma ferramenta popular que pode detetar vulnerabilidades de segurança, code smells e outros problemas no código. Suporta várias linguagens de programação e integra-se com várias ferramentas CI/CD.

3. OWASP ZAP: Um scanner de segurança de aplicações web de código aberto que pode detetar vulnerabilidades como injeção SQL, cross-site scripting e outros problemas de segurança.

4. CodeClimate: Uma plataforma baseada na cloud que analisa o código e fornece insights sobre qualidade, manutenibilidade e segurança. Suporta várias linguagens de programação e integra-se com GitHub, Bitbucket e outras ferramentas.

5. Snyk: Uma ferramenta baseada na cloud que analisa o código e dependências quanto a vulnerabilidades de segurança e fornece conselhos de correção. Suporta várias linguagens de programação e integra-se com várias ferramentas CI/CD.

6. AppDynamics: Uma ferramenta que fornece insights em tempo real sobre o desempenho das aplicações, incluindo tempo de resposta, taxa de erro e outras métricas. Ajuda a identificar gargalos de desempenho e otimizar o código.

7. Qodana. Avalie a integridade do código que possui, contrata ou compra. Enriqueça os pipelines CI/CD com todas as funcionalidades inteligentes que adora dos IDEs JetBrains

Conclusão

Dívida técnica é inevitável no desenvolvimento de software mas também pode ser um obstáculo significativo ao progresso e inovação. Ao desenvolver um sistema de priorização de dívida técnica que funciona para a equipa, pode minimizar o impacto e manter a qualidade e fiabilidade do software ao longo do tempo.

Lembre-se de que dívida técnica não é apenas um problema de programadores; afeta toda a organização. Ao incorporar a gestão de dívida técnica nos processos de gestão de projetos, pode garantir que todos têm conhecimento do impacto e trabalham em conjunto para resolvê-lo.

Finalmente, é importante lembrar que resolver dívida técnica não é um evento único; requer atenção e esforço contínuos. Ao rever e atualizar regularmente o backlog de dívida técnica, pode manter-se no topo de potenciais problemas e garantir que o software permanece saudável e fiável a longo prazo.

Leia a seguir: 5 Dicas para Priorizar Dívida Técnica