Essa é a tradução para português-brasileiro da apresentação do Henrik Kniberg entitulada "Technical Debt - how not to ignore it" apresentada no Agile 2008 em Toronto.

1. Dívida Técnica
Como não ignorá-la
Agile 2008
Toronto
Henrik Kniberg - Crisp AB
Mentor de Agile & cara de Java
Co-fundador / CTO de Goyada (serviços de mobile)
30 desenvolvedores
Arquitetro-chefe na Ace Interactive (jogos)
20 desenvolvedores
Chefe de desenvolvimento na Tain (jogos)
40 desenvolvedores
henrik.kniberg@crisp.se
+46 70 4925284
Tradução: Demetrius Nunes (www.demetriusnunes.com)

2. Metáfora por Ward Cunningham (OOPSLA 1992?)
O que é Dívida Técnica?
Qualquer coisa que atrasa o desenvolvimento
Por exemplo, quebrar as regras do Kent Beck para Código
Simples
1. Executa todas os testes corretamente
2. Não contém duplicação
3. Expressa todas as idéias que tivemos sobre o programa
4. Minimiza o número de classes e métodos
Outros exemplos:
Não consertar o build
Rotinas manuais e ineficientes de lançamento de versões
Henrik Kniberg 2

3. Quase todo mundo tem
Por que é um problema? Acaba com planejamento
Acaba com produtos
Acaba com empresas
Pontos Desmotiva todo mundo
restantes
É caro de consertar
400 É um desperdício
Vamos
acabar no
300 sprint 10!
Foi mal, atrasamos!
Com certeza acabamos
200
até o sprint 12! Oops... Vamos acabar
quando estiver pronto!
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Sprint
Henrik Kniberg 3

4. Como se detecta?
Sentimento do
Sentimento do cliente desenvolvedor Métricas
• Duplicação
Funcionalidades ficavam Esse código • Cobertura de testes
prontas muito mais rápido! é vergonhoso! • Tamanho de métodos
& classes
• Velocidade
velocidade
sprint #
Henrik Kniberg 4

5. Por que acontece? Velocidade
Estimada Real
”A gente conserta depois
Pensamento que lançar a versão.” 30 40 35
de curto-prazo
”Tudo TEM que ficar
pronto até o natal.
25 35 30
Pressão & Trabalhem mais!” 20 30 25
falta de ”folga” &
ritmo insustentável ”Não gostamos
de reclamações”
Não falar a respeito Vmax
”Qual o problema
com variáveis
Vreal
velocidade
globais?”
Falta de competência
técnica ”E daí, esse código
já está uma droga
mesmo”
Síndrome da
Janela Quebrada tempo
Henrik Kniberg 5

6. Como evitar? Definição de Pronto
Fale a respeito • .... bla bla ....
• Não há aumento da dívida técnica
Pull scheduling
TDD
Nt
o
Definição de DONE ch cke o
e d ut
ch cke o
e d ut D ne :o
o ! ) S R T G A B t a a re a !
P IN OL: e -re dy le se
W ri t e
D e o it
ps f a ilin g
Burndown
Vmax
t e st
2 d
D A O
C o d e I n t e g r
p D B
c le a n u t e s t
2 d d e s ig n
1 d 0 .5 d
2d
1d
Vreal t n
M igr a io
G U I
s pe c
2d
W r it e
f a ilin g
2 d t e s t
Ritmo sustentável!
1 d 3 d
t ol
o T ap e s
s p ik e
tr y
I m p l. 1 d
2d
m i g ra t i o n
8d
velocidade
W r it e
B a c k o f f ic e f a ilin g
t e s t
L o g in
I n t e g r .
I m pl
G U I
2 d
U la d it e s
np nne m N xt
e
1 d
w it h
J B o s s
2 d
F ix m
e m o r w
P W i e t i t h d t r e a st
W r h fd r a w
y
W r it e l e ak S a l e s s u ppo r t
W r i( t J e I
f a ilin g R A 1 2
Bc k o ffic e
a t e s t
3 d
f a i2 l i d n g
t e s t
5 )
3 d Writ e
w h it e p a p e r
U s e r a d m in 4 d
G U I C la r if y
d e s ig n I m pl
r e q u ir e -
( C SS) G U I
m e n t s
1 d 2 d 6 d
tempo
Henrik Kniberg 6

7. O que fazer a respeito?
Opção 1: Ignorar
Deixe o sistema decair até a morte por entropia e reze pra que
ninguém precisa mais dele até lá.
Como saber que não
Opção 2: Refazer Arriscado! Caro!
irá acontecer de novo?
Refaça o sistema do zero usando TDD
e outras boas práticas de engenharia. Não gera Não conserta
aprendizado. o processo
Opção 3: Resolva pontualmente
Um time separado e dedicado
conserta os problemas. Abordagem
preferida
Opção 4: Melhoria incremental
Conserte um pouco a cada sprint, enquanto ainda entrega-se
valor de negócio e funcionalidades
... ou “Sprints de Refatoramento” dedicadas de vez em quando
Henrik Kniberg 7

8. Lidando com dívida técnica
Segundo passo
Vmax (se for economicamente viável)
Vreal Reduza ainda mais
Primeiro passo Comece a pagar a dívida!
Reduza o ritmo
velocidade
Pare de acumular dívida técnica!
Ritmo sustentável
Definição de Done Definição de Done
• .... bla bla .... • .... bla bla ....
• Não há aumento da dívida técnica • Dívida técnica diminui
tempo
Fale
a respeito!
Henrik Kniberg 8

9. Conserte o processo, não apenas o produto!
Problemas técnicos são sintomas de problemas de processo
Quando um defeito passar e entrar numa versão
Conserte o defeito
Analise a causa do defeito
Melhore o processo para reduzir o risco desse tipo de defeito ocorrer novamente.
Exemplo: Servidor de produção cai quando mais de 100 usuários se logam
Pergunta Resposta Melhoria
Por que o servidor caiu? SessionHandler usa pool de Rejeite requisições de forma amigável
conexões com tamanho 100 quando pool de conexões estiver cheio
Por que o bug não foi detectado Não existem testes de Escreva testes de performance
antes de lançar a versão? performance automatizados automatizados
Por que os testes não foram Ninguém sabia como fazer Dê tempo ou treinamento para que as
escritos antes? pessoas aprendam
Por que o time não tirou tempo Muita pressão no time Reduza pressão reduzindo escopo do
para aprender? projeto. Introduza pull scheduling
Henrik Kniberg 9

10. Backlog de automação de testes
Passo 1: Liste seus testes
Alterar o skin
Alerta de segurança
Histórico de transações
Bloquear conta
Adicionar usuário
Ordenar resultado de consulta
Depositar dinheiro
Validar transferência
Henrik Kniberg 10

11. Backlog de automação de testes
Passo 2: Classifique cada teste
Caso de Custo de Testes Custo de
Risco
teste Manuais Automação
Alterar skin baixo 0,5 hrs 20 pt
Alerta de
segurança
alto 1 hrs 13 pt
Histórico de
transações médio 3 hrs 1 pt
Bloquear
conta alto 5 hrs 0,5 pt
Adicionar
usuário baixo 0,5 hrs 3 pt
Ordenar
consulta
médio 2 hrs 8 pt
Depositar
dinheiro
alto 1,5 hrs 1 pt
Validar alto 3 hrs 5 pt
transferência
Henrik Kniberg 11

12. Backlog de automação de testes
Passo 3: Escolha suas prioridades e ordene a lista
Caso de Custo de Testes Custo de
Por exemplo, priorize por: teste
Risco Manuais Automação
1. Custo de testes manuais
2. Risco Alterar skin baixo 0,5 hrs 20 pt
3. Custo de automação
Alerta de
segurança alto 1 hrs 13 pt
Histórico de
transações médio 3 hrs 1 pt
Bloquear
conta alto 5 hrs 0,5 pt
Adicionar
usuário baixo 0,5 hrs 3 pt
Ordenar
consulta
médio 2 hrs 8 pt
Depositar
dinheiro
alto 1,5 hrs 1 pt
Validar alto 3 hrs 5 pt
transferência
Henrik Kniberg 12

13. Backlog de automação de testes
Passo 4: Automatize alguns testes a cada sprint
Caso de Custo de Testes Custo de
Exemplos: Risco
teste Manuais Automação
“A cada sprint vamos implementar testes
automatizados para uma funcionalidade" Alterar skin baixo 0,5 hrs 20 pt
“A cada sprint vamos implementar até 10 Alerta de
pontos de testes automatizados" segurança alto 1 hrs 13 pt
“A cada sprint vamos gastar até 10% do Histórico de
nosso tempo automatizando testes" transações médio 3 hrs 1 pt
“A cada sprint, vamos terminar as Bloquear
conta alto 5 hrs 0,5 pt
funcionalidades novas primeiro, e então
gastar o resto do tempo automatizando Adicionar
usuário baixo 0,5 hrs 3 pt
testes"
Ordenar
“O Product Owner vai colocar no backlog do consulta
médio 2 hrs 8 pt
produto as histórias de automação de testes
Depositar
e priorizá-las como qualquer outra história." alto 1,5 hrs 1 pt
dinheiro
Validar alto 3 hrs 5 pt
transferência
Henrik Kniberg 13

14. Pra lembrar
Fale a respeito!
”Dívida Técnica” é uma ótima metáfora para se
comunicar com não-técnicos!
Pare de acumular dívida!
Não importa o quão ruim já esteja
Conserte incrementalmente!
Decida por um ritmo de pagamento da dívida viável
Evite re-escrever do zero ou tratar pontualmente
CONSERTE O PROCESSO,
NÃO APENAS O PRODUTO!
Henrik Kniberg 14

15. É isso! Perguntas?
15