Concrete Logo
Hamburger button

Como tratar débito técnico?

  • Blog
  • 12 de Fevereiro de 2018
Share

Débito técnico é uma realidade em praticamente todos os times ágeis que eu conheço. Para lidar com ele, antes precisamos entender como e quando ele surge, e por experiência digo que tempo certo não existe, mas normalmente aparece entre o meio e o final da Sprint, quando o próprio Time de Desenvolvimento o identifica.

Débitos técnicos são implementações e/ou soluções não realizadas da melhor forma dentro do trabalho esperado: pode ser uma cobertura de testes não alcançada, algum componente não implementado 100%, falta de padronização de código, etc.

Depois de identificados, os débitos são colocados no Product Backlog e dependem da negociação entre o Time e o Product Owner sobre a prioridade deles para serem resolvidos. Essa negociação é muito importante porque, se definido com baixa prioridade ou deixado de lado no Product Backlog, o débito técnico pode acabar virando uma bola de neve e trazer problemas para o projeto no futuro. Portanto, é importante que o Time explique bem, com detalhes, sobre o item para o Product Owner, mesmo que o PO não seja técnico (o que não é necessariamente um problema), para que ele possa tratá-lo na velocidade correta (sempre que possível).

É necessário que esteja clara também a diferença entre débito técnico e trabalho não finalizado. Se ao final da Sprint o Time não atingiu a Definition of Done de algum item, ele é denominado “não finalizado”, e deve voltar para o Product Backlog, com outra estimativa de prioridade.

Então, como tratar o débito técnico?

 

De acordo com minha experiência, criar folgas durante a Sprint para que, ao final do trabalho desenvolvido (Sprint Goal cumprida), o Time possa puxar os itens de débito técnico é uma das opções.

Outra ideia é: se de alguma forma o “work in progress” está limitado, deixando os membros do time “travados”, podemos então criar uma “Swimlane de Intangible” no quadro. Isso vai fazer com que o Time puxe os itens de débito técnico. Além disso, ainda podemos definir que em pelo menos 10% da Sprint o time trabalhará com débito técnico, eliminando-o aos poucos.

… Mas, pensando bem, não seria melhor criar uma Sprint somente para tratar débito técnico e acabar com o problema de vez?

O melhor é NÃO fazer isso!

Pode acontecer de ter acumulado tanto débito técnico que o PO foi convencido, forçadamente, de que criar uma Sprint só pra isso é a melhor opção para o momento. Se foi preciso criar uma Sprint só de débito técnico, ou “Hardening Sprint”, que é o termo técnico pra isso, não trabalhamos com Scrum. O objetivo ao final da Sprint é ter um incremento de software potencialmente entregável, ou seja, pronto para colocar em produção, o que provavelmente não aconteceu em alguma das Sprints anteriores por causa do débito técnico acumulado.

Ter débito técnico não é exatamente o pior dos mundos, pois nem tudo é realizado com a melhor qualidade sempre e muitas vezes será necessário entregar o atual valor rapidamente, aproveitando oportunidades de mercado.

Entretanto, um dos valores do Manifesto Ágil é ter Software em funcionamento.
E se este não é nem de longe o seu caso, então a melhor opção é agir e tratar imediatamente o débito técnico neste cenário caótico, mesmo que seja necessário uma Sprint só pra isso.

Concorda, discorda ou tem algo a dizer? Aproveite os campos abaixo e até a próxima!

Quer trabalhar com desenvolvimento de produto de verdade? Só vir!