Continuando com a questão (sempre acalorada) de Débito Técnico, uma boa analogia com a vida “civil”:
“A simples menção de dívida evoca a sensação de estar sobrecarregado e sob estresse. E sair da dívida é uma tarefa árdua!”.
Esses dias mesmo ganhou muita divulgação o case da Southwest, que foi agravado pela obsolescência e débito técnico acumulado da sua plataforma.
Toda solução tem seu ciclo de vida e ter débitos técnicos e obsolescência é inevitável. O que podemos escolher é como endereçar isso: de forma cotidiana e proativa, ou de forma displicente e encarar uma crise quando a plataforma colapsar.
Mas um ponto adicional que vale refletir e comentar mais uma vez é o aspecto de o quanto o modelo Agile pode impactar ainda mais o risco e as dores do débito técnico.
Infelizmente acaba sendo uma tendência do modelo Agile dar menos atenção ao planejamento e desenho de médio e longo prazo, priorizando a visão de curto alcance (uma outra sprint ou no máximo a PI). Isso por si só já aumenta o risco de se criar algo mais difícil de manter e atualizar no futuro.
Depois tem a questão de priorizar as ações de mitigação/resolução de débito técnicos dentro das sprints. Verdade seja dita, as demandas com impacto no business tendem a ganhar na hora da prioridade, muito pelo próprio entendimento geral de que o PO (primordialmente do business) é quem tem a prerrogativa usual de priorizar o que entra na sprint.
Soma-se a isso o fato de que muitas vezes as “contrapartes” de IT ou possuem menor poder de decisão (por exemplo um scrum master terceiro com pouca autonomia ou senso de ownership sobre a aplicação, ou mesmo arquitetos com foco apenas no desenho da solução, mas não na gestão do lifecycle do sistema ou infra).
Faz parte dos desafios de IT ser capaz de conciliar a agilidade com o zelo e excelência em criar e manter as soluções.
Vale a leitura dessa matéria da InfoWorld sobre o tema:
https://www.infoworld.com/article/3660632/you-re-thinking-about-technical-debt-all-wrong.html
