Jogando Jenga
Você participa de um projeto de software e começa a perceber um certo aumento de códigos comentados e aqueles pontos onde pode-se ler “TODO”. Apesar deste aumento, você não acha nada tão estranho até que suas próprias correções de bugs começam a inserir novos bugs e o que seria uma pequena adaptação acaba demorando mais que o esperado. Além de você, outras pessoas na equipe também começam ter as mesmas impressões sobre o código e acabam gastando cada vez mais tempo para fazer o que faziam antes, reduzindo a capacidade da equipe de uma forma geral. Essa redução, mais cedo ou mais tarde, resulta em alguma entrega frustrada ou não cumprimento dos prazos acordados, mas o projeto não pode parar nem deixar de entregar. Assim, as entregas começam a acontecer com menos rigor que as anteriores e os problemas identificados em produção, passando batido pelos testes e homologação, começam a surgir em quantidade acima do tolerável pelo cliente. Além da quantidade de incidentes, o que deixa seu cliente realmente chateado é ver um mesmo problema que já foi corrigido voltar a aparecer de novo, dando a impressão de que quem corrigiu não sabia exatamente o que estava fazendo (e talvez não soubesse mesmo). Por fim, este cenário resulta em uma situação onde manter o código é uma espécie de passeio por um campo minado e você, ao fim do dia, fica feliz de não ter sido o azarado que pisou em uma mina. Sua atividade diária é um misto de pressão externa por aumento de produtividade com o instinto de sobrevivência que te diz que é melhor não mexer no que está quieto e funcionando, mesmo quando uma mudança ou ajuste é claramente a melhor abordagem. Sua equipe inteira, incluindo seu gerente de projeto, tem consciência desta situação e acham que a melhor opção é ser transferido para um projeto que não esteja neste estágio, o que gera um ambiente de máxima necessidade com mínima capacidade. Dessa forma, o software tem extrema dificuldade de evoluir e ganhar novas funcionalidades que trariam boas demandas de trabalho para o projeto com boas possibilidades de realização de entregas e retorno positivo. Então, você percebe a situação do seu projeto como um conjunto de pessoas tentando equilibrar um monte de peças que encaixaram de forma inadequada no passado, mas que precisa ficar em pé mesmo assim. Você olha pra esse monte de peças e vê claramente como elas deveriam ter sido encaixadas, mas agora já é tarde, pois puxar uma delas de mau jeito vai causar um efeito cascata realmente catastrófico. Em um momento de reflexão você percebe duas coisas: primeiro, não é a primeira vez que você participa de um projeto que chega nessa situação; e segundo, você tem um forte pressentimento que não será a última.
Dívida
Na realidade de projetos de software, a situação acima não é exatamente uma raridade e, naturalmente, tem várias causas para seus diversos aspectos. No entanto, quando todos ou muitos dos sintomas acima manifestam-se em um projeto, é sinal de que uma coisa em especial está fazendo-se presente: Dívida Técnica. O termo “Dívida Técnica” foi cunhado por Ward Cunningham [1] para descrever uma metáfora que compara o custo de escolhas e decisões em um projeto de software com o custo de uma dívida financeira que tende a aumentar e atrapalhar a própria capacidade de quitação da dessa dívida. Ward Cunningham faz uma analogia entre “fazer um software rápido para aprender com ele” com “pegar dinheiro emprestado”. Nos dois casos, pode haver vantagens. Fazer e entregar software mais rápido costuma aumentar as chances de sucesso do projeto assim como pegar empréstimo para abrir um negócio pode ser melhor que acumular todo o dinheiro necessário para isso. Contudo, em ambos os casos, em algum momento, é necessário pagar o empréstimo. No caso do dinheiro propriamente dito ocorre o pagamento do empréstimo ou de juros financeiros. No caso do software ocorre o pagamento na forma de refatoração ou o pagamento de juros de produtividade e/ou qualidade no desenvolvimento futuro. Especificamente no caso do software, é destacada a oportunidade de aprender com o que foi feito de forma apressada (já que já foi feito). Neste caso, além de aprender, é preciso voltar e melhorar o software com o conhecimento adquirido ou este conhecimento pode ser perdido.
Ausência de Tratamento
A experiência em projetos de software indica que os sintomas mencionados no início deste artigo não são apenas comuns, mas praticamente uma regra na construção de um software. Código fonte criado e mantido por uma equipe de várias pessoas, tendo que atender prazos e requisitos muitas vezes incertos, caminha naturalmente para a geração de alguma dívida técnica. Contudo, como na metáfora do empréstimo financeiro, o problema não é a dívida em si e sim o seu não pagamento. Empurrar a dívida para frente parece uma boa escolha no início, mas aumenta a conta do que terá que ser pago no futuro de forma desproporcional. Na verdade, assim como dívidas financeiras, em algum momento, elas podem tornar-se justamente o maior problema que um projeto pode enfrentar. A redução de produtividade talvez possa ser resolvida, mas as questões de qualidade dificilmente serão sanadas com a chegada de mais pessoas. Na maioria dos casos, a chegada de pessoas a um projeto afetado por dívida técnica tende a piorar a situação no curto prazo.
Origens e Causas
Muitas vezes a dívida técnica tem origem em fatores externos ao software. Algumas vezes esses fatores são intransponíveis, mas outras vezes eles produzem efeito simplesmente pela demora em responder prontamente. Observe as frases abaixo e veja como pequenos comportamentos aparentemente inofensivos podem ser fontes de dívida técnica no futuro.
“Não dá pra botar só mais essa telinha?”
“Não tem o que cortar desse MVP”
“Esses testes não vão caber na Sprint”
“Se refatorar é por que fez algo errado”
“Se eu parar pra projetar eu não entrego”
“Não dá pra mudar isso agora”
“O prazo é político”
Uma vez que a dívida técnica não é um problema opcional, a melhor abordagem talvez seja procurar entender e identificá-la o quando antes. Assim, é importante identificar algumas de suas causas para que possam ser tomadas ações de redução ou mitigação antecipadamente. Abaixo estão algumas das causas mais comuns para a geração de dívida técnica:
- Definição Insuficiente
- Pressão do Negócio (Político/Legal)
- Lacuna de Entendimento sobre Dívida Técnica
- Alto Acoplamento
- Ausência de Suíte/Kit de Testes
- Falta de Documentação
- Falta de Colaboração
- Desenvolvimento Paralelo
- Postergação da Refatoração
- Ausência de Padronização
- Falta de Conhecimento
- Falta de Empenho e/ou Motivação
- Liderança Fraca em Tecnologia
- Especificação de “Último Minuto”
Acúmulo
Origens e causas podem explicar a introdução de dívidas técnicas em um projeto, mas seu acúmulo e não tratamento está ligado a uma armadilha no sistema de motivação das pessoas que trabalham para fazer entregas melhores e mais frequentes. Ironicamente, a dívida técnica é justamente um dos fatores que mais atrapalha este objetivo. O sistema de motivação em questão pode ser compreendido na figura abaixo que representa os tipos de tarefas em um projeto de software. A maior motivação de todos é pegar tarefas da zona verde (Funcionalidades) que além de serem visíveis pelo cliente tem um valor positivo (entregam valor de negócio). No gráfico, é possível ver na zona amarela que tarefas fundamentais como arquitetura e infraestrutura não gozam do mesmo desejo por não serem “entregáveis”. Da mesma forma, pode-se ver que a correção de defeitos (zona vermelha) apesar de visível pelo cliente não tem valor positivo, pois é um retrabalho em algo que já foi entregue. Contudo, o que chama a atenção neste gráfico é que a dívida técnica fica justamente na zona cinza onde as tarefas além de não terem visibilidade do cliente ainda são consideradas retrabalho ou “não entrega”. Dessa forma, a dívida técnica tende a acumular e, posteriormente, afetar as outras tarefas de forma negativa da mesma forma ou até de forma mais impactante do que se tivessem sido realizadas de forma diluída ao longo do tempo.
Classificação
Steve McConnel [2] faz uma divisão da dívida técnica em dois tipos: “Sem Querer” e “Intencional”. O primeiro tipo é quando a dívida técnica é inserida de forma não intencional. Por exemplo, um desenvolvedor menos experiente simplesmente escreve código ruim. Esta é uma dívida não estratégica resultado de um trabalho inferior. O segundo tipo é quando a organização toma a decisão consciente de otimizar para o futuro. Por exemplo, uma situação em que se não ocorrer uma entrega não haverá uma próxima.
Martin Fowler [3] faz uma classificação semelhante, mas acrescenta uma nova divisão entre “Prudente” e “Imprudente” de forma a criar quatro quadrantes mostrados na figura abaixo.
A dívida técnica também pode ser categorizada por assunto ou natureza de acordo com a necessidade ou mesmo da intenção e momento de tratamento. Abaixo são apresentadas alguns exemplos de categorias comuns nas quais são divididas a dívida técnica:
Código – Complexidade Ciclomática de método acima de 10
Documentação – EMS defasado ou ignorado (Mensagens do Sistema)
Teste – Testes parcialmente feitos ou desabilitados
Arquitetura – Aplicação monolítica e baseada em banco de dados
Gap Tecnológico – Aplicação JSF com muitos usuários simultâneos
Design – 70% do código na classe de fachada (God Class, Super Façade)
Conclusão
Dívida técnica não é uma questão de “se”, mas de “quando” e “quanto”, pois o quanto antes surgirem os sintomas de que algo não vai bem, mais rápido deve-se agir em relação ao possível impacto sobre o projeto. A partir dessa abordagem, o time é capaz de tratar naturalmente e de forma tempestiva sobre o assunto antes que ele vire um passivo.
Em relação ao “quando”, recomendamos este artigo sobre a abordagem de tratamento da dívida técnica desde o início do projeto bem como do seu proveito como fonte de aprendizado.
Em relação ao “quanto”, recomendamos a leitura deste artigo que apresenta uma gradação do impacto da dívida técnica sobre a sustentabilidade de um projeto. Esta escala pode ser usada para o gestor entender a atual situação do seu produto bem como decidir quais ações podem e devem ser tomadas.
Referências
[1] Ward Cunningham, Ward Explains Debt Metaphor, http://wiki.c2.com/?WardExplainsDebtMetaphor
[2] Technical Debt, Steve McConnell, http://www.construx.com/uploadedfiles/resources/whitepapers/Managing%20Technical%20Debt.pdf
[3] Technical Debt Quadrant, Martin Fowler, https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
2 comentários em “Dívida Técnica”