Métodos ágeis já passaram de tendência a realidade dentro do desenvolvimento de software. Não vou retratar aqui o uso de métodos ágeis ou ainda seus benefícios, mas sim tentar explanar um dos maiores causadores do fracasso de métodos ágeis, a Customização Prematura.
Realmente não sou um grande pensador de métodos ágeis, e nem tenho tanto assim a acrescentar sobre o assunto (nada que já não tenha se falado), mas sim quero apenas levar as pessoas a entender o que as vezes fica obscuro no dia a dia.
Vamos iniciar com um raciocínio simples.
Qualquer que seja o método ágil adotado (XP, Scrum, “coloque aqui sua favorita”) ele foi criado agregando diversas práticas que servem como ferramentas para sucesso da metodologia(não gosto desta palavra 
). Seguidos obviamente de incansáveis testes, ajustes, e remanejos por pessoas que sabiam muito sobre o que estavam fazendo.
É muito comum encontrar empresas que ao implantar métodos ágeis, fazem as customizações necessárias para encaixa-la a sua realidade, e este por sua vez pode ser um dos grandes causadores do fracasso desta implantação.
Como disse anteriormente, métodos ágeis são criados agregando necessidade e práticas de sucesso. Práticas essas que dentro de um contexto geral da metodologia complementam umas as outras, foram pensadas para trabalharem juntas, e só assim trazerem um bom resultado.
Um exemplo que vemos acontecer bastante é com a adoção de XP, sem utilizar o pair programming.
O XP foi concebido por grandes pensadores, que utilizaram esta metodologia por muito tempo e provaram seu valor. Porém provaram seu valor utilizando o pair programming.
Então pegamos como exemplo uma empresa que entra no mundo agile com XP, e a primeira coisa que faz é retirar esta técnica da metodologia interna alegando a elevação do custo do desenvolvimento ao ter dois programadores trabalhando na mesma coisa.
Independente do custo ou ainda da motivação do uso da prática de pair programming, esta foi adicionada a metodologia por trazer um benefício dentro do contexto que está sendo trabalhada em XP, e fazendo dela necessária para este contexto.
Retira-la da metodologia, sem nem ao menos entender sua necessidade pode ser um grande erro. É o mesmo que vender um carro sem os espelhos para diminuir o custo de produção. A primeira vista pode parecer lucrativo, mas em um contexto geral isso vai fazer diferença.
Brincadeiras a parte, não sou bom em fazer comparações.
Customizar uma metodologia não é uma má prática. Mas fazer isso sem o devido conhecimento pode e provavelmente vai trazer sérios problemas.
Acredito que uma equipe para chegar ao nível de poder customizar, ela já deve no mínimo ter trabalhado em alguns projetos utilizando de todos os artifícios e aspectos provenientes desta prática. E só assim, após um bom embasamento e alguma experiência poder discutir e decidir que alguma coisa pode não ser mais necessária para um determinado cenário.
Talvez o grande problema disso tudo seja saber quando estaremos prontos para a customização, mas isso já é assunto para outro post.
E você, o que acha ?
