Criar o Plano de Gestão do Projeto. PMBOK vs. AGILE
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguZSLRVY3kFjHcNiN0iLcRWaINESALlthZlSnPea_QFxOYE1bYAFFurdbIz_qOFKrFgpvRYPdp0mIyrp3WvKZO2KUqHi7UywrExuNIqyj1bcGJYTgX-ryrye0b8m-hifJs1Og9LSat4Klw/s320/PMBOK+vs+AGILE.jpg)
Na perspetiva do PMBOK o Plano de Gestão do Projeto é o documento que
explica a forma como o projeto irá ser gerido, e quais as ações
necessárias para definir, coordenar e integrar todos os planos setoriais
(Âmbito, Calendário, Custo, Qualidade, Risco, Comunicação, Recursos
Humanos, Aquisições e Expectativas dos Interessados) num documento único
que permita a gestão eficaz do projeto.
Criar o Plano de gestão do Projeto é um processo central da metodologia de gestão de projeto proposta pelo PMBOK uma vez que o seu resultado (o plano de gestão do projeto) é usado como guia e input fundamental de todos os processos de planeamento setoriais e de muitos dos processos de monitorização e controlo do projeto.
Veja o diagrama de fluxo de dados abaixo e repare que o resultado do processo é entrada para numerosos processos de planeamento setorial e que, por sua vez os planos que resultam desses processos são entradas do próprio processo de criação do plano de gestão de projeto. Isto é assim porque o PMBOK aconselha que o plano de gestão de projeto esteja em permanente aperfeiçoamento até ao fecho do projeto, num processo interativo de elaboração progressiva a que o PMBOK dá o nome de “rolling wave planning”.
Criar o Plano de Gestão de Projetos - Diagrama de Fluxo de Dados |
Na tabela abaixo comparamos a forma como esse plano é construído, quando o projeto é gerido de acordo com um modelo de processo estruturado, como aquele que é proposto pelo PMBOK, e como poderia ser construído quando usamos processos de gestão mais próximos do Agile.
PMBOK Processo
|
AGILE Processo
|
Entradas
Resultados
dos processos de planeamento setorial
Fatores Ambientais da Organização (Normas e Standards governamentais e ou setoriais;
Infraestrutura da organização; informação sobre condições de mercado)
Ativos de Processo da Organização (Processos da organização, formulários, normativos
internos, lições aprendidas em projetos anteriores)
|
Entradas
Documento de Inicio do Projeto (Termo de Abertura do Projeto) / Visão sobre o produto ou serviço a criar
Lista de Candidatas a Histórias de Utilizador /
Log de produto inicial
Fatores Ambientais da Organização (Normas e
Standards governamentais e ou setoriais; Infraestrutura da organização;
informação sobre condições de mercado)
Ativos de Processo da Organização
(Processos da organização, formulários, normativos internos, lições aprendidas em projetos anteriores)
|
Ferramentas e Técnicas
|
Ferramentas e Técnicas
|
Resultados
Plano
de Gestão do Projeto
|
Resultados
Ainda que estejamos a usar um
processo de gestão de projetos ágil podemos criar e documentar um plano de
gestão de projeto. Contudo, para projetos de pequena dimensão e de curta
duração, essa documentação deve ser sintética.
Repare que o PMBOK recomenda que o
plano de gestão de projeto seja um documento de elaboração progressiva, isto
é, esse plano irá sofrendo alterações á medida que os restantes planos vão
sendo aprofundados e atualizados. Este “rolling wave planning” adapta-se
muito bem ao conceito de planeamento adaptativo usado no Agile
|
A conclusão é que as diferenças existem, mas não são assim tão acentuadas, e que não devemos "rasgar as vestes" se, mesmo quando estamos a usar uma metodologia ágil de gestão de projeto, o nosso cliente fizer questão em que lhe entreguemos o plano de gestão do projeto.
Contudo também não devemos aceitar que, como tantas vezes se diz, o conceito de Rolling Wave Planing proposto no PMBOK é idêntico ao Planeamento Adaptativo dos métodos ágeis, porque isso não é verdade (veja aqui as diferenças) e tratar os dois conceitos como idênticos prejudica a correta gestão do projeto.
Contudo também não devemos aceitar que, como tantas vezes se diz, o conceito de Rolling Wave Planing proposto no PMBOK é idêntico ao Planeamento Adaptativo dos métodos ágeis, porque isso não é verdade (veja aqui as diferenças) e tratar os dois conceitos como idênticos prejudica a correta gestão do projeto.
Grp2ALL