O documento discute o conceito de dívida técnica, seus sintomas, impactos e formas de tratamento. Apresenta a dívida técnica como uma metáfora para descrever situações onde escolhas no desenvolvimento de software geram necessidade de melhorias futuras. Em seguida, explica como reconhecer, evitar acumular, alertar sobre, amortizar e aprender com a dívida técnica para evoluir em direção à excelência.

1. Dívida Técnica
Sintomas, impactos e a ausência
de contrapartidas
Douglas Siviotti
Outubro de 2018

2. Sobre esta Apresentação
2/47
1. Conteúdo: Dívida Técnica
2. Área/Foco: Engenharia de Software / Gestão
3. Público alvo: Gestores, Clientes e Desenvolvedores
4. Conteúdo relacionado: Refatoração, Gestão Ágil, Testes Unitários, Excelência Técnica
Organização (aproximadamente 40 minutos)
Introdução – O Novo Caminho do Negócio até o Código
Parte 1 – O Custo da Ausência de Contrapartidas: Dívida Técnica
Parte 2 – Tratando a Dívida Técnica em 5 Etapas
Material de apoio desta apresentação:
https://github.com/siviotti

3. Sintomas
comuns
equipe entregando cada vez menos
pontos a cada sprint
estimativas frustradas: o esforço
é sempre maior que o previsto
erros
frequentes em
produção
correção de um bug causa
outros problemas não previstos
incidentes resolvidos e o mesmo
erro voltando a aparecer
muito “To Do” espalhado pelo
código e/ou código morto
dificuldade de evolução ou
incorporação de novas
funcionalidades

4. Título do Slide (Arial 18)
4/47
O Novo Caminho doO Novo Caminho do
Negócio até o CódigoNegócio até o Código
Introdução

5. Título do Slide (Arial 18)
5/47
O que éO que é
CódigoCódigo
Fonte?Fonte?

6. Título do Slide (Arial 18)
6/47
O que éO que é
Negócio?Negócio?

7. Caminho Genérico do Negócio até o Código
7/47
NEGÓCIONEGÓCIONEGÓCIONEGÓCIO
CÓDIGOCÓDIGOCÓDIGOCÓDIGO
ProblemaProblema
SoluçãoSolução

8. Caminho Tradicional do Negócio até o Código (Artefatos)
8/47
NEGÓCIONEGÓCIONEGÓCIONEGÓCIO
CÓDIGOCÓDIGOCÓDIGOCÓDIGOProjetoProjeto
RequisitoRequisito
AnáliseAnálise
Compras online
Vários Produtos
Pedido {
List<Item> itens
}
Item {
Produto produto
}

9. Caminho Tradicional do Negócio até o Código (Papéis)
9/47
NEGÓCIONEGÓCIONEGÓCIONEGÓCIO
CÓDIGOCÓDIGOCÓDIGOCÓDIGOProjetoProjeto
Analista / AD
Analista de
Requisitos
Programador
Cliente
Arquiteto / DBA
RequisitoRequisito
AnáliseAnálise

10. Caminho Ágil do Negócio até o Código
10/47
Cliente
Desenvolvedores
+ Interação
- processo e ferramentas
+ Software
Funcionando
- documentação abrangente
NEGÓCIONEGÓCIONEGÓCIONEGÓCIO
CÓDIGOCÓDIGOCÓDIGOCÓDIGO

11. Quem?
11/47
+ Time
- papéis fixos
- intermediários

12. Título do Slide (Arial 18)
12/47
Inception / Descoberta
Backlog / Planning Poker
História de Usuário
Critérios de Aceite
Simple Design / DDD
Clean Code
Padrões de Codificação
Integração Contínua
Refatoração / Revisão
Testes Unitários / TDD
Comunidades de Práticas
+ Práticas
- artefatos
Como?

13. Título do Slide (Arial 18)
13/47
+ Leve
- prescritivo
+ Entregas
- tempo e surpresas ruins

14. Título do Slide (Arial 18)
14/47
+ Entregas
- tempo e surpresas ruins
+ Leve
- prescritivo
Contrapartida
+ eficiência na definição do problema
+ maturidade e multidisciplinaridade
+ excelência técnica
+ refatoração como parte do processo
+ automação de teste, build e entrega
+ controle de qualidade

15. O Custo da AusênciaO Custo da Ausência
de Contrapartidas:de Contrapartidas:
Dívida TécnicaDívida Técnica
Parte 1

16. O que é uma Dívida?
16/47
É uma coisa da qual você quer se livrar
Se você não fizer nada ela só aumenta (juros)
Quanto mais ela aumenta mais difícil fica de se livrar dela
Querendo ou não você acaba pagando

17. Conceito
17/47
Dívida Técnica é uma metáfora criada para descrever a situação onde
as escolhas (conscientes ou não) feitas em um projeto de software
geram necessidade de melhoria ou ajuste no futuro.
Assim como dívidas financeiras, há um efeito
cumulativo onde o não pagamento aumenta o
endividamento e diminui a capacidade de pagar
a dívida como uma cobrança de juros.
Ward Cunningham

18. Eu não posso te entregar todas
essas funcionalidades
na primeira versão
E cada funcionalidade precisa
ter o que chamamos de
“história de usuário”
Entendi, aqui está uma história:
Me dê todas as minhas
funcionalidades ou eu vou
arruinar sua vida!

19. Origem
19/47
Não dá pra botar só mais essa telinha?
Não tem o que cortar desse MVP
Esses testes não vão caber na Sprint
Se refatorar é por que fez algo errado
Se eu parar pra desenhar eu não entrego
Não dá pra mudar isso agora
O prazo é político

20. Você já terminou o software?
Não, eu ainda estou pagando
a dívida técnica do último
programador que você apressou.
Eu não sei o que isso significa
Bem, isso explica muita coisa

21. Causas (ou Combinação Delas)
21/47
Definição Insuficiente
Pressão do Negócio (Político/Legal)
Lacuna de Entendimento sobre Dívida
Técnica
Alto Acoplamento
Ausência de Suíte/Kit de Testes
Falta de Documentação
Falta de Colaboração
Desenvolvimento Paralelo
Postergação da Refatoração
Ausência de Padronização
Falta de Conhecimento
Falta de Empenho e/ou Motivação
Liderança Fraca em Tecnologia
Especificação de “Último Minuto”

22. Impacto na Qualidade e na Capacidade de Entrega
22/47
Sprint 1Sprint 1 Sprint 2Sprint 2
Dívida
Capacidade
de Entrega Sprint 3Sprint 3
Dívida
Custo da
Dívida Técnica
Capacidade
de Entrega
Qualidade Qualidade
Qualidade

23. Localização na Carga de Trabalho
23/47
FuncionalidadeFuncionalidade
Valor
Positivo
Arquitetura
Infraestrutura
Arquitetura
Infraestrutura
DefeitoDefeito Dívida TécnicaDívida Técnica
Valor
Negativo
Visível Invisível

24. Tipos Básicos de Dívida Técnica (Steve McConnell)
24/47
1. Sem Querer – O primeiro tipo de dívida técnica é do tipo incorrido
involuntariamente. Essa dívida técnica é o resultado não estratégico de se fazer
um trabalho ruim.
2. Intencional – O segundo tipo de dívida técnica é do tipo incorrido
intencionalmente. Isso geralmente ocorre quando uma organização toma uma
decisão consciente de otimizar para o presente e não para o futuro.
http://www.construx.com/10x_Software_Development/Technical_Debt/

25. Natureza da Dívida Técnica (Quadrantes do Martin Fowler)
25/47
“Não temos
tempo para
projetar”
“Não temos
tempo para
projetar”
Deliberado
(intencional)
“Vamos lidar
com as
consequências”
“Vamos lidar
com as
consequências”
“O que são
camadas?”
“O que são
camadas?”
“Agora sabemos
como devíamos
ter feito isso”
“Agora sabemos
como devíamos
ter feito isso”
Inadvertido
(sem querer)
Imprudente Prudente
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

26. Categorias Comuns
26/47
1. Código – Complexidade Ciclomática de método acima de 10
2. Documentação – EMS defasado ou ignorado (Mensagens do Sistema)
3. Teste – Testes parcialmente feitos ou desabilitados
4. Arquitetura – Aplicação monolítica e baseada em banco de dados
5. Gap Tecnológico – Aplicação JSF com muitos usuários simultâneos
6. Design – 70% do código na classe de fachada (God Class, Super Façade)

27. Parte 2
27/47
Tratando aTratando a
Dívida TécnicaDívida Técnica
Parte 2
1 2 3 4 5

28. Tratando a Dívida Técnica
28/47
1. Reconheça que a dívida existe e existirá
O pior problema é o que você não sabe que tem
Para saber se existe uma dívida é necessário saber como seria
um software sem a dívida (padrão de qualidade)
1 2 3 4 5

29. Quatro Regras da Simplicidade (Kent Beck)
29/47
● Todos os testes passam
● Claro, Expressivo e Consistente
● Nenhuma duplicação de
comportamento ou configuração
● Métodos, classes e módulos mais
simples possíveis (minimalistas)
1 2 3 4 5

30. Tratando a Dívida Técnica
30/47
2. Tente não contrair mais dívida
Tá no buraco? Pare de cavar! (Não pague dívida com cartão de crédito)
Simplesmente pare de fazer código ruim, se isso for possível
1 2 3 4 5

31. Não Deixa Nenhuma Janela Quebrada
31/47
Nenhuma
Janela Quebrada

32. Simplesmente Pare de Fazer Código Ruim
32/47
1 2 3 4 5

33. Tratando a Dívida Técnica
33/47
3. Se há juros embutidos, alerte!
Quem dá a missão dá os meios – Quem cala consente
O combinado não é caro nem barato
Se uma dívida é parte inerente de um produto ela também deve
ser parte natural do custo e deve ser prevista
1 32 4 5

34. Saber do perigo é o primeiro
passo para evitá-lo

35. Crédito Técnico
35/47
Concepção Construção
Dívida
Técnica
Crédito
Técnico
Sprint “Zero” ou encanamento eficiente
Componentes e infra são parte do escopo
Coisas simples/estáveis são adiantáveis
Integrações especificadas o quanto antes
Reconstrução dependente do legado
Novos “Macrossistemas” ou “Portais”
Restrições contratuais e/ou legais
Integração/dependência de terceiros
Prova de
Conceito
Protótipo
Adequação
1 32 4 5

36. Tratando a Dívida Técnica
36/47
4. Acostume-se com a amortização
O barato sai caro
O custo de ignorar ou postergar tarefas aparentemente
secundárias (refatoração, testes, padronização etc) pode ser
maior do que elas no futuro, pois a dívida cobra juros
1 42 3 5

37. trabalho de
formiguinha

38. Análise Estática com Refatoração
38/47
ConstruçãoConstrução
Análise EstáticaAnálise Estática
Issues?Issues?Não
RefatoraçãoRefatoração
Sim
Tratar?Tratar? Não
Dívida TécnicaDívida Técnica
Sim
Se a dívida técnica é inevitável a refatoração não é opcional
1 42 3 5

39. Dívida de Código na Ferramenta de Análise Estática
39/47
1 42 3 5

40. Testes de Unidade com Refatoração
40/47
ConstruçãoConstrução
Teste de UnidadeTeste de Unidade
Foi difícil?Foi difícil?Não
RefatoraçãoRefatoração
Sim
Simplificar?Simplificar? Não
Dívida TécnicaDívida Técnica
Sim
Teste de unidade é uma atividade de construção que acaba fazendo verificação
1 42 3 5

41. Item de Dívida Técnica como Parte do Backlog
41/47
Valor
Positivo
Valor
Negativo
FuncionalidadeFuncionalidade Arquitetura
Infraestrutura
Arquitetura
Infraestrutura
DefeitoDefeito Dívida TécnicaDívida Técnica
Visível Invisível
COLE
PUXE
“Backlog Técnico”
Siga a regra
dos escoteiros
1 42 3 5

42. Tratando a Dívida Técnica
42/47
5. Aprenda, evolua e busque a excelência
Os erros ensinam o que só os erros ensinam
O processo de aceitar, entender e tratar dívida técnica é uma
oportunidade única de aprender de forma eficiente e prática
sobre como desenvolver software
1 52 3 4

43. Ciclo Contínuo de Evolução
43/47
AferiçãoAferiçãoPadrão de
Qualidade
Padrão de
Qualidade RefatoraçãoRefatoração
TransparênciaTransparência BacklogBacklogExcelênciaExcelência
1 52 3 4

44. Ciclo Contínuo de Evolução
44/47
AferiçãoAferiçãoPadrão de
Qualidade
Padrão de
Qualidade RefatoraçãoRefatoração
TransparênciaTransparência BacklogBacklogExcelênciaExcelência
Reconheça
Evite
Alerte
Amortize
Aprenda, evolua e busque a excelência
1 52 3 4

45. “O que vale a pena ser feito vale a pena ser bem feito”
Excelência é um
objetivo e um meio
dívida técnica é a oportunidade
de aprender através de um
“curso” pelo qual você já pagou
excelência depende do índice HBC

46. Referência
46/47
CUNNINGHAM, Ward. Ward Explains Debt Metaphor, http://wiki.c2.com/?WardExplainsDebtMetaphor
FOWLER, Martin. TechnicalDebt, https://martinfowler.com/bliki/TechnicalDebt.html
HUNT, Andrew; THOMAS, David, O Programador Pragmático,
MARTIN, Robert, O Codificador Limpo, Alta Books, Rio de Janeiro 2012
MARTIN, Robert, Código Limpo, Alta Books, Rio de Janeiro 2011
McCONNELL, Steve, Technical Debt, http://www.construx.com/10x_Software_Development/Technical_Debt/

47. Obrigado!
Douglas Siviotti de Alcantara
douglas.siviotti@gmail.com
github.com/siviotti
Material de apoio desta apresentação:
https://github.com/siviotti