Se existe uma coisa certa na vida é a dívida técnica. Pelo menos na vida de um software sob medida, aquele em que um cliente apresenta um problema e um time de desenvolvimento projeta e implementa uma solução. Em projetos assim, é normal que o cliente não saiba exatamente qual é o seu problema, apesar de sempre saber pra quando precisa da solução. Esse momento é frequentemente anterior à previsão de entrega, mesmo quando a equipe de desenvolvimento já sabe exatamente qual solução construir, o que, de qualquer forma, também nunca acontece! Neste cenário, não adianta tentar adivinhar ou antecipar todo o problema, muito menos tentar desenhar de primeira aquela solução perfeita.

Pecado Original

Provavelmente, uma expectativa do cliente que pode, de forma realista, ser atendida é a de alguma entrega antecipada. Contudo, cada entrega deixa mais evidente o conflito que existe entre o desejo impulsivo de mais uma entrega e a necessidade de retrabalho em função do que acabou de ser aprendido. Assim, quando um desenvolvedor ou todo um time não resiste e cede a este impulso, nasce mais uma dívida técnica. A recém-chegada, em breve, também fará parte da dinâmica e vai influenciar ainda mais esses impulsos aos quais já é tão difícil resistir.

Tamanho do Impacto

Assim como sobrepeso, depressão, endividamento e outros problemas que podemos enfrentar durante a vida, a grande questão com a dívida técnica não é o dilema de deixar ou não o problema aparecer e sim o impacto que esse problema vai causar. Em um projeto de software, é importante estar atento aos sinais do quão grande está a dívida técnica antes que estes sinais indiquem que simplesmente não há mais o que fazer. Nesta linha de pensamento, este artigo apresenta uma classificação da dívida técnica em seis estágios de acordo com os sintomas que um projeto costuma apresentar. Estes estágios englobam alguns sinais que apoiam a identificação dos problemas que a equipe já tem o sentimento de confrontar. Essa sensibilidade ajuda na tomada de decisão sobre ações relacionadas à dívida técnica e assuntos correlacionados.

Estágio 0: Utopia

paisagem paradisíaca - utópica

Este é aquele momento inicial quando o projeto ainda não começou ou acabou de iniciar. Desenvolvedores pouco experientes vão, de forma incauta, escrever código com escolhas questionáveis, mas elas ainda não trarão nenhum impacto. Desenvolvedores experientes vão relembrar momentos difíceis de projetos passados, mas têm a certeza de que desta vez vai ser diferente. Eles lembram de toda a teoria sobre qualidade e boas práticas e pensam em como, desta vez, vão aplicá-las da forma que aprenderam. Nesta etapa todos acreditam em fazer uma boa cobertura de testes unitários e a maioria ainda acredita que não é só nos livros que o TDD funciona.

O Cálice Sagrado do Critério de “Done”

Durante a “utopia” todos estão empolgados para definir um critério de “done” que vai dar orgulho pra equipe. Neste momento, os desenvolvedores e os gestores fazem um juramento de que o “done” será cumprido por todos “sem exceção” e que é justamente assim que o projeto será bem-sucedido. Mal sabem eles que morreram tentando encontrar este cálice sagrado do desenvolvimento de software.

Clima das Pessoas

Clima da equipe: Euforia por ter um novo desafio. Vontade de colocar em prática algumas teorias, estudos e fazer diferente dos últimos projetos.

Clima do cliente: Esperança de que agora será atendido. Acredita ter clareza do que será feito.

Clima do gestor: Confiança. Acredita na equipe e no entendimento do problema.

Estágio 1: Universo em Expansão

universo expandindo

Neste estágio, o código fonte está em franca expansão, tudo que é feito é coisa nova e quase nada precisa ser entendido ou refatorado. Assim, mesmo que algumas escolhas não muito boas já estejam sendo tomadas, elas ainda não afetam as pessoas e, na prática, não são percebidas pela maioria dos desenvolvedores. Durante o “universo em expansão”, a dívida técnica já dá o ar da graça, mas ainda é um obstáculo de fácil transposição. Justamente por isso, por ser considerada uma coisa pequena, as primeiras ações não são tomadas.

O Discurso se Adapta à Prática

Neste estágio, o desejo de mostrar serviço nas primeiras entregas para validação ou mesmo produção é um pensamento dominante e tarefas “menores” acabam sendo postergadas. Testes de unidade ainda estão sendo construídos, mas algumas partes do sistema já são feitas sem cobertura suficiente. Agora, a maioria concorda que TDD é só teórico e que farão somente os testes mais importantes. Com as primeiras surpresas de entendimento e escopo (apesar de previstos) vêm os primeiros atrasos em tarefas e os desenvolvedores começam a tentar se livrar do que não é visível ou não tem valor de negócio óbvio.

Os Primeiros “Chatos”

Alguns poucos membros da equipe que já alertam sobre a dívida técnica são vistos com desconfiança ou como pessimistas. Apesar de as coisas já estarem dando sinais de que não estão indo conforme previsto, a equipe tem a sensação de que basta “dar uma acelerada”. Isso, na verdade começa a contribuir para mais escolhas duvidosas no projeto. Esse pessoal que começa a advertir sobre dívida técnica vai se sentindo como na caverna do Platão e, conhecendo o fim da história, acaba desistindo de falar sobre isso.

Clima das Pessoas

Clima da equipe: Motivados, apesar das primeiras dificuldades.

Clima do cliente: Satisfeito. Está vendo o produto ser desenvolvido e entregas serem realizadas.

Clima do gestor: Apesar de alguns problemas sinalizados pela equipe eles podem não parecer prioritários no momento, pois o cliente está satisfeito. Continuar entregando algo de valor é prioritário.

Estágio 2: O Rei Está Nu

rei solitario

Agora, a dívida técnica já é percebida por todos. Está bem claro que algumas escolhas estão impactando diretamente a velocidade e a capacidade de entregas do time. A velocidade baixou e alguma entrega já foi frustrada. Uma refatoração seria muito bem-vinda do ponto de vista do software, mas do ponto de vista dos prazos ela é a última coisa que se quer ver pela frente. Muitos ainda não usam o termo dívida técnica e/ou atribuem os problemas a fatores externos como questões de especificação ou mudanças não previstas.

Rei Nu

Quem menos quer enxergar a situação como ela está é o gerente/líder ou quem quer que seja responsável pelo cumprimento das entregas. A equipe tem dificuldade de dizer pra esta pessoa que há questões no código que precisam ser revistas para que parem de impactar na produtividade. Assim como o rei nu, as outras pessoas, apesar de terem uma opinião do que deve ser feito, ainda não são capazes de afirmar que uma revisão ou refatoração de grande proporção deve ser feita. Isto porque, no primeiro momento, algum esforço terá que deixar de ser empregado em construção e terá que ser gasto com este retrabalho. A equipe tem a certeza que se propuser algo do tipo vai ouvir que “agora não dá” ou até que teve culpa na atual situação. Assim, desiste de dizer o que acha e passa a dizer o que é melhor de se ouvir.

O Peso dos Juros

Durante este estágio, teorias e hipóteses sobre os problemas são apresentadas apenas como prestação de contas para algum nível hierárquico superior como forma de ganhar tempo, mas as soluções que são dadas não correspondem à real necessidade do projeto. Os “reis” dos níveis acima estão ainda “mais nus” por causa da distância e o foco nos resultados combinados. Dessa forma, uma realidade paralela de problemas e soluções toma conta do projeto enquanto a explicação mais simples tem dificuldade de ser aceita: a dívida técnica já está cobrando juros.

Clima das Pessoas

Clima da equipe: Há algumas falhas de comunicação e falta de perspectiva de resolver alguns problemas no código, apesar de já existir previsão sobre seus impactos futuros. Já entende que é preciso tratar dívida técnica.

Clima do cliente: Ainda satisfeito. Problemas pontuais devem estar acontecendo.

Clima do gestor: O cliente já percebe algumas falhas então é preciso agradá-lo. O gestor ainda entende horas extras e aumento de esforço como a melhor solução e não atacar diretamente o problema da dívida técnica, pois isso pode gerar ainda mais indisposição com o cliente.

Estágio 3: Malabarismo

homem fazendo malabarismo

Geralmente, o marco do estágio “malabarismo” é a maturidade das maiores e mais significativas partes do produto em produção. Arquitetura, infraestrutura e escolhas tecnológicas já foram selecionadas e as chances de alterar uma delas é baixa. Entrar em produção de forma robusta tendo uma dívida técnica cobrando juros significa que os relatos de erros e/ou incidentes vão piorar o estado de coisas do projeto uma vez que vão competir com a construção de novas funcionalidades.

O Monstro do Merge

Se antes já não havia tempo para uma reorganização ou pagamento de dívida técnica, agora as coisas vão ficar ainda mais difíceis. A partir de agora, provavelmente, a equipe terá que trabalhar com duas versões do código fonte e enfrentar o terrível monstro do “merge”. Aliás, piadas de duplo sentido com a palavra “merge” são um forte sintoma de que o estágio “malabarismo” foi alcançado. Além deste verbete, o vocabulário da equipe começa a ter maior incidência de termos como “Go Horse”, “POG”, ‘Gambi”, “NullpointerException”, “baixa o log”, “bate monstro” entre outros.

Mais Trabalho, Mais Dívida

Com muita frequência, a carga representada por uma quantidade razoável de incidentes e erros gera a necessidade de realização de horas extras. As horas extras muitas vezes são usadas para tentar não passar para o cliente o impacto do atual estado de coisas. Afinal, para o cliente ainda está tudo bem apesar de o número de erros ser maior do que ele gostaria. Existe um roadmap definido e o sistema precisa continuar a evoluir mesmo que seja clara, para a equipe de desenvolvimento, a necessidade de alguma pausa técnica para pôr ordem na casa. Essa última tentativa de varrer o problema para baixo do tapete, esperando que algo mágico aconteça, é justamente o oposto do que precisa ser feito neste momento.

Janela de Oportunidade

Aceitar que os juros da dívida técnica estão impactando o projeto é fundamental para dar uma boa resposta ao problema. Enquanto isso não acontece, o time vai equilibrando as diversas tarefas simultaneamente, tentando fazer tudo ao mesmo tempo sem deixar nada cair no chão. Muitos sistemas passam anos neste estágio arcando com o ônus de escolhas feitas nos estágios anteriores que, naqueles momentos, teriam representado um esforço bem menor do que o que é despendido agora.

Clima das Pessoas

Clima da equipe: Cansaço e vontade de sair do projeto e tentar uma nova oportunidade de fazer o certo da próxima vez.

Clima do cliente: O sistema precisa continuar evoluindo. Sente as pessoas mais tensas, mas não entende bem o motivo. Está um pouco frustrado pois não percebe que as entregas são feitas com o mesmo vigor.

Clima do gestor: É preciso manter o sistema e continuar entregando novas funcionalidades. Agora já reconhece o impacto da dívida técnica, porém já não tem os mesmos recursos para tratar o problema.

Estágio 4: Elefante na Sala

elefante sobre uma mesa

Este é o estágio onde o termo “dívida técnica” acaba sendo aceito por todos, incluindo gerentes de nível mais alto e até o próprio cliente, que muitas vezes, nem sabia que o conceito existia. Como um elefante na sala, a dívida técnica não só não pode mais ser ignorada como também não há mais paliativos como horas extras para esconder o problema. Além disso, incidentes corrigidos começam a aparecer como erros novamente e a percepção de que a equipe trabalha por tentativa e erro começa a ganhar força. Na verdade, inicialmente, a culpa tende a cair sobre o time de desenvolvimento apesar de vários fatores estarem envolvidos.

Assim, uma ação muito comum deste estágio é o aporte de mais pessoas à equipe na tentativa de dar vazão às tarefas que estão sendo impactadas pela dívida.

Horda de Mongóis

Esse grupo de pessoas que chega para “ajudar” é conhecido como “horda de mongóis”, pois, antes de ajudar de fato, eles vão atrapalhar bastante e sair destruindo tudo em seu caminho. Eles não conhecem o sistema e principalmente as armadilhas que foram se formando ao longo do tempo com a falta de tratamento de questões técnicas. Antes de representarem horas a mais na capacidade, eles serão responsáveis por horas a menos da equipe original que precisará explicar como o sistema funciona e cada decisão que lhes parece tão estranha.

Fahrenheit 451

Junto com a “horda de mongóis” são chamados os “bombeiros” pra ajudar a apagar os incêndios. Ao contrário dos bombeiros reais, que são bem vistos, nestes casos as pessoas dentro do incêndio tendem a não ver ajuda externa com bons olhos. Isso porque, geralmente, os agentes externos, consultores, arquitetos, especialistas etc, vão acabar dizendo algo que a equipe já vinha dizendo há algum tempo, além de expor as falhas e “queimando” a equipe. Normalmente, quando um sistema chega neste estágio não é por falta de aviso ou por falta de visão da equipe e sim por falta de dedicação e de tempo para o pagamento de dívida técnica. Costuma ser mais um problema de querer ou poder fazer do que saber como fazer.

Ctrl + Alt + Del

Uma coisa marcante do estágio “Elefante na Sala” é presença de uma sensação, quase unânime, de que o sistema seguiria melhor se sofresse um “reboot’. Ou seja, se tivesse uma grande parte simplesmente reescrita, pois tentar melhorar o que existe parece mais trabalhoso do que começar de novo. Esse processo de deterioração, dificuldade e reconstrução é apresentado no livro “Clean Code”, de Robert Martin, como “O Grande Replanejamento”. Muitas equipes passam anos neste ciclo sem conseguir sair dele e alternam pequenos períodos no estágio 0 e 1, quando começam a construir um sistema, e grandes períodos de “sofrimento” nos estágios seguintes, quando têm que manter os sistemas e arcar com os custos de suas escolhas no período inicial.

Cruzando o Rubicão

Alguns sistemas sobrevivem a esta fase e conseguem voltar aos trilhos. Normalmente, quando há entendimento geral sobre a necessidade de se pagar a dívida técnica e existe o patrocínio adequado para isso, o sistema pode recuar no que se refere à dívida técnica e até voltar a ter uma velocidade de cruzeiro com um desenvolvimento sustentável. Do contrário, o sistema cruza um marco decisivo e sem volta, avançando para o último e irreversível estágio desta escala: O Estol.

Clima das Pessoas

Clima da equipe: Revolta e sensação de injustiça. Desmotivada pois o cliente percebe e relata que o produto não está bom.

Clima do cliente: Identifica que há mais problemas do que ele considerava aceitáveis e não confia na qualidade do produto. Aponta problemas na equipe. Quando indagado sobre a necessidade de incluir refatorações e melhorias, fica chateado porque quer ver o sistema evoluir e suas necessidades continuarem a ser atendidas como antes.

Clima do gestor: Desgaste com o cliente para tentar explicar que a equipe precisa desacelerar nas entregas para tratar problemas estruturais.

Estágio 5: Estol

avião em estol

De acordo com a wikipedia, “Estol” é o termo utilizado em aviação e aerodinâmica que indica a separação do fluxo de ar extradorso da asa, resultando em perda total de sustentação. Isto significa que uma aeronave em situação de estol não está voando e sim caindo. De forma análoga, do ponto de vista da dívida técnica, um sistema que tenha atingido o estágio de “Estol” simplesmente perdeu a capacidade de ser mantido de forma sustentável. Em outras palavras, realizar manutenção neste software acaba gerando não só a sensação de que deveria ocorrer um “reboot”, mas sim a certeza de que esta é a única solução.

Prejuízo

O custo de manutenção em termos de tempo e pessoas empregadas somados aos frequentes impactos no funcionamento em produção são tão altos que a evolução acaba impossibilitada. Dessa forma, assim de forma análoga ao estol de aviação, o sistema não está gerando receita através de evoluções e sim custos através de horas extras, insatisfação do cliente, indisponibilidade, perda de integridade, além de glosas em contratos com impacto financeiro direto.

Ejetar

Do ponto de vista do desenvolvedor, a sensação é a mesma do piloto nesta situação, pode até parecer que ele está pilotando, mas na verdade o avião está indo numa direção que não se pode prever nem evitar. Frequentemente, neste estágio, os desenvolvedores, gestores e cliente concordam que a melhor ação é puxar a alavanca de “eject”.

Clima das Pessoas

Clima da equipe: Ejetar!

Clima do cliente: Ejetar!

Clima do gestor: Ejetar!

Conteúdo Relacionado

(Em breve) Heurísticas de Avaliação de Sustentabilidade Baseado em Dívida Técnica

2 comentários em “Escala de Estol – Os 6 Estágios da Dívida Técnica

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s