As 10 maneiras mais comuns de arruinar projetos com XP e Scrum

Povo, antes de mais nada quero me desculpar pela demora do novo post, nesta última semana o bicho pegou e não sobrou tempo para muita coisa. Agora, falando sobre o assunto do dia, na semana passada o Guilherme Chapiewski, da globo.com, postou em seu blog um resumo sobre a apresentação do Henrik Kniberg, que ocorreu na Agile 2008 Conference em Toronto/Canadá.

Na apresentação, Henrik Kniberg falou sobre "as 10 maneiras mais comuns de arruinar projetos com XP e Scrum". Lendo o resumo do Guilherme, cheguei a conclusão que, com as devidas adaptações de contexto, as tais 10 maneiras se aplicam a praticamente qualquer projeto de desenvolvimento de software, mesmo que não seja utilizada uma metodologia ágil para o desenvolvimento. Vou colocar as minhas considerações logo abaixo de cada item do resumo do Guilherme(em itálico).

Resumidamente, as 10 maneiras mais comuns de arruinar projetos com XP e Scrum são:

• Futilidades: debates homéricos sobre coisas como “vamos usar cartões ou post-its” quando o time sequer tem um Product Owner! Os problemas devem ser atacados em ordem de importância. Além disso, a aplicação do processo não precisa ser perfeita desde o início. Good enough is good enough.
  

Em outras palavras, a prioridade sempre deve ser para o que é mais importante. Quem nunca ouviu "faz o cadastro 123AABB e depois o cálculo" ou "começa a adiantar o código, e depois você vê direitinho com o cliente como vai funcionar". Nesses dois casos o mais importante está sendo deixado de lado ou postergado, este tipo de atitude invariavelmente leva a retrabalho e dor de cabeça.

• Definition of Done: muitos times não têm uma definição de pronto ou não respeitam essa definição. Isso não só é essencial como também é preciso que o cumprimento desta definição esteja dentro do controle do time.

Em scrum e xp existe um conceito muito interessante, que é a "definição de pronto". Esta definição é a referência para que os desenvolvedores possam dizer que algo está pronto. Isso evita que alguns desenvolvedores mais preguiçosos façam a programação correndo, com o famoso teste "compilou? beleza" e liberem para a equipe de qualidade.

• Velocidade: não é conhecida, usada ou é muito variável ao longo das iterações.

Métricas em desenvolvimento software ainda é algo muito complicado e as vezes polêmico, mas necessário. Para medir velocidade em scrum e xp, a métrica mais conhecida e utilizada é a de "story points", mas pode-se utilizar outras métricas, como a APF por exemplo. O ponto que quero chegar é, para poder melhorar é preciso ter uma medida de desempenho, fazendo uma rápida analogia, trabalhar sem uma métrica de velocidade é como estar em uma corrida de fórmula 1 sem cronômetro e velocímetro.

• Retrospectivas: não há retrospectivas e o time não evolui suas práticas ao longo do tempo aproveitando-se dos aprendizados obtidos nas iterações.

Aqui entra o lance do feedback, apesar de algumas pessoas acreditarem que essas reuniões são puro desperdicio de tempo, as reuniões de retrospectiva são muito importantes pra se buscar e obter feedback individual e coletivo. A equipe precisar ter um momento para analisar o ciclo, absorver novos conhecimentos e evoluir.

• Comprometimento do time: time é cobrado e sempre culpado por erros em estimativas. Isso faz com que eles sempre se comprometam com menos do que podem fazer, com medo de serem culpados novamente.

Temos que pensar que em 99,9% dos casos, ninguém gosta de errar, ninguém erra de propósito e que desenvolvedor não tem bola de cristal. Estimativa é só isso, estimativa, óbvio que estourar um prazo não é legal, mas acontece e com o passar do tempo há um refinamento nas estimativas. Exigir que os desenvolvedores sempre acertem as estimativas provoca comportamentos indesejados, como exagerar nas estimativas, trapacear na apuração dos tempos de tarefas, enrolar até dar o tempo previsto para a tarefa, etc.

• Débito técnico: é totalmente ignorado e só cresce ao longo das iterações.

Débito técnico são aquelas coisas "bizonhas" que aparecem na arquitetura de um software, que precisam ser re-estruturadas para ser possível trabalhar o código. Normalmente é o resultado do uso recorrente de marretadas. O problema é quando o software nunca é re-estruturado, nesse caso a empresa só perde dinheiro porque qualquer implementação ou manutenção fica díficil de fazer, até que se chega em um ponto onde o software precisa ser jogado fora e feito novamente a partir do zero.

• Trabalho em equipe: não há trabalho em equipe e existem tarefas fixas para determinadas pessoas, o que faz com que várias histórias sejam implementadas em paralelo.

Além do desenvolvimento em paralelo, que já faz com que a entrega de funcionalidades demore mais, a falta de trabalho em equipe cria "donos" de códigos, e isso gera muitos efeitos maléficos na organização como: códigos indecifráveis que apenas uma pessoa consegue trabalhar, a empresa fica réfem do "cara" que sabe tudo de uma coisinha só, surgem gargalos no desenvolvimento porque apenas uma pessoa consegue trabalhar com determinado assunto, não existe troca de conhecimento, etc.

• Product Backlog: não existe ou não está priorizado corretamente.

Uma vez um professor me disse a seguinte frase: "_Ahhh, muitas vezes é aquele negócio né? O último cliente que entra na sala com o pé na porta e gritando é o primeiro a ser atendido". Acho que isso ilustra perfeitamente a falta de um backlog(lista de pendências do produto) devidamente priorizado de acordo com as prioridades de negócio da empresa.

• Integrações da base de código: não existe um branch onde o código pode ser lançado em produção a qualquer momento e a gerência da base de código não é agil.

O impressionante mesmo, é ver que há empresas de desenvolvimento que já transformaram essa deficiência em política da empresa. Ilustrando com um exemplo: O cliente encontra um bug crítico no sistema e precisa de uma correção urgente, a resposta padrão é: "_Ahhh, infelizmente só poderemos estar liberando a versão que estará corrigindo o seu problema no final do mês, que é quando estaremos fechando versões".

• Sprint Backlog/quadro de tarefas: não existe, está longe do time, é muito complicado ou não é usado durante o Daily Scrum e atualizado diariamente.

Essa é exclusiva de quem trabalha com scrum e xp, mas, seria mais ou menos o mesmo que ter um project que nunca é atualizado. Nesse caso, não ter nada já é melhor.

Achei muito legal essa lista, principalmente porque ilustra a maioria dos problemas que já observei em desenvolvimento de software, seja com metodologias tradicionais, metodologias ágeis ou mesmo sem nenhuma metodologia.