Com o boom nacional das metodologias ágeis, um movimento formado por seus entusiastas vem crescendo vertiginosamente em torno de novos conceitos sobre processos de desenvolvimento de software. Portanto, se você faz parte desse universo, ou mesmo se apenas circula em âmbitos relacionados, cedo ou tarde irá deparar com esse tema.

Mais do que isso, é possível que você acabe sendo abordado de forma a rapidamente acreditar que seu time de desenvolvimento também deve encarar essa inevitável mudança e adotar uma Metodologia Ágil – Agile or die, afirmam os evangelistas.

Afinal de contas, se até mesmo gigantes como Google, Nokia e Yahoo! absorveram essa filosofia em suas operações, essa não é apenas a solução para seus (eventuais) problemas de produção, mas também uma clara evolução em termos de gestão operacional e conceitos estratégicos. Correto?

Talvez sim. Ou talvez não. Acontece que há diversas outras perguntas a serem formuladas (e devidamente respondidas) antes de se optar pela adoção (ou não) de uma Metodologia Ágil. E, infelizmente, a exposição de diversos insucessos na implantação de Agile tem nos mostrado que essas perguntas e suas respectivas respostas não têm sido devidamente postas na mesa previamente, ou pelo menos não de forma clara e objetiva.

O motivo? Embora incorra o risco de ser tachado de advogado do diabo, atrevo-me a dizer que, em boa parte dos casos, essa série de insucessos se deve a uma certa afobação por parte dos agentes da mudança, que, seduzidos pela suposta simplicidade do Agile, por termos como flexibilidade, framework intuitivo e equipe autogerenciável, e sobretudo pelo fator cool que se desenvolveu em torno de todo esse movimento (fato notório, é uma metodologia na moda), tratam de abraçar a causa das metodologias ágeis sem ao menos se respaldarem com um bom estudo preliminar que responda por que mudar, o que mudar e como mudar.

Perguntas com as quais se pode esclarecer se Agile se adequará ao seu cenário, se dará respaldo às estratégias organizacionais, se atenderá o seu tipo de projeto, se suportará o tamanho e a capacitação da sua equipe, se será bem aceito pelos clientes, investidores ou patrocinadores, se irá gerar ROI positivo ou vantagem competitiva. E, em especial, se sua aplicação poderá tornar mais eficaz e/ou mais eficiente o seu processo de desenvolvimento de software.

Em resumo, como tem sido ressaltado por diversos especialistas, é preciso entender que Agile não se adequa a quaisquer cenários e estratégias corporativas.

Mas não apenas isso: percebe-se também que, por vezes, certas equipes têm dilatado o conceito de flexibilidade, encarando Agile como uma forma de isentarem-se de disciplina e comprometimento. E, como são baseadas em (apropriadamente) poucos valores e princípios, pequenas rupturas no processo das metodologias ágeis podem causar um grande desvio em sua aplicação.

Por isso, depois de uma boa análise sobre todas as questões levantadas anteriormente, caso se opte pela implantação de Agile, é preciso construir uma infra-estrutura sólida para a atualização do processo. Essa mudança exige alinhamento prévio entre os gestores estratégicos e o time operacional, incluindo aqui não apenas os personagens do time de desenvolvimento, mas também de outros níveis da organização.

Negócio e Operação precisam estar sincronizados, resultando em uma mudança cultural que é indispensável para qualquer tipo de mudança de tamanho impacto (e essa talvez seja uma das barreiras mais difíceis de ser transpostas).

É preciso mais que predisposição, é preciso comprometimento de todos, é preciso atitude. Por isso, não há como simplesmente empurrar esse tipo de mudança para cima de ninguém. Pelo contrário, você deve conquistar o grupo através da fomentação da metodologia, e com enfoque não apenas nas potencialidades, mas também nas deficiências mais comuns registradas, para que vocês não escorreguem em problemas já identificados.

Então, apenas após o comprometimento de todos, parte-se para etapas mais avançadas da implantação, que podem ser divididas, por exemplo, em elaboração do plano de projeto, redesenho de processos, definição de papéis e escolha de ferramentas, culminando em treinamentos e capacitação da equipe (se possível com estudo de cases e aplicação da metodologia definida em um projeto piloto), até que, finalmente, haja a maturidade necessária para o início das atividades de acordo com o novo processo.

Lembrando, é claro, que devem ser definidas métricas, para que o processo seja medido e melhorado constantemente. Autocrítica é impreterível.

.

Ânderson Quadros

<strong>Ânderson Quadros</strong> (anderson@neexpmo.com) é gerente de projetos e analista de governança de TI.