O documento discute a dívida técnica em sistemas de software, como ela ocorre e como afeta projetos ao longo do tempo. A dívida técnica surge quando decisões de design e código de baixa qualidade são tomadas, e seus efeitos se acumulam como juros em um empréstimo. É importante reconhecer e priorizar a redução da dívida técnica para evitar custos crescentes no futuro.

1. Gustavo Cocina
https:www.linkedin.com/in/gustavo-cocina-08b9568
Junho/2016

2.  “Conforme um sistema é continuamente
modificado, sua complexidade, que reflete
sua estrutura deteriorada, aumenta a menos
que um trabalho seja feito para mantê-la ou
diminuí-la.”
Meir Lehman, em 1980
Estudioso da evolução do software
Leis de Lehman

3.  Pegar dinheiro emprestado pode
ser ótimo para realizar coisas em
pouco tempo.
 Mas você precisa pagar a dívida, senão os
juros se acumulam e se incorporam ao
principal.
 Fica cada vez mais caro pagar
juros sobre juros.

4.  Quando se adota um design técnico de baixa
qualidade, é como se você estivesse pegando
dinheiro emprestado.
 É bom para entregar software mais cedo e
obter benefícios para o negócio.

5.  Mas é preciso pagar a dívida, senão
desenvolver novas funcionalidades requer
esforço extra.
 Isso aumenta o custo e o tempo de novos
projetos, demandas e correções de erros,
além de ter sistemas engessados
que requerem técnicos especialistas.

6.  Ward Cunningham, em 1992.
 Criador da tecnologia wiki.
 Contribuidor e pioneiro em design patterns e
eXtreme Programming.
 Signatário do ManifestoÁgil.

7. Visível Invisível
FUNCIONALIDADE ARQUITETURA
BUGS DÍVIDATÉCNICA

11. Pressões do
negócio
Decisões de design
e codificação
Ausência de processo
e entendimento
Alto
acoplamento
Ausência de
roteiro de teste
Ausência de
colaboração
Desenvolvimento
em paralelo
Postergação do
refactoring
Desalinhamento a padrões
de indústria
Falta de
conhecimento
Ausência de
propriedade
Liderança
técnica ruim
Mudanças
tardias
Redução
de escopo
Não é possível planejar seu surgimento. Elas vão “pipocando” com o tempo.

12. Custodamudança(CoC)emtempoe$$$
Anos
Dívida
técnica
CoC
ideal
CoC
atual
Responsividade daTI ao negócio e
satisfação do cliente

14. O time não tem tempo
para o design e utiliza
uma solução rápida e
com pouca preocupação
com qualidade
IntencionalSem-querer
“Nós não temos
tempo para design”
O time precisa entregar
o produto agora com as
limitações conhecidas e
assume de maneira pró-
ativa as conseqüências.
O time não tem
consciência dos
princípios básicos de
design de software e
nem sequer imagina a
bagunça que estão
adicionando no sistema.
Time com excelentes
desenvolvedores.
Fornecem uma solução
que agrega valor ao
negócio mas entendem
que a abordagem
poderia ter sido melhor
Irresponsável Prudente
“Precisamos
entregar agora e
lidar com as
consequências.”
“O que são
camadas ?”
“Agora nós
sabemos como
devemos tê-lo
feito…”

15.  Martin Fowler, em 2009.
 Autor conhecido na área de arquitetura,
análiseOO, UML, design patterns e
desenvolvimento ágil.
 Signatário do ManifestoÁgil.

16.  “Ter débitos técnicos em um projeto é inevitável
e deve ser considerado como uma expectativa.”
 “A chave está em conscientizar o time para que
não seja introduzindo débitos técnicos
irresponsáveis, que podem ser muito difíceis de
pagar no futuro.”
Vikas Hazrati
Knoldus Software

17.  Um débito técnico bloqueia outro requisito?
 Compromete a entrega?
 Gera danos ao negócio?
Software correto > fazer software corretamente
Software é incerto por natureza

18.  Já estamos pagando juros cada vez que
precisamos iniciar um novo projeto, demanda
pontual, analisar um incidente ou requisição
de serviço.

19. Incidentes (ITIL) de sistemas de jan/15 a dez/15 por LOC
Os pontos azuis representam sistemas. Seus nomes foram ocultos para manter o anonimato da companhia.

20. Requisições de Serviços (ITIL) de sistemas de jan/15 a dez/15 por LOC
Os pontos azuis representam sistemas. Seus nomes foram ocultos para manter o anonimato da companhia.

21.  1. Conheça a dívida técnica atual.
 2. Evite novas dívidas.
 3. Priorize a redução de débitos ao passar
sobre eles.

22.  “Podemos optar por continuar pagando estes
juros ou quitar de vez a dívida, fazendo uma
refatoração, e transformando um design de
baixa qualidade em um design melhor.”
 “Apesar dos custos pra saldar a dívida, nós
ganhamos reduzindo os juros no futuro.”
Martin Fowler

23.  Sintomas que indicam probabilidade de
problemas maiores.
Martin Fowler
 “If it stinks, change it.”
Kent Beck
Signatário do Manifesto Ágil

25. Trechos ocultos para manter o anonimato da companhia

31.  Legado e DébitoTécnico, por Odair Bonin
 Sorry, não tenho uma fonte pública para esse ótimo trabalho.
 Métricas de Incidentes e Qualidade de Desenvolvimento Java: por
Gustavo Cocina, Samuel Rezende, Bruno Carneiro e Alexandre Canhoto
 Uso interno.
 Qualidade de Desenvolvimento em Banco de Dados, por Gustavo Cocina
e Fabio Cortez
 Uso interno.
 TheWyCash Portfolio Management System, porWard Cunningham
 http://c2.com/doc/oopsla92.html
 Debt Metaphor, porWard Cunningham
 http://www.youtube.com/WardCunningham#p/a/E95B31B1A940296B/2/pqeJFYwnkjE

32.  Technical Debt, por Martin Fowler
 http://martinfowler.com/bliki/TechnicalDebt.html
 Technical Debt Quadrant, por Martin Fowler
 http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
 DívidaTécnica, por Alexandre Freire
 http://pt.slideshare.net/alexandrefreire/divida-tecnica
 ManagingYourTechnical Debt, por Danilo Sato
 http://pt.slideshare.net/dtsato/managing-your-technical-debt-agilebrazil-2011
 Technical Debt
 https://en.wikipedia.org/wiki/Technical_debt

33.  Code Smell
 https://en.wikipedia.org/wiki/Code_smell
 Design Smell
 https://en.wikipedia.org/wiki/Design_smell
 Praticando o Desapego: quando ignorar a dívida técnica, por Ivayr Farah
Netto
 http://pt.slideshare.net/nettofarah/praticando-o-desapego-quando-ignorar-a-dvida-
tcnica
 As 8 leis de Lehman foram o Manifesto do séculoXX, por Jorge Horário
Audy
 http://ww2.baguete.com.br/colunas/jorge-horacio-audy/17/04/2014/as-8-leis-de-
lehman-foram-o-manifesto-do-seculo-xx