Como lidar com Débitos Técnicos do Time de Desenvolvimento?

Olá Scrum Masters, Product Owners e Agile Coaches, como vocês têm lidado com PBIs (Product Backlog Items) de débitos técnicos do time?

Quis começar esse artigo com uma pergunta e aproveito a oportunidade de colocar alguns pontos de vista sobre essa questão.

Os débitos técnicos são itens gerados pelo Time de Desenvolvimento, onde durante a codificação das histórias percebem a necessidade de criar esse PBI e revisitar futuramente essas partes de código para realizarem refatoração.

É errado isso?

Eu acredito que não, quando temos uma cobrança forte para entrega de uma Sprint, cabe ao time de desenvolvimento definir como devem implementar certos pontos do código e nesse caso se para atingir o objetivo da entrega seja necessário “pecar” em alguma das melhores práticas de desenvolvimento ágil de software para o bem da entrega, nesse caso eu acho válido, desde que esse mesmo desenvolvedor registre esse débito técnico e todo o time tenha ciência que precisa ser refatorado.

E como fazer para reduzir esses PBIs de débitos técnicos?

Durante a Sprint Retrospective, que é o momento onde todo o time de desenvolvimento aproveita para realizar Kaizen do processo, precisam conversar e estabelecer um plano de ação para a redução desses itens. Hoje em dia, diversas ferramentas são utilizadas durante o processo de deploy contínuo, como por exemplo: Sonar Qube e Codacy, que realizam inspeção da qualidade do código para revisões automáticas, detecção de bugs e vulnerabilidades de segurança e que “deduram” pontos para o time de desenvolvimento atuarem para correção/melhoria desses “issues”.

Qualquer Product Owner durante uma Sprint Planning, que ele traz a lista de PBIs priorizados para que o time faça a estimativa e identifique o que cabe na próxima Sprint, dificilmente entenderia a inclusão de um item identificado pelo Dev Team de débito técnico, nesse ponto é salutar que haja uma boa negociação com esse PO para que ele entenda a necessidade de refatoração de partes do código para uma melhor performance e também para evitar bugs e vulnerabilidades nos sistemas.

Uma alternativa válida é se comprometer com um número menor de histórias e ter um “buffer” para refatoração efetiva dos pontos identificados.

Concluindo

Débitos técnicos são ocorrências que sempre existirão durante o ciclo de vida de um produto, é responsabilidade de todos do time de desenvolvimento terem a consciência e a auto-organização necessária para identificá-los e em momentos oportunos realizar as melhorias visando a melhor qualidade do código e a satisfação do cliente com o produto que está sendo entregue.

Vamos discutir o tema com a comunidade, compartilhe, comente sua experiência, dê like no artigo para ele ganhar relevância, vamos falar sério sobre o tema.