Olá pessoal, alguns de vocês devem saber que sempre fui um grande entusiasta de boas práticas e agilidade. O quesito agilidade teve início pra mim em 2006 quando tive a chance de conhecer extreme programming com o Vinícius teles.
Ainda sem saber como realmente aquele universo funcionava me apaixonei de cara pelo XP e seus princípios, acho bem legal a forma de trabalhar em par, em ciclos e além de tudo existe o foco no cliente e na qualidade. Resumindo, perfeito!
Desde então aprendi um pouco mais de agilidade e boas práticas até conhecer o conceito de dívida técnica. Não recordo exatamente como ou onde, mas aquilo soou bem natural pra mim.

Durante os projetos que trabalhei assumi débitos técnicos diversas vezes, algumas por falta de conhecimento do negócio, outras vezes por falta de expertise técnica e algumas outras por pressão dos stakeholders. Como o elemarjr diz nesse post, eu ganhei experiência e pude aprender quais eram os momentos ideias para assumir esses débitos. Quero compartilhar aqui parte do aprendizado que obtive nós ultimos anos:

  1. Dívidas técnicas são plausíveis quando existe um release em produção do sistema. Com release quero dizer respeitar o time to market.
  2. Deixar de escrever testes não favorece a velocidade de um time maduro, nem mesmo temporariamente.
  3. Dívidas técnicas devem estar visíveis!
  4. Dívidas técnicas devem ser pagas de tempos em tempos.
  5. As dívidas não devem servir como um aditivo para performance do time.
  6. Não devemos contar com a capacidade do time de assumir dívidas.
  7. Precisamos limitar o endividamento.

Esta lista poderia ser maior, no entanto acredito que com as dicas acima já conseguimos tratar as dívidas de uma forma melhor do que eu vejo times trabalhando no mercado.

Para fechar eu acho que é importante relacionar as dívidas com a teoria das janelas partidas ou ainda com o princípio de pareto. Assim fica mais facil entender como as dívidas podem criar juros e ainda decidir a melhor forma de assumi-las, repetindo que não escrever os testes sem dúvida não é a melhor forma.

tags

Agile

Higor Ramos