Nos projetos de software sempre há algum nível de tech debt. Sempre a mesma história: não temos tempo para isso agora, na próxima oportunidade corrigimos.
O problema é que em muitos casos o acúmulo de coisas que deixamos pelo meio do caminho é prejudicial à saúde do projeto. Mais que preciosismo de nerds e perfeccionistas, tech debt pode –e geralmente vai- atrasar o andamento do time.
É bom alocar um orçamento para resolver estes problemas. Durante o planning game é importante deixar claro que precisamos resolver problemas enquanto estamos implementando funcionalidades e geralmente alocar alguns pontos na iteração para eles, normalmente algo perto de 20% do trabalho. Normalmente é aceitavel que estas histórias técnicas tenham prioridade baixa e no geral tudo ocorre bem.
No caso de uma emergência então costuma-se não ser muito flexível em relação à solução do problema. As histórias técnicas neste caso ganham prioridade máxima dentro da iteração.
Como geralmente o cliente está satisfeito com a velocidade da equipe num processo ágil (se não está há outro problema) quando sobra –e quase sempre sobra- tempo extra numa iteração geralmente eu preenche-se com tech debt, e em especial deixa-se os desenvolvedores priorizarem o que querem fazer. Muitas vezes não dá tempo para fazer homologação destas mudanças durante a iteração vigente e elas acabam indo para produção apenas na iteração posterior, mas é uma boa estratégia.
O que importa é não deixar o tech debt acumular. Se há duvidas dos problemas que o acúmulo de histórias técnicas causam basta lembrar a última vez que você entrou em um projeto para dar manutenção em um sistema pré-existente. Eu nunca vi um caso onde o sistema antigo não tenha toneladas de problemas causados por “deixar para depois” mudanças que não eram urgentes mas foram crescendo em urgência com o tempo.
Copiei e mudei algumas palavras para passar a mensagem que que gostaria de passar a todos vocês.
tech debts
Nenhum comentário:
Postar um comentário