Mão segurando um cartão de crédito

Este artigo apresenta uma abordagem para tratamento de dívida técnica baseado em muitas experiências vividas na prática. Se você não conhece dívida técnica, recomendamos estas duas leituras prévias: Dívida Técnica e Escala de Estol – Os 6 Estágios da Dívida Técnica. Caso o conceito já seja conhecido, o conteúdo apresentado a seguir não deve ser lido como manual ou fórmula e sim de forma crítica e adequado à a sua realidade, especialmente se houver identificação de problemas e situações entre o que será apresentado e as experiências vividas.

1. Reconheça que a Dívida Existe e Existirá

“O pior problema é o que você não sabe que tem”

Uma das maiores causas de projetos com problemas de dívida técnica elevada e causando prejuízo é a simples ignorância em relação a ela. Pode ser por parte dos desenvolvedores, dos gerentes ou ambos, mas sempre que o problema é ignorado ou simplesmente não tratado as consequências costumam ser danosas, pois querendo ou não a dívida sempre cobra juros. Assim, a primeira ação na direção de tratar dívida técnica é o reconhecimento de que ela é parte inevitável do processo de desenvolver software. Isto porque, por natureza, especialmente num cenário de metologias ágeis, a incerteza, mudanças, prazos e pressões são a regra e não exceções como gostaríamos de acreditar. Contudo, para saber o tamanho de uma dívida técnica de um software precisamos ter uma ideia do que seria um software sem dívida técnica. É necessário ter um modelo justamente daquele produto que nunca conseguimos fazer de primeira ou sem algum retrabalho. Em outras palavras é necessário um padrão de qualidade contra o qual nosso software possa ser comparado.

Padrão de Qualidade

Como uma espécie de passo “zero”, é necessário definir o que seria bom antes de reconhecer e começar a medir o que não é. Este artigo não tem objetivo de apresentar um amplo modelo de qualidade, mas um bom começo é avaliar se seu software segue quatro pequenas regras elaboradas por kent Beck:

1. Todos os testes passam (assumindo-se que deve existir um kit de testes)

2. O Código é claro, expressivo e consistente

3. Nenhuma duplicação de comportamento ou configuração

4. Mínimo de métodos, classes e módulos

4 regras da simplicidade de Kent Beck

As diretrizes de bom ou ruim podem incluir estas ou não, mas como parte desta primeira etapa, além de reconhecer a existência e inevitabilidade da dívida técnica, é importante ter em mente que é necessário existir uma meta de qualidade com a qual o produto será comparado.

2. Tente Não Contrair mais Dívida

“Tá no buraco? Pare de cavar!” (não pague dívida com cartão de crédito)”

Essa dica parece óbvia, mas não é. Assim que um time passa a enxergar dívida técnica em um projeto a reação pode ser de tentar resolver ou reduzir o problema, mas estas ações são, quase sempre, um trabalho concorrente com o que precisa continuar a ser feito. Isto significa que por mais que você considere importante pagar a dívida técnica, pode ser que isso não caiba no seu planejamento. Dessa forma, “simplesmente parar de fazer código ruim” já é uma grande evolução e, ao longo do tempo, fará a dívida diminuir proporcionalmente em relação ao resto do código. Novamente é importante ter bem definido o que é um código bom e o que é um código ruim. Um padrão de qualidade a ser seguido, mesmo genérico como o apresentado anteriormente, é um guia para evitar acúmulos de problemas, especialmente aqueles que os desenvolvedores nem sabem que são um problema (dívida não intencional).

“Simplesmente pare de fazer código ruim”

Essa segunda etapa pode ser bastante difícil. Afinal, ninguém gosta de concordar que o próprio código não é bom, até porque se já achasse isso antes provavelmente não o teria feito dessa forma. Ainda assim, se há problemas de qualidade em um código é importante que isso se torne claro e público para que se pare de fazer código desta forma. Mesmo que a dívida técnica não seja reduzida de imediato, ações de interrupção de novas dívidas têm um poder de contaminação positiva.

3. Se Há Juros Embutidos, Alerte!

“Quem dá a missão dá os meios. Quem cala consente. O combinado não é caro nem barato”

Muitas vezes seguir a dica da etapa anterior é apenas uma questão de iniciativa e conscientização para o problema. Porém, algumas vezes a dívida técnica é causada por fatores externos e/ou imponderáveis contra os quais a única ação a tomar é municiar os patrocinadores, de forma clara e embasada, do risco de contrair a dívida e suas possíveis consequências. Esta simples publicidade pode ajudar a evitar a dívida ou ao menos, no futuro, justificar algum gasto de recursos com seu pagamento. Afinal, o combinado não é caro nem barato e se uma notória dívida futura é parte do produto, ela também deve fazer parte do custo, sendo prevista e reconhecida desde o início.

Saber onde pisar é fundamental

Algumas situações comuns em projetos de software podem ser consideradas fortes candidatas para gerar um alerta de dívida técnica. A simples presença de alguma delas pode ser considerada um fator de aumento de risco de uma dívida ser criada. Por exemplo:

– Reestruturação Dependente de Legado –

– Grandes Sistemas Partindo do Zero –

– Restrições Contratuais ou Legais –

– Integração e/ou Dependẽncia de Terceiros –

Por outro lado, algumas boas práticas podem ajudar de forma antecipada a minimizar o impacto de prováveis dívidas. Por exemplo:

– Sprint “zero” e/ou encanamento suficiente

– Componentes e infraestrutura como parte do escopo e não “embutidos”

– Adiantamento de coisas simples e mais estáveis (sem BDUF)

– Integrações especificadas o quanto antes

4. Acostume-se com a Amortização

“O barato sai caro”

Uma origem bastante comum de dívida técnica é simplesmente a dificuldade ou falta de motivação das equipes em atacar o problema através do investimento de tempo e esforço para isso. No artigo [Dívida Técnica] é apresentado o quadrante de itens de backlog e pode-se ver que a dívida técnica não é nem visível (como funcionalidades e correções) nem tem valor positivo (como funcionalidades, arquitetura e infraestrutura). Assim, ela costuma estar no fim da lista de prioridades da distribuição de tarefas, gozando de pouquíssima motivação por parte dos membros da equipe na sua realização. Pode ser desmotivante, pode ser chato, mas fazer as pequenas coisas que mantém tudo em ordem é a forma mais barata de não deixar a dívida explodir. O custo de ignorar ou postergar tarefas aparentemente secundárias (refatoração, testes, padronização etc) pode ser maior do que essas mesmas tarefas no futuro, pois a dívida, como sabemos, cobra juros.

Quadrantes de itens de backlog por valor e visibilidade

Ao contrário do problema da etapa anterior, onde a questão é de origem externa, nesta etapa o grande desafio é gerar mudança de comportamento dos que estão dentro da equipe. Internalizar um comportamento de amortização contínua da dívida pode ser um grande desafio para o líder ou gerente, especialmente se no ambiente já existe alguma pressão. Ainda assim, é necessário introduzir o pensamento de que os juros raramente são uma boa opção e deixá-los crescer indefinidamente é quase certeza de alcançar um estágio de dificuldades pior do que o pior cenário de atraso.

Se voltarmos às quatro regras de Kent Beck, veremos que emergem duas práticas cotidianas e fundamentais para amortização de dívida técnica: Testes e Refatoração.

Testes

A regra 1 (Todos os testes passam) naturalmente é atingida com testes adequados, ou seja, testes de unidade construídos ao longo do desenvolvimento como parte do produto (TDD ou não) e não somente ao final para aferir se o código roda. Testes de unidade são uma atividade de construção que acabam servindo para verificação. Um código construído com testes de unidade desde o início tem naturalmente uma boa cobertura e uma engenharia superior, já que design ruim dificulta o teste e consequentemente produz uma melhora tempestiva.

Refatoração

As regras de 2 a 4 relacionam-se de forma um pouco antagônica gerando a necessidade de ajustes de tempos em tempos para que nenhuma delas seja prejudicada em detrimento das outras. Em outras palavras, para atingir os três objetivos (clareza, expressividade e consistência + nenhuma duplicação + mínimo de elementos) é necessário um esforço constante de reavaliação e de nova codificação a partir das conclusões. Ou seja, refatoração como parte cotidiana do processo de desenvolvimento. Assim como os testes, não se deve esperar longos períodos para pensar no assunto. A prática deve ser algo comum dentro da equipe de forma que dívidas técnicas possam ser atacadas com frequência e com custos diluídos ao longo dos ciclos de desenvolvimento.

Regra do Escoteiro

Atitude de colocar o item no backlog técnico e “puxá-lo”

Uma filosofia bastante interessante neste sentido é o que Robert Martin, no livro “Clean Code”, apresenta como a “regra do escoteiro”. Ela consiste simplesmente em deixar a área do acampamento mais limpa do que estava antes. Levando para o código fonte, toda oportunidade de alterar um código é uma boa oportunidade de deixá-lo melhor, fazendo uma limpeza extra além do que seria alterado inicialmente, amortizando, assim, um pouco de dívida técnica.

5. Aprenda, Evolua e Busque Excelência

“Os erros ensinam o que só os erros ensinam”

Ward Cunningham, em vídeo sobre a metáfora da dívida técnica [1], reforça a ideia de que a dívida em si não é um problema. Na verdade, usando a comparação com dinheiro emprestado, ele sugere que o empréstimo pode ser útil para acelerar o empreendimento. No entanto, no caso do software, é importante aproveitar o que foi aprendido através de refatoração precoce que mais tarde não terá o mesmo efeito ou não será mais pertinente. Dessa forma, uma vez que a dívida é inevitável e algum efeito negativo pode ser esperado, talvez a melhor abordagem seja aproveitar justamente a parte positiva do “empréstimo”.

Aprendizado Personalizado

Independente de praticar as etapas anteriores (Reconhecer, Reduzir, Alertar e Amortizar) uma dívida técnica é uma excelente chance para aprender algo sobre o projeto de software. No caso de dívidas não intencionais, é a chance de escolhas ruins não serem feitas novamente. No caso de dívidas intencionais, é uma boa oportunidade de avaliação da estratégia de deixar pra depois alguma coisa. Em ambos os casos, é a chance de aprender com um exemplo melhor do que o de qualquer livro: o resultado do seu próprio trabalho. Esta é uma forma bastante personalizada de mentoria sobre o software produzido, dando feedback sobre questões particulares do software que não serão encontradas nas bibliografias comuns. Naturalmente, para encontrar é necessário estar procurando.

Busca pela Excelência

Ciclo da excelência a partir da dívida técnica inerente

Outra faceta da dívida técnica é sua relação com a excelência no desenvolvimento de software. Pode parecer estranho, pois quando se ouve “dívida técnica” ou “excelência” não parece haver nenhuma relação de reforço entre elas, pelo contrário. À primeira vista, espera-se que um time de excelência não assuma muitas dívidas bem como imagina-se que um time com dívidas não tenha excelência. Na verdade, justamente pela sua função educativa associada à sua característica idiossincrática de um projeto de software específico, a dívida técnica, sendo aceita como fonte de aprendizado, é um caminho para uma equipe e seus membros individualmente atingirem a excelência.

Tempo, Treino e Técnica

Ao contrário da indústria aérea que dispõe de simuladores para os pilotos aprenderem com os próprios erros (e refletir como seriam as consequências desses erros), a área de software tem na dívida técnica uma oportunidade de prover uma experiência similar. Custos e consequências das ações que tomamos são fortes direcionadores para tomá-las de novo ou decidir fazer algo diferente. Ainda em relação à indústria aérea, ao contrário de um piloto, cujo erro é inaceitável face às consequências, no processo de software, cada vez mais aceitamos e adotamos a “tentativa e erro” como metodologia.

Pessoas

Por fim, ao pensarmos em desenvolvimento de software como uma atividade mais artesanal e menos industrial, vamos perceber que parte do processo de aprendizado entre pessoas com mais ou menos experiência acontece por vários canais e formatos. Todos partem de bibliografias e teorias aprendidas ainda em bancos escolares e acabam sendo apresentados a padrões e manuais das empresas onde vão trabalhar. Muitas vezes essas duas fontes de “como fazer” não se encaixam tão bem e é muito comum fazer algum ajuste do teórico com a prática gerando um conjunto de processos e boas práticas resultantes específico para um certo contexto. A dívida técnica é uma fonte extraordinária para este conjunto, atuando justamente no “como não fazer” aquela coisa que se deseja. Para um desenvolvedor iniciante em uma empresa, este “NOT TO DO” gerado pelos seus antecessores pode ser mais importante do que os conceitos e fundamentos ainda estão frescos em sua cabeça, e certamente é o que melhor vai complementar sua formação recém concluída.

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

Material de Apoio


2 comentários em “Tratando a Dívida Técnica em 5 Etapas

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