Débito técnico é um neologismo, cunhado por Ward Cunningham, que se refere ao acúmulo de defeitos, baixa legibilidade de código, dados desnormalizados, arquitetura ineficiente, desenho pobre e coisas como essas. É como um “cheque especial técnico” onde o débito vai se acumulando e depois é cobrado da solução final com juros e correção monetária. Abaixo o quadrante nada “mágico” do Débito Técnico.

Geralmente os times técnicos focam muito no débito técnico relativo ao código, mas ele pode ocorrer em todos níveis da arquitetura, incluindo mas não se limitando a, interface com usuário, lógica de domínio, comunicação e aos dados.

Esse gráfico não é o original cunhado por Martin Fowler. Ele teve o quadrante Inconsistente/Imprudente estendido por Scott Ambler para endereçar questões além do código.

Existem algumas razões Prudentes para  entrar no “cheque especial” do débito técnico como a redução do tempo de liberação da solução (time-to-market)  ou uma oportunidade de aprendizado, devido à pressão do negócio.

Outras razões são Imprudentes como não investir  em arquitetura e desenho de forma Intencional, ou mesmo de forma Inconciente, resultado de não ter o conhecimento suficiente para entregar a solução.

Entre diversas abordagens para fugir do débito técnico está a adoção de métodos de desenvolvimento centrados em arquitetura, aliados ao desenvolvimento de provas de conceito e refatorações. Essa é uma abordagem que tem se mostrado sustentável, para gerenciar melhor as decisões técnicas visando manter o débito técnico sob controle.

E você como administra o débito técnico na entrega de suas soluções?


Exibições: 431

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Adriano Tavares em 22 agosto 2012 às 10:28

Acredito que a chave para esta questão seja o balanceamento de acordo com os riscos envolvidos. Evoluindo a sua metáfora do avião, se você está construindo um avião de papel tudo bem (risco próximo de zero), vai tentando fazer ele voar até conseguir. Mas, se vai colocar pessoas lá dentro do avião aí não dá, não é? :)

De uma forma simplista, transportando risco para perda financeira apenas, sem falar de outras perdas envolvidas, se o risco de perda financeira é baixo, então é possível assumir mais risco e usar o "cheque especial técnico" por um tempo. Se o risco de perda financeira for alto, o "juros do débito técnico" pode te quebrar. :) 

Comentário de Rafael Fontoura em 19 agosto 2012 às 23:56

Estou passando por isso atualmente num projeto. A gerência de projetos, por não ter visibilidade da importância da arquitetura e provas de conceito, as julgam como sendo menos importante que o desenvolvimento da aplicação em si. No meu caso estão conscientes e, devido ao tempo (sempre) escasso, estão correndo o risco. Fiz uma analogia outro dia em e-mail, dizendo que, com o desenvolvimento e teste dos componentes que iríamos utilizar durante o projeto (um rascunho de rabisco de prova de conceito) eu estava tentando "construir o avião antes de colocá-lo pra voar" e não me entenderam.

Creio que a visibilidade da mitigação de problemas de performance e problemas funcionais com arquitetura, o que implica em redução de custos e esforço, deve ser vista também pela gerência dos projetos (seria bom que a diretoria também tivesse essa visibilidade). Mas para gerentes que nunca foram técnicos, ou que sempre trabalharam com projetos "pra ontem", apagando incêndio, fica difícil ter esta visão.

Comentário de Adriano Tavares em 10 julho 2012 às 5:54

Bruno, 
acho que esse é o que vi na maioria dos projetos também. Deve ser porque o argumento principal nesse quadrante seja em função do tempo. Mas, se isso é feito de forma que o projeto fique com débito muito alto, depois é necessário mais tempo para correções e refatorações. O importante então é gerenciar e balancear o investimento de tempo mais cedo possível para reduzir o débito técnico. Outro coisa é que se isso for feito de forma isolada pode não ser muito efetivo. Quando você define uma boa estratégia técnica aliada a uma estratégia gerencial, os resultados podem ser mais efetivos.

Comentário de Bruno Leite em 2 julho 2012 às 10:14

Com o intuito de enriquecer a discussão, aos que já relataram... Em qual quadrante os projetos que vocês participaram se encaixa mais? Creio que nos projetos onde vi grandes débitos técnicos, eles se encaixam no quadrante de intencional/imprudente, muitas vezes por negligência não só da gerência e sim da própria equipe, alguns dizerem:

"Vai mexer nisso para quê? Já está funcionando em produção"

"Dá preguiça de mexer nessa parte aqui viu, muito código e classes gigantes"

"Fulano que fez, fulano que conserte"

"Refatoração não funciona"

"Teste é para os fracos, o que eu faço funciona"

"A arquitetura desse sistema é ótima, ele é gigante e funciona a anos" (detalhe: o sistema exige manutenção diária)

Comentário de José Valdvogel de Almeida Junior em 27 junho 2012 às 23:42

Já sofri e ainda sofro muito com o chamado débito tecnico, muitas vezes pq de fato a parte de pensar no inicio do projeto fica para ajustar no final.

Comentário de Marcelo Antonio Alves em 21 junho 2012 às 15:04

Infelizmente a arquitetura não é dado tanto valor, principalmente se o projeto não é muito grande, sou se o profissional é caro. 

Concordo com ambos, pois sofro isto na pele. Tanto a arquitetura quanto os testes unitários (TDD) são considerados gargalo de desenvolvimento (principalmente os testes). 

O pior de tudo é que, no caso de testes unitários, é cultural pois os próprios desenvolvedores veem os testes unitários como perca de tempo e implantar uma metodologia como TDD é um "parto" pois a equipe alem de não acreditar não consegue ver os resultados dos testes unitários a médio/longo prazo.

Comentário de Adriano Tavares em 21 junho 2012 às 12:48

Bacana o seu ponto de vista Guilherme,

independente dos nomes dos papéis atribuídos por uma organização aos profissionais, o time deve buscar um equilíbrio com relação ao débito técnico.  

Comentário de Guilherme Coelho em 21 junho 2012 às 11:00

Muito bom o post.

Já sofri muito em projetos onde as questões arquiteturais foram deixadas de lado. O que percebi é que quase sempre isso acontece quando os gestores não conseguem ou não querem enxergar o real papel do arquiteto no projeto. Muitas vezes para estas pessoas o arquiteto é só um desenvolvedor super sênior que vai resolver os problemas que o restante da equipe não souber resolver. Geralmente nestes casos a arquitetura é vista como gargalo no projeto.

Evento TDC2016

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço