O XP (eXtreme Programming) tenta se utilizar de metáforas no desenvolvimento de software para trazer o entendimento de todos para mais próximo do mundo real. Metáforas são um instrumento poderoso.
Recentemente compareci na QConSP, e no meio de tantas palestras uma me chamou a atenção em particular, e se tratava justamente da explicação de uma metáfora (que acredito ser maravilhosa para se comunicar com a gerência ou clientes).
Todos nós sabemos o que é uma dívida no mundo real, e todos nós eventualmente entramos em dívidas, seja um financiamento de um imóvel que você vai pagar por 300 meses, ou um carro que você vai ficar endividado por 60 vezes. O pior de tudo é que além da dívida normal, você irá pagar um montante de juros absurso dependendo do tamanho da dívida que você está assumindo.
Existem as dívidas responsáveis ou conscientes como as citadas acima mas também existem dívidas inconscientes ou não responsáveis que são piores, pois surgem de uma hora para a outra sem te dar tempo para pensar se desejava assumir essa dívida ou não (ex: alguém gastando desordenadamente no cartão de crédito e quando vai ver a fatura fica surpreso).
Pois bem, no desenvolvimento de software é a mesma coisa!
Você tem que adicionar uma funcionalidade no seu sistema. Nesse momento você enxerga duas formas de fazer isso: Uma forma é rápida de fazer, mas é meio bagunçada e com certeza você iria ter mais trabalho ainda no futuro para modificar aquilo. A outra forma é mais elegante e organizada, porém vai demorar mais. Isso lhe parece familiar?! Esse trade-off acontece o tempo todo no desenvolvimento de sistemas, mas o que esquecemos é das dívidas que assumimos quando escolhemos a forma mais rápida e mais bagunçada (ex.: gambiarras)!
Parece que não temos ciência que todas as vezes que assumimos uma dívidas técnicas no sistema, mais lento o desenvolvimento se torna, mais difícil de modificar as funcionalidades existentes, mais difícil adicionar funcionalidades novas (como mostra o primeiro gráfico) e muito mais provável que uma mudança qualquer tenha impactos indesejados e desconhecidos. Temos que estar cientes das dívidas que assumimos no dia-a-dia do desenvolvimento de software.
Ah, então é por isso que não conseguimos aumentar a velocidade do time depois de tantas sprints??
Talvez! Aí nasce a questão importante que é o momento que iremos pagar nossas dívidas, ou ao menos parte delas. A grande maioria dos times conhecem os lugares no sistemas que estão com dívidas, e é preciso separar um tempo para PAGAR essas dívidas caso contrário os juros só fazem aumentar. Enquanto as dívidas não são pagas, nós nos deparamos com o cenário onde sprint após sprint, vamos fazer menos coisas (vide o segundo gráfico) pois agora é muito mais difícil modificar o sistema com tantas dívidas do que era no início do desenvolvimento quando não tínhamos dívida ou as poucas dívidas que tínhamos eram controláveis.
Cuidado com suas dívidas técnicas ou elas vão afundar você e seu projeto!
Bytes don't Bite! 
Concordo com tudo que você falou Thiago…e gostaria de salientar a importância de que todos do projeto tenham essa visão. Falo isso do ponto de vista do time de teste no qual é minha realidade, e vejo que muitos times de testes não entendem o porque o time de desenvolvimento muitas vezes “brigam” para que requisitos de mudanças (CRs) sejam criteriosamente avaliadas em severidade e prioridade e que muitas vezes os desenvolvedores aparentemente não “querem” (quando na verdade não podem) resolver CRs de melhoria ou baixa prioridade pois estão pagando essa dívida com o sistema nesse momento.
Excelente post, Parabéns 😉
Valeu Diego! Como você disse seria maravilhoso que todos do time tivessem essa visão (principalmente a gerência pois as vezes eles são os que menos tem essa visibilidade). Vamos difundir mais essa metáfora, que facilita o entendimento dessa dívida por todos!
Muito bom Burgos, a pressão “normal” por parte do cliente tem que ser bem administrada pela gerência senão podemos ter muitos problemas futuros 🙂
Isso Marcel, mas é preciso estar ligado pois a equipe TODA tem que saber quando estão entrando em uma dívida e alertar a gerência!
É preciso comprometimento de todos para que o PROJETO COMO UM TODO não entre em dívidas sérias! 🙂
Já tinha lido alguns artigos sobre a temática do ‘technical debt’ mas sempre tive dificuldade em passar a palavra devido ao desconhecimento da tradução em português.
Esta tradução é perfeita!
Deixo aqui outro artigo sobre este (excelente) tema: http://msdn.microsoft.com/pt-pt/magazine/ee335722(en-us).aspx
Então, eu estava nesta mesma palestra e ela foi realmente muito boa. Assim como o post. Parabéns!
Thiago no último comentário fala em “dívidas sérias”. E tem algo interessante sobre isso. Quando você deve 2 reais ao seu vizinho você provavelmente não vai pagar. Nem tampouco ele vai cobrar (bom, eu não cobraria hehe). Porque é algo realmente bobo. Ou seja, um débito técnico pequeno não tá gerando retrabalho e nem vai gerar no futuro. Então você deixa debitar da sua conta: dane-se! Mas quando a dívida começa a crescer, a preocupação do time também deveria. E é isso que falta nas nossas equipes de desenvolvimento. Isso não significa que toda vez que virmos uma gambiarra, iremos consertar imediatamente. Eu acho que isso é o ideal para os desenvolvedores, mas causaria atrasos na entrega. O overhead de fazer isso sempre e sempre seria pesado demais pra um projeto com prazos apertados. A sugestão dada é que as equipes EXIJAM um tempo para “pagar” o montante. Talvez uma semana ou uma sprint após cada release. E isso tem que ser prioridade. E se o gerente não quiser? Lembre-o dessa metáfora e chame-o de xexeiro! =)
Concordo, acho que sua visão está correta a respeito das dívidas pequenas e dívidas sérias 🙂
Ótimo post Thiago,
Pena que muitas vezes os novatos não tem o discernimento do que é (ou não) gambiarra. Cabe aos mais experientes orientar e procurar, em sua maioria, fazer as coisas da maneira correta.
Certa vez lí em um livro de design o seguinte: “faça o código funcionar, depois refatore, e refatore e refatore, e refatore, …”
Programar não é uma tarefa simples. Programar orientado a objeto, utlizando-se de padrões, seguindo as melhores práticas que reduzem, de maneira significativa o tempo de manutençao, garantam reusabilidade, extensibilidade do código, é bem mais difícil e custoso. Mas, no final, você vai ter um código que não dá problema. E quando precisar acrescentar funcionalidades vai ver o quanto simples isso se tornou.
Por isso, é fundamental ter um profissional especialista em arquitetura na equipe para garantir esse tipo de implementação
E Existe um Orgão de Proteção ao Projeto que vai cobrar do desenvolvedor essa dívida que ele tá fazendo… essa orgão tá sentado por trás de uma mesa com uma placa sobre a mesma escrito “GERENTE”.
Achei o post bastante interessante, mas a gente tem sempre que lembrar que o trabalho do desenvolvedor só existe para agregar valor e tornar realidade necessidades reais do cliente. Não acredito que a dívida técnica esteja somente relacionada com a gestão do projeto ou pressões do cliente. Todos os envolvidos têm que estar cientes das decisões técnicas que causam grande impacto que estão sendo tomadas, principalmente o gerente! Os pontos do sistema que mais tiverem “dívidas” podem ser levantados como risco do projeto e o controle e a mitigação dos mesmos são vitais para a boa gestão. A responsabilidade é compartilhada e não única e exclusiva do gerente.
de acordo!
O que é uma gambiarra?
gambiarra
s. f.
1. Renque de luzes entre as bambolinas do palco.
2. Extensão eléctrica, com fio comprido, que permite levar luz a sítios afastados.
Boa noite.
Gostei bastante da documentação e de como foi passado. Mas existem alguns erros de português.
Faça apenas 1 revisão e altere enriquecendo tudo o que falou.
Parabéns
Bom observei sua matéria, mas como estou começando agora estou leigo em certos pontos, por isso peço uma orientação em como responder a essa pergunta de um trabalho proposto a mim. A figura utilizada é de um gerente informa que vai subir e ver o que eles querem e o resto comece a codificar a questão informou que existe uma situação bastante interessante na questão organização e ciclo de vida do sistema. porém, analisando no aspecto de requisitos, o que poderia melhorar para que esta cena pudesse ser eliminada num processo de software?
Então qual a orientação de vcs já experiente no assunto poderia me repassar?