Débito Técnico no Agile Brazil 2010

Um dos tópicos mais abordados no Agile Brazil 2010 foi a metáfora Débito Técnico - cunhada por Ward Cunningham.

Logo no keynote inaugural, Martin Fowler abordou o assunto na segunda parte de sua SuiteOfTalks: Economics of Software Design. É uma palestra muito interessante que começa com uma discussão sobre custo X qualidade de software. Não o tipo de qualidade que estamos acostumados a discutir, a externa, e sim a obscura e difícil de mensurar qualidade interna do software - diretamente relacionada à qualidade do design e do código. Terminadas as introduções MF apresenta a Design Stamina Hypothesis, introduz a metáfora Technical Debt e descreve as formas de débitos técnicos usando o Technical Debt Quadrant.

O assunto voltou à tona durante um workshop sobre Release Planning ministrado por Philippe Kruchten. Nesse workshop jogamos um jogo criado por James King (ARPG - The Agile Release Planning Game: Mission to Mars).
No jogo, os participantes são um grupo de engenheiros e cientistas que estão "ilhados" em Marte depois de uma aterrisagem pra lá de problemática. Agora eles precisam reconstruir a infraestrutura básica para sobrevivência antes de voltar para o objetivo original da missão: descobertas cientifícas.
Os participantes devem então montar uma estratégia para: reconstrução da nave danificada, construção de uma base e/ou uma retomada aos objetivos iniciais de pesquisa. Enquanto montam essa estratégia decisões relacionadas à velocidade e qualidade devem ser contrapostas e avaliadas.
O jogo introduz conceitos de planejamento de releases, velocidade, priorização, débito técnico e planejamento adaptativo. Durante o jogo, fica bem claro o impacto dos débitos técnicos não pagos na velocidade.
O palestrante indicou também outro jogo que ajuda a explicar o conceito de débito técnico para gerentes e product owners: o Hard Choices.
Ambos os jogos são disponibilizados sob a licença Creative Commons e estão disponíveis para o público.

A utilização de jogos em treinamentos ágeis parece uma boa alternativa principalmente quando é preciso explicar conceitos mais complexos como débito técnico. Fica aí a dica.

O assunto foi novamente pauta em um dos open spaces que ocorreram no evento. O moderador, mais uma vez, foi Philippe Kruchten.

Na prática

Gosto muito dessa metáfora. Representa muito bem o impacto da qualidade interna do software na velocidade do time e sua capacidade de continuamente adicionar novas funcionalidades ao longo do tempo.

Um dos desafios é como compartilhá-los com nossos clientes. Como justificar a inclusão desses itens nos sprints/iterações. Obviamente, antes disso, é preciso mapeá-los e devidamente incluí-los no backlog, mais que isso, devem ser estimados, tanto o valor da dívida (fácil) quanto o da taxa de juros (difícil).

Fabio Pereira sugere em seu blog uma Techical Debt Wall Retrospective para mapear e priorizar os débitos técnicos de um projeto (imagem abaixo).

Só assim seremos capazes de decidir pelo pagamento, ou não, e qual pagar primeiro. Lógico que nem todos precisam ser pagos, podem existir casos onde continuar pagando os juros é uma opção (not worth, pouca dor = juros baixos) . Porém só chegaremos a esse tipo de conclusão se tivermos uma visão dos débitos dentro do backlog, com quais estórias eles se relacionam, quais componentes sofrem impacto e como tudo isso afeta a análise de valor.