A área de TI sempre teve dessas coisas: disputas entre defensores de tecnologias, métodos ou marcas diferentes. Linux vs. Windows, IBM vs. Microsoft, C++ vs. Java, JEE vs. “pontoNet”. A briguinha do momento chama-se “Àgil” vs. Planejamento (ou Ágil vs. RUP).
Se nos pautarmos pelos posts em blogs, redes sociais, revistas teremos a nítida impressão que encontramos a tão sonhada “bala de prata” que desde tempos imemoriais (em termos de Informática) atormenta os gerentes de desenvolvimento. Aparentemente, os métodos ágeis vêm ganhando de goleada.
Independente de quem está vencendo, imagino que muitos gerentes devem se perguntar: o que é necessário para aplicar uma metodologia ágil? A sua adoção com sucesso pode ser obtida de maneira rápida?
Entendo que há alguns critérios a serem avaliados antes de se adotar Gestão Ágil de Projetos. Vou tentar colocar aqui um checklist bem informal. Mas antes, vamos relembrar os princípios essenciais do Manifesto Ágil
– Pessoas e Interações (comunicação) devem prevalecer sobre Processos e Ferramentas.
– Software Funcionando deve prevalecer sobre Documentação Abrangente (ou seja, documentação pesada).
– Colaboração com o Cliente deve prevalecer sobre Negociações Contratuais.
– Resposta a Mudanças deve prevalecer sobre Seguir um Planejamento.
À primeira vista, da maneira como é escrito, ele me lembra aqueles movimentos panfletários da juventude, em prol de “um mundo melhor”, mas sem grandes efeitos práticos. O problema é que muitos desenvolvedores mais radicais lêem o manifesto e têm a impressão que não existe documentação, ou processo, ou planejamento. Eu discordo. Para mim isto é uma interpretação literal e grosseira do manifesto.
Vejam: o Manifesto expressa que os aspectos do lado esquerdo devem se sobrepor aos outros, mas não que os últimos devam desaparecer da face da Terra, como querem alguns agilistas mais radicais.
Deve-se tomar cuidado ao decidir por este caminho. E o próprio manifesto nos dá o caminho das pedras para essa decisão. Assim, seguem-se alguns aspectos que poderiam ser considerados numa transição para uma metodologia ágil. Essa lista foi baseada no artigo “Using Risk to Balance Agile and Plan-Driven Methods”, de Barry Boehm e Richard Turner.
Objetivo e criticidade do Projeto – quão crítico é o software para a Organização que irá utilizá-lo? Quais os impactos de uma falha ou defeito grave? Vidas podem ser perdidas? Pode haver altas perdas financeiras? A resposta a essas perguntas orientam o nível de formalização de processo, as necessidades de formalização contratuais, direcionam o grau de documentação a ser adotado e os controles necessários na gestão de mudanças.
Tamanho e Complexidade do Projeto – aqui, tocamos indiretamente numa pergunta muito comum e que tem gerado uma “sub-discussão”: arquitetura versus agilidade. A idéia ágil pura preconiza que a Arquitetura da aplicação seja desenvolvida no decorrer do projeto, contra a ideia das metodologias tradicionais que dizem que a arquitetura deve ser desenhada totalmente no início. Ora, se o projeto é relativamente uma “commodity” para a Organização, é provável que ela já tenha soluções conhecidas dentro de casa, seja na forma de “design patterns” ou de conhecimento da equipe. Assim, mesmo que sutilmente, a arquitetura já está no consciente coletivo da equipe. Porém, se a equipe está entrando em águas desconhecidas ou a complexidade do projeto é muito grande, deve-se ter algum desenho de arquitetura o quatnto antes, em aspectos mais críticos. Por exemplo, se utilizarmos o paradigma de 3 camadas e aplicar sobre ele a decisão: se a aplicação requer regras de negócio complexas, faz-se a arquitetura inicial sobre esses aspectos, podendo deixar aspectos de interface com o usuário mais pra frente.
Qualidade e Estabilidade dos Requisitos – sei que alguns mais apressados vão me bater aqui pois quase nunca há estabilidade de requisitos em software. Mas não é bem assim. Projetos de software embarcados (militares ou industriais), por exemplo, devem ter especificações de requisitos mais formalmente documentadas.
Características e Relacionamento com o Cliente – qual o grau de confiabilidade entre as partes? Qual a possibilidade de o cliente manter alguém com uma dedicação quase que exclusiva ao projeto? Qual a maturidade do cliente para priorizar os requisitos do software e evitar o chamado “scope creep”? Pelas características do método ágil, esses pontos devem ser avaliados com muito cuidado. Por exemplo, há possibilidade de o cliente aceitar propostas com escopo aberto?
Prazo do Projeto – este é um ponto que deve ser avaliado principalmente quando se pretende migrar de uma metodologia tradicional para uma metodologia ágil, pois haverá naturalmente uma curva de aprendizado e aculturamento na nova metodologia. Agora, se a organização não tem uma metodologia clara ou os resultados em termos de prazo não são lá essas coisas, esse item tem impacto mínimo na decisão.
Necessidade de Validação Formal e Rastreabilidade – como disse anteriormente, dependendo do tipo de projeto e das características do negócio, pode ser necessária uma validação formal de entregas, além de rastreabilidade futura. Nestes casos, o nível de formalização de documentação e processos deve ser avaliado.
Tamanho da Equipe – existe uma certa controvérsia sobre a escalabilidade de métodos ágeis. Aqui, se a empresa está em transição para este tipo de metodologia, deve-se iniciar praticando com equipes menores.
Maturidade e Aspectos Culturais da Equipe – não se trata de maturidade técnica, mas sim comportamental. Equipes ágeis devem ser autogerenciadas, o que implica entender e avaliar necessidades de negócio com cuidado, evitar perfeccionismo, saber se comunicar e ter abertura para expor problemas e conflitos.
Não tive a pretensão de propor um método nem ser extensivo. Apenas coloquei alguns pontos que devem ser considerados na decisão de se adotar ou não uma metodologia ágil.
Aproveito para passar um link muito interessante com alguns vídeos de depoimentos sobre o uso da metodologia ágil, que é parte de um concurso promovido por uma comunidade de prática do PMI. Os vídeos estão em inglês.
http://agile-pm.pbworks.com/Confessions-of-an-Agile-Project-Manager
Inté mais…
Marcel Fleming 