O que é débito técnico?
Os programas de software tradicionais têm uma abordagem baseada em fase para desenvolvimento: desenvolvimento de função, alfa, beta e golden master (GM).
Cada liberação começa com uma fase na qual são criadas novas funções, e (idealmente) problemas residuais do último lançado são abordados (mas vamos ser honestos: isso raramente acontece). O ciclo de desenvolvimento atinge "alfa" quando cada função é implementada e está pronta para teste. A fase beta é liberada quando erros suficientes foram corrigidos para permitir feedback dos clientes. Infelizmente, enquanto a equipe está ocupada tentando corrigir erros suficientes para chegar à fase beta, novos erros aparecem. É um ciclo sem fim: um erro é corrigido e mais dois aparecem. Finalmente, a liberação chega à fase golden master quando não há erros em aberto. "Nenhum erro em aberto" geralmente é obtido corrigindo alguns problemas conhecidos e adiando o resto (a maioria?), para a próxima liberação.
Procrastinar constantemente erros que precisam ser corrigidos é uma forma perigosa de se fazer um software. Como a contagem de erros cresce, lutar contra isso torna-se 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 erros reduz a velocidade de desenvolvimento. Enquanto isso, os clientes passam por problemas com os vários cortes causados pelos defeitos não corrigidos. E, além disso, alguns deles vão deixar você.
Deve haver um modo melhor.
Redução do débito técnico com o método ágil
O método ágil proporciona qualidade para a abordagem de desenvolvimento iterativa, então a equipe pode manter uma qualidade de nível consistente em todas as liberações. Se uma função não é boa o suficiente, ela 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 a assistência de qualidade começar. O problema com essa definição é que os erros se arrastam desde o início no ciclo de liberação–e continuam a se arrastar. Então, no momento que a equipe de assistência de qualidade começa a trabalhar, o produto já está selado com várias camadas de defeitos. As equipes ágeis, no entanto, definem "concluído" como pronto para liberação, o que significa que os desenvolvedores não prosseguem para a próxima história ou função até que o item atual esteja praticamente nas mãos do cliente. Para acelerar o processo, eles usam técnicas como fluxos de trabalho de ramificação de funções, teste automatizado e integração contínua em todo o ciclo de desenvolvimento.
A ramificação principal da base de código deve estar sempre pronta para ser lançada. Essa é a prioridade número um. Novas funções começam a ser usadas em uma ramificação de tarefa que contém o código para a função em si, bem como os testes automatizados. Assim que a função estiver concluída e os testes automatizados forem aprovados, a ramificação vai poder ser mesclada na principal. Como a barra de qualidade é sempre fixa (e alta), o débito tecnológico 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 novas funções.
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 novas funções 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 novas funções. 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.
Priorize o débito técnico no planejamento de sprint do mesmo modo que com uma função 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 diferi-los e isso apenas proporciona débito técnico. Se o teste não é feito como parte da história original ou da correção de erro, a correção de erro ou da história original não é feita. Mantenha uma definição estrita do que é a conclusão em seu programa e certifique-se de incluir testes automatizados completos. Nada consome mais a agilidade da equipe mais do que teste manual e uma base de código com erros.
Erros automatizados para longe
Quando alguém descobrir um erro no software, aproveite o tempo para adicionar um teste automatizado que demonstre isso. Assim que o erro 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 de negócios à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:
- Mostrar ao proprietário do produto o custo real do débito técnico. Garantir que os valores de ponto de história sejam precisos para futuras histórias que exijam resolução do débito técnico existente.
- Modularizar sua arquitetura e tomar uma posição firme sobre o débito técnico em novos componentes ou bibliotecas no aplicativo. Como a equipe e os negócios veem a agilidade nesses novos componentes, eles naturalmente desejarão estender essas práticas para outras partes do código.
- Escrever testes automatizados! Nada impede erros melhor do que os testes automatizados e a integração contínua. Quando um novo erro for encontrado, será necessário criar um novo teste para reproduzi-lo e, em seguida, corrigir o problema. Se o erro aparecer novamente, o teste automatizado irá encontrá-lo antes dos clientes.
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.
