segunda-feira, 15 de junho de 2009

PMBOK e Métodos Ágeis

No PMBOK não há proibição ao uso de Métodos Ágeis, assim como não advoga pelo ciclo em cascata para o desenvolvimento de projetos. Ao contrário ele descreve que o ciclo de vida depende do projeto e da empresa.

O que o PMBOK diz:

"É importante observar que muitos processos dentro do gerenciamento de projetos são iterativos devido à existência, e necessidade, de uma elaboração progressiva em um projeto durante todo o ciclo de vida do projeto" (PMBOK, 2004 p. 20).

Não existe uma única melhor maneira para definir um ciclo de vida ideal do projeto. Algumas organizações estabeleceram políticas que padronizam todos os projetos com um único ciclo de vida, enquanto outras permitem que a equipe de gerenciamento de projetos escolha o ciclo de vida mais adequado para seu próprio projeto...” (PMBOK, 2004 p. 20).

Gosto da visão dada por Alan Kock em sua apresentação "The Agile Manifesto and The PMBOK", de como pode ser trabalhado de forma iterativa os grupos de processos do PMBOK. Conforme figura:




Na sua apresentação, Kock aborda as compatibilidades e incompatibilidades entre a forma que o PMBOK trata os grupos de processos e as práticas Ágeis. Mas também sugere formas de fazer a conciliação nos casos de imcompatibilidade.

O certo é que não é tão simples, é preciso saber adaptar o processo, para a realidade do projeto e/ou empresa.

Os Métodos Ágeis além de abordarem o desenvolvimento de software de forma iterativa, evolutiva e incremental, são mais dinâmicos e flexíveis. Há forte ênfase na proximidade e comunicação com o cliente. Mais que apenas a mudança no ciclo de vida do desenvolvimento, há uma mudança de valores e princípios.

O gerenciamento de projetos Ágil e Tradicional, embora partam de pressupostos diferentes, podem coexistir e conviver bem em um mesmo ambiente. É necessário considerar criteriosamente o ambiente correto. A abordagem Ágil traz ótimos resultados em um projeto de desenvolvimento de software, mas o planejamento e acompanhamento tradicional podem agregar valor para grandes marcos, como releases e iterações e atividades não relacionadas diretamente a produção do software, como também no relacionamento de dependência entre projetos.

Nenhum comentário: