PROJETOS ÁGEIS: O PMBOK TAMBÉM É ÁGIL?

Juliano Paulo Menzen1

Adilson Pize2

Resumo: Este trabalho mostra que os projetos que utilizam o PMBOK como guia de gerenciamento de
projetos também podem ser considerados projetos ágeis. Isto é comprovado através da comparação entre as fases
do ciclo de vida de um projeto que utiliza o PMBOK e as fases do ciclo de vida de um projeto utilizando a
"Agile Project Management", com a inclusão do framework SCRUM nos pacotes de trabalho das fases de
execução de um projeto baseado no guia do PMBOK. A partir desta comparação percebe-se que o que define se
o projeto será ágil, é a forma como o projeto é planejado e executado,? e não somente as práticas
disponibilizadas através de guias, metodologias e frameworks.

Palavras-chave: projetos ágeis, PMBOK, APM, SCRUM, produtos inovadores, gerenciamento de projetos,
ciclo de vida, fases do projeto.

Abstract:. This work shows the projects that use the PMBOK as a guide to manage projects can be considered
agile projects. This is comproved by the comparing the phases of the life cycle between PMBOK and "Agile
Project Management" with the inclusion of the SCRUM framework to manage product implementation on the
PMBOK execution phase. This comparation defines that the agility is given by the way of the project is planned
and executed and not only by the practices provided through guides, methodologies and frameworks.

Key-Words: agile projects, PMBOK, APM, SCRUM, innovative products, project management, life cycle,
project phases.

Introdução

Nos últimos anos tem-se ouvido falar muito em métodos ágeis, que
originalmente, foram criados como técnicas de gerenciamento para o desenvolvimento de
software, porém, foram adaptados e também utilizados para o gerenciamento de projetos.

Com o surgimento destas novas formas "ágeis" de gerenciar projetos os atuais

guias de gerenciamento de projetos como o PMBOK, passaram a ser criticados por alguns por
não propiciarem agilidade na sua forma de gerenciar.

Este artigo tem por objetivo desmistificar a afirmativa que um projeto

gerenciado seguindo as melhores práticas descritas pelo PMBOK não é ágil, através de uma

1
Autor; pós-graduando MBA Gestão Estratégica em Gerenciamento de Projetos da Faculdade da Serra Gaúcha;
Bacharel em Ciência da Computação pela Universidade de Caxias do Sul;
Endereço eletrônico: juliano.menzen@softbyte.inf.br.
2
Co-autor; graduado em Processamento de Dados e Pós-Graduado em Qualidade Total e Reengenharia;
Certificações PMP, ITIL Foundations e ScrumMaster;
Diretor de Certificação da Seção Rio Grande do Sul do PMI;
Sócio da Excellence Gestão Empresarial;
 2

comparação entre o ciclo de vida de um projeto ágil representado através da "Agile Project
Management" (APM) e a estrutura genérica de ciclo de vida (inicio, organização e
preparação, execução e encerramento do projeto) referenciada pelo guia PMBOK para a
comunicação à alta administração ou entidades menos familiarizadas ao gerenciamento de
projetos (PMBOK, 2008). Esta comparação mostra ainda que os métodos ágeis podem
coexistir com os modelos tradicionais de gerenciamento de projetos, de forma a se
complementarem, demonstrando como é possível aplicar o framework ágil SCRUM dentro de
um projeto baseado nas práticas descritas pelo guia PMBOK.

Desenvolvimento

Atualmente, devido ao aumento da concorrência no mercado atual, tem-se a

necessidade cada vez maior de entregar um produto de qualidade, dentro dos prazos
estimados e sempre com o menor custo possível. Estas três premissas são o que chamamos de
Diagrama de Qualidade x Custo x Tempo (Amaral, 2004).

Um auxilio para tornar possível esta realidade na construção de um produto ou

entrega de um serviço, é a utilização de conceitos de gerenciamento de projetos. Neste
contexto existem metodologias, métodos, frameworks e também guias de melhores práticas
para realizar o gerenciamento de um projeto.

O PMBOK é um guia de autoria do Project Management Institute (PMI), o

qual é um padrão reconhecido para a profissão de gerenciamento de projetos, descrevendo
normas, métodos, processos e práticas estabelecidas, fornecendo diretrizes para o
gerenciamento de projetos (PMBOK, 2008).

O PMBOK apresenta nove áreas de conhecimento divididas em cinco grupos

de processos nos quais incluem-se quarenta e dois processos, que devem ser aplicados
conforme os objetivos do projeto (PMBOK, 2008). Atualmente o PMBOK encontra-se em
sua quarta edição, mas desde a sua criação, as informações contidas nele são utilizadas como
base no desenvolvimento de projetos nas mais variadas áreas.

Por outro lado, nos últimos anos tem sido divulgado através de diversas
bibliografias como ("SCRUM", 2009, "Highsmith", 2004, "Highsmith", 2000) e também
através de grupos de discussão, modelos de gerenciamento de projetos ágeis. Estes modelos
 3

objetivam a entrega de um produto de valor para o cliente de tempos em tempos conforme o

produto do projeto é implementado.

Para realizar a comparação entre os modelos de gerenciamento de projetos,

será utilizado o "Agile Project Management" (APM) (Highsmith, 2004) em conjunto com o
PMBOK. Este modelo de gerenciamento de projetos não está dividido em áreas de
conhecimento e processos, como o PMBOK, mas sim em valores, a partir dos quais podem
ser criadas atividades e processos.

Os valores propostos pelo Agile Project Management são originários do

Manifesto for Agile Software Development3, o qual apresenta quatro valores:

 Indivíduos e interações mais que processos e ferramentas;

 Software em funcionamento mais que documentação abrangente;
 Colaboração com o cliente mais que negociação de contratos;
 Responder a mudanças mais que seguir um plano

O manifesto ágil denota que tanto os valores da esquerda como os da direita

devem ser utilizados, entretanto, os valores da esquerda devem ser mais importantes que os
valores da direita.

A APM utiliza estes valores, apenas substituindo o objetivo do manifesto, que

no caso da APM, é para gerenciar projetos de produtos e serviços, enquanto que o manifesto
ágil foi criado originalmente para transmitir uma nova forma de pensar o desenvolvimento de
software (Highsmith, 2004).

Um dos motivos que levou a utilização de novas formas gerenciar projetos foi
a busca de práticas que fossem mais eficientes e eficazes do que as atuais para atingir os
objetivos do projeto, visto que mesmo com a utilização do PMBOK para auxiliar o
gerenciamento de projetos, existe um número considerável de projetos que fracassam, o que é
apresentado pelo “CHAOS Summary de 2009”. Esta pesquisa realizada pelo Standish Group,
aponta que 32% de todos os projetos são concluídos dentro do tempo, orçamento e com todas
as funções implementadas, enquanto que 44% são entregues com algum atraso, diferenças de

3
Manifesto criado em 2001 declarando os princípios que fundamenta o desenvolvimento ágil de softwares.
Originalmente possuíndo dezessete signatários: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon
Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
 4

orçamento e menos funcionalidades que as previstas e por fim, 24% dos projetos falham,
sendo cancelados antes da entrega ou então com entregas nunca utilizadas.

Estes altos índices de fracassos indicados pela pesquisa podem estar ligados
aos critérios que definem o sucesso do projeto. Sob a ótica do planejamento de projetos, um
projeto será bem sucedido quando o mesmo for realizado conforme o planejado, obedecendo
escopo, prazo e orçamento. Entretanto, outro ponto que pode ser considerado como fator de
sucesso é o valor que o projeto traz para o seu solicitante. De acordo com um poadcast do
Ricardo Vargas4 um projeto é considerado de sucesso, quando o mesmo gera valor ao
solicitante do projeto. Um exemplo disso é o projeto Iridium da Motorola, para a telefonia
global, que pode ser considerado de sucesso em relação ao escopo, tempo e custo, porém, por
não ter sido receptivo a mudanças, no momento do seu lançamento já havia sido
disponibilizada a tecnologia GSM e TDMA/CDMA, tornando o projeto um fracasso
comercial. Outro exemplo foi o filme Titanic, que ultrapassou enormemente o seu orçamento
e tempo, porém, foi o primeiro filme a gerar uma bilheteria mundial de um bilhão de dólares.
Considerando-se que o sucesso de um projeto está ligado ao seu valor gerado, podemos
considerar que o filme Titanic foi um projeto de sucesso, enquanto que se o critério para o
sucesso for o escopo, tempo e custo, o projeto Iridium é que foi um projeto de sucesso.

Em diversos produtos, como os produtos ligados a tecnologia, o

desenvolvimento de novos softwares e produtos industriais que necessitam de automação, as
oportunidades, incertezas e riscos são inerentes ao produto e não ao gerenciamento do projeto,
devido a isso, a gerência de projetos deve aceitar estas características do produto, sem tentar
eliminar as mesmas, pois o objetivo da gerência é aumentar as oportunidades e
sistematicamente reduzir as incertezas, mitigando os riscos durante a realização do projeto
(Highsmith, 2004).

Para que o gerenciamento de projetos possa aumentar as oportunidades do

produto é necessário que ela se adapte, deixando de ser um processo linear, prescritivo e
padronizado, passando a ser dinâmico, voltado para a experimentação, se antecipando e sendo
adaptativo da mesma forma que atualmente são os processos de criação de produtos.

4
Ricardo Vargas | MSc, IPMA-B, PMP. Especialista em gerenciamento de projetos, riscos e portfólio. É autor de
dez livros em português e inglês. Consultor em projetos, administra um portfólio de investimentos gerenciados
superior a US$18 bilhões mundialmente. Foi Chairman do Project Management Institute (PMI), maior
associação do mundo em gerenciamento de projetos.
 5

Um projeto para o desenvolvimento de um produto ou serviço que utilize as

práticas fornecidas pelo PMBOK e que tenha todo o seus requisitos analisados e detalhados
durante a fase de planejamento seguindo um método cascata tradicional, será um projeto de
resposta lenta a mudanças e adaptações devido principalmente ao emprego do método cascata.
Mesmo assim este projeto poderá ser um projeto de sucesso no caso dele ser concluído
conforme o planejado. Porém, se o tempo de planejamento for excessivo, o tempo total do
projeto será maior e em casos de produtos ou serviços inovadores, pode significar a redução
do valor gerado pelo produto do projeto.

Nesta constante necessidade de dinamismo ao gerenciamento de projetos, uma

critica bastante comum ao gerenciamento de projetos com base no PMBOK é o excesso de
documentação e processos a serem seguidos, entretanto, o PMBOK é claro em informar que
os processos devem ser aplicados conforme o objetivo do projeto, devendo ser avaliada a sua
aplicação a cada projeto. Isso deve-se a característica de cada projeto ser único, enquanto que
o PMBOK é um conjunto de práticas genéricas para serem aplicadas em qualquer projeto.

A escolha de quais processos devem ser utilizados no projeto são do gerente de

projetos, em colaboração com sua equipe (PMBOK, 2008). Para esta escolha ser feita
assertivamente é importante que o gerente de projetos tenha conhecimento dos processos do
PMBOK e maturidade para identificar quais são os processos, e as respectivas ferramentas e
técnicas que agregarão valor ao projeto. Este esforço de definição dos processos que farão
parte do projeto, muitas vezes podem causar o fracasso do mesmo. Por outro lado, a utilização
insuficiente de processos para o gerenciamento do projeto também pode gerar insucesso ou
deficiências na gestão do projeto.

Para auxiliar a entender o que leva um gerente de projetos a escolher os

processos adequados para gerenciar o seu projeto, pode ser utilizada a expressão que o CEO
fundador da Visa International, Dee Hock (1999) (Highsmith, 2004) utilizou, empregando a
palavra "charodic" para definir o mundo atual, no qual o gerenciamento é feito entre o chaos e
a ordem. A percepção que o administrador possui do mundo é que definirá a forma como será
realizado o gerenciamento. Se o administrador tem uma visão estática, o gerenciamento
predominante será o antecipatório e prescritivo, enquanto que se o administrador possuir uma
visão dinâmica do mundo, a sua forma de gerir será adaptativa evolutiva. O que ocorre muitas
vezes é o balanceamento destas duas formas de gerenciamento e isso pode ser transportado
para o gerenciamento de projetos.
 6

Um projeto em conformidade com os processos e técnicas fornecidas pelo guia

PMBOK pode ser gerenciado tanto de forma estática como de forma dinâmica, tendo como
elemento decisivo o seu time juntamente com o seu gerente, enquanto que o gerenciamento
ágil de projetos define que o projeto será sempre gerenciado de forma dinâmica e evolutiva.

O Gerenciamento de Projetos Ágeis através da APM, propõe um framework

dividido em cinco fases. Transportando este modelo para o PMBOK, pode-se aplicar os
métodos do PMBOK dentro de cada uma das fases, de acordo com as suas características.
Esta estrutura da APM é focada na execução e na adaptação baseando-se no modelo
"Speculate-Collaborate-Learn" descrito no livro "Adaptative Software Development
(Highsmith, 2000).

As fases propostas pela APM para o gerenciamento de projetos ágeis são cinco:
Visionar, Especular, Explorar, Adaptar e Finalizar (Highsmith, 2004) . Estas fases formam o
ciclo de vida de um projeto ágil. Por outro lado, o ciclo de vida de um projeto que utiliza o
PMBOK por base possui genericamente quatro etapas: Iniciar o projeto, Organizar e preparar
o Projeto, Executar o produto do Projeto e Encerrar o Projeto (PMBOK, 2008). Em cada uma
destas etapas, podem estar envolvidas uma ou mais fases, as quais não são estabelecidas pelo
PMBOK, mas identificados pelo gerente e a equipe do projeto.

Muitos gerentes de projetos que utilizam o PMBOK, interpretam este ciclo de

vida de maneira inadequada, planejando todo o produto do projeto durante uma única fase de
organização e planejamento, deixando pouco espaço para mudanças no escopo do produto do
projeto que possam surgir durante a fase de execução, ignorando o mundo exterior, para que
após o seu encerramento, seja iniciado um novo projeto para efetuar as mudanças ocorridas
durante o tempo em que o projeto ficou bloqueado para a execução. O próprio PMBOK
recomenda o "planejamento por ondas sucessivas", indicando que o planejamento é um
processo iterativo e contínuo (PMBOK, 2008).

Um projeto que utiliza o framework APM é iniciado na fase de Visionamento

(Envision) (Highsmith, 2004). Esta fase é o equivalente aos pacotes de iniciação e
planejamento presentes em um projeto baseado no PMBOK. Para um projeto ágil, o primeiro
passo é criar uma visão para os envolvidos iniciais no projeto sobre o que será feito no
mesmo, criando uma visão geral do produto e do seu escopo geral. O segundo passo é criar
uma visão sobre quem estará envolvido com o projeto, desde os clientes, gerentes, membros
do time do projeto, terceiros envolvidos e todos os demais interessados que foram
 7

identificados até o momento. Neste momento os membros do projeto devem criar uma visão
sobre como será feita a comunicação entre eles para que o projeto possa ser realizado.
Comparativamente a um projeto seguindo as indicações do PMBOK, nesta fase de
visionamento, podem ser incluídas duas áreas de conhecimento: O Gerenciamento do Escopo
do Projeto e o Gerenciamento da Comunicação.

A Fase de Especulação de um projeto seguindo a APM denota as atividades

ligadas a "Organização e Preparação" (planejamento) do ciclo de vida de um projeto que
segue as práticas do PMBOK. A diferença entre o termo planejamento e o termo especular
refere-se a característica de incerteza de um projeto. O termo planejar pode ser entendido
incorretamente, enquanto que o termo especular, tem em seu significado o sentido de
"conjecturar algo baseado na incerteza de fatos ou informações". A causa do fracasso de
muitos projetos reside no seu próprio planejamento, pois as métricas para definir o seu
andamento não refletem a realidade devido ao planejamento ser feito com base na incerteza.
Esta é uma característica comum em produtos que empregam tecnologias inovadoras,
conforme já foi mencionado neste artigo.

A APM considera mais importante visionar, especular e explorar o que já é

conhecido, do que planejar e executar situações futuras que talvez nunca ocorram, fazendo
com que o projeto e por conseqüência o produto do projeto sejam feitos de forma incremental
e não prescritiva.

Durante a fase de especulação são levantados os requisitos iniciais do produto

para que o mesmo possa ser construído, são definidas as atividades com base nos recursos do
produto, é criado um plano de entregas que inclui a alocação de recursos e cronograma para
os requisitos já definidos, são adicionadas estratégias para mitigar os riscos inerentes até o
momento e são feitas estimativas de custo e outras informações necessárias para a
administração do projeto. Em um projeto que utiliza a estrutura do PMBOK, podem ser
preparados os documentos relativos as áreas de conhecimento de Gerenciamento de Tempo,
Gerenciamento de Riscos, Gerenciamento de Custos, Gerenciamento de Recursos Humanos
do Projeto e Gerenciamento de Aquisições.

Após a fase de Especulação, a APM propõe a fase de exploração, a qual refere-

se à execução para entregar os recursos do produto definidos na fase de especulação. Esta fase
é composta por três atividades: A primeira refere-se à capacidade de entregar os recursos do
produto definidos pelas atividades, utilizando a técnica necessária e realizando a mitigação do
 8

risco. A segunda atividade é conseguir formar um time auto organizável e colaborativo, em

que todos saibam as suas responsabilidades e o terceiro é gerenciar as iterações entre o time e
os demais interessados no projeto (Highsmith, 2004) . Comparativamente a um projeto
baseado no PMBOK, neste momento encontram-se os pacotes de trabalho relacionados a
execução do trabalho do projeto, empregando as áreas de conhecimento necessárias ao
gerenciamento das atividades desta fase. Tanto a APM como o PMBOK descrevem as
atividades necessárias para o gerenciamento do projeto, mas não descrevem os processos
ligados ao gerenciamento do processo de produção do produto, entretanto, recomendam que
estes processos devam ser conhecidos e utilizados para que o produto possa ser elaborado
(PMBOK, 2008).

Devido a APM e o PMBOK serem relacionados ao gerenciamento de projetos,

e não ao produto, pode-se inserir um framework relacionado ao processo de construção das
atividades ligadas ao produto, para gerenciar a execução dos pacotes de trabalho do produto.

Para a criação de produtos baseados na incerteza, como os produtos de

Software, pode-se utilizar um framework conhecido como SCRUM (SCRUM, 2009),
integrado a APM ou ao PMBOK.

Scrum é um framework que foi formalizado em 1995 por Ken Schwaber,

entretanto o mesmo foi criado, documentado e aplicado por Jeff Sutherland, John
Scumniotales e Jeff McKenna em 1993. Este Framework descreve práticas que devem ser
empregadas para o desenvolvimento de novos produtos, dentre estes, produtos de software.

O Scrum permite o controle de processos empíricos de forma iterativa e

incremental para desenvolver um produto e está baseado em três pilares, conforme descreve o
Guia do Scrum (SCRUM, 2009).

-Transparência: Este pilar garante que tudo o que afeta o resultado deva ser
visível e conhecido por aqueles que gerenciam os resultados.

-Inspeção: Os aspectos do processo devem ser inspecionados com uma

frequencia que permita detectar variações inaceitáveis no projeto. A frequencia é
realizada conforme a característica do que está sendo inspecionado.
 9

-Adaptação: Se a partir da inspeção, forem detectadas características fora do

esperado para o produto resultante, os aspectos do processo devem ser modificados,
para permitir minimizar estas características.

Sobre estes três pilares, foi descrito um processo, conforme visualizado na

imagem abaixo.

Figura 1: Processo do Scrum

Fonte: http://epf.eclipse.org/wikis/scrum/index.htm

Conforme apresentado, o processo do Scrum prevê o Produtct Backlog, o qual

é o repositório de histórias do usuário, estas histórias são os requisitos definidos pelo usuário
e tarefas que compõe a construção do produto até o momento. O Sprint Backlog é um
conjunto de requisitos priorizados do Product Backlog e definidos para serem desenvolvidos
dentro de um Sprint. Cada Sprint é um período de tempo determinado, no qual as atividades
serão realizadas pelo time do projeto.

A cada dia que se passa, é realizada uma reunião, normalmente com 15

minutos de duração, que visa identificar possíveis impedimentos ao desenvolvimento das
atividades do Sprint.

Cada Sprint executado produz um incremento no produto, tornando o mesmo

uma entrega potencial ao cliente. Ao final do Sprint é realizada uma reunião de encerramento
e o produto é apresentado. Esta reunião permite obter as lições aprendidas para serem
aplicadas no próximo Sprint do produto.
 10

Para realizar o processo desenhado pelo Scrum, são necessários alguns

artefatos. O BurnDown Chart do Sprint, que representa o trabalho ainda necessário para a
realização do sprint, e que fica visível a todos os membros do time do projeto. Também há o
Scrum Board, que permite a identificação através de post-its de quais as tarefas estão sendo
executadas no momento, as tarefas que já foram executadas e as tarefas que serão executadas.

O Framework SCRUM prevê três atores envolvidos no processo. O

ScrumMaster, este ator é o responsável em garantir a aderência do Time aos valores do
Scrum. Ele serve para liberar os impedimentos do Time durante a execução das atividades do
Sprint, objetivando garantir o sucesso do mesmo, podendo, em alguns casos, ser comparado
ao gerente de projetos. Também há o ProductOwner, responsável por gerenciar o product
backlog e interagir com o cliente garantindo o valor do trabalho realizado pelo Time. E por
fim, existe o Time do Scrum, que são os desenvolvedores responsáveis em transformar o
backlog do produto em funcionalidades com potencial de serem entregues ao término de cada
Sprint.

Os processos descritos do Scrum estão diretamente relacionados com os seus

pilares de Transparência, Inspeção e Adaptação. Criando uma relação entre os pilares e os
artefatos do Scrum, temos para o pilar da Transparência, os artefatos do Product e Sprint
Backlog, além do Scrum board, que demonstra para todos o que está sendo feito pelo time.

Para o pilar da inspeção, encontram-se os artefatos da reunião diária e

burndown da sprint, que permitem identificar e inspecionar o andamento do projeto. E para o
pilar da Adaptação, existem os artefatos de reunião de finalização do Sprint, que permitem
identificar qual foi o produto potencialmente entregável, tornando possível reavaliar o
Product Backlog e por consequencia os próximos sprints.

Em um projeto implementado com o uso do PMBOK, o SCRUM pode ser

utilizado durante a execução dos pacotes de trabalho relacionados às fases de execução do
produto do projeto, com algumas mudanças de conceito quanto aos processos aplicados.

O Product Backlog será formado pelas tarefas já definidas durante o processo

de planejamento do projeto. Estas tarefas podem estar totalmente definidas, ou podem
necessitar de mais análise, conforme o planejamento das mesmas durante o processo de
levantamento de requisitos. O Sprint Backlog será um conjunto de tarefas agrupadas de
 11

acordo com a sua data de entrega. O Sprint Backlog será considerado uma entrega do projeto,
devendo estar definido no planejamento do cronograma do mesmo.

Durante a execução do Sprint são realizadas as reuniões diárias, procurando

identificar e resolver impedimentos ocorridos durante o dia, para evitar atrasos na entrega dos
produtos do projeto. Esta reunião também permite identificar antecipadamente mudanças que
possam ser necessárias no projeto, permitindo adaptações no mesmo.

A entrega do Sprint e conseqüente reunião de fechamento devem ser realizadas

da mesma forma que o SCRUM tradicional, porém, elas também servem de base para
identificar a necessidade de mudanças no projeto e aprendizado antecipado para as lições
aprendidas.

O Scrum Master não necessita ser o gerente de projetos nestes casos, podendo
ser um membro do time de execução do produto ou alguém que tenha as habilidades e
competências necessárias para exercer esta função. O Product owner será um representante do
cliente, conforme acontece no Scrum tradicional.

No caso de um projeto ágil, o Scrum pode ser aplicado conforme a descrição

do seu Framework original, estando inserido durante a fase de especulação e exploração. A
fase de especulação permite que seja definido o Produtct Backlog, incluindo no mesmo as
histórias de usuários e tarefas. A fase de exploração permite a implementação do Sprint
Backlog e conseqüente execução do Sprint. As reuniões diárias são realizadas de acordo com
a descrição do Scrum, e ao término do Sprint, é realizada a reunião de encerramento do
mesmo, que permite identificar lições aprendidas, além de servir de base de revisão do que foi
realizado durante a fase de execução, para ser analisado na fase de Adaptação do projeto, que
será apresentada a seguir. Novamente o Scrum Master não necessita ser o gerente do projeto.

Após utilizar o SCRUM para a fase de execução, ocorre a fase de Adaptação.

Esta fase serve para avaliar os resultados obtidos até o momento entre as partes interessadas,
avaliando a performance do projeto.

Esta fase serve em muitos casos para revisar a visão do projeto com os seus
objetivos, refazer o processo de especulação e novamente explorar e adaptar o que foi revisto.
Este processo nos leva a um ciclo iterativo incremental entre as fases de Envisionamento,
Especulação, Exploração e Adaptação até o projeto ser concluído. Este processo é necessário
devido à característica dos projetos, pois em muitos deles, como mencionado anteriormente,
 12

não há um conhecimento de todo o projeto durante a sua iniciação e planejamento inicial, de

forma que o conhecimento do projeto progride conforme o mesmo vai sendo executado. O
PMBOK também menciona esta necessidade, quando fala do "planejamento em ondas
sucessivas" (PMBOK, 2008).

Comparativamente, tanto a APM como o PMBOK demonstram a necessidade

de desenvolver o projeto de forma iterativa e continua. A diferença entre o conceito de
adaptação e validar o planejamento é que a validação do planejamento denota que se o
resultado está diferente do planejado, temos uma falha e se estiver igual, temos sucesso,
entretanto, devido ao fator de incerteza que reside na característica de muitos dos produtos de
projetos, não há possibilidade de planejar tudo, somente de criar uma percepção do que
precisa ser feito. Por isso, a adaptação implica na revisão continua do que está sendo
realizado, analisando se há necessidade de alterar o que está sendo feito ou continuar a
execução, referenciando-se sempre ao objetivo que pretende-se alcançar. Este conceito é
guiado pela filosofia de que responder a mudança é mais importante que seguir um plano,
onde o sucesso é a entrega de um produto de projeto que agregue valor ao patrocinador do
projeto (Highsmith, 2004).

Tanto no gerenciamento de projetos ágeis (APM) (Highsmith, 2004), como no

gerenciamento através do PMBOK (PMBOK, 2008), é recomendado que ao final do projeto
ou ao final de uma iteração ou fase do projeto sempre deva ser realizado um fechamento, para
concluir a etapa.

O Fechamento deve servir para o cliente e demais interessados no projeto

perceberem se o que o projeto se propôs a fazer até aquele momento está concluído e aceito,
considerando que solicitações de mudança após este momento implicam em manutenção ou
alterações do produto que serão feitas fora do escopo do projeto. Este momento também serve
para o time do projeto incorporar e registrar o aprendizado adquirido para ser aplicado nas
próximas iterações ou em outros projetos.

Considerações Finais

Como pode-se perceber durante a evolução deste artigo, um projeto criado

através dos conceitos fornecidos pelo PMBOK também pode ser ágil conforme a descrição de
um projeto ágil.
 13

As fases e práticas fornecidas pela APM para a elaboração de um projeto ágil

são contempladas pelo PMBOK. A utilização do SCRUM para gerenciar o trabalho de
elaboração do produto também não concorre com o PMBOK, o qual abrange diversas áreas de
conhecimento necessárias para o gerenciamento do projeto, enquanto que o SCRUM limita-se
a ser um framework para um processo de construção do produto, o qual pode ser incorporado
ao PMBOK durante o processo de execução do produto, conforme demonstrado. Na figura
abaixo, é mostrado de forma prática como o SCRUM pode ser integrado ao PMBOK.

Figura 2: SCRUM para gerencia de produtos e não projetos (Highsmith, 2009)

Pelas comparações apresentadas, um projeto implementado utilizando as

práticas do PMBOK também pode ser ágil, pois não é o PMBOK que propicia a não agilidade
ao projeto, mas sim a forma como o mesmo é empregado. Os valores propostos pelo
Manifesto Ágil, fornecem uma mudança na forma de trabalho e isso é o que define a
agilidade, pois a mesma não está somente no processo, mas sim na atitude.

Entretanto, muitas vezes, mesmo com atitude ágil, há outro problema que
implica na inviabilidade do emprego de métodos ágeis, que é o contrato para a construção do
produto.

Este artigo não tem por foco falar de contratos, entretanto, um contrato de
escopo e custo fixos para a elaboração de um novo produto, para o qual ainda não se possui
conhecimento de todos os requisitos do produto, inviabiliza o emprego de muitos dos itens
que implicam na agilidade do gerenciamento do projeto.
 14

Referências

(PMBOK, 2008) Um Guia do Conjunto de Conhecimentos em Gerenciamento de

Projetos (Guia PMBOK®) Quarta Edição 2008 Project Management Institute, EUA.

(SCRUM, 2009) Schwaber, Ken. Guia do SCRUM. Trad. Heitor Roriz Filho, Michel
Goldenberg, Rafael Sabbagh. Dísponivel em: http://www.scrum.org/scrumguides/

(Highsmith, 2004) HighSmith, Jim. Agile Project Management: Creating innovative

products. Primeira Edição, Boston: Addison-Wesley 2004

(Highsmith, 2009) HighSmith, Jim. Agile Project Management: Creating innovative

products. Segunda Edição, Boston: Addison-Wesley 2009

(Highsmith, 2000) HighSmith, Jim. Adaptive Software Development: A Collaborative

Approach to Managing Complex Systems. Primeira Edição: Dorset House Publishing
Company, 2000

(Amaral, 2004) Amaral, J.A.A Modelos para gestão de projetos: como utilizar
adequadamente conceitos, ferramentas e tecnologias. São Paulo: Scortecci, 2004.

(Vargas, 2009) Poadcast: Acessado em 06/2010, http://www.ricardo-

vargas.com/pt/podcasts/agile2_2/