Metodologia ágil no desenvolvimento de software

Sexta-feira passada ( 27/06/2008 ), estive em um evento da Borland sobre metodologia ágil para desenvolvimento de software e gostaria de compartilhar um pouco do que foi falado. :)

Metodologia ágil

Antes de começar, quero deixar claro algumas coisas:

  • PMI é um orgão – Project Management Institute. Este órgão regulamenta o conteúdo do PMBOK ( Project Management Body of Knowledge), que é um livro que cita as melhores práticas de gerenciamento de projetos. Muita gente diz que PMI é metodologia, de forma totalmente errônea;
  • Metodologia ágil não se limita ao SCRUM. SCRUM foi criado em cima do conceito de metodologia ágil;

Ouvi muita gente falar: - “Puxa, gostaria de aprender a metodologia do PMI”; – “Você foi em evento de metodologia ágil, de SCRUM ?”. Puro “modismo”. O mesmo fato ocorria com o RUP, que foi desenvolvido pela Rational em cima do conceito de Processo Unificado.

Voltando ao que interessa…

Quando você começa a estudar diversas metodologias, acaba descobrindo que muitos conceitos são genéricos em todas, portanto, não foge muito. A forma de implementar varia e muito, de empresa para empresa. Na metodologia ágil, não é diferente. Possui diversas características do processo unificado, alguns conceitos de gestão de projeto do PMBOK, com algumas modificações. Pontos interessantes:

  • Product backlog – é a lista de funcionalidades do projeto;
  • Sprint – corridas curtas para definir determinado”escopo”;
  • Lista de funcionalidades priorizadas e rankeadas são o norte do projeto;
  • Processo iterativo e incremental ( da mesma forma que ocorre no UP );

Outro ponto interessante que encontrei é a interação do usuário com a equipe do projeto, facilitando modificações dos requisitos, caso seja necessário. Diferente dos métodos convencionais, esse modelo facilita mudanças no decorrer do projeto sem que o nível de retrabalho seja alto. Como o escopo é definido gradativamente e os sprints são curtos, o risco de se produzir algo errado é bem mais baixo do que o meio convencional de especificar, codificar e testar.

Além disso os rótulos dos cargos somem. Não existe mais desenvolvedor, analista, testador, gerente. Há somente a equipe e ela é responsável pela tomada de decisão do projeto.  Todas as reuniões são curtas, conhecidas como STANDUP MEETINGS e acaba a história das longas reuniões de follow-up para o gerente, diretor, etc. O status report do projeto é objetivo: “o que você fez, o que você vai fazer e quais são os problemas”

* Uma nota interessante é que a equipe que você precisa para chegar nesse nível precisa ser mais “generalista”, pois os conhecimentos amplos são úteis. Obviamente que você não pode dispensar um especialista, mas no dia-dia não é a melhor opção.

Para concluir essa breve explanação, considero que é altamente produtivo o emprego das metodologias ágeis, porém, a mentalidade da empresa precisa mudar para se adequar, já que é totalmente diferente dos modelos clássicos de gestão. O gerente e/ou diretor da área não devem se meter no dia-dia do projeto e seu andamento/evolução dependem somente da equipe. O papel das pessoas muda, porém, os resultados também mudam.

Muitas empresas estão de olho nisso e implantando como teste em projetos. Sua empresa ou os funcionários já se movimentaram e fizeram alguma tentativa ? Comente aqui.

Bookmarksbookmark bookmark bookmark bookmark bookmark bookmark

Popularity: 3%

No Comment

Vale Presente