parte da dívida técnica.
Se ela for ignorada, em algum momento o código pode se tornar tão confuso e
caótico que sua manutenção será prejudicada, aumentando o custo de desenvolvi-
mento e suporte, diminuindo a produtividade do time, aumentando o número de
defeitos devido à alta complexidade e dificuldade de compreensão do código, e fi-
nalmente diminuindo a motivação da equipe, devido à baixa produtividade e alto
número de defeitos. É previsível que, em num cenário como esse, os clientes e usuá-
rios, provavelmente, também não estarão muitos contentes.
O valor da metáfora da dívida técnica está em tornar o time consciente desses
problemas e de como a produtividade pode estar sendo afetada. Se o time fizer um
acompanhamento da dívida técnica, é possível evitar que ela se torne cada vez maior e, em vez disso, trabalhar para pagá-la pouco a pouco.
É importante que a equipe mantenha um backlog de dívida técnica, ou seja, uma
lista de tarefas que podem ser realizadas para melhorar o código, e essa lista pode ser priorizada pelo time e, então, pode-se negociar com o Product Owner para que pouco
a pouco, esses itens sejam incluídos nas iterações.
Poderíamos ter itens como Refatorar Método de 2000 linhas na Classe de Trans-
ferência Bancária, ou Atualizar Biblioteca POI para Versão mais Recente para evitar 88
Casa do Código
Capítulo 4. Entregando Valor
Vazamento de Memória, ou Aumentar Cobertura de Testes do Módulo de Emprés-
timos etc.
Alguns tipos de dívida técnica podem ser deliberadamente deixados de lado, por
não haver valor em resolvê-los. Por exemplo, em casos de produtos próximos ao tér-
mino de seu clico de vida, ou de um protótipo com objetivo único de aprendizagem,
ou produtos com ciclos de vida muito curtos (como projetos para campanhas de
marketing pontuais, por exemplo). É importante que o time foque naquilo que de
fato trará benefícios para a produtividade do time e qualidade do produto.
E então? Seu time está pronto para pagar suas dívidas? Lembre-se que assim
como nas dívidas financeiras, quanto mais tempo levamos para pagar, mais difícil,
porque paga-se com juros.
Nada de Janelas Quebradas
Pesquisas no campo de criminalidade e decadência urbana, descobri-
ram que uma janela quebrada pode rapidamente levar um prédio limpo
e intacto a se tornar um prédio decadente e abandonado [68].
A Teoria da Janela Quebrada afirma que uma janela quebrada, se não
consertada por algum tempo, transmite para as pessoas um senso que
ninguém se importa com o prédio [61]. Então, de repente, outra janela é
quebrada, lixo se acumula, paredes são pichadas, em pouco tempo o pré-
dio fica tão prejudicado que o dono já não consegue mais repará-lo, então
o que antes era apenas um senso de abandono, agora se torna realidade.
Da mesma forma, quando um desenvolvedor deixa um código sem
cobertura testes, por exemplo, o próximo desenvolvedor tem essa sen-
sação que não houve zelo por aquele código, e cria um novo método,
deixando-o sem testar também.
Com o tempo será possível notar uma grande queda na cobertura de
testes, tanto que talvez se torne muito difícil para a equipe reverter o ce-
nário. O mesmo poderia valer para código deixado sem refatorar, ou
qualquer outra má prática de desenvolvimento.
Quando uma janela é deixada quebrada, outra será quebrada, e outra,
e outra... Por isso, não deixe janelas quebrada se achar uma, e nunca seja
o primeiro a quebrar uma janela.
89
4.12. Agilidade Explícita com Mural de Práticas
Casa do Código
4.12
Agilidade Explícita com Mural de Práticas
Nós somos aquilo que fazemos com frequência. Excelência, então, não é um ato, mas
um hábito
Aristóteles
Desculpe-me,
mas eu tenho que dizer: Não é o quadro na parede que faz da sua
equipe uma equipe ágil.
O filósofo grego Aristóteles que viveu há mais de 300 A.C. já reconhecia que nós
somos frutos dos nossos hábitos, das nossas ações frequentes e constantes. Nessa
linha de pensamento, você não pode dizer que é uma pessoa caridosa, só porque
uma vez na vida fez uma doação para uma causa beneficente, não pode dizer que é
uma pessoa aventureira se quando tinha 17 anos de idade pulou de bungee jump no
parque de diversões.
Você também não pode dizer que sua equipe é ágil só porque 1 dos 25 desenvol-
vedores do seu time, uma vez, tentou aplicar desenvolvimento guiado por testes em
seu tempo livre, e nem pode dizer que sua organização tem uma cultura de apren-
dizagem só porque há um espaço para palestras uma vez no ano. De jeito nenhum.
Aristóteles sabia bem do que estava falando.
O ponto é que nós podemos dizer que somos ágeis porque nós estamos frequen-
temente utilizando práticas ágeis e nós podemos dizer que nossa organização tem
uma cultura de aprendizagem porque estamos aprendendo algo novo todos os dias.
Quanto mais eu treino, mais sorte eu tenho.
Tiger Woods
A pergunta é: quais são as práticas que fazem de nós uma equipe ágil? E uma
ferramenta muito simples para ajudar as equipes a se fazerem essa pergunta com