Atualmente atuo como product owner em um projeto para um grande cliente da Concrete Solutions. Após uma retrospectiva mais acalorada, a equipe percebeu que a definição de pronto precisava de uma adição importante: todos os itens deveriam ser feitos utilizando BDD (behavior-driven development). Com isso, a conclusão foi a de que histórias já entregues estavam com débito técnico.

Na reunião de planning seguinte, me pediram, imploraram e finalmente exigiram que eu criasse user stories para que os débitos técnicos de histórias feitas em sprints passados fossem pagos. Então, começamos a debater se essa era realmente a melhor saída. Em algum momento, times ágeis se deparam com essa dúvida: devemos criar user stories no product backlog para lidarmos com tarefas técnicas e/ou tarefas relacionadas a pagamento de débitos técnicos? Como devemos proceder?

Tarefas sem valor, mas necessárias

Para organizações que visam o lucro, valor é o que beneficia a organização e é representado em termos financeiros ou resultados do uso de um produto ou serviço. Times ágeis normalmente diferenciam valor de desperdício. Valor é tudo o que serve ao cliente, o resto é desperdício. Seguindo essa linha, muitas atividades que o time de desenvolvimento precisa implementar podem ser consideradas desperdício. Usuários de um sistema não se preocupam com os problemas dos desenvolvedores do sistema. Tais tarefas não geram valor direto para o usuário. É o que os times chamam de “tarefas sem valor, mas necessárias”: trabalho que fazemos porque precisamos. Um exemplo é o pagamento de débitos técnicos de histórias já entregues.

O que é débito técnico?

É o resultado de todo o trabalho que não ficou realmente “pronto”.  Segundo Martin Fowler, quando temos um pedaço de funcionalidade que precisamos adicionar ao produto, temos dois caminhos a escolher: o primeiro é rápido de implementar, apesar de não ser uma boa solução, pois sabemos que no futuro teremos uma manutenção mais difícil. Já o segundo resulta em um melhor design e uma implementação mais limpa, porém é mais difícil e demorado. Débito técnico é uma metáfora criada por Ward Cunningham para nos ajudar a pensar nesse problema. Nesta metáfora, escolher o caminho rápido e sujo nos leva a gerar cada vez mais débitos técnicos, que são similares a dívidas financeiras. Assim como as dívidas no cartão de crédito, débitos técnicos acarretam pagamento de juros, que vem na forma de esforço extra que teremos no desenvolvimento futuro devido à escolha do caminho rápido e sujo. Podemos continuar pagando os juros ou podemos pagar o débito principal, refatorando a implementação rápida e suja em uma melhor solução. Apesar do custo de pagar o débito principal, ganhamos ao reduzir os pagamentos de juros no futuro. A causa mais comum da criação de débitos técnicos é a falta de uma “definição de pronto” completa, que signifique “pronto para entrega” e que otimize a manutenção, a sustentação e a capacidade de fazer melhorias.

Curto prazo x longo prazo

No curto prazo, débitos técnicos têm como consequências um baixo custo de desenvolvimento, alta produtividade do time, alto return of investment (ROI) e baixo total cost of ownership (TCO). Entretanto, estes números pioram rapidamente e a situação se inverte. Em muito pouco tempo, a produtividade fica comprometida, uma vez que o custo com manutenção se torna bastante elevado. Como resultado, temos um produto com uma pequena vida útil, alto custo de manutenção e em desvantagem em relação à concorrência.

Impasse

Desenvolvedores entendem sobre débito técnico e têm consciência da importância de encarar o problema, entretanto normalmente não possuem habilidades para maximizar o valor gerado pelo trabalho do time. Product owners possuem habilidades para maximizar o valor gerado pelo trabalho do time, entretanto normalmente não entendem a necessidade e os benefícios de se pagar débitos técnicos, e não permitem “user stories” técnicas nos seus projetos e planos de release.

Como resolver o impasse?

O product owner deve compreender que débitos técnicos afetam diretamente o TCO, o ROI e a vida útil do produto a médio/longo prazo. Também deve reconhecer que em alguns momentos o time de desenvolvimento simplesmente terá tarefas técnicas que precisam ser feitas. Ele pode decidir acompanhar essas tarefas internamente, mas não deve tratá-las como progresso direto do produto desenvolvido. O time de desenvolvimento deve compreender o papel do product owner, mas ao mesmo tempo deve lhe mostrar a necessidade de pagar débitos técnicos e de implementar tarefas técnicas. Pagamento de débitos técnicos e implementação de tarefas técnicas são fundamentais para que seja entregue software funcional de qualidade com longa vida útil.

Como pagar débitos técnicos?

• Pare de criar débitos técnicos;
• Faça um pequeno pagamento;
• Repita a partir do passo 2.

Conclusão

O product owner tem como meta maximizar o valor entregue para os usuários. Para isso, evita histórias em que a persona seja alguém envolvido no desenvolvimento ao invés de um usuário que interaja com o produto. Por exemplo: “Eu, como desenvolvedor, gostaria de configurar o Jenkins, para que possamos ter um ambiente de integração contínua”. O time de desenvolvimento vai analisar se a tarefa técnica pode ser vista como um comportamento funcional ou uma característica de qualidade do produto. Caso seja possível, o time reformula a “user story” a partir do ponto de vista do usuário.

O product owner toma sua decisão baseado no tempo que ele deseja que seu produto sobreviva. Caso seja um produto com baixa vida útil, como um hotsite, talvez não seja interessante se preocupar com débitos técnicos. Caso deseje construir um produto duradouro, se houver uma competição forte em seu mercado, é fundamental que se preocupe em manter um baixo índice de débitos técnicos. Sempre que a equipe julgar necessário o pagamento de algum débito técnico, o time de desenvolvimento cria tarefas no sprint backlog para pagar débitos técnicos relacionados apenas às histórias que estejam sendo desenvolvidas no sprint atual. Normalmente, não vale a pena gastar e fazer o esforço para pagar débitos técnicos para histórias já entregues que não estão nesse sprint.

O primeiro passo para o time é parar de gerar débitos técnicos, e o pagamento é feito aos poucos na medida em que histórias são feitas ou revisitadas. Tarefas puramente técnicas são, dessa forma, implementadas como parte de uma user story. Em casos extremos, se houver necessidade, o product owner pode criar product backlog items relacionados ao débito técnico, mas não vai ser uma user story. As user stories são criadas apenas para  evidenciar a geração de valor direto aos nossos usuários e clientes.

Ficou alguma dúvida, tem alguma sugestão ou crítica? Aproveite os campos abaixo.

Até a próxima!