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?

3 comentários sobre “Dívida Técnica, um mal necessário, mas não é um carma

  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?

    • 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 😉

  2. Pingback: NÃO entregar valor NÃO é opção em uma sprint | Jorge Horácio "Kotick" Audy

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 )

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s