Para que a dívida seja efetivamente identificada e monitorada no Scrum, é proposta a introdução de um artefato contendo itens de dívida técnica a serem pagos durante os sprints. Este “Technical Backlog” segue o mesmo princípio do Product Backlog, com a diferença de ser uma lista de tudo que precisa ser feito para que a dívida técnica se mantenha sob controle. Isso significa a inclusão de itens detalhados não limitados a melhorias de design/arquitetura, distribuição de conhecimento, teste, segurança, requisitos e performance. Cada item representa uma tarefa que foi deixada para trás, mas que traz um risco de causar problemas caso não seja feita. O time de desenvolvimento será responsável por manter e priorizar esta lista, que em acordo com o PO, será adicionado aos sprints conforme necessidade.
Os itens do Technical Backlog são identificados de forma automática ou humana. Abaixo é apresentado um modelo de um item do Technical Backlog com seus respectivos atributos. Este modelo é uma adaptação de Seaman et al, 2013 (A Case Study on Effectively Identifying Technical Debt).
Tabela 12 - Item do Technical Backlog ID Número de identificação da Dívida Técnica
Responsável Pessoa ou papel que deverá resolver este item
Tipo design, documentação, defeito, teste ou outro tipo de dívida
Localização Lista de todos os arquivos/classes /métodos ou documentos/páginas envolvidos
Capital estimado
Quantidade de trabalho necessário para pagar este item técnico em uma escala de três pontos:
Alto/Médio/Baixo
Valor do juro estimado
Quantidade de esforço extra a ser empregado no futuro caso este item técnico não seja pago imediatamente em uma escala de três pontos:
Alto/Médio/Baixo
Probabilidade de juros estimado
Probabilidade de este item, caso não seja pago, requerer trabalho extra no futuro em uma escala de três pontos:
Alto/Médio/Baixo
Intencional? Sim/Não/Não Sei
O capital estimado refere-se ao custo de se eliminar completamente a dívida, isto é, resolver completamente a imperfeição técnica. Isso inclui diferentes tipos de atividades como adicionar documentação faltante, fazer refactoring em um código difícil de manter ou manter um conjunto de testes de regressão para se adequar ao código e aos requisitos. Dados históricos podem ser utilizados de forma a se obter estimativas mais precisas e confiáveis além de Alto/Médio/Baixo.
O segundo componente da dívida, o juro, é composto de duas partes: (1) a probabilidade de juros é a probabilidade da dívida que, caso não seja paga, fará com que outro trabalho seja mais custoso em dado um período de tempo ou um release; (2) o valor do juro é uma estimativa da quantidade de trabalho extra necessário caso este item de dívida não seja pago de volta. A probabilidade de juros pode ser estimada com dados históricos, por exemplo, e dados de defeitos. Além disso deve-se considerar a variável tempo, pois a probabilidade varia ao longo do tempo. Por exemplo, a probabilidade de um módulo que necessite refactoring causar problemas na próxima release (porque modificações serão feitas nele) pode ser muito baixa, porém ela aumenta se considerarmos períodos maiores, por exemplo, ao longo do próximo ano ou 5 anos.
Além das propriedades financeiras da dívida técnica, algumas propriedades que auxiliam na decisão de pagamento são capturadas neste modelo:
1) O tipo de dívida ajuda a refinar o pagamento da dívida com características de qualidade de interesse. Por exemplo, dívidas de defeito (defeitos conhecidos
ainda não consertados) podem ser diferentemente percebidas em sistemas críticos.
2) A decisão original de se aceitar a dívida foi feita intencionalmente ou não intencionalmente? Esta informação ajuda a entender como decisões relacionadas à dívida técnica são gerenciadas no projeto.
3) O responsável por consertar ou pagar a dívida técnica é importante por motivos administrativos e provê uma base para avaliar o capital e juros. 4) A localização da dívida é importante para entender o impacto no produto,
relacionamentos entre os itens e efeitos colaterais no código quando a dívida for paga.
O processo de identificação e monitoramento começa com a detecção dos itens de dívida e construção desta lista pelo time de desenvolvimento. O próximo passo é o time medir os itens estimando o capital, valor do juro e probabilidade de juros. A dívida é então monitorada ao longo dos sprints pelo Scrum Master e decisões podem ser feitas em relação a quais itens da dívida devem ser pagos ou postergados, seguindo a priorização do Product Owner. Abaixo é ilustrado o Scrum estendido utilizando o Technical Backlog.
Figura 16 - Technical Backlog
Para ajudar no monitoramento da dívida, é proposta a utilização de um mecanismo semelhante ao “Burndown chart”. Esta ferramenta de planejamento e monitoramento ajudará a saber qual é o nível de dívida técnica existente no projeto ao longo do tempo.
A criação do “Technical Burndown” se dá após a quebra das tarefas de itens do Technical Backlog pelo time de desenvolvimento, geralmente durante o Sprint Planning. Uma vez quebradas as tarefas, um gráfico é gerado tendo no eixo X as datas do Sprint enquanto que o esforço restante, em ordem decrescente, no eixo Y.
Figura 17 - Exemplo de um Technical Burndown
O Technical Burndown busca dar visibilidade ao progresso das tarefas do Technical Backlog. Desta forma, pode-se diferenciar o progresso do pagamento da dívida com tarefas de adição de funcionalidades ao produto, permitindo assim um melhor monitoramento e visibilidade da dívida técnica.