Escapar do buraco negro do débito técnico

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

Dan Radigan Dan Radigan

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 (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 recurso é implementado e está pronto 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 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 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 recurso 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 recurso, teste automatizado e integração contínua em todo o ciclo de desenvolvimento.

A ramificação principal, ou mestre, da base de código deve estar sempre pronta para ser enviada. 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 poderá ser mesclada na mestre. Como a barra de qualidade é sempre fixa (e alta), o débito técnico permanece sob controle.

For many organizations this is a huge cultural change. With agile, the focus away from schedules and towards high-quality, demonstrable software. The product owner is empowered to focus the team on the most valuable work first, reducing the scope of the release instead of compromising on quality.

Não podemos nos esquecer: quanto mais tempo os erros 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 ajudarão você a controlar o débito existente e a permitir que sua equipe se foque em tarefas divertidas, como um novo recurso de desenvolvimento. 

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 correção de erros ou 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 a lista de pendências e desenvolver a base de código. 

Pro Tip:

Priorize o débito técnico no planejamento de sprint do mesmo modo que com um recurso normal. Não oculte em uma lista de pendências separada ou no rastreador de problemas. 

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.

Lembre-se: o débito técnico é uma realidade para todas as equipes de software. Ninguém consegue evitá-lo completamente–o fundamental é que ele não saia fora de controle. 

Up Next
Testing