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.
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).
