Problemas no desenvolvimento de software: Dívida Técnica

Compartilhe:

A dívida técnica é um dos principais problemas contemporâneos no que diz respeito aos sistemas de software e retrata o atual cenário do mercado, de aumento de demanda de mão de obra e baixa qualidade técnica no software. Este artigo trata do conceito de dívida técnica, sua origem, causas e consequências, assim como sua interferência direta na qualidade do software e o processo de desenvolvimento do mesmo nas empresas.  As informações apresentadas neste artigo têm por base o livro Qualidade de Software na Prática, escrito por Cleuton Sampaio, do qual indexa um conjunto de conceitos de qualidade de software definidos pelos grandes gurus da área, como Martin Fowler e Robert C. Martins, o Tio Bob. Cleuton Sampaio é mestre em Sistemas de Informação e arquiteto de software. Possui vasta experiência em desenvolvimento de aplicações para as mais diversas áreas.

Podemos conceituar dívida técnica (technical debt) ou débito técnico como tudo aquilo que se deixa devendo ao software. Da mesma forma, trata-se em assumir uma dívida com o artefato resultante do trabalho do desenvolvedor de software, ou seja, a arquitetura do sistema e seu código fonte.

Entregar código imaturo é assumir um débito. Um pequeno débito que acelera o desenvolvimento, contanto que seja pago, assim que possível, com uma revisão de código fonte. A orientação a objetos torna este custo tolerável. O perigo ocorre quando o débito não é pago. Cada minuto gasto com um código ruim conta como juros da dívida. Organizações de engenharia de software inteiras podem ser levadas a um “beco sem saída” sob o peso do débito de uma implementação ruim, orienta a objetos ou não. (Ward Cunningham, 1992, The WyCash Portfolio Management System, tradução de  Cleuton Sampaio.)

Além do débito técnico inicial, aplicado durante a concepção do sistema até a liberação de sua versão final, ainda no escopo original de projeto, tem-se o débito aplicado pela decorrência de manutenções sucessivas, já quando o sistema encontra-se pronto, porém sofre adição ou modificação de funcionalidades ou correções de funcionalidades de modo contemplar os requisitos iniciais. Este segundo tipo de débito adiciona ao sistema o problema denominado Brittleness, termo importado da indústria metalúrgica que representa a fragilidade, falta de estabilidade e baixa manutenabilidade em sistema antigos ou não, que sofreram reprogramação sem a devida refatoração de arquitetura e código fonte. Ou seja, concertos aqui, que geram problemas ali e diminuem a confiabilidade do sistema como um todo. (Wikipedia - Software Brittleness)

O brittleness é causado por diversos fatores. A troca de equipe que compôs o projeto original geralmente é um dos fatores acentuados, pois a nova equipe que assume a manutenção do software não se sente suficientemente responsável pelo mesmo, deixando assim de ter atenção nos ajustes à arquitetura e na refatoração do código fonte. Outros fatores são: a baixa competência técnica da equipe, a falta de testes automatizados que garantem a integração contínua e a refatoração, baixo cuidado por parte da análise ao modelar uma alteração sem a devida análise de impacto através da rastreabilidade do requisito, a pressão imposta por gerências ou clientes autoritários, falta de arquitetura inicial do sistema, a utilização de pseudos métodos ágeis, a não utilização de um repositório de controle de versão (SCM - Software Configuration Management), código de baixa qualidade em geral, entre outros débitos técnicos. (Wikipedia - SCM)

Segundo Cleuton Sampaio, a principal causa da dívida técnica é a dificuldade de balancear a qualidade esperada do software com a entrega do mesmo dentro do cronograma apresentado ao cliente. Entre outras causas da dívida técnica e que geralmente ocasionam juros altíssimos, estão:

  • Results-driven programing: programação orientada a resultados. Nesta modalidade, quando existem testes, o que importa é passar nestes e ser aceito. O principal objetivo é entregar, seja como for, para cumprir o prazo do cronograma, sem considerar as consequências de médio e longo prazo.
  • Apagar-incêndio: consiste no comportamento de desenvolver o código rapidamente, sem o devido cuidado, apenas para conquistar o cliente, geralmente em poucos dias. A solução neste caso não tem definição de análise ou arquitetura bem definida, apenas contém um código fonte que resolve o problema específico e que está rodando em ambiente de produção.
  • Legado do herói: quando a empresa possui um único desenvolvedor, ou analista desenvolvedor, ou qualquer outra pessoa que domina exclusivamente o funcionamento e o código fonte de algum sistema específico, dificultando e impedindo assim a manutenção deste sistema através dos demais membros da equipe. O problema se intensifica quando a empresa faz algum tipo de acordo com este profissional para não perder este herói para o mercado de trabalho, ficando a mercê desta pessoa.
  • Má gestão: quando a gestão opta ou impõe a adoção de técnicas e jargões que estão em alta, ou seja, adoção de metodologias que estão sendo altamente difundidas no mercado, como métodos ágeis XP, Scrum, etc, apenas para se sentirem envolvidos pelo mesmo, sem nem mesmo entender como funcionam. No entanto, a simples adoção sem o devido conhecimento e lucidez não implica em um aumento na qualidade do software.
  • Má gestão de negócios de TI: consiste no problema ocasionado por uma má venda do software pelo papel do analista de negócios, do qual deve ter vendido o projeto sem consultar a equipe sobre disponibilidade de cronograma, prazos ou ainda viabilidade técnica. Por consequência, acaba pressionando a equipe para agilizar a entrega e diminuir a sua responsabilidade sobre o atraso do projeto.

As consequências dos problemas ocasionados pela dívida técnica vão além do desenvolvimento do software em si, afetando desde a organização que o produziu até o cliente, passando pelo suporte. Cleuton Sampaio ressalta que todos sofrem com a dívida técnica, mas poucos se dispõem a resolvê-la, pois o mercado não lhe atribui o devido valor, considerando um trabalho que deve ser feito nos bastidores do desenvolvimento, sem ser avaliado, estimado e até mesmo remunerado. Além disso, podendo ter um agravante, que ocorre quando a gestão do projeto, ou o setor de vendas, sequer consideram um problema de falta de qualidade do software como uma dívida.

De modo geral, todos os papéis envolvidos são afetados. Para os desenvolvedores, tem-se a alta complexidade do código e baixa manutenabilidade, gerando muitas horas extras e esforço para fazer coisas simples, retrabalhando constante. As consequências disto é a criação de um sistema “monstro” de alto custo de manutenção. As dificuldades do trabalho geram incerteza nos prazos, rotatividade da equipe e alto custo de suporte pós-entrega.

Para o cliente, têm-se sistemas de baixa confiabilidade, que geram problemas aleatórios, consumindo recursos de hardware em demasia, afetando o banco de dados e dificultando a operação por parte do usuário. As consequências são toda uma cadeia de processamento de informações afetada, elevando os custos de operação na área de produção. O cliente terá mais despesas com pesquisas de falhas no software, perda de receita e credibilidade devido a estas falhas, baixo retorno do investimento devido aos juros crescentes da dívida técnica, e, até mesmo, sua estratégia competitiva afetada.

Para o suporte, para os diversos níveis de atendimentos, há uma sobrecarga de demandas e chamados referentes a falhas diretas ou indiretas, ocasionadas pelo sistema de baixa qualidade. O acumulo destas falhas acaba obrigando a área de suporte a solicitar projetos inteiros de correção do sistema. As consequências são o elevado custo de atendimento desnecessário, baixando a lucratividade inicial obtida com a construção do software e a perda de tempo com falhas recorrentes.

No entanto, deve-se ter ciência que não existe projeto sem alguma dívida técnica e que o mais sensato é aceitar a sua existência administrando o máximo possível esta realidade. Em um cenário composto por um sistema simples, pequeno, de escopo acadêmico, pode-se admitir débito técnico zerado, mas isto não faz parte da realidade das empresas. No mercado de software, toleram-se algumas dívidas com ressalvas, como: algumas violações de regras de padrões de projeto, algum acoplamento de conjuntos de códigos, algumas dependências ruins, cobertura de teste inferior de 100%, complexidade alta em algumas classes, algum código sem refatoração, entre outras.

Qualquer débito que será tolerado deve ser reconhecido, palpável, contabilizado e sua correção gradual deve ser programada. A bibliografia cita que refatorações ocasionais podem ajudar a reduzir a dívida para um patamar aceitável. Uma estratégia para atacar o débito é, depois de mensurar o tamanho dos juros, aplicar a Lei de Pareto, da qual regra que 20% das causas geram 80% dos problemas e, se corrigimos estes vinte, o que sobrar poderá ser administrado. (Wikipedia - Pareto Principle)

Outra estratégia para administrar a dívida é utilizar um mapa de situação, que auxilia na tomada de decisão, conforme a característica do contexto do problema da dívida. Este mapa é apresentado por Martin Fowler em seu artigo sobre o assunto e consiste em um quadrante de situações combinatórias que caracterizam a gravidade da decisão tomada. (Martin Fowler - Technical Debt Quadrant)

 

Imprudente

Prudente

Deliberado

Não temos tempo para estes detalhes de projeto.

Temos que entregar agora e lidar com as consequências.

Inadvertido

O que são padrões de projeto?

Agora sabemos como deveríamos ter feito isto.

 

  • Deliberado e imprudente: os envolvidos possuem conhecimento para evitar o problema, mas optam por não aplicar por acreditar simplesmente que não tem tempo para isto. Este é o contexto mais grave de dívida técnica. Deve se observar possíveis problemas gerenciais.
  • Inadvertido e imprudente: os envolvidos não possuem conhecimento para aquilo que estão trabalhando, por isto não aplicam as melhores práticas. Este contexto exige capacitação da equipe técnica.
  • Inadvertido e prudente: os envolvidos aprendem que determinada solução não é a melhor e passam a evitar em outras ocasiões. Neste contexto ocorre o débito técnico, mas a equipe tem lucidez e gerencia o mesmo para não gerar juros demasiados.
  • Deliberado e prudente: os envolvidos conhecem a dívida técnica antes de aplicá-la, porém assumem a mesma de modo liberar mais rapidamente a release. Além disto, administram os juros e sabem que irão ter que remover o débito neste projeto em projetos futuros.

Através da análise desta tabela observa-se que o cruzamento de deliberado e prudente possui um bom balanceamento entre qualidade do software e a entrega do mesmo, considerando sempre uma melhoria constante.

Além disto, outras práticas podem atacar de modo preventivo a redução da dívida técnica, como: versionar código em um SCM, gerenciar as requisições de mudanças com um sistema de controle de mudanças vinculado ao SCM, de modo a permitir o acompanhamento de todo ciclo de vida do software. A empresa deve, à medida que desenvolve novos sistemas, formar um repositório de componentes, com controle de versão, para que possam ser reutilizados nos projetos futuros, podendo até mesmo montar seu próprio framework. Deve ainda ter um processo de Integração Contínua (CI – Continuous Integration) bem definido, com execução de builds e testes automatizados. (Wikipedia - CI)

Outra prática de ação paliativa e preventiva consiste na execução de analise do artefato produzido, através ferramentas de análise de complexidade e arquitetura de código fonte, das quais verificam os códigos, as boas práticas, os padrões de projetos, entre outras características do material, de modo a gerar indicadores que servem como base de mensuração da qualidade do software, conforme as metas de qualidade definidas pela empresa. Todavia, esta tarefa exige demasiada experiência e capacidade técnica e pode ser realizado pelo papel do arquiteto de software, um analista com experiência em codificação, uma consultoria especializada em qualidade, testadores ou até mesmo por uma equipe interna, formada por diversos papéis e que está responsável pela qualidade. Porém, deve-se sempre estabelecer metas mínimas de qualidade para cada aspecto, modificando as mesmas à medida que a organização for amadurecendo no processo de melhoria.

Referências complementares:

O quadrante de débito técnico – Martin Fowler

Sobre débito técnico – Martin Fowler

Início do débito técnico - 1992 - Ward Cunningham

Metáfora do débito técnico – Ward Conningham

Artigo da MSDN Magazine

O artigo sobre débito técnico - Juan Maiz

Deixe seu comentário


* Campos obrigatórios.

Comentários (0)