KÊNIO DIAS LOYOLA NICKSON DUTRA PINHEIRO

ESTUDO DA VIABILIDADE DE UTILIZAÇÃO DO PMBOK® E O SCRUM COMO MODELO DE GESTÃO DE PROJETOS NO SETOR DE TI DE INSTITUIÇÕES DE TEÓFILO OTONI

FACULDADES UNIFICADAS DOCTUM – TEÓFILO OTONI 2010

KÊNIO DIAS LOYOLA NICKSON DUTRA PINHEIRO

ESTUDO DA VIABILIDADE DE UTILIZAÇÃO DO PMBOK® E O SCRUM COMO MODELO DE GESTÃO DE PROJETOS NO SETOR DE TI DE INSTITUIÇÕES DE TEÓFILO OTONI

Trabalho de Conclusão de Curso apresentado à Comissão Examinadora das Faculdades Unificadas Doctum - Campus Teófilo Otoni como requisito para obtenção de título do Bacharel em Sistemas de Informações, sob orientação do Prof. Fabiano Ferreira Santos.

FACULDADES UNIFICADAS DOCTUM – TEÓFILO OTONI 2010

FOLHA DE APROVAÇÃO

Aprovada em 18 de Novembro de 2010

____________________________________ Prof. Fabiano Souza Santos (Orientador)

____________________________________ Prof. Yvssa Carneiro Desmots

____________________________________ Prof. Salim Ziad Pereira Aouar

dando .Dedicamos a Deus por ter nos acompanhado nesta trajetória.nos força e inspiração para concluir este trabalho. .

pela base sólida que sempre nos deu incentivo para encarar a vida de frente e nunca desistir dos nossos sonhos. e que nos influenciaram de forma determinante para a conclusão deste trabalho. Ao professor Prof.AGRADECIMENTOS Agradecemos primeiramente a Deus por ter nos dado força. e nos guiado para conseguirmos chegar ao fim de mais uma importante etapa de nossas vidas. agradecemos aos demais professores e amigos da faculdade que fizeram parte dessa jornada. Salim Ziad Pereira Aouar pela disponibilidade de nos ajudar sempre que necessitamos. Por fim. Aos nossos familiares. Prof. Ao nosso orientador. Fabiano Souza Santos pela dedicação e disponibilidade em sempre estar sanando nossas dúvidas e dificuldades através de uma orientação inteligente e esclarecedora. .

Não se deve julgar o mérito de um homem pelas suas grandes qualidades. (La Bruyère) . mas pelo uso que sabe fazer delas.

.... 28 2..........4 Cerimônias.......... 19 2.................... 56 3............................ 58 3.....................1 PMBOK® X Scrum: Ciclo de Vida ............1 O que é o PMBOK®? .........................1...................... 57 3.....4.....................3 Artefatos .... 52 2............................................12 Gerência de Aquisições do Projeto ..................................8 Gerência de Qualidade do Projeto ............6 Gerência de Tempo do Projeto .....5 Perfil de um Gerente de Projetos ..................... 32 2..... 25 2.......... 39 2. 33 2.3 Ciclo de Vida do Projeto .................6 Benefícios do Gerenciamento de Projetos .......2 Papéis ................. 21 2......................2....................5 Gerência de Escopo do Projeto ....................2.............................Project Management Body of Knowledge .....3 PMBOK® X Scrum: Gerenciamento de Escopo .............................SUMÁRIO 1 INTRODUÇÃO ........ 35 2...........................4. 59 ......................... 50 2.............................................................................................2 Grupos de Processos do PMBOK® .......................... 59 3........ 37 2.......................... 42 2...... 19 2.......... 24 2............4 Gerência de Integração do Projeto ...4..................1.......................2..................................... 38 2..................................................3 Desenvolvimento ágil .... 44 2............................................... 28 2.........................2 O que é o Gerenciamento de Projetos? .....................2.......................2 PMBOK® ............................................2........................................................................................................................................1..............................4 PMBOK® X Scrum: Gerenciamento de Tempo . 19 2........................................... 15 2 REFERÊNCIAL TEÓRICO ...............2..................................1.........1 Ciclo de Vida do Scrum ....2...............................................................................2 PMBOK® X Scrum: Gerenciamento de Integração ...........................................................................................................1..............................................11 Gerência de Riscos do Projeto ...4 Partes Interessadas em um Projeto ....................1 O que é um projeto? ................................................... 45 2..................... 21 2.....................7 Gerência de Custo do Projeto .. 54 3 ESTUDO COMPARATIVO: PMBOK® x Scrum ................................4 Scrum . 48 2................................ 40 2......................10 Gerência de Comunicações do Projeto .......................................................4..................................2...............2...................1........................................2............................................... 31 2................................... 47 2...................................................................2.............1 GERÊNCIA DE PROJETOS ....................................................2.................................9 Gerência de Recursos Humanos do Projeto ....................3 As nove áreas de Conhecimento do PMBOK® .......... 29 2...... 22 2.....................

......5 PMBOK® X Scrum: Gerenciamento de Custos .............................................................................................................3 Proposta de utilização de um framework híbrido ... 65 4.........................4..............4...........2 Instituição B ................................ 80 ... 72 5 CONSIDERAÇÕES FINAIS ............................... 63 4 ESTUDO DE CASO: Viabilidade da utilização do PMBOK® e o Scrum ..............2 Instituição B ..................11 PMBOK® X Scrum: Conclusão do Projeto..................... 71 4............................................... 62 3................................3......................................................................... 75 REFERÊNCIAS BIBLIOGRÁFICAS ........1 Instituição A ........................4 Diagnóstico das análises realizadas ............................ 62 3.............................................. 78 ANEXOS ........... 64 4....................................................................................................... 61 3...................................8 PMBOK® X Scrum: Gerenciamento de Comunicações .........2........................................................................10 PMBOK® X Scrum: Gerenciamento de Aquisições ...................2.......................7 PMBOK® X Scrum: Gerenciamento de Recursos Humanos .........................................................1 Instituição A ........................................2 Descrição das instituições analisadas.................................. 66 4...................9 PMBOK® X Scrum: Gerenciamento de Riscos .......................... 65 4...... 64 4......... 60 3.. 65 4.......... 63 3..............1 Métodos adotados para o estudo de caso ....... 71 4........................................ 60 3...........6 PMBOK® X Scrum: Gerenciamento de Qualidade ...................................................................................

e posteriormente a criação de um framework híbrido oriundo das práticas dos dois métodos. Gerenciamento de Projetos. no setor de Tecnologia da Informação de instituições de Teófilo Otoni. foi realizada uma análise comparativa entre ambos os paradigmas estudados identificando seus pontos de compatibilidades e diferenças. Este trabalho demonstrou o uso dos benefícios proporcionados por um método inovador.PMBOK®. . com o intuito de apresentar uma nova forma de garantir qualidade e agilidade nos projetos desenvolvidos pelo setor de Tecnologia da Informação. baseado na junção de práticas tradicionais e ágeis. Para tal objetivo ser alcançado. Palavras-chave: Scrum.RESUMO A presente pesquisa objetiva analisar a viabilidade de utilização das práticas tradicionais em gerenciamento de projetos do guia PMBOK® em conjunto com a metodologia ágil Scrum. Metodologia ágil.

Project Management.ABSTRACT This research aims to examine the feasibility of use of traditional practices in project management PMBOK ® in conjunction with the Scrum agile methodology. we performed a comparative analysis between both paradigms studied by identifying the points of compatibilities and differences. For this goal to be achieved. Agile methodologies. with the intention of presenting a new way to ensure quality and agility in projects developed by the Information Technology sector.PMBOK ®. Keywords: Scrum. . the Information Technology sector institutions of Teófilo Otoni. and subsequently the creation of a hybrid framework of practices derived from the two methods. This study demonstrated the use of the benefits provided by an innovative method based on the junction of traditional practices and agile.

.... 41 FIGURA 13 ................. 24 FIGURA 2 ..... 35 FIGURA 7 ................................................................ 44 FIGURA 15 ..............................Mapeamento do Gerenciamento de Custos .. 52 FIGURA 17 ............. 49 FIGURA 16 ... 39 FIGURA 11 ........... 67 FIGURA 21 .....Exemplo de uma EAP Específica ............... 69 ......................................Cerimônias do Scrum .... 37 FIGURA 9 .......Mapeamento do Gerenciamento das Aquisições ..........Mapeamento do Gerenciamento das Comunicações ....... 34 FIGURA 6 ...............................Mapeamento do Gerenciamento de Integração ...........................LISTAS DE FIGURAS FIGURA 1 ................................... 32 FIGURA 5 ...Exemplo do Novo Product Backlog ........................................................................................................... 66 FIGURA 20 ......................... 31 FIGURA 4 ...................... 68 FIGURA 22 .......Tipos de profissionais requeridos ao longo do projeto ...................................................... 38 FIGURA 10 .......................................Mapeamento do Gerenciamento de Qualidade ...........Exemplo de um EAP.........Mapeamento do Gerenciamento de Tempo ........Novo ciclo de vida: PMBOK® e Scrum ................................Mapeamento do Gerenciamento do Escopo ........................... 30 FIGURA 3 ..................................................................... 58 FIGURA 19 ..........Relação entre as Partes Interessadas e o Projeto.............................Exemplo de um Product Backlog ...... 43 FIGURA 14 ....Ciclo de vida do Scrum ..............Mapeamento do Gerenciamento de Qualidade ...... 36 FIGURA 8 .......................... 40 FIGURA 12 ..........Visão Geral das Áreas de Conhecimento do PMBOK® (2004) ................................... 54 FIGURA 18 .....Os Grupos de Processos do Gerenciamento de Projetos .............................Comparação entre o ciclo de vida do PMBOK® e do Scrum...............Mapeamento do Gerenciamento de Riscos .....Product Backlog Priorizado .......

...Evolução dos Percentuais de sucesso.......LISTA DE GRÁFICOS GRÁFICO 1 .......... 26 GRÁFICO 2 ........ 53 ....Evolução dos credenciados PMP no Mundo ...................................................................Exemplo de um Burndown Chart .. atraso e falhas . 27 GRÁFICO 3 ...................

...................... 56 .........LISTA DE TABELAS TABELA 1 ..............Comparativo entre a abordagem Tradicional X Ágil ......Definição das Partes Interessadas em um Projeto ........ 23 TABELA 2 ......

Organização das Nações Unidas PMI .American National Standard EAP .LISTA DE ABREVIATURAS E SIGLAS PMBOK .Estrutura Analítica de Projetos NFe .Project Management Professional ANSI .Project Management Institute PMO .Project Management Body of Knowledge TI .Tecnologia da Informação ONU .Nota Fiscal Eletrônica .Project Management Office PMP .

tendo em vista que os mesmos estão cada vez mais modernos requerendo uma alta diversidade de habilidades. metodologias de gerenciamento e desenvolvimento surgiram no mercado com intuito de guiar todo o ciclo dos projetos. . o restante ou são abortados ou não cumprem os requisitos estabelecidos. as funcionalidades não atendem às necessidades dos usuários ou porque não cumprem o orçamento especificado. além de ambientes cada vez mais exigentes em termos de recursos. seja porque não cumprem o cronograma. buscando obter o aprimoramento de suas habilidades e técnicas. O Scrum constitui uma metodologia ágil para gerência de projetos inicialmente de software. proporcionando assim a garantia de um diferencial competitivo. Contudo observa-se um crescente aumento na implantação de projetos nas organizações. Tendo como base esta realidade e visando melhorias nesses tipos de projetos. Em contrapartida. desenvolvido pelo PMI (Project Management Institute) destaca-se através do fornecimento de um somatório de conhecimentos de gerenciamento para diversos tipos de projetos. a fim de se submeter a uma constante atualização. INTRODUÇÃO Diante da evolução dos meios tecnológicos e o mercado cada vez mais globalizado e competitivo. surge à necessidade das organizações estarem se adequando a essa nova realidade.15 1. as tradicionais e as ágeis. grande complexidade técnica. porém pode ser aplicado a qualquer contexto onde pessoas precisem trabalhar juntas para obter um objetivo comum. atuando com dois tipos de abordagens diferentes. Pesquisas realizadas pela Standish Group revelam que a maioria dos projetos tendem a falhar. o PMBOK® (Project Management Body of Knowledge). Dentre as abordagens tradicionais. Apenas 26% dos projetos são bem sucedidos. a abordagem ágil vem se destacando e ganhando adeptos em todo o mundo.

H3: Não é viável. como o controle efetivo dos prazos. baseado na junção de práticas tradicionais e ágeis para gerência de projetos com o intuito de proporcionar benefícios para as empresas que o adotarem.16 Mediante aos fatos supracitados. H2: É viável. se é cada vez mais exigido uma maior produtividade e qualidade. custos e o constante monitoramento dos riscos e qualidade do projeto. A pesquisa em questão contempla minimizar os contratempos enfrentados pelas empresas de Teófilo Otoni. e abrange algumas áreas do curso como a Engenharia de Software e a Gerência de Projetos. que devido à acirrada concorrência. e que freqüentemente defronta com um dos seus maiores problemas que é a falta de uma metodologia ou procedimento capaz de orientar de forma eficaz seus projetos. pois proporcionará mais qualidade aos projetos desenvolvidos. a presente pesquisa foi desenvolvida no 8º período do curso de Sistemas de Informações. pois a utilização de testes em cada ciclo de desenvolvimento poderá ocasionar atrasos na entrega do projeto Final. pois obrigará a documentação para melhorar a comunicação e conseqüentemente o conhecimento da equipe sobre o projeto. principalmente no setor de Tecnologia da Informação (TI). Este trabalho visa propor a utilização de um método inovador. como requisito para obtenção do título de bacharel em Sistemas de Informações. tendo como base este cenário o problema motivador desta pesquisa foi: É viável utilizar o PMBOK® e o Scrum em conjunto. O objetivo geral desta pesquisa foi verificar a viabilidade de utilização do PMBOK® e o Scrum em conjunto como modelo de gestão de projetos no setor de Tecnologia da Informação de Instituições de Teófilo Otoni. Portanto. . como modelo de gestão de projetos no setor de TI de Instituições de Teófilo Otoni? As hipóteses criadas para responder a essa pergunta problema foram: H1: É viável utilizar o PMBOK® e o Scrum. onde permitirá o uso dos benefícios proporcionados pelas práticas das duas abordagens em questão para auxiliar nos processos do setor de TI.

Esta pesquisa é classificada quanto aos fins como uma pesquisa exploratória por objetivar uma maior familiarização com o problema e na construção de hipóteses que possa resolvê-los. . e também constitui uma pesquisa aplicada. também contribuirá como fonte para tomada de decisões no que se diz respeito ao desenvolvimento e implantação de futuros projetos. comprovar ou rejeitar hipóteses construídas pelos modelos teóricos. contribuirá na escolha entre qual a metodologia se enquadra mais adequadamente na sua organização ou no projeto que será desenvolvido. onde com base nos estudos realizados. ou até na utilização das características combinadas de ambas as abordagens que melhor adaptam-se ao seu projeto. Estudar o guia de práticas em gerenciamento de projetos PMBOK®. Esta pesquisa foi de grande importância. pois além de verificar a viabilidade da utilização das práticas em gerenciamento de projetos de um método tradicional em conjunto com uma metodologia ágil. Realizar uma abordagem comparativa entre as áreas de conhecimento do PMBOK® com a metodologia ágil de gerência de projetos Scrum.17 Os objetivos específicos pretendidos com este trabalho foram:    Estudar a metodologia ágil de gerência de projetos Scrum. Este trabalho também proporcionou um estudo comparativo entre o modelo tradicional PMBOK® e a metodologia ágil Scrum. Criar um framework híbrido utilizando práticas das duas abordagens estudadas.   Conhecer a realidade do setor de TI de Instituições de Teófilo Otoni. com o auxilio de um framework híbrido oriundo das duas abordagens estudadas. pois consiste em investigar. oferecendo uma gama de conhecimentos de como adaptar e usar as práticas em gerenciamento de projetos da melhor forma possível. possibilitando um maior entendimento relacionado ao tema abordado.

artigos e revistas. dentre outras definições técnicas que serão utilizadas no decorrer do trabalho. no quinto capítulo foram realizadas as considerações finais sobre o trabalho e apresentação de propostas para trabalhos futuros. pois é desenvolvida com base em materiais já elaborados oriundos principalmente de livros. expondo o que o tema aborda a problemática do trabalho. No terceiro capítulo foi realizado um estudo comparativo entre as nove áreas de conhecimento do PMBOK® com as práticas adotadas pela metodologia ágil Scrum. o primeiro capítulo refere-se à introdução da pesquisa.18 Pode-se definir esta pesquisa quanto aos meios como uma pesquisa bibliográfica. com o intuito de verificar a viabilidade de utilização das práticas em gerenciamento de projetos oferecidas pelo PMBOK® em conjunto com a metodologia ágil Scrum. Por fim. No segundo capítulo denominado referencial teórico. e o objetivo geral e objetivos específicos pretendidos com o mesmo. e também como uma pesquisa de campo. pois é complementada por um estudo de caso da utilização de uma técnica ou abordagem já estudada e na análise aprofundada de instituições em particular. as hipóteses criadas. No quarto capítulo foi apresentado um estudo de caso no setor de TI de duas instituições de Teófilo Otoni. . dando enfoque principalmente a apresentação do PMBOK® e do Scrum. Este trabalho está dividido em quatro capítulos. caracterizada como um estudo de caso. aborda conceitos iniciais sobre projetos. mostrando seus pontos de compatibilidade e diferenças. e propor um framework híbrido através das práticas das duas abordagens. gerência de projetos e metodologias ágeis.

serviço ou resultado exclusivo.1 O QUE É UM PROJETO? Segundo o PMBOK® (2004).1 GERÊNCIA DE PROJETOS Este capítulo tem como objetivo apresentar alguns conceitos iniciais sobre projetos. um projeto constitui um esforço temporário empreendido para criar um produto.S. custo e recursos [STANLEIGH. 2001]. Segundo a Organização das Nações Unidas (ONU). um projeto é um processo único. um projeto é um empreendimento com características próprias. custo e qualidade. Para a Norma ISO 10006. consistindo de um grupo de atividades coordenadas e controladas com data de início e término. REFERENCIAL TEÓRICO 2. De acordo com BRAGA (2003).19 2.1. que conjulga-se em um conjunto de atividades intercaladas e coordenadas a fim de alcançar objetivos específicos dentro dos limites de um orçamento e de um período de tempo estabelecido [I. conduzido por pessoas com a finalidade atingir metas estabelecidas dentro de parâmetros de prazo.A. incluindo limitações de tempo. um projeto é um empreendimento planejado. . 2. 2005]. voltados para alcance de um objetivo conforme requisitos específicos. tendo início e fim. gerenciamento de projetos e metodologias ágeis dando enfoque principalmente as práticas de gerência de projetos do PMBOK® e do Scrum.

objetivos. A capacidade técnica é outro fator de extrema importância para se obter resultados positivos. Para MARTINS (2003). que são essenciais para que se tenham caminhos criativos para realização das atividades e ao mesmo tempo comprometimento com as atividades que se está criando. A criação de um projeto requer uma estrutura organizacional adequada para desenvolvimento de novas idéias. com início. E por fim a criatividade e o comprometimento. ajudando no desenvolvimento da criatividade e na participação de todos. custo. caracterizado por uma seqüência clara e lógica de eventos. VARGAS (2009) define um projeto como sendo um empreendimento não repetitivo. um projeto constitui uma combinação de recursos organizacionais. Para CLELAND (2009). meio e fim. proporcionando o desenvolvimento de boas idéias e estratégias. sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo. Para cada projeto deve-se definir uma missão. que se destina a atingir um objetivo claro e definido. de modo a proporcionar um aperfeiçoamento da capacidade de desempenho no planejamento e na realização de estratégias organizacionais. um projeto pode ser conceituado como plano. 2009]. que é o profissional responsável por descobrir talentos individuais de cada participante. intento. colocados de forma conjunta para criar ou desenvolver algo que não existia previamente. prazo e qualidade. projetos são temporários e únicos. Diferentemente das operações baseadas em processos contínuos e repetitivos. . uma estrutura de processos ou atividades e uma forma de funcionamento [TALLES. devido às suas características ou condições exclusivas.20 Um projeto consiste em um empreendimento com objetivo identificável. propósito que se forma para realizar algo. além de algumas variáveis importantes como a distinção do papel do líder no grupo. requer tempo e paciência para que se possa trabalhar em conjunto. recursos envolvidos e qualidade. que consome recursos e opera sobre condições de custo.

” [PMBOK®. VARGAS (2009) descreve o gerenciamento de projetos como sendo um conjunto de ferramentas gerenciais que proporcionam as empresas desenvolverem um conjunto de habilidades. o ciclo de vida de um projeto foca basicamente em definir o começo e o término do projeto. estabelecendo qual a atividade deve ser realizada em cada fase.8]. Os gerentes de projetos podem dividir os projetos em várias fases com o intuito de obter melhor controle gerencial. O ciclo de vida também é o . tempo e custo predeterminado. a gestão de projetos é a aplicação de conhecimento. De acordo com BRAGA (2003). únicos e complexos. voltados ao controle de eventos não repetitivos. ferramentas e técnicas na administração eficiente das atividades do projeto. Custo e Qualidade. incluindo conhecimento e capacidades individuais.2 O QUE É O GERENCIAMENTO DE PROJETOS? O Guia PMBOK® (2004) define o conceito de gerenciamento de projetos da seguinte forma: “O Gerenciamento de Projetos é a aplicação de conhecimento. Segundo a PMI (2004). e encerramento. Estas fases são conhecidas como ciclo de vida dos projetos. gerenciar projetos envolve tomar decisões sobre:  Escopo. e quem deve estar envolvido. habilidades. Tempo.  Requisitos identificados (necessidades).1.3 O CICLO DE VIDA DO PROJETO. O conhecimento obtido com estudos e práticas dinamiza os processos de iniciação. 2. Segundo MARTINS (2003).  Diferentes necessidades e expectativas dos clientes e partes interessadas. p. ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação. execução. habilidades.21 2. 2004. e não identificados (expectativas). planejamento. execução. dentro de um cenário de qualidade.1. planejamento. controle e encerramento que compõem o projeto. monitoramento e controle.

Dentre eles.  O ciclo de vida avalia como o projeto está progredindo até o momento. podem ser citados os seguintes:  A análise correta do ciclo de vida determina o que foi. a Tabela 1 a seguir mostra a definição das principais partes interessadas em um projeto. ou não feito pelo projeto.4 PARTES INTERESSADAS EM UM PROJETO De acordo com o Guia PMBOK® (2004).1. 2. .22 responsável por definir o conjunto de processos que devem ser seguidos para que o projeto seja gerenciado com qualidade. As descrições do ciclo de vida de um projeto podem ser resumidas ou muito detalhadas. As descrições com alto nível de detalhamento envolvem a criação de formulários. Para VARGAS (2007). O ciclo de vida de um projeto tradicional é dividido basicamente em quatro fases: a fase conceitual. e listas de verificação para oferecer uma melhor estrutura e controle gerencial. cujos interesses podem ser afetados com o resultado da execução ou do término do projeto. as partes interessadas em um projeto são as pessoas e organizações ativamente envolvidas no projeto. a fase de execução e a fase de conclusão ou encerramento. o ciclo de vida propicia uma gama de benefícios para qualquer tipo de projeto.  O ciclo de vida permite que seja indicado qual o ponto exato em que o projeto se encontra no momento. Baseado no guia PMBOK® (2004). gráficos. a fase de planejamento.

no andamento do projeto. INFLUENCIADORES PMO Fonte: Desenvolvido pelo autor. geralmente relacionados com a gestão dos projetos . um dos mais importantes é o patrocinador do projeto. Consiste no departamento ou grupo que define e mantém os padrões de processo. Consiste na pessoa ou organização que utilizará o produto desenvolvido pelo projeto. A Figura 1 descreve as principais partes interessadas e sua relação com o projeto. Consiste no grupo que está executando o trabalho do projeto. Consiste na empresa cujos funcionários estão mais diretamente envolvidos na execução do trabalho do projeto. e gerenciar sua influência em relação aos requisitos para garantir um projeto bem sucedido. incluindo próprio gerente de projetos. A equipe de gerenciamento precisa identificar as partes interessadas. dentro da organização. Consiste na pessoa ou no grupo que fornece os recursos financeiros para o projeto. devido à posição de uma pessoa na organização do cliente ou na organização executora. podem influenciar. mas que.23 Tabela 1: Definição das Partes Interessadas em um Projeto PARTE INTERESSADA GERENTE DE PROJETOS CLIENTE/USUÁRIO ORGANIZAÇÃO EXECUTORA MEMBROS DA EQUIPE DO PROJETO EQUIPE DE GERENCIAMENTO DE PROJETOS PATROCINADOR DESCRIÇÃO Consiste na pessoa responsável pelo gerenciamento do projeto. . positiva ou negativamente. determinar suas necessidades e expectativas. O termo Stakeholders refere-se a todas as partes interessadas no projeto. Consiste nos membros da equipe do projeto que estão diretamente envolvidos nas atividades de gerenciamento dos projetos. Consiste nas pessoas ou grupos que não estão diretamente relacionados à aquisição ou ao uso do produto do projeto. Dentre as partes interessadas. que consiste na pessoa que financia ou defende o projeto dentro da organização.

As partes interessadas positivas beneficiam um resultado bem sucedido do projeto.1. habilidade para aplicar seus conhecimentos na prática. técnicas e ferramentas de gerenciamento. As partes interessadas em um projeto podem ocasionar influências positivas e negativas em um projeto. De acordo com MARTINS (2003). a pessoa para alcançar o nível de maturidade condizente com a função de um gerente de projetos deve possuir conhecimentos de conceitos básicos. A .24 Figura 1: Relação entre as Partes Interessadas e o Projeto Fonte: PMBOK®. o gerente de projetos se destaca dentro das organizações devido à evolução e relevância do gerenciamento dos projetos. 2004]. enquanto as partes interessadas negativas criticam o projeto. 2. enxergando resultados negativos a partir do sucesso do projeto [PMBOK®. Um gerente de projetos deve ter a capacidade de trabalhar em equipe.5 PERFIL DE UM GERENTE DE PROJETOS O gerente de projetos é a pessoa responsável pela realização dos objetivos do projeto. bem como a capacidade prática e aplicável destes conhecimentos. liderança. 2004. facilidade nos relacionamentos interpessoais e boa comunicação. Para MARTINS (2003).

Segundo estudos realizados pela Standish Group em 2001.  Monitoramento e controle dos riscos e da qualidade do projeto. Cada vez mais as organizações estão designando pessoas sem qualquer formação e capacitação para exercerem a função de gerente de projetos. podendo inclusive resultar em possíveis reduções. e imediata tomada de ações corretivas ou pró-ativas.  Retorno do investimento. 2004]. . permitindo a identificação prévia de desvios. O gerenciamento de projetos pode ser aplicado em empreendimentos de qualquer complexidade. A escolha de profissionais capacitados é fator crucial para sucesso dos projetos. custos e recursos. 23% são cancelados.25 profissão de gerenciamento de projetos é bastante promissora mediante a gama de oportunidades que está surgindo atualmente. os benefícios proporcionados pelo gerenciamento de projetos são os seguintes:  Controle efetivo de prazos. 94% são reiniciados pelo menos uma vez excedendo o orçamento original em 188% e o prazo original em 222%. a gestão de projetos tem-se destacado nos últimos tempos devido a sua eficácia. revelam que apenas 16% dos projetos são bem sucedidos. levando em consideração as deficiências na gestão de recursos.  Eficácia na integração e comunicação necessária durante todo o projeto. Para MARTINS (2003). que eventualmente possui remuneração inferior a de um profissional qualificado. e orçamentos definidos. com entrega conforme a especificação. 2. atraso e falhas de 1994 até 2008. além das entregas serem geralmente efetuadas fora dos prazos estabelecidos [MARTINS. e apenas 61% mantém o escopo original [SOTILLE. ocasionando aumento do custo final do projeto. 28% são realizados no prazo e orçamento especificados.6 BENEFÍCIOS DO GERENCIAMENTO DE PROJETOS Segundo MARTINS (2003). e para qualquer tipo de negócio. O Gráfico 1 mostra a evolução dos percentuais de sucesso. 2003]. conseguindo alcançar resultados desejados dentro dos prazos.1.

. Atraso e Falhas Um projeto bem sucedido é aquele que é realizado conforme o planejado. A certificação PMP (Project Management Professional) comprova o conhecimento aprofundado sobre o PMBOK®. Se o projeto gastou menos recursos que o previsto.26 Gráfico 1: Evolução dos Percentuais de Sucesso. houve uma falha no planejamento que permitiu que os recursos fossem superestimados. 2004]. 2004]. e não uma economia de recursos [SOTILLE. e das regras impostas pela PMI para exercer a profissão de gerente de projetos [PMI. tornando um diferencial e requisito em relação à especialização no assunto. Diante deste cenário. O Gráfico 2 a seguir mostra a importância do gerenciamento de projetos vista através da evolução do número de profissionais certificados PMP no mundo. as organizações estão cada vez mais optando por profissionais de gerência de projetos que possuem algum certificado que comprove o conhecimento na área.

respeito à cultura da organização e aceitação prévia do cliente. dentro do orçamento previsto com nível de desempenho adequado. o gerenciamento de projetos proporciona inúmeras vantagens em relação às demais formas de gerenciamento. utilizando recursos eficientes dentro das limitações de custo. A gestão profissional de projetos é a forma mais indicada a ser aderida pelas organizações para a realização de projetos.asp Para TORREÃO (2005). O gerente de projetos é a pessoa responsável por guiar todas as atividades do projeto.br/pmp/credenciados. tempo e desempenho. .27 Gráfico 2: Evolução dos credenciados PMP no Mundo Fonte: http://www.ietecnet. controle eficaz nas mudanças do escopo. tendo se mostrado bastante eficaz em conseguir os resultados desejados.com. podendo ser aplicado a empreendimentos de qualquer natureza. com alto nível de complexidade. De acordo com VARGAS (2007). devendo estar devidamente qualificado para exercer seu papel e garantir o sucesso do projeto. o sucesso na gestão de projetos pode ser mensurado através do alcance dos seguintes objetivos: entregas dentro do prazo estabelecido. dentro dos orçamentos e prazos definidos pela organização. A grande vantagem do gerenciamento de projetos é o fato de não ser restrito apenas a projetos grandes.

Logo mais tarde baseado nos comentários positivos recebidos pelos membros da PMI foi publicada a sua segunda versão. que é a principal referência para as organizações que estão em busca de melhorias em seus processos de gerenciamento [NARDI. a equipe de gerenciamento de projetos é responsável por determinar o que é adequado para um projeto específico. tornando-se a norma mundial relacionada ao gerenciamento de projetos. e que existe um consenso geral em relação ao seu valor e sua utilidade. “Boa prática” significa que existe acordo geral de que a aplicação correta dessas habilidades. 2. O PMBOK® é reconhecido pela ANSI (American National Standard). lançada em 2008. “Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo. 2004. O guia PMBOK® (2004) descreve o seu principal objetivo da seguinte forma: “O principal objetivo do Guia PMBOK® é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. O PMBOK® teve sua primeira publicação no ano de 1987. ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. grupos de processos. adições aos processos.” [PMBOK®. O PMBOK® pode ser usado como uma guia. . e não uma descrição completa. p. abrangendo seus conceitos.1 O QUE É O PMBOK®? O PMBOK® constitui um padrão formado a partir de um conjunto de conhecimentos e melhores práticas sobre a gerência de projetos. Uma boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos. e suas nove áreas de conhecimento em gerenciamento de projetos. fornecendo aos gerentes alternativas para se obter sucesso nos projetos.Project Management Body of Knowledge Esta seção objetiva demonstrar uma visão geral sobre a estrutura do PMBOK®.28 2. e foi desenvolvido pelo PMI (Project Management Institute).3]. 2009]. sendo um dos melhores e mais versátil documento disponível para gerência de projetos [PMBOK®. “Identificar” significa fornecer uma visão geral.2.2 PMBOK® . objetivos. 2004]. Atualmente está em sua quarta edição. A sua terceira versão teve publicação em 2004 com melhorias em sua estrutura original. termos e domínios do programa e do portfólio.

Fornece uma estrutura básica para o entendimento sobre gerenciamento de projetos. em 5 grupos básicos e 9 áreas de conhecimento. Qualidade. p. sendo que cada processo pode ser relacionado com uma área de conhecimento e a um grupo de processos. 2.2 GRUPOS DE PROCESSOS DO PMBOK® A base de conhecimentos em gerenciamento de projetos do guia PMBOK® (2004) é constituída por 44 processos estruturados. De acordo com o PMBOK® (2004). e Fechamento. O Guia PMBOK® (2004) reconhece 44 processos em cinco grupos de processos básico e nove áreas de conhecimento. Tempo. Especifica todos os processos de gerenciamento de projetos usados pela equipe do projeto para gerenciar um projeto. Cada uma das áreas de conhecimento do PMBOK® contém os processos que precisam ser realizados para a gestão dos projetos. Custo. . Os cinco grupos de processos do PMBOK® são: Iniciação.  Seção III: As áreas de conhecimento em gerenciamento de projetos. resultados ou serviços. a definição de processo é: “Um processo é um conjunto de ações e atividades inter-relacionadas realizadas para obter um conjunto pré-especificado de produtos. Comunicações. Risco. Execução. As nove áreas de conhecimento em gerência de projetos do PMBOK® são: Integração. Recursos Humanos. ele se divide três seções:  Seção I: A estrutura do gerenciamento de projetos.  Seção II: A norma de gerenciamento de projetos de um projeto. Controle e Monitoração. 38].29 De acordo com o próprio Guia PMBOK® (2004). Organiza os 44 processos de gerenciamento de projetos dos grupos de processos de gerenciamento de projetos. Planejamento. Escopo.” [PMBOK®. Aquisições. 2004.2.

e monitora regularmente o progresso do projeto a fim de identificar variações em . O Guia PMBOK® (2004) caracteriza os grupos de processos estruturados da seguinte forma:  Grupo de Processos de Iniciação: Define e autoriza o projeto e as fases do projeto. e o escopo para os quais o projeto foi realizado.  Grupo de Processos de Monitoramento e Controle: Assegura que os objetivos do projeto estão sendo cumpridos. bem como a seleção da melhor alternativa para alcançar os objetivos do projeto.  Grupo de Processos de Execução: Coordena pessoas e outros recursos para realizar o plano de gerenciamento de projetos. Figura 2: Os Grupos de Processos do Gerenciamento de Projetos O Fonte: PM Tech Capacitação em Projetos.  Grupo de Processos de Planejamento: Define e refina os objetivos.30 A Figura 2 mostra resumidamente os grupos de processos em gerenciamento de projetos que compõem o PMBOK®.

A Figura 3 a seguir mostra resumidamente as nove áreas de conhecimento do PMBOK® (2004) e seus respectivos grupos de processos. e abrange diversos processos de gerenciamento.2.  Grupo de Processos de Encerramento: Formaliza a aceitação do projeto. sendo ao todo 44 processos. Cada uma dessas áreas é responsável por uma parte do gerenciamento dos projetos.3 AS NOVE ÁREAS DE CONHECIMENTO DO PMBOK® O PMBOK® (2004).31 relação ao plano de gerenciamento de projetos. para que se possa tomar as devidas ações corretivas. 2004. serviço ou resultado. 2. possui em seu contexto nove áreas de conhecimento. e conduz o projeto ou uma fase do projeto a um final ordenado. Figura 3: Visão Geral das Áreas de Conhecimento do PMBOK® (2004) Fonte: PMBOK®. .

A seguir será apresentada cada uma das nove áreas de conhecimento que compõem o PMBOK®. 2. unificar e coordenar os diversos tipos de atividades do gerenciamento de projetos. definir. Figura 4: Mapeamento do Gerenciamento de Integração Fonte: Manual Prático do Plano Do Projeto. O termo de abertura do projeto concede aos gerentes o privilégio de aplicar os recursos organizacionais nas atividades do .32 As áreas de conhecimento do PMBOK® são os principais pontos a serem explorados a fim de garantir sucesso nos projetos desenvolvidos. 2004]. 2004]. o gerenciamento de integração objetiva principalmente garantir que todas as demais áreas estejam integradas. Para VARGAS (2009). A Figura 4 a seguir proporciona uma visão geral sobre os processos que compõem esta área de conhecimento. estruturando todo o projeto de modo a possibilitar que as necessidades dos envolvidos sejam atendidas pelo projeto.2. O Gerenciamento de Integração é responsável por fornecer processos necessários para assegurar que todos os elementos do projeto estão sendo gerenciados de forma correta [PMBOK®.4 GERENCIAMENTO DE INTEGRAÇÃO DO PROJETO O Gerenciamento de Integração é composto por processos e atividades necessárias para identificar. através dos grupos de processos que o compõem [PMBOK®. juntamente com seus grupos de processos. combinar.  Termo de Abertura do Projeto: Constitui um documento que autoriza formalmente um projeto.

2004].  Declaração do Escopo Preliminar do Projeto: Responsável em fornecer uma descrição em alto-nível do escopo do projeto. 2004]. Trata principalmente da documentação das necessidades de negócio. e consiste na execução de todo o trabalho definido pelo plano de gerenciamento de projetos. controle. do novo produto e da justificativa do projeto [PMBOK®. 2. Consiste na identificação. Trata principalmente da definição e controle do que está e do que não está incluso no projeto [PMBOK®.  Encerrar o Projeto: Consiste na finalização de todas as atividades e grupos de processos de gerenciamento de projetos. de forma que as mudanças aprovadas sejam incorporadas a uma linha de base revisada. coordenar e integrar todos os planos auxiliares em um plano de gerenciamento do projeto. e posteriormente o encerramento formal do projeto por completo. revisão.  Plano de Gerenciamento do Projeto: Responsável em incluir as ações necessárias em para definir. execução e encerramento.  Monitorar e Controlar o Trabalho do Projeto: Tem o objetivo de monitorar e controlar todos os processos associados com a iniciação.2. e manutenção das possíveis mudanças que venham a ocorrer. do atendimento atual das necessidades do cliente. planejamento. gerenciamento. rejeitando ou aprovando-as. .  Orientar e Gerenciar a Execução do Projeto: É diretamente afetado pela área de aplicação do projeto. atendendo aos objetivos definidos pelo plano de gerenciamento de projetos.  Controle Integrado de Mudanças: É realizado desde o início do projeto até o seu término.33 projeto.5 GERENCIAMENTO DE ESCOPO DO PROJETO O Gerenciamento de Escopo inclui os processos necessários para garantir que o projeto se complete somente com o trabalho necessário.

visando documentar como o escopo do projeto será definido.34 Segundo VARGAS (2007). sem deixar de realizar nenhum requisito estabelecido no objetivo do projeto. o gerenciamento de escopo tem como principal objetivo definir e controlar os trabalhos a serem realizados pelo projeto. organizando e definindo o escopo total do projeto. A definição do escopo fornece um entendimento comum do escopo do projeto a todas as partes interessadas no projeto. .  Planejamento do Escopo: Define a criação de um plano de gerenciamento do escopo do projeto. além de orientar o trabalho da equipe durante a execução do projeto. de modo a garantir que o produto ou serviço requisitado seja obtido através da menor quantidade de trabalho possível. Verifica e controla como a estrutura analítica do projeto (EAP) será criada. Figura 5: Mapeamento do Gerenciamento do Escopo Fonte: Manual Prático do Plano Do Projeto. descrevendo seus principais objetivos.  Definição do Escopo: Consiste na definição detalhada das entregas do projeto. A Figura 5 a seguir ilustra os processos que compõem o gerenciamento de escopo. e o trabalho necessário para realizar essas entregas. A Figura 6 a seguir exemplifica a estrutura de um projeto de software através de uma EAP de forma detalhada.  Criar EAP: Consiste na subdivisão do trabalho a ser executado pela equipe do projeto. e subdividindo todo o projeto em partes menores visando uma maior facilidade no gerenciamento.

tendo em vista que a maioria das pessoas que se interessam por projetos tem como objetivo inicial controlar prazos.35 Figura 6: Exemplo de um EAP Fonte: PMBOK®. . o gerenciamento de tempo juntamente com o gerenciamento de custos são as áreas mais visíveis do gerenciamento de projetos. 2.  Verificação do Escopo: Consiste na formalização através de um documento consistindo entregas que foram aceitas e entregas que não foram aceitas. Para VARGAS (2007). com intuito de controlar o impacto que essas mudanças geram no projeto. juntamente com os motivos da sua reprovação. 2004.  Controle do Escopo: Consiste no controle das mudanças no escopo do projeto. o Gerenciamento de Tempo do projeto inclui os processos necessários para garantir o término do projeto dentro dos prazos estabelecidos. confeccionar cronogramas e estabelecer custos.6 GERENCIAMENTO DE TEMPO DO PROJETO De acordo com o PMBOK® (2004).2.

36 Os processos que compõem essa área de conhecimento são os seguintes: definição de atividade. durações e seqüências de atividades para criar o cronograma do projeto. e quantidade de recursos necessários para realizar cada atividade do cronograma.  Desenvolvimento do Cronograma: Visa à análise dos recursos necessários.  Estimativa de Duração da Atividade: Consiste na estimativa do número de horas necessárias para se termine as atividades individuais do cronograma.  Estimativa de Recursos da Atividade: Consiste na estimativa do tipo. podendo ocasionar a reavaliação das estimativas de . a previsão da quantidade de recursos necessários para a finalização da atividade e o número de períodos de trabalho necessários. Esse processo determinara as datas de início e término das atividades. estimativa de recursos de atividades.  Definição da Atividade: Consiste em identificar e documentar as atividades específicas do cronograma.  Seqüenciamento de Atividades: Consiste na identificação e documentação das dependências entre as atividades do cronograma. seqüenciamento de atividades. A Figura 7 a seguir ilustra o mapeamento do gerenciamento de tempo de um projeto. Figura 7: Mapeamento do Gerenciamento de Tempo Fonte: Manual Prático do Plano do Projeto. desenvolvimento do cronograma e controle do cronograma. para produzir as entregas do projeto. restrições do cronograma.

o gerenciamento de custos do projeto tem o objetivo de assegurar que o projeto seja concluído dentro das limitações de orçamento previstas. gerando um cronograma para ser aprovado. O projeto pode entrar em execução somente após a aprovação prévia do orçamento. o principal objetivo do gerenciamento de custos de um projeto é garantir que o capital disponível será suficiente para obter todos os recursos necessários para se realizar os trabalhos do projeto. Segundo VARGAS (2007).  Orçamentação: Consiste em agregar os custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base de custos.  Controle do Cronograma: Consiste no controle das mudanças no cronograma do projeto. A Figura 8 ilustra os processos que compõem o gerenciamento de custos.7 GERENCIAMENTO DE CUSTOS DO PROJETO De acordo com o PMBOK® (2004). As definições orçamentárias do projeto devem ser realizadas por quem irá realizar o projeto. .2. 2.  Estimativa de Custos: Consiste em desenvolver uma estimativa de custos necessários para o término de cada atividade do projeto.37 duração e recursos. Figura 8: Mapeamento do Gerenciamento de Custos Fonte: Manual Prático do Plano do Projeto. servindo como linha de base para o projeto.

O principal responsável pelo gerenciamento da qualidade é o gerente de projetos. 2. do custo e do tempo [VARGAS. e determinação de como fazê-los.2.8 GERÊNCIAMENTO DE QUALIDADE DO PROJETO O objetivo mais importante desta área de conhecimento é assegurar que o projeto será concluído dentro dos níveis de qualidade previstos. Para o PMBOK® (2004). garantindo a satisfação das necessidades de todas as partes envolvidas. Os processos que compõem o gerenciamento de qualidade são ilustrados através da Figura 9 a seguir.  Planejamento de Qualidade: Visa identificar os padrões de qualidade relevantes para o projeto. e as mudanças no orçamento do projeto. prevenção de erros e a melhoria continua dos processos. Figura 9: Mapeamento do Gerenciamento de Qualidade Fonte: Manual Prático do Plano do Projeto. 2007].38  Controle de Custos: Consiste em controlar os fatores que criam variações de custos no projeto.  Realizar a Garantia da Qualidade: Consiste na aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos necessários para atender aos requisitos. devendo proporcionar igual prioridade a gestão da qualidade.  Realizar o Controle da Qualidade: Consiste no monitoramento de resultados específicos do projeto com o intuito de determinar se eles estão de acordo . o gerenciamento de qualidade de um projeto preocupa-se exclusivamente com a satisfação do cliente.

e identificação de maneiras para eliminar as causas de um desempenho insatisfatório. 2. Tendo em vista que os custos sofrem variação significativamente ao longo do ciclo de vida dos projetos. pois o envolvimento dos membros da equipe desde o início proporciona o fortalecimento do compromisso com o projeto. pois são elas que definem as metas. De acordo com o guia PMBOK® (2004) todos os membros da equipe devem ter intensa participação no processo de tomada de decisão do projeto.2. . os planos. Figura 10: Tipos de profissionais requeridos ao longo do projeto Fonte: Manual Prático do Plano do Projeto.39 com os padrões relevantes de qualidade.9 GERENCIAMENTO DE RECURSOS HUMANOS DO PROJETO Para VARGAS (2007) o gerenciamento de recursos humanos de um projeto tem como principal objetivo fazer o melhor uso possível dos indivíduos envolvidos no projeto. VARGAS (2007) afirma que as pessoas são a parte mais importante de um projeto. dependendo da natureza do trabalho a ser realizado e do nível de maturidade da equipe do projeto. os recursos humanos são requisitados em vários níveis de especialidade. A Figura 10 a seguir mostra os tipos de profissionais requisitados ao longo de cada fase do projeto. utilizando de suas habilidades técnicas e sociais. organizam o trabalho. coordenam e controlam as atividades do projeto.

elém de um plano pessoal de gerenciamento. dentre eles. . fornecimento de feedback .  Gerenciar a Equipe do Projeto: Visa o acompanhamento de desempenho de membros da equipe. responsabilidades e relações hierárquicas do projeto. armazenamento. distribuição. recuperação e destinação das informações sobre o projeto de forma adequada.10 GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO Segundo o PMBOK® (2004) esta área de conhecimento emprega os processos necessários que garantem a geração. controlar ou mobilizar a equipe do projeto.resolução de conflitos e coordenação de mudanças 2.  Desenvolver a Equipe do Projeto: Consiste em garantir a melhoria de competências e a iteração entre os membros da equipe para aprimorar o desempenho do projeto. coleta. Figura 11: Mapeamento do Gerenciamento de Recursos Humanos Fonte: Manual Prático do Plano do Projeto. desenvolver a equipe do projeto e gerenciar a equipe do projeto. A Figura 11 a seguir ilustra o mapeamento do gerenciamento dos recursos humanos do projeto.  Contratar ou Mobilizar a Equipe do Projeto: Objetiva obter os recursos humanos necessários para terminar o projeto.40 O gerenciamento de recursos humanos possui quatro processos principais.2.  Planejamento de Recursos Humanos: Consiste na identificação e documentação das funções. o planejamento de recursos humanos.

41 O gerenciamento das comunicações é necessário para assegurar que todas as informações desejadas cheguem às pessoas corretas. o relatório de desempenho. através de relatórios de andamento medição de progresso e previsão. O gerente de projetos utiliza a comunicação para garantir de que o time do projeto trabalhe de maneira integrada para resolver os problemas do projeto. A Figura 12 a seguir descreve o mapeamento dos principais processos do gerenciamento de comunicações. O PMBOK® (2004) subdivide o gerenciamento de comunicações em quatro processos básicos. dentre eles. As informações relacionadas .  Planejamento das Comunicações: Objetiva determinar as necessidades de informações e comunicações das partes interessadas no projeto.  Relatório de Desempenho: Tem como principal objetivo coletar e distribuir as informações sobre o desempenho do projeto.  Distribuição das Informações: O processo de distribuição das informações consiste em colocar as informações necessárias a disposição das partes interessadas no momento adequado. a distribuição das informações. tendo em vista que o fluxo de informações está exigindo cada vez mais agilidade e eficiência nas comunicações. o planejamento das comunicações. e gerenciar as partes interessadas. Figura 12: Mapeamento do Gerenciamento das Comunicações Fonte: Manual Prático do Plano do Projeto. Para VARGAS (2007) a comunicação deve ser vista nas organizações como uma estratégia de crescimento. se tornado um dos fatores principais para garantir o sucesso de um projeto.

42 ao relatório de desempenho podem incluir os recursos que estão sendo utilizados para garantir os objetivos do projeto. custo. descritos conforme a Figura 13. custo e qualidade do projeto. Os riscos de um projeto constituem um evento incerto. De acordo com o PMBOK® (2004). além de informações sobre o escopo. e minimizar a probabilidade de ocorrer eventos negativos no projeto. envolvendo os membros da equipe com intuito de identificar e responder aos possíveis riscos que podem ocorrer geralmente associados ao tempo. . o gerenciamento de riscos objetiva principalmente aumentar probabilidade de acontecer eventos positivos.11 GERENCIAMENTO DOS RISCOS DO PROJETO Segundo VARGAS (2007). a falta de pessoal designado para realizar alguma tarefa exclusiva do projeto. e resolver problemas com os mesmos. e qualidade. uma das causas pode ser. devido a problemas com as partes interessadas. Os riscos podem ocorrer por várias causas. custo.2. O PMBOK® subdivide o gerenciamento de riscos do projeto em seis principais processos. escopo ou qualidade do projeto. e se por ventura vier a acontecer poderá ter um efeito positivo ou negativo sobre pelo menos um dos objetivos do projeto. ou seja. afetando principalmente as especificações de tempo. 2. é um evento que pode ou não ocorrer. O gerenciamento das partes interessadas aumenta a probabilidade do projeto não desviar o foco. o gerenciamento de riscos do projeto possibilita a oportunidade de compreender melhor a natureza do projeto.  Gerenciar as Partes Interessadas: Consiste no gerenciamento das informações para satisfazer os requisitos das partes interessadas no projeto. cronograma. por exemplo.

 Identificação de Riscos: Consiste em determinar e documentar as características dos riscos que por ventura possam afetar o projeto.  Análise Quantitativa dos Riscos: É a análise numérica dos efeitos identificados nos objetivos gerais do projeto. os mesmos são quantificados através da atribuição de valores numéricos a estes riscos.43 Figura 13: Mapeamento do Gerenciamento de Riscos Fonte: Manual Prático do Plano do Projeto.  Análise Qualitativa dos Riscos: Prioriza e avalia a probabilidade de ocorrência e dos impactos dos riscos a partir de métodos que priorizam os riscos identificados para uma análise qualitativa.  Planejamento do Gerenciamento de Riscos: Consiste na tomada de decisões de como abordar. e a realização de novas avaliações em busca de novos riscos que possam afetar os objetivos do projeto.  Planejamento de Respostas a Riscos: Consiste no desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. planejar e executar as atividades de gerenciamento de riscos de um projeto.  Monitoramento e Controle dos Riscos: Tem o objetivo de acompanhar e monitorar os riscos identificados. Após a priorização dos riscos na análise qualitativa. .

A Figura 14 fornece uma visão geral dos principais processos que compõem o gerenciamento de aquisições.44 2. O gerenciamento de aquisições possui técnicas que possibilitam a compra de mercadorias ou a aquisição de algum serviço específico de forma adequada para dar andamento ao projeto. Para VARGAS (2007) o gerenciamento de aquisições possui como característica assegurar de que todo elemento externo participante do projeto irá garantir o fornecimento do seu produto ou serviço para o projeto. O gerenciamento de aquisições dispõe de processos que propiciam o gerenciamento de contratos e o controle de mudanças necessárias para administrar os contratos e pedidos de compra emitidos por algum dos membros do projeto.12 GERENCIAMENTO DE AQUISIÇÕES DO PROJETO De acordo com o PMBOK® (2004) o gerenciamento de aquisições inclui os processos necessários para comprar ou adquirir produtos ou serviços de fora da equipe do projeto.  Planejar Compras e Aquisições: Consiste na determinação do que comprar ou adquirir. e quando e como fazer isso. .2. O planejamento de compras e aquisições identifica quais as necessidades do projeto podem ser melhor atendidas pela compra ou aquisição de algum produto. especialmente se o comprador desejar ter influência ou controle sobre as decisões de contratação. com a finalidade de realizar os objetivos do trabalho. Este processo também inclui possíveis fornecedores. Figura 14: Mapeamento do Gerenciamento das Aquisições Fonte: Manual Prático do Plano do Projeto.

em projetos onde ocorrem constantes mudanças nos . preços. termos de confidencialidade.3 Desenvolvimento ágil O desenvolvimento ágil surgiu em meados da década de 90. usadas com o propósito de garantir que todos os fornecedores possuem um entendimento claro sobre a aquisição.  Solicitar Respostas de Fornecedores: Consiste na obtenção de informações. Elas devem ser aplicadas exclusivamente a projetos onde os requisitos atuais são estáveis e os requisitos futuros podem ser previstos. ou versões padronizadas de todas as partes dos documentos de licitação necessários. a fim de identificar possíveis fornecedores e solicitar respostas aos mesmos. Este processo inclui reuniões com licitantes. visando discutir formas de estabelecer princípios comuns compartilhados a todos os métodos. A partir desta reunião conhecida como “Aliança Ágil” foi estabelecido o “Manifesto Ágil”. além da obtenção de opiniões especializadas. cujos conceitos são:  Indivíduos e interações ao invés de processos e ferramentas. descrições padrões de itens de aquisição. Entretanto. as metodologias ágeis são apontadas como uma alternativa às abordagens tradicionais. 2. listas de verificação de critérios de avaliação de propostas.  Respostar rápidas a mudanças ao invés de seguir planos. e reuniões com possíveis fornecedores. ofertas ou propostas de produtos com os fornecedores. cotações. com o objetivo de proporcionar melhorias no desempenho dos projetos [SOARES. As ferramentas e técnicas utilizadas neste processo incluem contratos. 2008].  Colaboração do cliente ao invés de negociação de contratos. Segundo SOARES (2008). quando um grupo de dezessete especialistas em processos de desenvolvimento de software se reuniu em uma estação de esqui nos Estados Unidos da América.45  Planejar Contratações: Consiste em documentar os requisitos de produtos e serviços.

2. e as equipes são razoavelmente pequenas. 12. Manter uma equipe motivada fornecendo ambiente. promovendo a união entre a equipe e o cliente. 6. A prioridade é satisfazer ao cliente através de entregas de software de valor contínuas e freqüentes. A maneira mais eficiente da informação circular dentro da equipe é através de uma conversa face a face. requisitos e projetos provêm de equipes organizadas. 7. apoio e confiança necessário para a realização do trabalho.” [Reinert. 2008. p. Portanto. fazendo com que o mesmo participe continuamente do processo de criação do projeto [SOARES. sempre na menor escala de tempo.46 requisitos. dentre eles são: “1. Atenção contínua a excelência técnica e um bom projeto aumentam a agilidade. Com o presente trabalho pretende-se priorizar o aprimoramento e compreensão das técnicas do Scrum. mesmo em uma fase avançada. Todos envolvidos devem ser capazes de manter um ritmo de desenvolvimento constante. 4. As melhores arquiteturas. dando aos clientes vantagens competitivas. onde foram apresentadas suas características e definições nas seções seguintes. a equipe deve refletir sobre como se tornarem mais eficazes e então se ajustar e adaptar seu comportamento. Simplicidade é essencial. As equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente durante todo o projeto. 2008]. inúmeras metodologias de gerenciamento e desenvolvimento que já existiam começaram a ganhar espaço no mercado. Em intervalos regulares. A partir do conhecimento dos conceitos supracitados. 8.3]. Entregar softwares em funcionamento com freqüência de algumas semanas ou meses. as metodologias ágeis são as mais indicadas. Processos ágeis promovem o desenvolvimento sustentável. Ter o software funcionando é a melhor medida de progresso. . 11. 10. 5. o conceito ágil estabeleceu doze princípios para quem deseja trabalhar com metodologias ágeis. 9. 3. Receber bem as mudanças de requisitos. O conceito de agilidade enfatiza responder aos problemas da equipe de forma rápida e efetiva.

criada por Ken Schwaber e Jeff Sutherland. objetivando conseguir uma melhor avaliação do ambiente em evolução. . O Scrum tem como base o desenvolvimento com foco na equipe e com ciclos de iteração curtos [GONÇALVES. Ele se destaca dos demais métodos ágeis pela maior ênfase dada ao gerenciamento do projeto. De acordo com BOSSI (2007). sendo aplicável a ambientes voláteis. Segundo Marçal (2007) o Scrum pode ser descrito da seguinte forma: “O Scrum é um método que aceita que o desenvolvimento de software é imprevisível e formaliza a abstração. permitindo que cada participante da equipe faça o seu melhor. onde os requisitos estão em constante mudança.3]. 2008]. ou apenas algumas funcionalidades é desenvolvido. voltadas para o trabalho em equipe e melhoria da comunicação. Reúne atividades de monitoramento e feedback. É indicado ao desenvolvimento e gerenciamento de projetos em ambientes complexos. visando à identificação e correção de quaisquer deficiências e/ou impedimentos no processo de desenvolvimento. existe um vocabulário específico utilizado na metodologia Scrum:  Product Backlog: Lista de todas as funcionalidades a serem desenvolvidas durante o projeto completo.  Sprint: Período não superior a 30 dias. tornando-se uma alternativa para aumentar a produtividade das organizações [GONÇALVES. podendo ser aplicada no gerenciamento de qualquer atividade. e que possui como premissa estabelecer um processo de desenvolvimento iterativo e incremental. o Scrum dispõe de um conjunto de regras e práticas de gestão que devem ser adotadas para garantir o sucesso dos projetos.  Sprint Planning Meeting: Reunião de planejamento. O Scrum é aplicável tanto a projetos pequenos como grandes. em geral. 2008]. Segundo GONÇALVES (2008). p.4 Scrum O Scrum é uma metodologia ágil de desenvolvimento e gerenciamento de projetos.” [MAÇAL. onde o projeto. reuniões rápidas e diárias com toda a equipe. 2007.47 2.

no qual não é possível prever o que irá acontecer. não tem propriamente autoridade sobre os demais membros da equipe.  Scrum Master: Elemento da equipe responsável pela gestão do projeto. não define o que fazer em todos os casos. conhecidos como Sprints.  Desenvolvimento: Consiste na criação de várias Sprints para o desenvolvimento dos incrementos de funcionalidade do produto. 2. o Scrum não é um processo previsível.48  Sprint Review Meeting: Reunião de revisão. Segundo SOARES (2008) o ciclo de vida do Scrum é dividido em quatro fases:  Planejamento: Visa estabelecer uma visão do projeto. O desenvolvimento é dividido em intervalos de no máximo 30 dias.  Stagging: Consiste em avaliar as várias dimensões do projeto criando itens para o Product Backlog. Apesar de ser gestor. garantindo recursos para sua execução.  Sprint Backlog: Trabalho a ser desenvolvido numa Sprint de modo a criar um produto ou resultado a ser apresentado ao cliente. no máximo sete pessoas. onde os requisitos são pouco estáveis e as iterações são curtas.1 Ciclo de Vida do Scrum O ciclo de vida do Scrum baseia-se no princípio da utilização de equipes pequenas. .  Product Owner: Proprietário do produto. é utilizado para trabalhos com alto nível e complexidade.4. dispondo de um framework que serve como um guia de boas práticas para gerência de projetos.  Scrum Team: Equipe de desenvolvimento de uma Sprint.  Dayling Scrum: Reunião diária. Para PEREIRA (2005).

que consiste em uma reunião voltada para lições aprendidas. A Figura 15 a seguir ilustra de forma simplificada o ciclo de vida do Scrum. visando à melhoria dos processos para a próxima Sprint [PEREIRA. através da realização das reuniões diárias chamadas de Daily Meeting. Ao final da Sprint é realizada uma reunião de revisão. onde a equipe controla o andamento do desenvolvimento do projeto. que neste contexto chamado de Product Owner. onde o time demonstra a parte funcional desenvolvida na Sprint.com/blog/wp-content/uploads/2009/03/ciclo-de-vida. 2007]. . onde a equipe de desenvolvedores obtêm contato com o cliente.49  Releasing: Consiste na realização da entrega final ao cliente. A próxima fase consiste na execução da Sprint. denominada Sprint Review.png Antes da realização de uma Sprint. 2007]. 2007]. com duração de no máximo 15 minutos. Figura 15: Ciclo de vida do Scrum Fonte: http://paoloramos. chamada de Sprint Retrospective. é feita uma reunião de planejamento chamada Sprint Planning Meeting. visando assegurar que tudo ocorreu de acordo com os requisitos estabelecidos anteriormente no Product Backlog [PEREIRA. para decidir como será feito o trabalho e selecionar as tarefas que a equipe irá realizar dentro da Sprint [PEREIRA. Posteriormente realiza-se a reunião de retrospectiva. O progresso realizado no projeto pode ser visto através de um gráfico chamado Sprint Burndown.

 Pode mudar os requisitos e prioridades a cada Sprint. principalmente durante as reuniões de planejamento (Sprint Planning Meeting). cuja função é corrigir qualquer contratempo na utilização de suas práticas.  É responsável pelo retorno financeiro do produto. cujas pessoas envolvidas são divididas em três grupos : o Product Owner.  Prioriza os requisitos de acordo com o seu valor de mercado. Além de ser o responsável em dividir o trabalho em várias partes menores e manter o Product Backlog em ordem. o Scrum implementa um processo iterativo e incremental. com o intuito de priorizar as tarefas que serão realizadas na Sprint.  Aceita ou rejeita o resultado de cada Sprint. Outro papel muito importante do Scrum é o Scrum Máster. o Scrum Team.4. não sendo necessário que tenha um conhecimento aprofundado sobre o Scrum. que consiste na pessoa que trabalha exclusivamente com a equipe. O Scrum máster é o responsável em garantir a boa aplicabilidade das práticas do Scrum no projeto. O Product Owner tem o papel de representar os interesses de todos no projeto. decide a data de release e o que deve conter nela. também são responsabilidades do Product Owner segundo PEREIRA (2007):  Define os requisitos do produto. 2008]. e todos interagindo entre si. e durante as reuniões de revisão (Sprint Review). e o Scrum Master. e a equipe deve enxergá-lo como a pessoa que tem conhecimento amplo sobre o Scrum. Deve sempre estar disponível para a equipe. .2 Papéis De acordo com PEREIRA (2007). mas deve conhecer bem o trabalho que será desenvolvido.50 2. e tirar dúvidas referentes ao Scrum de qualquer pessoa envolvida no projeto [MAGNO. cada um com s sua função em específico.

responsável por desenvolver as funcionalidades do projeto. analista. as principais responsabilidades do Scrum Máster são:  Permitir que o time seja auto gerenciável.  Tem todo o direito de realizar o que quiser dentro da Sprint para cumprir seus objetivos. tais como designer.  Garantir que os caminhos para a comunicação da equipe estejam abertos permanentemente. Por fim. é responsável por realizar a versão de demonstração do produto finalizado. sendo responsável pelo sucesso de cada iteração e consequentemente do projeto como um todo. Todos os membros da equipe trabalham juntos no projeto com a intenção de atender aos requisitos do Product Backlog.organização do trabalho entre os membros da equipe de forma participativa. arquiteto. De acordo com PEREIRA (2007).  Remover qualquer impedimento que a equipe encontre. Nele não existe uma divisão através de funções como na abordagem tradicional. dentre outros. o Scrum Team. .  Auto .  Garantir e auxiliar equipe a seguir as práticas do Scrum.  Ao final da Sprint. as responsabilidades do Scrum Team são:  Selecionar entre os itens priorizados os que serão executados durante a Sprint.  Proteger a equipe de interferências externas para garantir que sua produtividade não seja afetada. que consiste na equipe de desenvolvimento composta de no máximo nove membros.51 Segundo MAGNO (2008).

que geralmente deve ser a primeira tarefa a se realizar antes de iniciar uma Sprint. Outro artefato de grande importância no Scrum é a Sprint Backlog. 2007]. prioriza os itens do Product Backlog e extrai os de maior relevância para serem inseridos na Sprint Backlog. Consiste basicamente em uma lista de itens priorizados que inclui tudo o que precisa ser realizado no projeto. A equipe juntamente com o Product Owner. Não há necessidade do Product Backlog estar totalmente completo antes do início do projeto. Os Principais artefatos do Scrum são: o Product Backlog. A priorização das atividades do Product Backlog deve ser feita pelo Product Owner. quando deve ser feito e como está o andamento do trabalho. . que consiste no conjunto de tarefas a serem executadas pelo time durante uma Sprint.52 2. A Figura 16 a seguir exemplifica um Product Backlog. sendo associado ao valor de negócio do cliente.4.3 Artefatos Os artefatos do Scrum consistem nos documentos que auxiliam no entendimento do que deve ser feito no projeto. Figura 16: Exemplo de um Product Backlog Fonte: Scrum e XP direto das Trincheiras. a Sprint Backlog e o Burndown Chart. O Product Backlog é o coração do Scrum. bem como a remoção de requisitos já existentes [PEREIRA. pois com o tempo pode ser feito a inclusão de novos requisitos.

Segundo PEREIRA (2007). a equipe de desenvolvimento questiona se realmente consegue assumir o compromisso de realizar as tarefas dentro da Sprint. facilitando a detecção de problemas no andamento da Sprint e a tomada de providências para a resolução dos mesmos.53 A equipe de desenvolvimento tem a função de estabelecer a quantidade de itens que serão inseridos no Product Backlog. a equipe passa para o próximo item. O Gráfico 3 a seguir exemplifica um Burndown Chart. Esse levantamento e seleção dos itens são feitos por meio da reunião de planejamento da Sprint [PEREIRA. e finalizar o item priorizado. Uma vez decidido o item. Após todas as tarefas estimadas. estimando em horas a duração de cada uma delas. para cada item inserido na Sprint. não permitindo que ultrapasse o limite máximo de tempo que é de 16 horas para cada tarefa. o time inicia o detalhamento de suas atividades. . 2007]. Gráfico 3: Exemplo de um Burndown Chart Fonte: Entendendo o Scrum para Gerenciar Projetos de forma Ágil. 2007] Por fim. A sua principal função é mostrar o ritmo de trabalho que o time está desempenhando. continuando o processo até que todos os itens da Sprint Becklog sejam concluídos [PEREIRA. o Burndown Chart. que consiste em um gráfico que representa a quantidade de horas que faltam ser completadas para atingir o objetivo da Sprint.

o Scrum Master e todo o Scrum Team.é uma reunião realizada durante o início de cada Sprint. . tendo como principal objetivo auxiliar no monitoramento. possibilitando a detecção de falhas durante o desenvolvimento e execução do projeto. Na Sprint Planning Meeting.4. Figura 17: Cerimônias do Scrum Fonte: Uma abordagem automatizada para monitorar o desenvolvimento ágil com Scrum. cada uma delas com objetivos bem peculiares e realizadas em momentos específicos do ciclo de vida. Esta reunião opcionalmente pode ser dividida em partes. Sprint Review e a Sprint Retrospective. 2009]. com duração de aproximadamente 8 horas. O Scrum possui quatro tipos de cerimônias: Sprint Planning Meeting.54 2. é de responsabilidade do Product Owner descrever as funcionalidades de maior prioridade para a equipe. devem estar presentes o Product Owner.4 Cerimônias As cerimônias do Scrum consistem nas reuniões feitas durante todo o ciclo de desenvolvimento do projeto. 2009]. Daily Scrum Meeting. conforme demonstrado através da Figura 17 a seguir [ALMEIDA. objetivando estabelecer o que será feito na próxima iteração. A reunião de planejamento ou Sprint Planning Meeting. Essas tarefas irão dar origem ao Sprint Backlog [ALMEIDA. gerenciamento e desempenho da equipe. a Sprint Planning 1 e a Sprint Planning 2 cada uma com duração de 4 horas. Durante a Sprint Planning Meeting. No decorrer da Sprint Planning Meeting a equipe faz perguntas de modo que seja capaz de transformar as funcionalidades em tarefas técnicas após a reunião.

onde o Scrum Team mostra o que foi feito durante a Sprint. cujo objetivo é identificar o que funcionou bem. geralmente na parte da manhã. proporcionando a todos o conhecimento dos impedimentos que ocorreram no dia. Outra cerimônia do Scrum é a Sprint Review. e priorizando o trabalho que se inicia no dia em questão [ALMEIDA. é ideal que a Daily Scrum seja realizada sempre no mesmo lugar e na mesma hora do dia.55 Outra cerimônia de grande importância é a Daily Scrum Meeting. Durante a Daily Scrum cada membro da equipe deve ter respostas para cada um destas três perguntas:  O que você fez ontem?  O que você fará hoje?  Há algum impedimento no seu caminho? Depois de detectados os impedimentos no Daily Scrum. ajudando a estabelecer as prioridades do novo dia de trabalho. e quais as atitudes vão ser tomadas para melhorar. Ao final da Sprint. Segundo PEREIRA (2007). pois as questões abordadas devem ser levadas para fora da reunião e tratadas por um grupo menor de pessoas que tem um conhecimento maior sobre o problema discutido [PEREIRA. 2009]. A Daily Scrum deve ter a participação de todos os membros da equipe. As pessoas que participam da Sprint Review são tipicamente o Product Owner. discutindo que foi feito no dia anterior. Esta cerimônia tem como objetivo difundir o conhecimento a todos os membros da equipe. o que pode ser melhorado. os mesmos devem ser tratados o mais rápido possível pelo Scrum Master. Nesta reunião consiste basicamente em apresentar a versão de demonstração das funcionalidades do projeto já concluídas. 2007]. que é uma reunião feita ao final de cada Sprint. e não deve ser utilizada como uma reunião para resolução de problemas. que consiste em uma reunião diária feita no início ou no fim de cada dia. o Scrum Team. . ocorre uma reunião chamada Sprint Retrospective. o Scrum Master.

Cliente comprometido (com autonomia para decidir). Rígido: seguir especificação predefinida. voltada para trabalhadores do conhecimento. Ênfase: papel do gerente. Burocrático: controlar sempre para alcançar o objetivo. ABORDAGEM ÁGIL Adaptativo: conhecer o problema. Planejamento direciona resultados (incentiva controlar). Comunicação gera confiança. Sucesso corresponde a entregar o planejado. Tabela 2: Comparativo entre a abordagem Tradicional X Ágil ABORDAGEM TRADICIONAL Preditivo: detalhar o que ainda não é bem conhecido. Cliente pouco envolvido. Retrabalho/reestruturação caros.56 3 ESTUDO COMPARATIVO: PMBOK® X Scrum Neste capítulo.voltada para o trabalho em massa. Gerenciamento no estilo comando e controle. Simplista: fazer algo simples agora e alterar se necessário. Orientado a pessoas: motivadas e comprometidas. Sucesso corresponde a entregar o desejado. resolver antes questões críticas. a qualquer custo. . Flexível: adaptar-se a requisitos atuais. A Tabela 2 a seguir demonstra resumidamente uma comparação entre a abordagem tradicional e a abordagem ágil. que podem mudar. Orientado a processos: podem garantir a qualidade. foi apresentado um estudo comparativo entre e as nove áreas de conhecimento tradicionais do PMBOK® com a metodologia ágil de gerenciamento e desenvolvimento de projetos Scrum. Gerenciamento no estilo liderança/ orientação. Ênfase: criatividade/flexibilidade e atenção às pessoas. Desenvolvedor ágil (colaborador). Requisitos conhecidos e estáveis. apresentado seus pontos de compatibilidade e diferenças. Desenvolvedor hábil (variedade). planejamento e disciplina fortes. Requisitos emergentes e mutáveis. Resultados direcionam planejamento (incentiva mudar). Documentação gera confiança. Retrabalho/reestruturação baratos.

. Tanto a abordagem ágil quanto a abordagem tradicional possuem características positivas e negativas. Utilização das práticas é crucial princípios e boas práticas devem ser levadas ao extremo. Abordagem ainda superficial para gerência de projetos. e o planejamento é feito no inicio de cada fase. Foco: projetos grandes ou que envolvam restrição de confiabilidade (exigem mais formalismo). e é a equipe de gerenciamento a responsável por definir todo o ciclo de vida do projeto. minimizando e dinamizando tarefas e artefatos. Foco na disciplina. Foca em questões ligadas ao trabalho técnico e valor agregado ao produto (resultado). escritos. Objetivo: controlar em busca de alcançar o objetivo planejado (em termos de tempo. praticados. No Scrum. Foca em questões ligadas ao gerenciamento. tanto de projeto quanto de processo. As fases são executadas uma após a outra. seguindo valores. 3. controlados e cobrados. Objetivo: simplificar processo de desenvolvimento. Responsabilidade recai sobre o processo da organização (menos suscetível a falhas) Foco na maturidade. quem está envolvido no trabalho e como controlar e aprovar cada fase do projeto [PMBOK®. a grande diferença entre as duas abordagens está no conjunto de propósitos de cada uma. Abordagem mais profunda para gerência de projetos. Conjunto de valores com atitudes e princípios definidos. decorrente da definição e uso de processos e modelos de maturidade. Premia o valor rápido obtido. desenvolvimento e Releasing. Premia a garantia da qualidade. 2004]. treinados.1 PMBOK® X Scrum: Ciclo de Vida No PMBOK®. Define geralmente qual o trabalho deve ser realizado. com equipes pequenas /médias (exigem maior adaptação). Foco: projetos de natureza exploratória e inovadores.57 Conjunto de processos com metodologia definida. Responsabilidade recai sobre o envolvimento e a experiência dos membros da equipe. estabelecendo quais são as ferramentas e técnicas mais adequadas a serem utilizadas para determinado tipo de projeto. Institucionalização de processos é crucial definidos.custo e escopo). princípios e boas práticas documentados na literatura. Stagging. o ciclo de vida do projeto é dividido em várias fases. o ciclo de vida do projeto é composto em quatro fases: à fase de planejamento. Fonte: Uma comparação entre o PMBOK® e a XPM.

2 PMBOK® X Scrum: Gerenciamento de Integração No PMBOK®. 2008]. planejamento e coordenação das atividades do projeto. O plano do projeto é realizado de forma bastante formal e detalhada. Na fase de integração. Figura 18: Comparação entre o ciclo de vida do PMBOK® e do Scrum Fonte: http://www. . 2004]. o gerente é o responsável pelo projeto e tem o controle total sobre ele [PMBOK. A Figura 18 abaixo ilustra uma comparação entre o ciclo de vida do PMBOK® e do Scrum. onde o planejamento é feito no início de cada Sprint e somente para aquela Sprint específica [MACIEL. a integração refere-se os objetivos.com.fokasearch. e somente no início do projeto.br/?p=229 3.58 O projeto é dividido em Sprints.

No Scrum.4 PMBOK® X Scrum: Gerenciamento de Tempo O Gerenciamento de tempo é semelhante entre os dois métodos. minimizando que possíveis impedimentos venham a ocorrer. No Scrum o gerente de projetos é representado pelo Scrum Master. o gerenciamento de tempo também é realizado através da elaboração de um cronograma. definindo o escopo detalhado no início do projeto. No PMBOK®. que define e discute as funcionalidades durante cada ciclo de desenvolvimento. 2008].59 No Scrum. estimativa de esforço e duração das atividades são definidos através da elaboração de um cronograma detalhado contendo todas as atividades necessárias para a execução do projeto [PMBOK®. inclusive o cliente. o escopo é definido com um alto nível de detalhamento. O gerenciamento de escopo deve ser realizado utilizando ferramentas centralizadas e processos de tomada de decisão. 3. onde são constantemente atualizados durante o decorrer do projeto. . havendo uma participação direta do cliente que é o responsável em definir a prioridade funcional de cara iteração [VIANA. 2004]. o plano do projeto é representado pelo Product Backlog e a Sprint Backlog. o gerenciamento de escopo tem a finalidade de garantir que o projeto termine apenas com o esforço necessário. mas com a intenção de permitir um melhor entendimento do trabalho. os processos de definição. mas com a peculiaridade de ser orientado exclusivamente ao produto que será produzido em cada iteração. onde toda a informação levantada deve ser documentada na especificação de requisitos. 3. onde após sua definição os requisitos são estabelecidos e priorizados com a participação de toda a equipe do projeto. No PMBOK®. que servirá de base para a gestão de mudanças durante o andamento do projeto [PMBOK®. e atua somente como um facilitador do projeto.3 PMBOK® X Scrum: Gerenciamento de Escopo O Gerenciamento de Escopo no PMBOK® não é compatível com o Scrum. 2004]. No Scrum.

Os processos de gerenciamento de qualidade destinam-se principalmente no monitoramento e controle da qualidade dos resultados do projeto. . onde são realizados testes desde o início do projeto. a fim de garantir a satisfação do cliente. mas o valor final do projeto pode sofrer variações muito grandes se não forem repassadas ao consentimento dos patrocinadores do projeto para ressarcimento do custo adicional. o gerenciamento de qualidade é voltado para criação de planos de testes a partir das especificações de requisitos e nos processos de verificação e validação. O foco está em controlar. monitorar e documentar as mudanças para que não afete o custo planejado inicialmente no projeto [PMBOK®. No PMBOK®. As alterações ocorridas durante o ciclo de desenvolvimento do projeto são críticas e afetam todo o projeto. para isso existe uma estimativa de custos dos recursos necessários para terminar as atividades do projeto. No Scrum. as duas abordagens são similares. e são incorporadas na iteração mais apropriada. No Scrum existe sempre a preocupação em atender o cliente. o gerenciamento de custos do projeto tem o objetivo de garantir que o projeto termine dentro do orçamento estabelecido. as alterações podem ser realizadas mesmo em fases avançadas do projeto. No Scrum. o diferencial entre os dois métodos está na forma de garantir e controlar a qualidade. havendo total consentimento do cliente. tanto o Scrum como o PMBOK® reconhecem a importância em planejar a qualidade do projeto. o gerenciamento de qualidade é realizado durante todo o ciclo de vida do projeto.6 PMBOK® X Scrum: Gerenciamentos de Qualidade Neste contexto.5 PMBOK® X Scrum: Gerenciamento de Custos No PMBOK®.60 3. 2004]. devido ao fato do projeto estar sendo elaborado de forma incremental a cada iteração desenvolvida. e assegurar que estes resultados estejam de acordo com o que o cliente deseja. 3. e dentro dos padrões de qualidade desejados.

exigindo profissionais habilidosos. que tem com principal objetivo melhorar os processos para a próxima Sprint. No PMBOK®. responsabilidades e as relações hierárquicas entre seus integrantes. é feita a Sprint Retrospective. a cada término de uma Sprint é feita a Sprint Review. mas com características bem peculiares. as etapas que já foram concluídas são entregues ao Product Owner. a definição coerente dos papéis e responsabilidades dos integrantes da equipe é um objetivo primordial dessa área de conhecimento. não exigindo necessariamente que toda a equipe tenha o mesmo nível. No Scrum. O planejamento de recursos humanos no PMBOK® visa organizar e gerenciar a equipe. No Scrum. proporcionando o melhoramento da interação e o desempenho dos membros da equipe. onde são realizadas as entregas das partes do projeto que foram concluídas durante a Sprint anterior ao Product Owner. a confiança e a colaboração dos integrantes da equipe é um fator essencial no projeto. Tanto no Scrum como no PMBOK®. verificando quais as práticas serão mantidas e quais deixarão de ser feitas. identificando e documentando as funções. pois cada membro é treinado e guiado através dos processos na execução de suas tarefas. O planejamento e a tomada de decisões são realizados em conjunto entre todos os participantes do projeto. No Scrum. 3. todos os integrantes da equipe têm a liberdade de fazer de tudo um pouco. . e a equipe é selecionada de acordo com as habilidades que cada pessoa desempenha visando atender aos requisitos do Product Backlog. onde o mesmo tem o privilégio de aceitar ou recusar estas entregas realizadas caso elas não atendam aos requisitos especificados anteriormente. Durante a Sprint Review. que irá verificar se realmente as entregas atendem aos requisitos estabelecidos.7 PMBOK® X Scrum: Gerenciamento de Recursos Humanos Neste contexto as duas abordagens são compatíveis.61 Ao detectar um problema no projeto o Scrum Master juntamente com Product Owner são os responsáveis em resolvê-los. Posteriormente. as premiações e comemorações pela realização de um projeto bem sucedido são comuns entre ambas as abordagens.

na revisão das Sprints e em todo processo de desenvolvimento do projeto. No monitoramento e controle dos riscos. O único ponto em comum entre o PMBOK® e o Scrum neste contexto é o fato de ambas as abordagens divulgarem e documentarem assuntos que são de extrema importância durante o decorrer do projeto.9 PMBOK® X Scrum: Gerenciamento de Riscos Neste contexto.62 3. planejamento de respostas. monitoramento e respostas aos eventos de riscos são realizados continuamente durante as reuniões de planejamento de cada iteração. análise.8 PMBOK® X Scrum: Gerenciamento de Comunicações Nesta área de conhecimento o PMBOK® e o Scrum se divergem. identificação e respostas aos riscos são comuns. com divulgação e acompanhamento dos resultados do trabalho feitos no decorrer do projeto. No Scrum. 3. devido ao fato de ser uma metodologia ágil traz melhorias no processo de comunicação e na interação entre os envolvidos no projeto. O objetivo primordial do gerenciamento das comunicações no PMBOK® é documentar todos os fatos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto. No PMBOK®. mas necessita de que as mesmas tenham maturidade suficiente para que não haja conflitos. No Scrum. a identificação. promovendo um constante feedback durante o processo de construção do projeto. garantindo a identificação. No Scrum o processo de comunicação é feito de forma colaborativa e direta entre os envolvidos no projeto através das reuniões diárias. O Scrum por não ter um nível de formalismo mais abrangente como acontece no PMBOK®. No PMBOK® o gerenciamento de comunicações é realizado de maneira formal e documentada. tanto o PMBOK® quanto Scrum a análise. proporciona uma maior aproximação entre as partes envolvidas no projeto. é feita uma reavaliação . avaliação. monitoramento e controle dos processos durante o ciclo de vida do projeto. quantificação. é feito um plano formal para o gerenciamento de riscos. as duas abordagens são similares.

63

durante as reuniões de retrospectiva das iterações, onde os riscos são analisados e revistos para que sejam eliminados para as próximas iterações. 3.10 PMBOK® X Scrum: Gerenciamento de Aquisições No PMBOK®, todo o processo de aquisições é realizado a partir do escopo e da documentação detalhada e bem definida, garantindo o controle e acompanhamento das atividades do projeto e do fornecedor, formalizando um contrato que obriga que tanto os representantes do projeto quanto os fornecedores cumpram o que foi combinado. No Scrum, há uma dificuldade muito grande em se estabelecer negociações através de contratos, devido ao fato da ocorrência constante de alterações no escopo original do projeto. Neste contexto não ha preocupação em definir detalhadamente o processo de aquisição de mercadorias. 3.11 PMBOK® X Scrum: Conclusão do Projeto No PMBOK®, o projeto só é finalizado após todas as entregas tiverem sido realizadas e documentadas. No Scrum, o término do projeto se da somente após todos os requisitos do Product Backlog estiverem sido concluídos.

64

4 ESTUDO DE CASO: Viabilidade de Utilização do PMBOK® e Scrum Neste capítulo foi apresentado um estudo de caso com a finalidade de verificar a viabilidade de utilização das práticas tradicionais do PMBOK® em conjunto com a metodologia ágil Scrum, como modelo de gestão de projetos no setor de Tecnologia da Informação de instituições de Teófilo Otoni, propondo um framework híbrido utilizando as duas abordagens. 4.1 Métodos adotados para o estudo de caso O método utilizado como estratégia de pesquisa neste trabalho foi o estudo de caso qualitativo, pois consiste em uma categoria que aborda a realidade de forma clara e objetiva, cujo principal foco é a análise de forma aprofundada e bem definida de um programa, uma instituição, um sistema educativo, uma pessoa ou uma unidade social [GIL, 2002]. A princípio, para a realização do estudo de caso que esta pesquisa contempla, foi realizada uma análise aprofundada a respeito do tema estudado, para posteriormente a construção de hipóteses, e problematizar as situações envolvidas no cenário atual da organização. O Estudo de caso em questão foi caracterizado como uma pesquisa descritiva e uma pesquisa de campo, pois foi realizado através da análise presencial do setor de Tecnologia da Informação de instituições de Teófilo Otoni e de entrevistas realizadas através de questionários aplicados aos responsáveis pelo setor, para o levantamento e coleta de dados. Posteriormente a fase de coleta de dados, foi feita uma análise e interpretação dos dados coletados, voltados aos objetivos da pesquisa, para em seguida a comprovação e validação do framework.

65

4.2 Descrição das Instituções analisadas O estudo de caso proposto por esta pespesa foi realizado em duas instituições da cidade de Teófilo Otoni, sendo a primeira uma Instituição de Ensino Superior, e a segunda, uma cooperativa do ramo de laticinios, que por motivos de segurança não tiveram seu nome e nem localização divulgados, por isso neste contexto serão denominadas respectivamente instituição A e instituição B. 4.2.1 Instituição A Fundada em 30 de setembro de 1953 por Juscelino Kubitschek de Oliveira, e federalizada em 17 de dezembro de 1960. A Instituição de Ensino Superior é constituída de três campus, abrigando seis faculdades e 23 cursos de graduação. O Campus Avançado da instituição é localizado na cidade de Teófilo Otoni (MG) e abriga três faculdades com nove cursos de graduação. A instituição conta com aproximadamente 500 servidores, entre professores, técnicos administrativos etc. Desde a sua criação, a Instituição vem desenvolvendo um importante trabalho de ensino, pesquisa e extensão, priorizando sempre a prestação de serviços às comunidades dos Vales do Jequitinhonha e do Mucuri. 4.2.2 Instituição B Fundada em 16 de dezembro de 1961, pelo idealismo de seus pioneiros, tem por missão disseminar princípios cooperativistas de produção, absorvendo e transformando os produtos agropecuários de seus associados em bens de consumo, de forma a satisfazer exigências de mercado realizando obras que possam viabilizar o crescimento e desenvolvimento sócio-econômico próprio e de seus cooperados, dotando-lhes de estímulos à cultura, ao uso de novas tecnologias e da consciência de cidadão de um novo tempo. A Instituição contribui para o abastecimento de lácteos, principalmente, das regiões nordeste e sudeste brasileira. Seus produtos industrializados, que levam a marca Cisne e Papagaio, têm o padrão de qualidade reconhecido em todo o território brasileiro.

3 Proposta de utilização de um framework híbrido Esta pesquisa demonstra que as diversas áreas de conhecimento do PMBOK® são completamente ou parcialmente adaptáveis com a metodologia Scrum. porém existem algumas práticas que são conflitantes. A figura 19 a seguir ilustra o novo ciclo de vida do Scrum agregando algumas práticas tradicionais importantes do PMBOK®.66 4. . A seguir foi apresentada uma proposta de utilização de um modelo de gestão contendo as melhores práticas de ambas as abordagens através de um framework híbrido. Figura 19: Novo ciclo de vida: PMBOK® e Scrum Fonte: Desenvolvido pelo Autor.

que consiste na pessoa responsável pelo setor de TI. realizada através da primeira reunião de planejamento. o gerente de projetos com base nas idéias expostas pelos demais integrantes da Sprint Planning 1 cria uma lista inicial de necessidades que devem ser produzidas para que a visão do projeto seja bem sucedida. O Product Backlog será exposto no ambiente de trabalho para todos os integrantes da equipe tomar conhecimento do que será feito no projeto. neste contexto denominada Sprint Planning 1. Figura 20: Exemplo do Novo Product Backlog Fonte: Desenvolvido pelo Autor. que neste contexto será denominado Product Backlog. a equipe de desenvolvimento do projeto. Etapa 2 .Visão do Projeto: A primeira etapa do framework consiste em uma visão geral de como será a estrutura do projeto.67 Etapa 1. onde serão reunidos o cliente que é representado por uma pessoa responsável pelo departamento que necessita dos serviços do setor de tecnologia da informação da instituição. A figura 20 a seguir ilustra o modelo de um novo Product Backlog que será utilizado neste framework. cuja competência é garantir que os objetivos do projeto estão sendo compridos. e posteriormente desenvolve um quadro. . contendo todas as funcionalidades do projeto que precisam ser atendidas.Product Backlog: Na segunda etapa do framework. e o gerente de projetos.

para posteriormente dar inicio ao ciclo de desenvolvimento. com o objetivo de priorizar os itens de maior importância do Product Backlog.Product Backlog Priorizado: Na quarta etapa do framework. e irá realizar o planejamento de aquisições e o planejamento de recursos humanos do projeto.Documentação: Na terceira etapa do framework. criar uma EAP com base no projeto que será desenvolvido. Figura 21: Exemplo de uma EAP específica Fonte: Desenvolvido pelo Autor Etapa 4 . o gerente de projetos. chamada Sprint Planning 2. detectar e documentar os possíveis riscos que podem ocorrer durante o andamento do projeto. A figura 21 a seguir ilustra um exemplo de estrutura de uma EAP específica que será utilizada neste framework. . para então criar a Sprint Backlog contendo os itens de maior relevância. a equipe de desenvolvimento e o cliente realiza a segunda reunião de planejamento.68 Etapa 3 . o gerente de projetos juntamente com a sua equipe de desenvolvimento irá realizar a documentação da descrição detalhada do projeto.

para que todos os integrantes da equipe tomem conhecimento dos requisitos e das tarefas mais importantes que devem ser desenvolvidas primeiramente.69 Etapa 5 . as atividades em andamento juntamente com o nome da pessoa responsável por essa atividade. .Sprint Backlog: Nesta etapa do framework. e as tarefas já concluídas. O quadro de itens priorizados deve ser colocado pelo gerente de projetos ao lado do Product Backlog. juntamente com as atividades que devem ser realizadas em cada um destes requisitos. a Sprint Backlog deve ser criada através de um quadro contendo os requisitos em ordem de maior importância. A figura 22 exemplifica como dever ser o quadro de itens priorizados do Product Backlog para esse framework. Após a conclusão de todas as atividades do primeiro requisito. automaticamente a equipe passa para o próximo requisito até que todos os requisitos sejam concluídos e a finalização do projeto ocorra. Figura 22: Quadro de itens priorizados Fonte: Desenvolvido pelo autor.

por padrão o DotProject utiliza o usuário “admin” e a senha é “passwd”. Após utilizá-lo.70 Para auxiliar no gerenciamento das atividades das etapas 2 e 5 deste framework. assim sua utilização independe de sistema operacional e instalação na máquina do usuário. como demonstrado a seguir através do seu tutorial de utilização. pois é executado em um servidor. Preencha o nome do usuário e senha Clique em login . O DotProject consiste em uma aplicação web e seu acesso é feito através de um navegador. com um conjunto de funcionalidades e características que o tornam indicado para implementação em ambientes corporativos. Tutorial de Utilização do DotProject O DotProject é um sistema de gerência de projetos em software livre de fácil utilização. que utiliza banco de dados MySQL. deve-se seguir os seguintes passos para 1º Passo: Fazer Login Fazer o login no sistema. pois atende a diversas necessidades de gerentes e Escritórios de Projetos. Em termos mais técnicos. o DotProject é um sistema escrito em PHP. instalado o DotProject. foi proposto a utilização da ferramenta de gerenciamento de projetos DotProject.

Técnico administrativo ou informática .71 Ao clicar em login aparecerá à seguinte tela: 2º Passo: Criar Usuário Deve-se cadastrar os usuários administradores que irão utilizar o sistema. e adicionar os projetos em que os mesmos irão trabalhar.Doutorando .Pós doutorando .Mestrando .Coordenação geral (usuários vinculados exclusivamente a administração da rede) .Pesquisador (todos os outros usuários) . Para adicionar um usuário é necessário: Acessar o link Administrar Usuários Clicar em adicionar usuário Preencher os campos Nome de usuário: deve possuir no mínimo quatro caracteres Grupo de usuários: selecione a categoria que este pertence .Iniciação científica .

Após clicar na aba “nova empresa” irá aparecer um formulário contendo os campos que devem ser preenchidos com as informações da empresa a ser cadastrada.72 Senha: deve conter no mínimo quatro caracteres Confirm Password: repetir a senha Nome: nome do pesquisador Instituição: selecione a Instituição que o usuário possui vínculo Divisão: selecionar o nó que o usuário possui o vinculo Clicar no botão 3º Passo: Cadastrar Empresa Para cadastrar uma empresa no sistema DotProject basta clicar a aba empresa e posteriormente em nova empresa. . basta preenche-los e clicar no botão “enviar”.

o projeto é alterado. Após clicar em “novo projeto” irá aparecer um formulário que deverá ser preenchido com as informações referentes ao projeto que será criado. dependências e recursos humanos. selecionar a empresa que será criado o projeto e em seguida clicar em “novo projeto”. é necessário acessar o projeto onde deseja inserir a tarefa. preencher as informações sobre a tarefa nas abas detalhes. ou seja. e em seguida clicar em salvar.73 4º Passo: Criar um Projeto Para adicionar um novo projeto. As tarefas devem ser vinculadas a um projeto e as informações cadastradas nestas. . datas. 5º Passo: Criando as tarefas. definem o projeto em que estas estão vinculadas. basta clicar em “empresa”. como datas. basta preencher os campos e clicar em “enviar”. dependências e recursos humanos. Para criar uma tarefa. qualquer alteração nas tarefas. clicar em nova tarefa.

 Selecione a empresa clicando sobre ela. .  Clicar sobre o nome do projeto que deseja inserir a nova tarefa.74 Para cadastrar uma nova tarefa é necessário acessar o projeto que deseja inserir esta tarefa.  Clique no link empresa.

Etapa 8 . dando continuidade ao desenvolvimento até que todos os itens do Product Backlog tenham sido finalizados. descrevendo tudo o que foi feito na Sprint. Nesta reunião também são realizados testes funcionais no produto desenvolvido. Após a reunião de retrospectiva o ciclo de desenvolvimento retorna a fase de priorização das atividades. para realizar a tomada de providências. após a priorização de todos os requisitos é dado inicio ao ciclo de desenvolvimento.Atualização da documentação: Nesta etapa. ficando a critério do gerente de projetos decidir o que é melhor para aquele determinado projeto. O objetivo principal desta reunião é promover melhorias para o próximo ciclo de desenvolvimento. Durante o ciclo de desenvolvimento da Sprint serão realizadas diariamente reuniões de no máximo 20 minutos objetivando disseminar a todos os componentes da equipe as barreiras encontradas naquele dia de trabalho. o gerente de projetos juntamente com sua equipe realiza uma reunião de retrospectiva após cada ciclo de desenvolvimento.Retrospectiva: Nesta etapa.75  Clique sobre o link nova tarefa. quais foram às barreiras encontradas durante andamento do projeto. traçando planos de ação para realizar essas melhorias. após a finalização de cada ciclo de desenvolvimento é realizado a atualização de toda a documentação do projeto. Etapa 7 . Etapa 9 . Etapa 6 . e o que pode ser melhorado para dar inicio a próxima Sprint. e o arquivamento . ou de apenas algumas funcionalidades. dentro do prazo estimado de 2 a 4 semanas para conclusão de todo o projeto. neste contexto denominado Sprint Retrospective. pois os membros da equipe irão identificar e priorizar o que consideram que foi bem e o que pode se melhorado.Sprint: Nesta etapa.Entrega Final: Nesta fase é realizado o fechamento e documentação do projeto a partir da conclusão de todos os itens do Product Backlog.

foram feitas análises presenciais no setor de Tecnologia da Informação de ambas as instituições citas anteriormente.4.76 das lições aprendidas durante o projeto com o intuito de minimizar falhas em projetos futuros. e projetos voltados para a área de redes de computadores. para o levantamento e coleta de informações. constatou-se que o mesmo não utiliza nenhuma metodologia ou procedimento capaz de orientar de forma eficaz os seus projetos. e entrevistas aplicadas aos responsáveis pelo setor TI. chefiados por 2 analistas de sistemas responsáveis pelo setor de TI. Após a reunião de planejamento do projeto a equipe define superficialmente o escopo do projeto para todas as partes envolvidas. onde foi constatado o seguinte: 4. o mesmo feito de forma informal. ocorre sempre uma tempestade de idéias desorganizadas (brainstorming) entre os componentes da equipe. onde ocorre o detalhamento do projeto que será executado. técnicos em informática. chefes de diretoria de Tecnologia da Informação e monitores de Informática. O setor de TI desenvolve projetos voltados aos interesses da instituição comumente em um período de 2 em 2 messes. Na fase de desenvolvimento de um projeto pelo setor de TI a equipe realiza reuniões bem superficiais entes do início de cada etapa. dentre eles.4 Diagnóstico das análises realizadas Para constatar a viabilidade ou inviabilidade da utilização da proposta deste trabalho. 4. tendo como principais projetos criados o desenvolvimento de sistemas.1 Instituição A O setor de Tecnologia da Informação da Instituição de Ensino Superior analisada neste trabalho é composto por 18 colaboradores. Quando se é requisitado um novo projeto. . e posteriormente a organização das mesmas para em seguida ocorrer o planejamento e desenvolvimento do projeto. ocorrendo sempre inconformidades nos resultados entregues ocasionadas pela falta de uma descrição detalhada do escopo. Após a análise do setor de TI da Instituição. analistas de sistemas. sempre de forma bastante informal.

Os projetos realizados não possuem um prazo predeterminado para sua conclusão. e dentre os principais projetos criados estão o desenvolvimento de sistemas. Na fase de conclusão de um projeto não são feitas documentações de todo o trabalho que foi realizado.4.2 Instituição B O setor de Tecnologia da Informação da cooperativa de laticínios analisada neste trabalho é composto por 2 colaboradores. 4. Ao ser requisitado para o desenvolvimento de um novo projeto. O setor de TI da Instituição de Ensino Superior analisada não possui políticas burocráticas para implantação de novos projetos e na maioria das vezes têm trazido resultados satisfatórios. porém com alguns contratempos ocasionados pela falta de um procedimento capaz de gerenciar suas atividades de forma eficaz. constatou-se que o mesmo também não utiliza nenhuma metodologia ou procedimento capaz de agilizar as tarefas relacionadas ao desenvolvimento dos seus projetos. Após a realização da análise no setor em questão. sendo 1 técnico em informática e 1 analista de sistemas.77 Alterações no escopo original do projeto desenvolvido pela equipe do setor de TI freqüentemente são requisitadas. e não há uma forma eficaz de estimar com precisão o tempo de duração de cada projeto criado. O cronograma do projeto na maioria das vezes possibilita um acompanhamento eficaz do projeto. mas a equipe não emprega nenhuma ação para garantir a qualidade das atividades que são desenvolvidas no projeto. Os custos relativos aos projetos geralmente são condizentes com o combinado. implantação de sistemas. o gerenciamento de suas atividades é . e realizadas sem algum tipo de documentação ou revisão. O Setor de TI desenvolve projetos voltados aos interesses da cooperativa mensalmente. e projetos relacionados a banco de dados. sem nenhum mecanismo capaz de priorizar as atividades de maior importância para serem desenvolvidas primeiramente. treinamentos de funcionários. mas também são feitos de forma informal sem nenhuma documentação ou controle de mudanças. As atividades realizadas pela equipe são feitas de forma seqüencial.

Visão do Projeto: No projeto NF-e foi realizada uma reunião inicial.Documentação: No projeto NF-e não houve a construção de uma EAP. Etapa 5 . a equipe do setor de TI da cooperativa determinou quais as tarefas precisariam ser executadas para dar andamento ao projeto.Product Backlog: Ao final da reunião descrita na etapa1 do framework. caracterizando um Product Backlog. Houve o planejamento das aquisições na área de TI e na área contábil.Sprint: Os prazos para conclusão de cada funcionalidade estavam balizados pelo tempo final da entrega de todo o projeto. Etapa 2 . gerando atrasos na iniciação das tarefas posteriores. onde seguindo as etapas do framework constatouse o seguinte: Etapa 1. Etapa 3 . entretanto nenhuma política de gestão neste sentido foi realizada. As reuniões diárias e a gestão de riscos nesta fase não foram realizadas. onde se obteve uma visão geral de como seria a estrutura deste projeto. no qual os membros da contabilidade expuseram para o setor comercial e o departamento de tecnologia as determinações legais e conseqüências fiscais da não realização do projeto da nota fiscal eletrônica. conforme descreve a primeira etapa do framework. Etapa 4 . indicando os possíveis riscos caso algum prazo fosse extrapolado.Product Backlog Priorizado: No projeto NF-e foram construídas listas de tarefas a serem executadas. entretanto não houve documentação formal para acompanhar o desenvolvimento delas. . sendo assim não houve determinação formal da entrega de cada uma das funcionalidades.78 feito apenas através da descrição superficial das tarefas a serem executadas por meio de editores de texto. A fase de execução foi baseada através da utilização do framework proposto no projeto de implantação do sistema de nota fiscal eletrônica (NF-e) já desenvolvido pela equipe de TI da cooperativa. observando critérios de prazo e custos. planilhas eletrônicas e ferramentas de compartilhamento de arquivos. o gerenciamento de riscos não foi levantado formalmente.

Etapa 7 . ocasionando erros freqüentes na maioria das funcionalidades desenvolvidas. evidenciando assim o atropelamento das outras tarefas em função do pouco tempo para o cumprimento do projeto final.79 Etapa 6 .Entrega Final: No projeto NF-e não foram aplicadas nenhuma das propostas apresentadas pelo framework para o fechamento do projeto.Retrospectiva: No projeto NF-e não ocorreu nenhuma reunião de retrospectiva objetivando realizar o levantamento dos pontos positivos e negativos em cada funcionalidade desenvolvida. o mesmo foi entregue informalmente no início da simulação do ambiente operacional. Também não ocorreram testes funcionais no projeto visando corrigir possíveis erros.Atualização da documentação: Não houve atualização na documentação criada em função da falta de procedimentos que monitorasse estas ocorrências. Etapa 8 . .

foi apresentado um estudo comparativo entre as duas abordagens estudadas. revelando que o uso combinado dos dois paradigmas cria um método de gerenciamento preventivo. reuniões diárias e reuniões de retrospectiva apresentada pelo Scrum. Entretanto existem algumas atividades que são conflitantes e apresentam particularidades. principalmente no que se diz respeito aos processos de gerenciamento de projetos do PMBOK® e da metodologia ágil Scrum. Conforme apresentado no inicio deste trabalho de conclusão de curso. Posteriormente. só os torna mais ágeis. Porém o único segredo esta em saber adaptá-los corretamente. onde pode-se concluir que as nove áreas de conhecimento do PMBOK® são adaptáveis com a metodologia Scrum. eficazes e preventivos. Neste sentido. que não onera os projetos em termos de documentação. com o intuito de auxiliar aos gerentes ou até mesmo as organizações a entenderem um pouco melhor sobre estes paradigmas. Primeiramente este trabalho concentrou-se em estudar fundamentos teóricos sobre o tema abordado. Em seguida.80 5 CONSIDERAÇÕES FINAIS Esta pesquisa apresentou um estudo sobre duas abordagens muito utilizadas atualmente para gerenciamento e desenvolvimento de projetos. o objetivo geral do mesmo foi analisar a viabilidade de utilização do PMBOK® e o . busca auxiliá-los a escolher qual o melhor se adapta a sua realidade ou até mesmo no uso combinado de suas práticas. como é o caso das reuniões de planejamento. foi visto a criação de um modelo de gerência de projetos através do uso combinado das práticas do PMBOK® em conjunto com a metodologia ágil Scrum através de um framework híbrido.

Esta hipótese não foi validada. pois proporcionará mais qualidade aos projetos desenvolvidos. de forma a contribuir com a disseminação da comunicação entre a equipe de desenvolvimento. o resultado final dos projetos é satisfatório. uma vez que atende as necessidades dos usuários. Neste contexto comprovarmos que o uso do modelo proposto irá acrescentar inúmeros benefícios ao referido setor. conclui-se que é perfeitamente viável a utilização de ambos os paradigmas em conjunto. foram mencionadas algumas hipóteses onde pode-se chegar as seguintes conclusões : H1: É viável utilizar o PMBOK® e o Scrum. aplicados ao setor de Tecnologia da Informação de instituições de Teófilo Otoni. H3: Não é viável. não ocorrendo inconformidades no que foi requisitado. . pois foi comprovado que com a utilização do modelo proposto. Após a realização deste trabalho. pois foi comprovado que em nenhuma das instituições analisadas possui um processo de documentação eficaz dos projetos realizados. uma vez que é mais fácil corrigir erros em cada funcionalidade em particular do que no projeto como um todo. pois foi demonstrado que a realização de testes em cada ciclo de desenvolvimento garante a redução do tempo final do projeto. pois a utilização de testes em cada ciclo de desenvolvimento poderá ocasionar atrasos na entrega do projeto final. H2: É viável. Essa hipótese foi validada. Essa hipótese foi validada. onde foi levantada uma proposta de investigação que buscou responder a seguinte questão problema: É viável utilizar o PMBOK® e o Scrum em conjunto como modelo de gestão de projetos no Setor de TI de instituições de Teófilo Otoni? Para tal modelo ser utilizado. como modelo de gestão de projetos no setor de TI de instituições de Teófilo Otoni.81 Scrum. pois obrigará a documentação para melhorar a comunicação e conseqüentemente o conhecimento da equipe sobre o projeto.

. somente é necessário saber como aplicar os processos para cada projeto em particular.82 principalmente no que diz respeito ao gerenciamento de seus projetos. segura e eficiente. podendo-se destacar: o aumento do controle gerencial pela subdivisão das principais etapas do projeto em componentes menores e mais facilmente gerenciáveis com uso de uma EAP. fica a sugestão para trabalhos futuros o desenvolvimento de uma aplicação fundamentada nos paradigmas estudados. proporcionando uma prestação de serviços mais ágil. e o melhoramento de habilidades para atender as exigências dos usuários internos da instituição. o envolvimento de todos os participantes do projeto em todas as fases. Para finalizar. Porém. para auxiliar no desenvolvimento de projetos no setor de Tecnologia da Informação.

2007 MARTINS. Disponível em: www.visaoagil.ietec. 4ª Ediçao. André Silva. PMBOK x SCRUM: Como gerenciar um projeto de software? 2009. GIL. 2008. 2007. 2003. Disponível em: http://www. São Paulo 2002. 2009. Edição 4 2008. 2010 FRANCO. Gestão de Projetos em Pequenas e Médias Empresas: Principais dificuldades.com. Metodologias Ágeis para o Desenvolvimento de Software. Marcio. Antonio Carlos.com.br/site/techoje/categoria/detalhe_artigo/83. Sucessos e Falhas em Projetos de TI. Estendendo o SCRUM segundo as áreas de processo de gerenciamento de projetos do CMMI. Ultimo acesso em 12/10/2010 às 09:40 MIRANDA. Gestão Profissional de Projetos. Como Elaborar Projetos de Pesquisa. Gerência de Projetos: Preparação para a Certificação PMP. M. Alcir Rodrigues.ietec. Um modelo de gerenciamento de projetos baseado nas metodologias ágeis de desenvolvimento de softwares e nos princípios da produção enxuta. Ultimo acesso em 13/09/2010 às 10:00 MAGNO. Kleber. Alexandre.br/site/techoje/categoria/detalhe_artigo/677. Leonardo Vieira. NARDI. GONÇALVES. Ultimo acesso: 11/10/2010. Revista Visão Ágil – Scrum Master por Ele Mesmo. Novembro 2003. J. Disponivel em: http://www.83 REFERÊNCIAS BIBLIOGRÁFICAS BRAGA. DAVILA. Eduardo Ferreira.com. MARÇAL. Scrum eExtreme Programming X Metodologias Tradicionais RUP. Ana Sofia. .

2008.br/elgg/html/pg/ file/benhur/read/349/entendendo-scrum-para-gerenciar-projetos-de-forma-gil.com/wp-content/uploads/2010/04/comparacaoentremetodologias. 2007. Manual prático do plano do projeto. Comparação entre metodologias ágeis e tradicionais para desenvolvimento de software. 2004.ietec.Rio de Janeiro. Ambiente Inteligente de aprendizado para Educação em Gerenciamento de Projetos.Project Management Body of Knowledge. Mundo PM.com/ricardo. 2009. Paulo. Dissertação (Pós-Graduação em Ciência da Computação) – Universidade Federal de Pernambuco. 2005. Paula.br/site/techoje/categoria/detalhe_artigo/393.pdf.fatecinformatica. Ultimo acesso em 15/09/2010 às 15:10. Brasport. Combinando a Norma ISO 10006 e o Guia PMBOK para garantir sucesso em projetos. ultimo acesso em 26/09/2010às 20:30. 2005. STANLEIGH. Disponível em: http://www. Disponível: http://www. Disponível em: http://www. Ricardo. . 3ª Ed.lapjor. Ultimo acesso em 25/09/2010 às 14:20 VARGAS.vargas/docs/manualprat. SOARES. Gerenciamento de projetos em processo ágil de desenvolvimento de software.cce. Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos.ufsc. PEREIRA. Michael.Rio de Janeiro. Brasport. Terceira Edição. Jonatas Davson. Ultimo acesso em: 25/09/2010 às 16:00 REINERT. Recife.com. Entendendo o Scrum para Gerenciar Projetos de Forma Ágil. Michel dos Santos. Departamento de Informática e Estatística – Universidade Federal de Santa Catarina. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 3ª Ed. Antonio Geraldo Gonçalves. 2007. Disponível em:http://issuu. Guia PMBOK. Ricardo. VIANA.84 PMBOK . VARGAS. TORREÃO. Estudo do uso de Metodologias Ágeis no Desenvolvimento de uma aplicação de governo eletrônico.

.......... Em quais cursos?.... 18 R: Instituição B.............................Qual a formação das pessoas da equipe? ( ) Ensino Médio: Quantos da equipe?...85 ANEXO 1 Roteiro de Entrevista (questionário utilizado para o levantamento e coleta de informações) Identificação da Empresa Nome: Endereço: Cidade: Ramo de Atuação: Identificação do Entrevistado Nome: Email: Formação: Cargo na Empresa: Atividade que Desenvolve: Questionário 1 .. ( ) Ensino Superior: Quantos da equipe?........................ ......Qual o número de colaboradores que trabalham no setor de Tecnologia da Informação da Instituição? 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5 ( ) Quantos?....... 2 2 ................... ( ) Ensino Técnico: Quantos da equipe?..... R: Instituição A.

86 R: Instituição A. 12 com ensino médio, 2 com ensino técnico, 3 com ensino superior em Sistemas de Informações e 1 em ciência da computação.

R: Instituição B. 1 com ensino médio, e 1com ensino superior completo em ciência da computação. 2 - Quantos são os responsáveis pela gestão de projetos no setor de TI da instituição? R: Instituição A. 3 pessoas. R: Instituição B. 1 pessoa. 3 - Qual a freqüência média de implantação de projetos desenvolvidos pelo setor de TI da instituição? ( ) Semanal ( ) Mensal ( ) Bimestral ( ) Semestral ( ) Anual

R: Instituição A. Bimestral. R: Instituição B. Mensal. 4 - Qual é o tipo de projeto mais desenvolvido pela equipe de Tecnologia da Informação da Instituição? ( ( ( ( ) Desenvolvimento de Sistemas. ) Implantação de Sistemas. ) Banco de dados. ) Treinamentos.

Outros? ..................................................................... R: Instituição A. Desenvolvimento de Sistemas e redes de computadores. R: Instituição B. Desenvolvimento de Sistemas, Implantação de Sistemas, Banco de dados, e treinamentos. 5 - O setor de TI utiliza algum tipo de metodologia para gerenciamento ou desenvolvimento de seus projetos? Se utiliza, o que levou a instituição a adotar esse modelo?

87 R: Instituição A. Não. R: Instituição B. Não. 6 - Como se da o gerenciamento de projetos no setor de TI da instituição? Cite as etapas, funções desempenhadas e ferramentas utilizadas. R: Instituição A. 1 - Tempestade de idéias (brain storming), 2 - organização da idéias, 3 - Planejamento, 4 - Ação, 5 - Manutenção. R: Instituição B. O gerenciamento se pauta apenas em descrições de tarefas a serem executadas utilizando-se de um editor de texto, planilhas eletrônicas e ferramentas de compartilhamento de arquivos. 7 - O setor de Tecnologia da Informação realiza alguma reunião de planejamento com todas as partes envolvidas no projeto antes do inicio de cada etapa do projeto? Justifique. R: Instituição A. Sim, antes de ter as idéias iniciais são feitas reuniões de planejamento. R: Instituição B. Apenas na etapa inicial, entretanto não há controle automatizado dos cumprimentos dos prazos, tarefas e custos estabelecidos nesta reunião. As demais ocorrem há medida que surgem problemas que impeçam o andar do projeto. 8 - Como é feito o detalhamento do projeto a ser executado? R: Instituição A. Deforma informal. R: Instituição B. Informalmente, utilizando-se de ferramentas eletrônicas ou não. 9 - Como são documentadas as etapas de realização de cada projeto? R: Instituição A. Não são, e quando são somente é realizado eletronicamente. R: Instituição B. Não há documentação. 10 - O Escopo do projeto é definido claramente para todos os envolvidos, ou ocorrem inconformidades nos resultados entregues, ocasionados pela falta de uma especificação detalhada do escopo?

88 R: Instituição A. Sempre há inconformidades. R: Instituição B. O Escopo de projeto é definido, entretanto não é detalhado o suficiente para que os resultados dos entregáveis produzam algo sem erros. 11 - Como são controladas as solicitações de mudanças e alterações no escopo do projeto e qual forma de registro destas alterações? R: Instituição A. Informalmente, sem revisão. R: Instituição B. Não são controladas e sim impostas, isto é, as alterações que surgem no decorrer do projeto geralmente são regidas por normativas legais e/ou estratégicas, sem que haja documentação formal para registrá-las. 12 - A instituição possui algum tipo de cronograma para auxiliar no gerenciamento do tempo das entregas do projeto? R: Instituição A. Sim, bem informal e impresso. R: Instituição B. Não possui. 14 - Como são controladas e documentadas as mudanças no cronograma do projeto? R: Instituição A. Não são controladas. R: Instituição B. Não são controladas. 13 - Se possui, o cronograma possibilita o acompanhamento eficaz do projeto? R: Instituição A. Na maioria das vezes sim. R: Instituição B. Não possui um cronograma. 15 - Os projetos possuem algum prazo máximo predeterminado para sua conclusão? Comente.

entretanto a prioridade segue a orientação para os atos Legais em função de penalizações por descumprimento de prazos.Os custos dos projetos são planejados e acompanhados adequadamente. R: Instituição A. são as penalidades. Sim. Geralmente sim. Todos os projetos têm prazos pré-determinados. R: Instituição B. geralmente não são completados dentro do cronograma. R: Instituição B. R: Instituição B. Sim. Todos os outros mecanismos não são tratados formalmente. ou ocorrem custos adicionais nos projetos ocasionados pela falta de uma gestão eficaz? . no caso dos Legais. Há claramente duas espécies de projetos na empresa: O Legal.As atividades e os prazos de conclusão apresentados são condizentes com o combinado? R: Instituição A. Os projetos Legais devem ter seus prazos confirmados uma vez que há penalizações severas no caso de atrasos. 17 . inserido por alguma normativa Federal. Os projetos Estratégicos.89 R: Instituição A. mesmo com prazo pré-estabelecidos. Tratase de uma reunião semanal entre os Gerentes para deliberação de assuntos de todas as áreas da empresa. Não possui um prazo máximo de conclusão predeterminado devido ao fato de que nem sempre é possível estimar com precisão o tempo de duração de cada projeto. Estadual ou Municipal. e o Estratégico. Não existe. O segundo mecanismo vale para todos os projetos.Existe algum mecanismo utilizado para priorizar as funcionalidades mais importantes a serem desenvolvidas no projeto? Comente. O primeiro mecanismo é externo. 18 . inserido por determinação da Direção da Empresa para fins de melhoria funcional. 16 .

Sim.Os projetos desenvolvidos pelo setor de TI da instituição tem trazido resultados satisfatórios? R: Instituição A.Durante a fase de execução de um projeto na instituição quais ações são realizadas com o intuito de garantir que o projeto emprega todos os processos de qualidade necessários para atender aos requisitos especificados? R: Instituição A. Nesta fase há treinamentos in loco deste ambiente. Se sim. e algumas vezes controlando o projeto. Entretanto acho que a TI deva passar por reformulações nas suas atividades primárias. Na medida do possível sim. 19 . como? R: Instituição A. São duas políticas claras adotadas pelo setor de TI: a) Testes das funcionalidades: Bateria de testes visando validar os resultados alcançados com os requisitos especificados. R: Instituição B. Sim são planejados. 21 . 20 .90 R: Instituição A. R: Instituição B. entretanto podem surgir novas funcionalidades e o planejamento de custo é alterado informalmente. Sim. Nenhuma ação é empregada. R: Instituição B. principalmente na . Sim. Direcionando e cobrando as especificações do Projeto. utilizando-se material e os recursos humanos que serão usados diretamente na produção. b) Simulação do ambiente operacional: Trata-se de execução das tarefas implementadas no próprio ambiente de funcionamento das atividades. controlando.O responsável pelo setor que necessita dos serviços do Setor de TI da instituição participa ativamente no projeto. Geralmente os custos são adequados. Planejando. R: Instituição B.

Política Legal e Estratégica. R: Instituição B. Acho extremamente necessária algumas produções de artefatos do PMBOK em conjunto com interatividade e fluidez do Scrum. Os dois.O Scrum e o PMBOK® são metodologias de gerenciamento de projetos que vem ganhando adeptos em todo o mundo devido ao seu feedback positivo. por auxiliarem na organização e agilizarem as tarefas. R: Instituição B.Quais são as políticas adotadas pela instituição para a implantação de novos projetos? R: Instituição A. Não há políticas. 23 . para que haja maior produtividade funcional com ganhos reais para a empresa. . Voçê acha viável utilizar algum destes modelos no setor de TI desta instituição? R: Instituição A. Sim. 22 .91 área de desenvolvimento.

au) trabalha serviços correlacionados ao mesmo. Para resumir. por isso ele vai precisar ser instalado em um servidor. Para instalar o dotproject primeiramente precisa-se baixar o pacote.saki.net/sourceforge/dotproject/dotproject-2.tar. No Debian esse diretório seria o /var/www ou no public_html. Como já foi dito anteriormente.gnu. konqueror.0.txt) e tem seu desenvolvimento mantido principalmalmente pela a empresa qual australiana mantendo Saki Computers extras (http://www.com. Você pode também simplificar esse primeiro passo simplesmente com os comandos:  # apt-get install wget .Download As etapas de instalação do DotProject a seguir será baseada na plataforma Linux.92 ANEXO 2 Tutorial de Instalação do DotProject O dotProject é um programa distruibuido sob licença GNU-GPL (http://www.org/licenses/gpl. como customização. Se preferir clique no link abaixo. Para usuários acessarem o DotProject eles devem usar um browser (Mozilla firefox. o servidor que terá o DotProject deverá ter:  LAMP: Linux+Apache+MySQL+PHP  WAMP: Windows+Apache+MySQL+PHP  WIMP: Windows+IIS+MySQL+PHP Passo 1 . o DotProject é um software online. No site oficial você irá achar o pacote. suporte técnico e etc. e esse servidor tem de ter suporte a PHP e MySQL.  http://ufpr.gz Em seguida deve descompactar em algum diretório que tenha acesso a web e permissão de escrita.4. opera. internet explorer e etc).dl. Para outros sistemas existem diretórios diferentes.sourceforge.

Configurando usuários Para poder ter privilégios de escrita. Passo 3 .4.93   # cd /var/www # wget -c -nd http://ufpr.tar. . você precisa configurar o usuário para que ele possa fazer o que precisa."># tar xzvf dotproject2.tar.Acessando a pasta Depois que tiver baixado o pacote e modificado as permissões você deve iniciar a instalação. para isso você deve digitar os seguintes comandos no terminal: Para configurar o root como dono de todos os arquivos digite: o chown -R root dotproject Para ajustar as permissões dentro do DotProject você deve digitar no terminal: o chmod o+w dotproject/includes o chmod o+w dotproject o chmod o+w dotproject/files Feito isso as permissões estão liberadas para que você instale o DotProject na sua máquina.4.sourceforge. para isso entre na pasta citada anteriormente usando o browser. Basta digitar o endereço seguinte na barra de endereço do seu browser:  http://localhost/dotproject Feito isso vai aparecer uma tela para você clicar no link para iniciar a instalação e configuração do DotProject (Star Installation).0.0.gz<LI< a> style="text-align:justify.gz Passo 2 .dl. leitura etc. Obs: Essas permissões serão modificadas posteriormente para assegurar a segurança do sistema.net/sourceforge/dotproject /dotproject-2.

Se você já tiver criado o banco de dados para o dotProject basta colocar a senha escolhida no campo DATABASE USER PASSWORD e clicar em install db & write cfg e seguir para o passo 6. o banco de dados está criado com os privilégios necessários. caso contrario siga para o passo 5. Feito isso vá até o navegador que está na página de instalação e digite a senha que você definiu na criação do banco de dados no campo DATABASE USER PASSWORD. Clique no botão install db & write cfg . já que Algumas das configurações podem resultar em falha parcial ou completa da instalação. para isso basta você abrir o terminal e digitar os seguintes comandos:  mysql -u root  CREATE DATABASE NOME_DO_BANCO_DE_DADOS  GRANT ALL PRIVILEGES ON nome_do_banco_de_dados* to "dpuser"localhost" IDENTIFIED BY "SENHA"  FLUSH PRIVILEGES  Quit Pronto. Confira os detalhes da pagina. Se precisar fazer modificações as faça e depois atualize a página.94 Passo 4 . Passo 5 .Criando Banco de dados Você vai precisar criar um banco de dados para o DotProject. Por exemplo.Iniciando a Instalação Depois de ter clicado no link referido acima você vai entrar numa nova página. se você não tiver modificado as permissões no passo 2 terá que fazé-lo para suportar upload de arquivos ou para permitir escrita na configuração principal.

Sign up to vote on this title
UsefulNot useful