Dívida Técnica, um mal necessário, mas não é um carma

É temerário tentar construir um software tecnicamente perfeito, ao tentarmos fazê-lo provavelmente estaremos sendo narcisistas, egocêntricos, em detrimento do que o cliente realmente necessita. Se uma equipe se dedicasse ao ideal de uma engenharia de software perfeita, com certeza estariam desconsiderando o devido equilíbrio entre valor e qualidade.

Dito isto, débito técnico, são decisões que a equipe toma no transcorrer de um projeto para garantir certo valor entregue, abrindo mão de uma melhor solução em detrimento a entregar uma solução que atenda, mesmo ciente de que é possível e deve ser seu objetivo fazer melhor.

  • Débito técnico NÃO é bug, NÃO é programação orientada a gambiarra (POG), NÃO é entrega a qualquer custo, NÂO é desculpa para não fazer uma boa programação, nem tampouco construir algo que a única solução futura será jogar fora e refazer.
  • Débito técnico É construir software eficiente, mas não eficaz, passível de ser refatorado e melhorado, É as vezes abrir mão de melhores práticas para garantir uma entrega, mas É não entrar em postergação indefinida, lembrar de voltar para melhorar.

Via de regra, dívida técnica é inversamente proporcional ao ROI do produto, o retorno sobre o investimento diz respeito à construção de software de valor e de qualidade. Qualquer equipe SCRUM que tenham senso de pertença e entendido seu papel deve ter no seu radar a busca do equilíbrio entre entrega contínua de valor em produção e boa qualidade de engenharia, manutenabilidade e evolução.

Diferentes abordagens e leituras

Martin Fowler cita Ward Cunningham, que apresentou em 1992 uma metáfora onde o débito técnico no início de um projeto é como se endividar, decisão que pode acelerar o desenvolvimento, mas que deve ser seguido de refatoramentos para reduzir o endividamento e mantê-lo sob controle. Uma dívida não mitigada, acumula dívida sobre dívida, colocando em risco todo o projeto.

Martin Fowler propôs uma canvas para diagnosticar débito técnico:

debit-tecnico

Vale a pena citar Neal Ford da TW, keynote no primeiro dia do Agile Brazil de 2012, ele diz que nós temos 2 usuários, um visível que se beneficia do software que vamos construir e um usuário oculto, que são os próximos profissionais que irão dar continuidade e manutenção futura no software que construímos …

Exemplo: Neal Ford cita um exemplo de decisão em sua reflexão sobre as distrações das abstrações, como a Dietzler’s law sobre o paradoxo de soluções que abstraem e facilitam a construção de uma solução, agilizando resultados iniciais, mas que podem tornar o projeto inviável na reta final, quando exigir especialização ou flexibilidade do framework inicialmente abençoado. Referenciou o MAVEN como exemplo, ele ajuda nos primeiros 80%, dificulta nos 10% seguintes e inviabiliza nos últimos 10%.

Sobre dívida técnica, Uncle Bob afirma que mau código, de má qualidade, NÃO é dívida técnica, pois a premissa para dívidas técnicas é quando desenvolvedores tomam uma decisão calculada, adotando uma estratégia de engenharia de software não desejável e sustentável, mas que gera valor imediato, garantindo uma entrega importante para o cliente por exemplo.

Este conceito está ligado a boas práticas de engenharia, por isto intimamente relacionado à XP (Extreme Programming) e refatoração, ação recomendada como parte importante do processo de desenvolvimento. Refatoração não é realizada devido a código mal escrito, é feito de forma a ter-se uma visão evolutiva contínua do software.

Relação com as 8 leis de Lehman

O conceito de evolução contínua e “refatoração” não é novo, nos anos 70 haviam as 8 leis da evolução de software de Meir Lehman. Com uma abordagem técnica, por 30 anos a Lei de Lehman esteve para o Software do século XX assim como a Lei de Moore esteve para o hardware.

A lei #2 tratava da complexidade crescente e afirmava que se não forem tomadas medidas para reduzir a complexidade do software conforme ele é alterado sua complexidade irá aumentar progressivamente. Deve haver um esforço para reduzir a complexidade final de um sistema enquanto este recebe alterações.

Conclusões

Débito técnico é um opção, deve ser discutida e a equipe deve ter consciência dos ganhos e perdas, riscos e oportunidades envolvidos, acima de tudo é preciso ter clareza de que não é grátis, tem um custo que deve ser aos poucos mitigado.

A prioridade e investimento para manter a dívida técnica sob controle é para ser uma decisão coletiva, precisa estar constantemente no radar e a cada sprint deve ser negociado, atentando à busca contínua pelo equilíbrio entre valor entregue e qualidade de engenharia.

Acima de tudo, manter clareza de objetivos e estratégia, fosse fácil e não seria desenvolvimento de software algo que temos paixão de fazer, não é mesmo?

2 comentários

  1. O problema é quando a equipe deixa dívidas técnicas mas nunca volta para paga-las. Fica pra famosa “fase II” que no fim acaba nunca acontecendo.

    Presumo que a dívida técnica tenha que sempre ser paga ainda de dentro do mesmo projeto, para fazer parte do mesmo “orçamento”.

    Correto?

    Curtir

    1. Com certeza, cada planning de cada sprint deve permitir uma boa reflexão do time sobre esta conta corrente. O quanto aumenta ou diminui, lembrando de abater racionalmente parte da divida tecnica e se possível evitar contrair novas dividas. Mas não é óbv I ou trivial, sse é um um dos grande desafio a ser enfrentado por equipes ágeis de desenvolvimento 😉

      Curtir

Deixe uma resposta para Vitor Canova Weingaertner Cancelar resposta

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