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

TL; TR: Critérios de Priorização

• Conhecimento do Código. Qual é o seu nível de familiaridade com o código?

• Gravidade. Como ele 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 Correção. Quantos story points custaria para corrigir o problema de dívida técnica?

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

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

• TL; TR: 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
  • Gravidade
  • Dependência e escala do sistema
  • Custo de correção
• Personalize as descrições dos critérios
• Critérios inadequados para avaliação de dívida técnica
  • Não use: Valor de Negócio ou Experiência do Usuário
  • Não use: Ocorrência
  • Não use: Idade do Item
• Cálculo da pontuação de prioridade para os itens de dívida técnica
• Colete itens para o backlog de dívida técnica
  • Dica 1. Crie uma seção dedicada no seu rastreador de tarefas
  • Dica 2. Use um formato consistente
  • Dica 3. Forneça uma descrição clara
  • Dica 4: Use a Frequência de Mudança de Código para coletar dívida técnica Acontecida
  • Dica 5: Faça Verificação Automática do seu código para 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 extra de desenvolvimento que surge quando o código que é fácil de implementar no curto prazo é escolhido em vez de opções mais robustas ou escaláveis que podem levar mais tempo. Refere-se ao custo de tomar atalhos ou escrever código que não é otimizado para manutenibilidade, extensibilidade ou confiabilidade a longo prazo.

Exemplos de dívida técnica incluem escrever código espaguete difícil de ler e entender, usar bibliotecas ou frameworks desatualizados que não são mais suportados, falhar em documentar código ou testes e negligenciar a realização de manutenção ou atualizações regulares.

Exemplos de Dívida Técnica

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

1. Uso de tecnologia desatualizada ou depreciada: Usar tecnologia antiga ou sem suporte pode resultar em problemas de compatibilidade e vulnerabilidades de segurança.

2. Baixa qualidade do código: Código difícil de ler, entender e manter pode resultar em bugs, diminuição da produtividade e aumento do tempo de desenvolvimento.

3. Falta de documentação: Falhar em documentar código, processos e requisitos pode dificultar para futuros desenvolvedores entenderem o software, levando a aumento do tempo de desenvolvimento e custos mais altos.

4. Testes insuficientes: Pular ou atrasar testes pode resultar em bugs não detectados, vulnerabilidades de segurança e insatisfação do usuário.

5. Falhas no design da arquitetura: Projetar software com arquitetura subótima ou falhar em planejar a escalabilidade pode levar à dívida técnica à medida que o software se torna mais complexo e difícil 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 posteriormente.

2. Tomar decisões informadas de 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 seja aceitável para os objetivos do projeto.

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

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

O problema da dívida técnica

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

• Recursos levam mais tempo para desenvolver

• Mais Bugs

Sempre há um trade-off entre melhorar seu código e adicionar novos recursos.

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

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

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

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

Quadro 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 equipe de desenvolvimento com o código-base em que estão trabalhando. Inclui a capacidade de compreender e navegar pelo código, bem como o entendimento 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 equipe de desenvolvimento porque impacta diretamente sua capacidade de escrever e manter código de alta qualidade com eficiência. Equipes com mais conhecimento do código podem trabalhar mais rápida e precisamente.

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

• 1: Autor. Eu escrevi essa parte do código—posso mantê-la e explicá-la.

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

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

• 5: Documentado. Não trabalhei nele. Temos alguma documentação sobre ele.

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

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

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

Gravidade

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

• 1: Nenhum impacto.

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

• 3: Menor: Funciona bem, mas podemos melhorá-lo. Pode ser tratado no futuro quando recursos e tempo estiverem disponíveis.

• 5: Construtor: Diminui a produtividade, torna o código menos mantível ou impede a adição de novos recursos. Pode ser tratado posteriormente quando os recursos permitirem. Pode ser tratado mais tarde

• 8: Bloqueador. Bloqueia melhorias ou atualizações futuras em um componente do software. Deve ser tratado em breve para evitar que problemas significativos surjam.

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

• 21: Quebrador. 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: Menor local. É autocontido em um único método, classe ou função. Pode violar princípios SOLID—sem impacto significativo na qualidade geral do software.

• 3: Moderado local: 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. Autocontido em uma única aplicação ou serviço, mas envolve violações SOLID em subsistemas em um sistema mais extenso que se espalham para áreas aparentemente não relacionadas. Também pode incluir incompatibilidade entre camadas de abstração, problemas de pontos de integração e acoplamento rígido. Essa dívida não impacta consumidores da aplicação ou serviço, mas é sentida ao modificar o próprio serviço.

• 8: Maior global. 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êmico. Se espalha por múltiplas aplicações, infraestruturas ou equipes. Envolve numerosos serviços compartilhando um armazenamento de dados, alto acoplamento entre diferentes contextos delimitados e incompatibilidade gritante 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ítico. Representa um risco significativo para a qualidade geral do software e pode impactar a estabilidade e confiabilidade do sistema.

Custo de correção

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

• 1: Nenhum esforço

• 2: Baixo custo: 10% da duração da Sprint.

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

• 5: Significativo: Meia Sprint

• 8: Alto: Uma Sprint

• 13: Muito alto: Mais de uma Sprint, mas menos de duas Sprints. Recomendado dividir em múltiplos itens.

• 21: Proibitivamente caro. Sem ideia agora de como lidar com isso. Duas Sprints ou mais.

Personalize as descrições dos critérios

Não se esqueça de que as melhores descrições de critérios são mais fáceis para seus colegas de equipe entenderem. Quanto mais específicas forem as descrições dos critérios e da escala — melhor para seu processo de priorização. Especifique durações de Sprint, explicações de dependências, definições de bloqueadores e significado de conhecimento do código. Leia mais sobre edição de descrição de critérios.

Personalize as Descrições dos 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 usuário são critérios não confiáveis para avaliar dívida técnica.

Não use: Valor de Negócio ou Experiência do Usuário

Fatores como qualidade do código, documentação, cobertura de testes e arquitetura de software raramente se correlacionam diretamente com métricas de negócio como receita. Esses fatores afetam a capacidade da equipe de desenvolvimento de fazer mudanças com eficiência e a qualidade geral, confiabilidade e escalabilidade do software.

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

Não use: Ocorrência

Considere a probabilidade do problema de dívida técnica ocorrer novamente no futuro. Dívida técnica não é um bug que pode ocorrer novamente. Não perca seu tempo prevendo o futuro.

Não use: Idade do Item

Pode parecer uma ideia evidente e direta refatorar bibliotecas antigas mais cedo. Mas por que você deveria gastar tempo nisso se o código funciona bem e não deixa lento nem cria vulnerabilidades? Idade não deve ser seu critério de priorização.

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

Como de costume, precisamos equilibrar os pesos dos critérios para a estratégia correta de definir prioridades máximas para itens de dívida técnica. Por padrão, temos peso -2. Quanto menos recursos de desenvolvimento você tiver na sua equipe — mais negativo o peso deve ser.

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

A fórmula final é bastante simples:

Colete 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 acontecida, conhecida e direcionada.

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

• Por outro lado, dívida técnica conhecida é dívida técnica que a equipe de desenvolvimento já conhece e pode ver no software. Exemplos de dívida técnica conhecida incluem baixa qualidade do código, falta de documentação ou testes insuficientes.

• Finalmente, dívida técnica direcionada é dívida técnica conhecida que a equipe de desenvolvimento escolheu tratar em uma Sprint ou release específica. Isso 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 entender os diferentes tipos de dívida técnica, as equipes de desenvolvimento podem priorizar seus esforços e trabalhar para tratar a dívida técnica para minimizar seu impacto na manutenibilidade e confiabilidade de longo prazo do software.

Dica 1. Crie uma seção dedicada no seu rastreador de tarefas

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

Dica 2. Use um formato consistente

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

Dica 3. Forneça uma descrição clara

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

Dica 4: Use a Frequência de Mudança de Código para coletar dívida técnica Acontecida

Frequência de Mudança de Código é com que frequência mudanças são feitas no código-base de um sistema de software.

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

• 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 a dívida técnica e outros problemas.

Altamente recomendado assistir a palestra de Adam Tornhill sobre essa ideia, "

."

Dica 5: Faça Verificação Automática do seu código para Lentidão e Vulnerabilidades

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

1. Code Scene — Uma ferramenta para visualizar, entender e melhorar seu software em relação ao código, conhecimento e pessoas por trás dele. Faça melhorias com base em recomendações automatizadas, priorizadas e acionáveis.

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

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

4. CodeClimate: Uma plataforma baseada em nuvem que analisa seu código e fornece insights sobre sua 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 em nuvem que verifica seu código e dependências em busca de vulnerabilidades de segurança e fornece aconselhamento de remediação. Suporta várias linguagens de programação e integra-se com várias ferramentas de CI/CD.

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

7. Qodana. Avalie a integridade do código que você possui, contrata ou compra. Enriqueça seus pipelines de CI/CD com todos os recursos inteligentes que você adora das 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 funcione para sua equipe, você pode minimizar seu impacto e manter a qualidade e confiabilidade do seu software ao longo do tempo.

Lembre-se de que dívida técnica não é apenas um problema dos desenvolvedores; afeta toda a organização. Ao incorporar o gerenciamento de dívida técnica nos seus processos de gerenciamento de projeto, você pode garantir que todos estejam cientes de seu impacto e trabalhando juntos para tratá-lo.

Finalmente, é importante lembrar que tratar dívida técnica não é um evento único; requer atenção e esforço contínuos. Ao revisar e atualizar regularmente seu backlog de dívida técnica, você pode se manter atualizado sobre problemas potenciais e garantir que seu software permaneça saudável e confiável a longo prazo.

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