Siga no twitter 
Ontem, na sede da IVIA em Fortaleza, foi promovida uma palestra sobre a introdução às metodologias ágeis, com o título “Metodologias Ágeis: Porquê e Como utilizá-las”. Na palestra, mediado pelo nosso colaborador Marcelo Barros, foi abordado como as empresas de TI convivem com os modelos tradicionais e/ou métodos ágeis.Para que você entenda mais do assunto, fizemos uma entrevista com nosso gerente de projetos, Marcelo Barros. Leia a entrevista:
Blog IVIA - Olá Marcelo! Seja bem vindo a nossa 1ª de várias entrevistas do nosso blog. Então, explique para os leitores do Blog IVIA, o que é a Metodologia Ágil?
Marcelo Barros – Obrigado pela oportunidade. Ok, vamos às respostas. A Metodologia Ágil é um método de desenvolvimento de software que defende um maior foco em mudanças, indivíduos, entregas, e participação ativa dos clientes. É uma alternativa para os chamados “Modelos Preditivos”, em que existe um grande trabalho de planejamento e certa rigidez na documentação e no software. “Modelos Preditivos” acabam dificultando a resposta à mudança e desfavorecendo a adaptação e comunicação.
Blog IVIA – Na palestra foram mostradas algumas técnicas. Você poderia nos dar exemplos dessas técnicas e comentar sobre uma delas?
Marcelo Barros – A principal técnica apresentada na palestra foi o SCRUM, sendo outra técnica muito conhecida, o XP (eXtreme Programming). O SCRUM é um chamado "framework" para gerência de projetos em ambientes seguidores de metodologias ágeis. Este é aplicável em diversos tipos de projetos, não só da área de TI. O SCRUM defende a utilização de iterações curtas, chamadas de “sprints”, e oferece formas bem definidas de gerenciar, definir e ajustar o seu escopo, melhorando e mantendo constantemente a equipe unida e focada. O SCRUM, assim como o próprio conceito de metodologia ágil, é intensamente baseado em retorno de investimento.
Blog IVIA - Quais as vantagens e desvantagens de implementar os métodos ágeis?
Marcelo Barros – A principal vantagem é evitar os problemas já conhecidos de tentar estimar e planejar software em detalhes, atividades que comprovadamente falham. Junto a isso, somam-se os atrativos de se manter uma equipe mais motivada e produtiva, envolver mais pessoas (como o cliente) na tomada de decisão e focar em trabalhos que realmente agregam valor. A desvantagem está em não se ter uma visão detalhada do sistema (uma análise tradicional) antes de começar a construí-lo e depender mais da equipe e de sua produtividade (que passa a ter mais autonomia). Outro problema frequentemente discutido - mais direcionado ao cliente -, é que este não tem uma estimativa de orçamento e prazo tão rígido como no modelo tradicional. Isso pode gerar insegurança em muitos casos.
Blog IVIA – Os métodos ágeis podem conviver “harmonicamente” com os métodos tradicionais?
Marcelo Barros – Sim. Isso não parece claro em princípio, mas a grande maioria dos princípios "ágeis" são totalmente compatíveis com a base dos modelos tradicionais. O grande desafio está na forma de comercialização, já que seguir o modelo tradicional de venda (escopo fechado e preço fechado) limita a forma de aplicação da metodologia ágil. Porém, formas de unir ambas as bases vêm sendo estudadas e já estão disponíveis para os interessados em constante mudança e melhoria.
Blog IVIA – Obrigado, Marcelo Barros! O Blog de notícias IVIA agradece a sua participação em nosso site, explicando melhor sobre esses métodos tão em voga no momento.
Marcelo Barros - Agradeço ao Blog IVIA pelo convite, e a IVIA Educação pelo apoio na realização do evento. Contem comigo em próximos bate papos!
3 comentários:
Palestra muito interessante e bem direcionada. Valeu Marcelo pela ótima condução de tudo e pelo conhecimento compartilhado!
Abraço a todos da IVIA
Olá,
gostaria de parabenizar ao post. Acho que a forma descontraída de se falar tenta melhorar a comunicacao, e comunicação é um dos valores das metodologias ágeis.
Gostaria de fazer uma pergunta ao entrevistado, Marcelo Barros, no tocante sobre como os metodos ágeis podem 'conviver' com os metodos tradicionais. (XP vs Waterfall)
Não entendi a resposta, citada na ultima pergunta que diz:
"...a grande maioria dos princípios "ágeis" são totalmente compatíveis com a base dos modelos tradicionais."
Todos sabemos que no modelo tradicional, os processos e documentos são mais importantes que as pessoas e a comunicação entre elas, sabemos que a tentativa de prever todas as mudancas agem em detrimento das ações de feedback que o software entregue ao cliente oferece. Sabemos que não existe coragem em por o cliente lado a lado com o desenvolvedor, pois se houvesse, a figura de um analista, por exemplo, seria diluída. Sabemos que na forma tradicional existem as ideias de 'chão de fábrica' instituida tão fortemente, vindo em confronto ao conceito de equipes autogerenciadas pregadas pelo eXtreme Programming.
Enfim, à primeira vista não entendi como os modelos tradicionais poderiam ser aplicados harmoniozamente com metodos ágeis.
Obrigado.
Prezado Rodrigo,
Obrigado pelo comentário. Qanto a sua dúvida em específico, a verdade é que modelos "mistos" estão sendo estudados há muito tempo, e só para ter uma ideia há uns dois meses foi defendida uma tese "SCRUMMi - integrando CMMi ao SCRUM" (algo parecido) no mestrado da UNIFOR.
O que entendo nesta parte vem do princípio do mundo ágil. Se você ler o Agile Manifesto (www.agilemanifesto.org), verá que dos doze princípios levantados, nenhum fere diretamente um modelo tradicional. Em outras palavras: fazer debates constantes, conversar mais com o cliente, fazer iterações curtas, analisar pontos fortes e fracos e melhorar a produtividade da equipe não é novidade. Faz parte da cadeia de desenvolvimento e é visto com bons olhos por ambos os modelos.
Quantos aos seus pontos em específicos - foco em processo e documento, prevenção de mudanças, e hierarquias bem definidas - o importante é entender que esses conceitos não fazem parte do modelo tradicional, mas da interpretação e aplicação prática dada aos modelos. Para ser avaliado em CMMi não é necessário 1000 artefatos, evitar mudanças, ou um rigoroso isolamento entre papéis. O que é necessário é se ter uma metodologia bem definida, mesmo que na metodologia existam influências "ágeis" ou facilitadoras. Nada impede que um analista seja desenvolvedor em um projeto e analista em outro, ou que seja analista/programador/tester, desde que fique claro qual é o seu papel e sua responsabilidade, e seja comprovada a eficiência daquela escolha.
Uma das coisas que vem se estudando hoje é o registro de reuniões como evidência. Por que um relatório de status, um documento de controle de mudança, ou até um plano específico, não pode ser simplesmente uma reunião corretamente executada e registrada (em vídeo, papel, fotos, etc)? O que o modelo tradicional pede é que determinadas fases não sejam puladas (ex: tem que haver alguma análise, alguma gerência de configuração, etc), mas o como fazer isso é decisão da equipe. Se alguém afirmar, por exemplo, que sentar com o cliente, desenhar telas em quadros e discutir features de um produto não é análise, duvide desta pessoa. Pois a diferença entre fazer isso ou especificar um caso de uso, por exemplo, não é tão grande assim não.
Obrigado mais uma vez!
Postar um comentário