Newsletter #041 - Débito Técnico e a perca de produtividade.
Seu newsletter semanal voltado para tecnologia e qualidade de software
Olá pessoal, mais uma semana de newsletter voltado para tecnologia e qualidade de software.
Na semana passada conhecemos sobre os principais débitos que podem ocorrer em um projeto de automação e passos para solucioná-lo, caso não tenha lido, segue o link. Na newsletter de hoje vamos continuar nossa conversa sobre débito técnico voltado para projetos em geral e como esses débitos prejudica a produtividade do time, então bora lá?
Pesquisando uma imagem para a capa do tema de hoje encontrei essa de Luke Chesser na qual mostra um gráfico em queda. Talvez o contexto do gráfico não seja sobre débito técnico, mas diz muito sobre o início de um projeto de software.
Assim que o projeto se inicia, todo o time se empenha o máximo possível para a entrega, cada sprint é visto as entregas do time, cheio de funcionalidades novas e a primeira entrega para o cliente. Contudo, ao passar do tempo o time começa perceber alguns problemas e dúvidas como, “será que o framework X vai funcionar para a funcionalidade que o cliente pediu?", “a biblioteca X não suporta as cores e o layout que o cliente pediu", “a versão do framework de testes atualizou, vamos atualizar?", além disso o débito técnico pode ser “essa nova funcionalidade do cliente pode ser implementado depois", “esse bugzinho não é critico pode deixar para depois". Tenho certeza você já ouviu algumas dessas frases e dúvidas.
Essas frases mostram um comportamento que é o seguinte, quanto mais o débito técnico se acumula, torna-se cada vez mais difícil de pagar, pois os desenvolvedores são forçados a lidar com problemas urgentes, deixando pouco tempo para resolver questões fundamentais, e assim os bugs vão crescendo, problemas aparecendo e aquela produtividade que vimos no começo vai se exaurindo, chegando no final do projeto (se é que vai chegar rsrs) um time esgotado e com vários problemas no sistema entre elas instabilidade, retrabalho constante e a dificuldade de manutenção.
Nós como QA ou de engenharia devemos sempre procurar meios de conter essas dívidas e gerar estratégias para pagar o mais rápido possível. Alguns textos podem dizer que o planejamento é o grande herói dessa história, contudo, mesmo com muito planejamento, vivemos em constante evolução e uma hora ou outro irá surgir um débito, o mais importante de tudo é estarmos preparados e com estratégias criadas.
Assim, uma das formas de criarmos estratégias é pesquisar como as grandes empresas buscam diminuir o débito técnico, por exemplo o artigo Definindo, Medindo e Gerenciando Dívida Técnica , os autores mostram como o Google realiza a contenção das dívidas, lá utilizam de um quadro faseado que apresenta desde dívidas técnicas que são reativas (passíveis de bug) até a fase estrutural que é quando a maturidade do projeto está muito fraca e estruturalmente o projeto se tornou uma dívida técnica.
Já no Departamento de Defesa dos EUA em 2022 desenvolveram um estudo para aprofundar em como resolver os débitos técnicos dentro da organização e principalmente dentro de sistemas intensivos e altamente críticos para o sistema de defesa do país. Após o estudo geraram 5 recomendações para os times, sendo:
Compartilhe melhores práticas - As organizações de desenvolvimento devem capacitar os desenvolvedores para incorporarem a gestão técnica da dívida nas atividades do ciclo de vida de desenvolvimento de software como uma das principais práticas de engenharia de software. Dentre esse tópico deve criar etapas com metas pré-estabelecidas para a conclusão do débito técnico.
Atualizar a política existente para incluir práticas técnicas de gestão da dívida - As organizações que desejam controlar a dívida técnica devem continuar a atualizar suas diretrizes e recomendações, políticas e orientações de melhores práticas de desenvolvimento de software existentes para incluir práticas de gestão de dívida técnica.
Incentive o treinamento técnico em gestão da dívida - A formação pode ajudar a sua organização a institucionalizar práticas importantes de dívida técnica, tornando a questão visível para mais partes interessadas e garantindo que estas partes interessadas estejam munidas das práticas e estratégias necessárias para gerir eficazmente a dívida técnica.
Exigir coleta contínua de dados e métricas técnicas relacionadas à dívida - Os sistemas que gerenciam dívidas técnicas usando com sucesso métricas de gerenciamento de defeitos e vulnerabilidades, tempo médio para resolução, duração aberta, taxa de recorrência e densidade, criam softwares bem-sucedidos.
Garantir maior acesso a ferramentas e práticas modernas de desenvolvimento, análise e CI/CD - Para garantir que todas as etapas anteriores sejam feitas com sucesso é importante que haja automações e ferramentas que possam mostrar que o fluxo de desenvolvimento e de entrega está numa cadência esperada e que mitigue que os erros não chegue no final do processo.
Bom, no texto de hoje quis trazer um pouco mais sobre como as dívidas técnicas surgem em um projeto e como nós QA podemos mitigar a resolução dessas dívidas encontrando na literatura cases de sucesso. A dívida técnica não é uma tarefa fácil de solucionar, deve ser um papel de todos do time, deve se criar estratégias e metas para que consiga resolver o mais breve possível. Um exemplo em minha carreira, participei de um projeto que todas as sextas-feiras era o dia de pegar uma dívida técnica para resolver, durante algum tempo conseguimos zerar a dívida.
Espero que tenham gostado do tema e espero vocês na próxima semana com um conteúdo mais técnico (talvez até uma automação rsrs) para praticarmos! Como de costume nas seções abaixo tem o que rolou de tecnologia da semana, qualidade de software e os eventos na semana. Até a próxima pessoal! 🚀
O que rolou de Tecnologia?
Como ( não) implementar métricas DORA - DORA métricas já foi um tema da nossa newsletter e um tema recorrente no mercado. Aprendemos muito a forma certa de fazer, contudo com exemplos de como não implementar conseguimos verificar que errar é muito mais fácil que achamos na criação dessas métricas.
Removendo a ambigüidade nas avaliações de Pull Request - muitos acham que o code review é fácil, contudo dentro de uma avaliação de PR podemos ter muitas falhas de comunicação e ambiguidades. No texto é apresentado formas de resolver esses problemas de ambiguidade.
SRE x DevOps x SysAdmin - artigo muito interessante e completo que mitiga de uma vez a diferença entre as áreas. Se você possui dúvidas a respeito, o texto irá responder todas.
E Qualidade de Software, como está?
Por que conseguir um trabalho de teste de software está se tornando difícil - dia após dia estamos vendo a diminuição das vagas no mercado. Após um boom de vagas com a economia voltando a patamares pré-pandemia, acaba que podemos ficar preocupado com a extinção da nossa área. Excelente artigo que explica mais um pouco dessa visão.
Estratégias de teste: tendências atuais e melhores práticas - texto muito completo que explica as estratégias de teste que estão em tendência no momento e quais as melhores práticas. Para quem está estudando para a CTFL é um excelente artigo para ter como referência.
Os 5 principais repositórios GitHub para testadores de software - sempre é bom termos repositórios do Github que podemos nos espelhar. No artigo traz 5 repositórios que deve estar no favorito do nosso navegador para pesquisar em momentos de dúvida.
Eventos Importantes não perca!
Simulação de ataque e defesa no âmbito de resposta a Incidentes - Evento Online.
Data: 16/05
Inscrições abertas
Vejo vocês na próxima newsletter 😁🚀!
“Confine a si mesmo no presente”– Marco Aurélio