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

Transcrição

1 PROJETOS ÁGEIS: O PMBOK TAMBÉM É ÁGIL? Juliano Paulo Menzen 1 Adilson Pize 2 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 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 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 Development 3, 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 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 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 Vargas 4 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 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 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 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 referese à 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 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 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 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: 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 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 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 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 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 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: (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, (Vargas, 2009) Poadcast: Acessado em 06/2010,