Paul Tevis está em uma equipe que há quatro meses encontra-se em uma transição Scrum. O projeto possui uma grande quantidade de débito técnico, e ele está às voltas com o problema de como controlar e pagar os débitos técnicos. Tevis escreve que:
Minhas preocupações são (1) logo que iniciar o acompanhamento das tarefas que não são estórias ainda, perdermos o foco em entregar valor aos clientes, e (2) se não fizermos este tipo de tarefas visíveis, não vamos avançar sobre elas no ritmo que precisamos. Quais são os bons padrões que você já experimentou para lidar com tarefas técnicas que não estão diretamente ligados a uma estória (ou que entrelaçam múltiplas estórias)?
Qual é a dívida da técnica? Ward Cunningham criou o termo "dívida técnica" para referir-se à responsabilidade que uma organização possui quando se diminui a qualidade da sua base de código, a fim de cumprir as metas de curto prazo. Diminuir a qualidade do código sempre custa mais no futuro, do que custaria se a qualidade tivesse sido resolvida imediatamente. Este custo extra representa o "interesse" sobre a dívida técnica.
Malcolm Anderson apresenta um caso para assumir o débito técnico em determinadas circunstâncias:
Existem muitas razões para assumir um débito técnico de curto prazo. Eu uso a analogia de um cartão de crédito com uma taxa de juros de 36%. Você não vai querer usar esse cartão. Mas há momentos em que fará todo sentido para o negócio usar esse cartão como no caso de uma situação de curto prazo.
Mas Adam Sroka tem uma objeção:
Se você está no caminho de tomar essa decisão para seu negócio você poderia, pelo menos, desejar saber:
1. Quanto deve gastar?
2. Quanto de taxa de juros você vai aguentar? Durante quanto tempo?
3. Vou ter receita suficiente para pagar de volta?Quando as equipes assumem voluntariamente um débito técnico, elas raramente (ou nunca) sabem a resposta para uma dessas perguntas.
Se foi ou não foi uma boa idéia fazer isso, no caso de Tevis, a dívida já foi tomada. Então, como podemos melhorar a redução do débito técnico existente em nossos projetos?
Roy Morien oferece duas soluções possíveis para o problema de como pagar o débito técnico:
Você realmente tem uma escolha tão difícil a fazer? Eu gosto de pensar que se os seus requisitos de desenvolvimento "técnico" são tão importantes e tão grandes, ou mesmo muitos, não seria uma idéia mais prática chamar o usuário e gastar um tempo de desenvolvimento face a face com ele, e obter todas essas questões técnicas ajustadas e sobre a mesa?
Ou é possível redirecionar alguns desenvolvedores para receber essas questões técnicas e desenvolvê-las, enquanto o resto do time continua a trabalhar no material que foi orientado pelo usuário? Isso pode afetar a velocidade da equipe, mas e daí?
Ron Jeffries não concorda com essas duas abordagens, e diz:
Trabalhar sobre "questões técnicas" funciona melhor quando conduzida por estórias. A base do código está provavelmente na necessidade de que ele trabalhe em qualquer lugar, mas a recompensa será recebida apenas quando o código for trabalhado voltado para as razões do usuário. Se nenhuma estória não passar por alguma área intrínseca, trabalhar nela é em grande parte, um trabalho desperdiçado.
Portanto, eu prefiro a abordagem das estórias, como de costume (mais provavelmente umas poucas delas), e seguindo a "regra dos escoteiros" de deixar o acampamento melhor do que você encontrou. Em outras palavras, sempre que as estórias nos direcionarem, vamos escrever mais testes, vamos refatorar mais agressivamente.
Esta abordagem tem, no mínimo, as seguintes vantagens:
* Mantém "os mais sensíveis" fluxos de histórias;
* Oferece ajuda de todo o talento da equipe;
* Prove a equipe inteira a aprender a manter seu código limpo;
* Foca a melhoria exatamente onde ela é necessária;
* Não desperdiça melhorias que "podem" ser necessárias;... e provavelmente mais.
E "banshee858" oferece a seguinte sugestão (com crédito original a Tobias Mayer) que se encaixa perfeitamente com a abordagem de Ron Jeffries :
Liste todas os itens em débito técnico sobre pequenas notas de post-it adjacentes ao seu Task Board. Quando um item do Product Backlog (PBI) é selecionado para um Sprint, dê uma olhada nos itens que encontram-se em débito técnico e selecione as tarefas passíveis de serem concluídas enquanto você trabalha no seu PBI. Adicione esses itens no escopo do trabalho do PBI e estime quanto tempo será necessário para concluir os itens do product backlog e os itens em débito técnico.
Assim, você faz com que o débito técnico seja visível e pode priorizá-lo, além de poder relacioná-lo com algo de valor para o negócio.