Escapar do buraco negro do débito técnico

//A FAZER (brincadeira!) Mas, sério: você fica tenso quando vê isso? Sim, a gente também. 

Dan Radigan Dan Radigan
Buscar tópicos

Os programas de software tradicionais têm uma abordagem baseada em fase para desenvolvimento: desenvolvimento de recurso, alfa, beta e golden master (GM).

Débito técnico ágil | Coach Agile Atlassian

Cada liberação começa com uma fase na qual são criados novos recursos e (em um mundo ideal) itens residuais da última liberação são abordados (mas vamos ser honestos: isso quase nunca acontece). O ciclo de desenvolvimento atinge "alfa" quando cada recurso é implementado e está pronto para teste. A fase beta é liberada quando bugs suficientes foram corrigidos para permitir feedback dos clientes. Mas, enquanto a equipe está ocupada tentando corrigir bugs suficientes para chegar à fase beta, novos erros aparecem. É um ciclo sem fim: um bug é corrigido e mais dois aparecem. Enfim, a liberação chega ao marco golden master quando não há bugs em aberto. "Nenhum bug em aberto" costuma ser obtido corrigindo alguns itens conhecidos e adiando o resto (a maioria?), para a próxima liberação.

Procrastinar constantemente bugs que precisam ser corrigidos é uma forma perigosa de se fazer um software. Como a contagem de bugs cresce, lutar contra isso fica cada vez pior, resultando em um ciclo vicioso de débito técnico. Para piorar, os cronogramas ficam bagunçados porque codificar em torno dos bugs reduz a velocidade de desenvolvimento. Enquanto isso, os clientes sofrem com as constantes inconveniências causada pelos defeitos não corrigidos e, como resultado, alguns acabam migrando para outro fornecedor.

Deve haver um modo melhor.

Redução do débito técnico com o método ágil

A agilidade proporciona qualidade para a abordagem de desenvolvimento iterativa, então a equipe pode manter uma qualidade de nível consistente em todas as versões após o lançamento. Se um recurso não é bom o suficiente, ele não é lançado. Acha difícil de acreditar? Há um truque: definir, ou redefinir, a definição de "concluído".

Para equipes tradicionais, "concluído" significa bom o suficiente para garantia de qualidade, para começar. O problema com essa definição é que os bugs aparecem no início do ciclo de lançamento–e continuam a aparecer. Então, quando chega para a garantia de qualidade, o produto é sobrecarregado com várias camadas de defeitos. As equipes ágeis, no entanto, definem "concluído" como pronto para ser lançado, o que significa que os desenvolvedores não passam para a próxima etapa da história ou recurso até que o elemento atual esteja quase nas mãos dos clientes. Para acelerar o processo, eles usam técnicas como fluxos de trabalho de ramificação de recursos, testes automatizados e integração contínua ao longo do ciclo de desenvolvimento.

O branch principal, ou ramificação principal, da base de código deve estar sempre pronto para ser lançado. Essa é a prioridade número um. Novos recursos começam a ser usados em uma ramificação de tarefa que contém o código para o recurso em si, bem como os testes automatizados. Assim que o recurso estiver completo e os testes automatizados forem aprovados, a ramificação pode ser mesclada na mestre. Como a barra de qualidade é sempre fixa (e alta), o débito técnico permanece sob controle.

Para muitas organizações, essa é uma grande mudança cultural. Com a agilidade, o foco se distancia dos cronogramas e vai em direção ao software demonstrável e de alta qualidade. O proprietário do produto tem o poder de concentrar a equipe no trabalho mais valioso primeiro, reduzindo o escopo da versão em vez de comprometer a qualidade.

Não se esqueça: quanto mais tempo os bugs permanecem, maior é o trabalho de correção.

Controle do débito de sua equipe

Se está trabalhando com código legado, há chances de você ter herdado algum débito técnico. Os tópicos a seguir vão ajudar você a controlar o débito existente e a permitir que a equipe se concentre na parte boa, como o desenvolvimento de novos recursos.

Definição

Às vezes, os desenvolvedores e os gerentes de produto discordam sobre o que constitui o débito técnico. Então vamos acabar com essa controvérsia:

Isto inclui quaisquer atalhos técnicos feitos para cumprir os prazos de entrega!

Há uma tentação no lado de desenvolvimento para caracterizar a obra arquitetural como débito técnico. Pode ou não ser isso, dependendo da natureza da mudança (por exemplo, substituir um atalho com a "verdadeira" solução versus dividir uma base de código monolítico em microsserviços). Por outro lado, a equipe de gerenciamento de produtos muitas vezes sente mais urgência na criação de novos recursos do que na atualização de segurança ou em correções de desempenho lento. Para evitar que ambos os lados fiquem enfadados com a opinião uns dos outros, todos precisam compreender a distinção entre débito técnico, mudanças arquiteturais desejadas na base de código e novos recursos. Uma comunicação clara entre as equipes de desenvolvimento e gerenciamento de produtos é fundamental para priorizar o backlog e desenvolver a base de código.

Dica profissional:

Priorize o débito técnico no planejamento de sprint do mesmo modo que com um recurso normal. Não oculte em um backlog separado ou no rastreador de itens.

Cuidado com as tarefas e sprints de teste

Lute contra a vontade de comprometer a definição de conclusão adicionando uma tarefa de teste separada à história original do usuário. É muito fácil ver a diferença, e isso apenas proporciona débito técnico. Se o teste não foi feito como parte da história ou atualização de segurança original, então ela não está concluída. Mantenha uma definição estrita do que é estar concluído no programa e não se esqueça de incluir testes automatizados completos. Nada consome mais a agilidade da equipe mais do que teste manual e uma base de código com bugs.

Erros automatizados para longe

Quando alguém descobrir um bug no software, aproveite o tempo para adicionar um teste automatizado que demonstre isso. Assim que o bug for corrigido, refaça o teste para garantir a aprovação. Este é o núcleo do desenvolvimento orientado a testes, uma metodologia consagrada pelo tempo para a manutenção de qualidade no desenvolvimento ágil.

Onde começar?

Mudando a percepção da equipe (e a das partes interessadas da equipe) de que gerenciar o débito técnico não é fácil. As necessidades comerciais às vezes reduzem o tempo de desenvolvimento para que o produto chegue ao mercado mais cedo. Com isso em mente, vamos recapitular alguns itens de ação para controlar o débito técnico:

  • Eduque o proprietário do produto sobre o verdadeiro custo do débito técnico. Garanta que os valores do ponto da história sejam precisos para histórias futuras que exijam a resolução de débito técnico existente.
  • Modularize a arquitetura e assuma uma posição firme sobre débitos técnicos em novos componentes ou bibliotecas no aplicativo. À medida que a equipe e a empresa veem a agilidade desses novos componentes, eles naturalmente querem estender essas práticas para outras partes do código.
  • Escreva testes automatizados! Nada impede bugs melhor do que testes automatizados e integração contínua. Quando um novo bug for encontrado, escreva um novo teste para reproduzir o bug e então corrija o item. Se esse bug ressurgir, o teste automatizado vai detectar ele antes que os clientes o façam.

Não se esqueça: o débito técnico é uma realidade para todas as equipes de software. Ninguém consegue evitar completamente, o importante é que ele não saia de controle.

a seguir
Testing