Monografia Pmbok e Scrum PDF

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
Dedicamos a Deus por ter nos
acompanhado nesta trajetória, dando - nos
força e inspiração para concluir este
trabalho.
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.
Aos nossos familiares, pela base sólida que sempre nos deu incentivo para
encarar a vida de frente e nunca desistir dos nossos sonhos.
Ao nosso orientador, Prof. 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.
Ao professor Prof. Salim Ziad Pereira Aouar pela disponibilidade de nos
ajudar sempre que necessitamos.
Por fim, agradecemos aos demais professores e amigos da faculdade que
fizeram parte dessa jornada, e que nos influenciaram de forma determinante para a
conclusão deste trabalho.
Não se deve julgar o mérito de um homem
pelas suas grandes qualidades, mas pelo
uso que sabe fazer delas.
(La Bruyère)
SUMÁRIO
1 INTRODUÇÃO ....................................................................................................... 15
2 REFERÊNCIAL TEÓRICO ..................................................................................... 19
2.1 GERÊNCIA DE PROJETOS ............................................................................. 19
2.1.1 O que é um projeto? ................................................................................ 19
2.1.2 O que é o Gerenciamento de Projetos? ............................................. 21
2.1.3 Ciclo de Vida do Projeto ...................................................................... 21
2.1.4 Partes Interessadas em um Projeto ..................................................... 22
2.1.5 Perfil de um Gerente de Projetos ......................................................... 24
2.1.6 Benefícios do Gerenciamento de Projetos .......................................... 25
2.2 PMBOK® - Project Management Body of Knowledge ....................................... 28
2.2.1 O que é o PMBOK®? ............................................................................... 28
2.2.2 Grupos de Processos do PMBOK® ......................................................... 29
2.2.3 As nove áreas de Conhecimento do PMBOK® ........................................ 31
2.2.4 Gerência de Integração do Projeto .......................................................... 32
2.2.5 Gerência de Escopo do Projeto ............................................................... 33
2.2.6 Gerência de Tempo do Projeto ................................................................ 35
2.2.7 Gerência de Custo do Projeto .................................................................. 37
2.2.8 Gerência de Qualidade do Projeto ........................................................... 38
2.2.9 Gerência de Recursos Humanos do Projeto ............................................ 39
2.2.10 Gerência de Comunicações do Projeto .................................................. 40
2.2.11 Gerência de Riscos do Projeto .............................................................. 42
2.2.12 Gerência de Aquisições do Projeto ........................................................ 44
2.3 Desenvolvimento ágil ........................................................................................ 45
2.4 Scrum ................................................................................................................ 47
2.4.1 Ciclo de Vida do Scrum ....................................................................... 48
2.4.2 Papéis .................................................................................................. 50
2.4.3 Artefatos .............................................................................................. 52
2.4.4 Cerimônias........................................................................................... 54
3 ESTUDO COMPARATIVO: PMBOK® x Scrum ..................................................... 56
3.1 PMBOK® X Scrum: Ciclo de Vida ............................................................... 57
3.2 PMBOK® X Scrum: Gerenciamento de Integração ..................................... 58
3.3 PMBOK® X Scrum: Gerenciamento de Escopo .......................................... 59
3.4 PMBOK® X Scrum: Gerenciamento de Tempo .......................................... 59
3.5 PMBOK® X Scrum: Gerenciamento de Custos ........................................... 60
3.6 PMBOK® X Scrum: Gerenciamento de Qualidade ...................................... 60
3.7 PMBOK® X Scrum: Gerenciamento de Recursos Humanos ...................... 61
3.8 PMBOK® X Scrum: Gerenciamento de Comunicações ............................... 62
3.9 PMBOK® X Scrum: Gerenciamento de Riscos ............................................ 62
3.10 PMBOK® X Scrum: Gerenciamento de Aquisições ................................... 63
3.11 PMBOK® X Scrum: Conclusão do Projeto................................................. 63
4 ESTUDO DE CASO: Viabilidade da utilização do PMBOK® e o Scrum ............... 64
4.1 Métodos adotados para o estudo de caso ................................................... 64
4.2 Descrição das instituições analisadas.......................................................... 65
4.2.1 Instituição A ................................................................................................... 65
4.2.2 Instituição B ................................................................................................... 65
4.3 Proposta de utilização de um framework híbrido ......................................... 66
4.4 Diagnóstico das análises realizadas ............................................................ 71
4.4.1 Instituição A ................................................................................................... 71
4.4.2 Instituição B ................................................................................................... 72
5 CONSIDERAÇÕES FINAIS ................................................................................... 75
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 78
ANEXOS ................................................................................................................... 80
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, no setor de Tecnologia da Informação de instituições de
Teófilo Otoni. Este trabalho demonstrou o uso dos benefícios proporcionados por um
método inovador, baseado na junção de práticas tradicionais e ágeis, com o intuito
de apresentar uma nova forma de garantir qualidade e agilidade nos projetos
desenvolvidos pelo setor de Tecnologia da Informação. Para tal objetivo ser
alcançado, foi realizada uma análise comparativa entre ambos os paradigmas
estudados identificando seus pontos de compatibilidades e diferenças, e
posteriormente a criação de um framework híbrido oriundo das práticas dos dois
métodos.
Palavras-chave: Scrum.PMBOK®. Gerenciamento de Projetos. Metodologia ágil.

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

LISTAS DE FIGURAS
FIGURA 1 - Relação entre as Partes Interessadas e o Projeto................................ 24

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

GRÁFICO 2 - Evolução dos credenciados PMP no Mundo ...................................... 27
GRÁFICO 3 - Exemplo de um Burndown Chart ........................................................ 53
LISTA DE TABELAS
TABELA 1 - Definição das Partes Interessadas em um Projeto ................................ 23

TABELA 2 - Comparativo entre a abordagem Tradicional X Ágil .............................. 56
LISTA DE ABREVIATURAS E SIGLAS
PMBOK - Project Management Body of Knowledge

TI - Tecnologia da Informação
ONU - Organização das Nações Unidas
PMI - Project Management Institute
PMO - Project Management Office
PMP - Project Management Professional
ANSI - American National Standard
EAP - Estrutura Analítica de Projetos
NFe - Nota Fiscal Eletrônica
15
1. 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, buscando obter o aprimoramento de suas
habilidades e técnicas, a fim de se submeter a uma constante atualização,
proporcionando assim a garantia de um diferencial competitivo.
Contudo observa-se um crescente aumento na implantação de projetos nas

organizações, tendo em vista que os mesmos estão cada vez mais modernos
requerendo uma alta diversidade de habilidades, grande complexidade técnica, além
de ambientes cada vez mais exigentes em termos de recursos.
Pesquisas realizadas pela Standish Group revelam que a maioria dos

projetos tendem a falhar, seja porque não cumprem o cronograma, as
funcionalidades não atendem às necessidades dos usuários ou porque não
cumprem o orçamento especificado. Apenas 26% dos projetos são bem sucedidos,
o restante ou são abortados ou não cumprem os requisitos estabelecidos.
Tendo como base esta realidade e visando melhorias nesses tipos de

projetos, metodologias de gerenciamento e desenvolvimento surgiram no mercado
com intuito de guiar todo o ciclo dos projetos, atuando com dois tipos de abordagens
diferentes, as tradicionais e as ágeis. Dentre as abordagens tradicionais, o PMBOK®
(Project Management Body of Knowledge), 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. Em contrapartida,
a abordagem ágil vem se destacando e ganhando adeptos em todo o mundo. O
Scrum constitui uma metodologia ágil para gerência de projetos inicialmente de
software, porém pode ser aplicado a qualquer contexto onde pessoas precisem
trabalhar juntas para obter um objetivo comum.
16
Mediante aos fatos supracitados, a presente pesquisa foi desenvolvida no 8º

período do curso de Sistemas de Informações, como requisito para obtenção do
título de bacharel em Sistemas de Informações, e abrange algumas áreas do curso
como a Engenharia de Software e a Gerência de Projetos.
A pesquisa em questão contempla minimizar os contratempos enfrentados

pelas empresas de Teófilo Otoni, principalmente no setor de Tecnologia da
Informação (TI), que devido à acirrada concorrência, se é cada vez mais exigido
uma maior produtividade e qualidade, 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.
Este trabalho visa propor a utilização de um método inovador, 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, como o controle efetivo
dos prazos, custos e o constante monitoramento dos riscos e qualidade do projeto.
Portanto, tendo como base este cenário o problema motivador desta

pesquisa foi: É 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?
As hipóteses criadas para responder a essa pergunta problema foram:
H1: É viável utilizar o PMBOK® e o Scrum, pois proporcionará mais

qualidade aos projetos desenvolvidos.
H2: É viável, pois obrigará a documentação para melhorar a comunicação e

conseqüentemente o conhecimento da equipe sobre o projeto.
H3: Não é viável, pois a utilização de testes em cada ciclo de

desenvolvimento poderá ocasionar atrasos na entrega do projeto Final.
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, 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.
17
Os objetivos específicos pretendidos com este trabalho foram:
 Estudar a metodologia ágil de gerência de projetos Scrum.
 Estudar o guia de práticas em gerenciamento de projetos PMBOK®.
 Realizar uma abordagem comparativa entre as áreas de conhecimento

do PMBOK® com a metodologia ágil de gerência de projetos Scrum.
 Conhecer a realidade do setor de TI de Instituições de Teófilo Otoni.
 Criar um framework híbrido utilizando práticas das duas abordagens

estudadas.
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, também contribuirá como fonte para tomada
de decisões no que se diz respeito ao desenvolvimento e implantação de futuros
projetos, possibilitando um maior entendimento relacionado ao tema abordado,
oferecendo uma gama de conhecimentos de como adaptar e usar as práticas em
gerenciamento de projetos da melhor forma possível, com o auxilio de um framework
híbrido oriundo das duas abordagens estudadas.
Este trabalho também proporcionou um estudo comparativo entre o modelo

tradicional PMBOK® e a metodologia ágil Scrum, onde com base nos estudos
realizados, contribuirá na escolha entre qual a metodologia se enquadra mais
adequadamente na sua organização ou no projeto que será desenvolvido, ou até na
utilização das características combinadas de ambas as abordagens que melhor
adaptam-se ao seu projeto.
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, pois
consiste em investigar, comprovar ou rejeitar hipóteses construídas pelos modelos
teóricos.
18
Pode-se definir esta pesquisa quanto aos meios como uma pesquisa
bibliográfica, pois é desenvolvida com base em materiais já elaborados oriundos
principalmente de livros, artigos e revistas, e também como uma pesquisa de campo,
caracterizada como um estudo de caso, 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.
Este trabalho está dividido em quatro capítulos, o primeiro capítulo refere-se

à introdução da pesquisa, expondo o que o tema aborda a problemática do trabalho,
as hipóteses criadas, e o objetivo geral e objetivos específicos pretendidos com o
mesmo.
No segundo capítulo denominado referencial teórico, aborda conceitos

iniciais sobre projetos, gerência de projetos e metodologias ágeis, dando enfoque
principalmente a apresentação do PMBOK® e do Scrum, dentre outras definições
técnicas que serão utilizadas no decorrer 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, mostrando seus pontos de compatibilidade e diferenças.
No quarto capítulo foi apresentado um estudo de caso no setor de TI de

duas instituições de Teófilo Otoni, 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, e propor um framework híbrido através das
práticas das duas abordagens.
Por fim, no quinto capítulo foram realizadas as considerações finais sobre o

trabalho e apresentação de propostas para trabalhos futuros.
19
2. REFERENCIAL TEÓRICO
2.1 GERÊNCIA DE PROJETOS
Este capítulo tem como objetivo apresentar alguns conceitos iniciais sobre
projetos, gerenciamento de projetos e metodologias ágeis dando enfoque
principalmente as práticas de gerência de projetos do PMBOK® e do Scrum.
2.1.1 O QUE É UM PROJETO?
Segundo o PMBOK® (2004), um projeto constitui um esforço temporário

empreendido para criar um produto, serviço ou resultado exclusivo.
De acordo com BRAGA (2003), um projeto é um empreendimento com

características próprias, tendo início e fim, conduzido por pessoas com a finalidade
atingir metas estabelecidas dentro de parâmetros de prazo, custo e qualidade.
Para a Norma ISO 10006, um projeto é um processo único, consistindo de

um grupo de atividades coordenadas e controladas com data de início e término,
voltados para alcance de um objetivo conforme requisitos específicos, incluindo
limitações de tempo, custo e recursos [STANLEIGH, 2005].
Segundo a Organização das Nações Unidas (ONU), um projeto é um

empreendimento planejado, 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.S.A, 2001].
20
Um projeto consiste em um empreendimento com objetivo identificável, que

consome recursos e opera sobre condições de custo, prazo e qualidade. Para cada
projeto deve-se definir uma missão, objetivos, uma estrutura de processos ou
atividades e uma forma de funcionamento [TALLES, 2009].
Para MARTINS (2003), um projeto pode ser conceituado como plano,

intento, propósito que se forma para realizar algo. Diferentemente das operações
baseadas em processos contínuos e repetitivos, projetos são temporários e únicos,
devido às suas características ou condições exclusivas.
VARGAS (2009) define um projeto como sendo um empreendimento não

repetitivo, caracterizado por uma seqüência clara e lógica de eventos, com início,
meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido
por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos
envolvidos e qualidade.
Para CLELAND (2009). um projeto constitui uma combinação de recursos

organizacionais, colocados de forma conjunta para criar ou desenvolver algo que
não existia previamente, de modo a proporcionar um aperfeiçoamento da
capacidade de desempenho no planejamento e na realização de estratégias
organizacionais.
A criação de um projeto requer uma estrutura organizacional adequada para

desenvolvimento de novas idéias, requer tempo e paciência para que se possa
trabalhar em conjunto, além de algumas variáveis importantes como a distinção do
papel do líder no grupo, que é o profissional responsável por descobrir talentos
individuais de cada participante, ajudando no desenvolvimento da criatividade e na
participação de todos.
A capacidade técnica é outro fator de extrema importância para se obter

resultados positivos, proporcionando o desenvolvimento de boas idéias e
estratégias. E por fim a criatividade e o comprometimento, 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.
21
2.1.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, habilidades,

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,
planejamento, execução, monitoramento e controle, e encerramento.”
[PMBOK®, 2004, p.8].
De acordo com BRAGA (2003), gerenciar projetos envolve tomar decisões

sobre:
 Escopo, Tempo, Custo e Qualidade.
 Diferentes necessidades e expectativas dos clientes e partes interessadas.
 Requisitos identificados (necessidades), e não identificados (expectativas).
Segundo MARTINS (2003), a gestão de projetos é a aplicação de

conhecimento, habilidades, ferramentas e técnicas na administração eficiente das
atividades do projeto. O conhecimento obtido com estudos e práticas dinamiza os
processos de iniciação, planejamento, execução, controle e encerramento que
compõem o projeto.
VARGAS (2009) descreve o gerenciamento de projetos como sendo um

conjunto de ferramentas gerenciais que proporcionam as empresas desenvolverem
um conjunto de habilidades, incluindo conhecimento e capacidades individuais,
voltados ao controle de eventos não repetitivos, únicos e complexos, dentro de um
cenário de qualidade, tempo e custo predeterminado.
2.1.3 O CICLO DE VIDA DO PROJETO.
Os gerentes de projetos podem dividir os projetos em várias fases com o

intuito de obter melhor controle gerencial. Estas fases são conhecidas como ciclo de
vida dos projetos.
Segundo a PMI (2004). 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, e quem deve estar envolvido. O ciclo de vida também é o
22
responsável por definir o conjunto de processos que devem ser seguidos para que o
projeto seja gerenciado com qualidade.
Para VARGAS (2007), o ciclo de vida propicia uma gama de benefícios para
qualquer tipo de projeto. Dentre eles, podem ser citados os seguintes:
 A análise correta do ciclo de vida determina o que foi, ou não feito

pelo projeto.
 O ciclo de vida avalia como o projeto está progredindo até o

momento;
 O ciclo de vida permite que seja indicado qual o ponto exato em que o
projeto se encontra no momento.
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, gráficos, e listas de verificação para oferecer uma melhor estrutura e
controle gerencial.
O ciclo de vida de um projeto tradicional é dividido basicamente em quatro

fases: a fase conceitual, a fase de planejamento, a fase de execução e a fase de
conclusão ou encerramento.
2.1.4 PARTES INTERESSADAS EM UM PROJETO
De acordo com o Guia PMBOK® (2004), as partes interessadas em um

projeto são as pessoas e organizações ativamente envolvidas no projeto, cujos
interesses podem ser afetados com o resultado da execução ou do término do
projeto.
Baseado no guia PMBOK® (2004), a Tabela 1 a seguir mostra a definição

das principais partes interessadas em um projeto.
23
Tabela 1: Definição das Partes Interessadas em um Projeto
PARTE INTERESSADA DESCRIÇÃO

Consiste na pessoa responsável pelo gerenciamento do
GERENTE DE PROJETOS projeto.
Consiste na pessoa ou organização que utilizará o
CLIENTE/USUÁRIO produto desenvolvido pelo projeto.
Consiste na empresa cujos funcionários estão mais
ORGANIZAÇÃO diretamente envolvidos na execução do trabalho do
EXECUTORA projeto.
MEMBROS DA EQUIPE DO Consiste no grupo que está executando o trabalho do
PROJETO projeto.
EQUIPE DE Consiste nos membros da equipe do projeto que estão
GERENCIAMENTO DE diretamente envolvidos nas atividades de
PROJETOS
gerenciamento dos projetos.
Consiste na pessoa ou no grupo que fornece os
PATROCINADOR recursos financeiros para o projeto.
Consiste nas pessoas ou grupos que não estão
diretamente relacionados à aquisição ou ao uso do
produto do projeto, mas que, devido à posição de uma
INFLUENCIADORES
pessoa na organização do cliente ou na organização
executora, podem influenciar, positiva ou
negativamente, no andamento do projeto.
Consiste no departamento ou grupo que define e
PMO mantém os padrões de processo, geralmente
relacionados com a gestão dos projetos , dentro da
organização.
Fonte: Desenvolvido pelo autor.
O termo Stakeholders refere-se a todas as partes interessadas no projeto,

incluindo próprio gerente de projetos. Dentre as partes interessadas, um dos mais
importantes é o patrocinador do projeto, que consiste na pessoa que financia ou
defende o projeto dentro da organização.
A equipe de gerenciamento precisa identificar as partes interessadas,

determinar suas necessidades e expectativas, e gerenciar sua influência em relação
aos requisitos para garantir um projeto bem sucedido.
A Figura 1 descreve as principais partes interessadas e sua relação com o

projeto.
24
Figura 1: Relação entre as Partes Interessadas e o Projeto
Fonte: PMBOK®, 2004.
As partes interessadas em um projeto podem ocasionar influências positivas

e negativas em um projeto. As partes interessadas positivas beneficiam um
resultado bem sucedido do projeto, enquanto as partes interessadas negativas
criticam o projeto, enxergando resultados negativos a partir do sucesso do projeto
[PMBOK®, 2004].
2.1.5 PERFIL DE UM GERENTE DE PROJETOS
O gerente de projetos é a pessoa responsável pela realização dos objetivos

do projeto. Um gerente de projetos deve ter a capacidade de trabalhar em equipe,
liderança, habilidade para aplicar seus conhecimentos na prática, facilidade nos
relacionamentos interpessoais e boa comunicação.
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, técnicas e ferramentas de gerenciamento, bem
como a capacidade prática e aplicável destes conhecimentos.
Para MARTINS (2003), o gerente de projetos se destaca dentro das

organizações devido à evolução e relevância do gerenciamento dos projetos. A
25
profissão de gerenciamento de projetos é bastante promissora mediante a gama de

oportunidades que está surgindo atualmente.
A escolha de profissionais capacitados é fator crucial para sucesso dos

projetos. 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, que
eventualmente possui remuneração inferior a de um profissional qualificado,
ocasionando aumento do custo final do projeto, levando em consideração as
deficiências na gestão de recursos, além das entregas serem geralmente efetuadas
fora dos prazos estabelecidos [MARTINS, 2003].
2.1.6 BENEFÍCIOS DO GERENCIAMENTO DE PROJETOS
Segundo MARTINS (2003), a gestão de projetos tem-se destacado nos

últimos tempos devido a sua eficácia, conseguindo alcançar resultados desejados
dentro dos prazos, e orçamentos definidos. O gerenciamento de projetos pode ser
aplicado em empreendimentos de qualquer complexidade, e para qualquer tipo de
negócio.
Para MARTINS (2003), os benefícios proporcionados pelo gerenciamento de

projetos são os seguintes:
 Controle efetivo de prazos, custos e recursos, permitindo a

identificação prévia de desvios, e imediata tomada de ações corretivas
ou pró-ativas, podendo inclusive resultar em possíveis reduções;
 Eficácia na integração e comunicação necessária durante todo o
projeto;
 Monitoramento e controle dos riscos e da qualidade do projeto;
 Retorno do investimento, com entrega conforme a especificação;
Segundo estudos realizados pela Standish Group em 2001, revelam que

apenas 16% dos projetos são bem sucedidos, 28% são realizados no prazo e
orçamento especificados, 23% são cancelados, 94% são reiniciados pelo menos
uma vez excedendo o orçamento original em 188% e o prazo original em 222%, e
apenas 61% mantém o escopo original [SOTILLE, 2004]. O Gráfico 1 mostra a
evolução dos percentuais de sucesso, atraso e falhas de 1994 até 2008.
26
Gráfico 1: Evolução dos Percentuais de Sucesso, Atraso e Falhas
Um projeto bem sucedido é aquele que é realizado conforme o planejado.

Se o projeto gastou menos recursos que o previsto, houve uma falha no
planejamento que permitiu que os recursos fossem superestimados, e não uma
economia de recursos [SOTILLE, 2004].
Diante deste cenário, 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, tornando um diferencial e requisito em relação à
especialização no assunto.
A certificação PMP (Project Management Professional) comprova o

conhecimento aprofundado sobre o PMBOK®, e das regras impostas pela PMI para
exercer a profissão de gerente de projetos [PMI, 2004].
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.
27
Gráfico 2: Evolução dos credenciados PMP no Mundo
Fonte: http://www.ietecnet.com.br/pmp/credenciados.asp
Para TORREÃO (2005), o sucesso na gestão de projetos pode ser

mensurado através do alcance dos seguintes objetivos: entregas dentro do prazo
estabelecido, dentro do orçamento previsto com nível de desempenho adequado,
controle eficaz nas mudanças do escopo, respeito à cultura da organização e
aceitação prévia do cliente.
De acordo com VARGAS (2007), o gerenciamento de projetos proporciona

inúmeras vantagens em relação às demais formas de gerenciamento, tendo se
mostrado bastante eficaz em conseguir os resultados desejados, 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,
com alto nível de complexidade, podendo ser aplicado a empreendimentos de
qualquer natureza.
A gestão profissional de projetos é a forma mais indicada a ser aderida pelas

organizações para a realização de projetos, utilizando recursos eficientes dentro das
limitações de custo, tempo e desempenho. O gerente de projetos é a pessoa
responsável por guiar todas as atividades do projeto, devendo estar devidamente
qualificado para exercer seu papel e garantir o sucesso do projeto.
28
2.2 PMBOK® - Project Management Body of Knowledge
Esta seção objetiva demonstrar uma visão geral sobre a estrutura do

PMBOK®, abrangendo seus conceitos, objetivos, grupos de processos, e suas nove
áreas de conhecimento em gerenciamento de projetos.
2.2.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. O PMBOK® é
reconhecido pela ANSI (American National Standard), e foi desenvolvido pelo PMI
(Project Management Institute), que é a principal referência para as organizações
que estão em busca de melhorias em seus processos de gerenciamento [NARDI,
2009].
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. “Identificar” significa fornecer
uma visão geral, e não uma descrição completa. “Amplamente reconhecido”
significa que o conhecimento e as práticas descritas são aplicáveis à maioria
dos projetos na maior parte do tempo, 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, ferramentas e técnicas
podem aumentar as chances de sucesso em uma ampla série de projetos
diferentes. Uma boa prática não significa que o conhecimento descrito deverá
ser sempre aplicado uniformemente em todos os projetos; a equipe de
gerenciamento de projetos é responsável por determinar o que é adequado
para um projeto específico.” [PMBOK®, 2004, p.3].
O PMBOK® teve sua primeira publicação no ano de 1987. Logo mais tarde
baseado nos comentários positivos recebidos pelos membros da PMI foi publicada a
sua segunda versão. A sua terceira versão teve publicação em 2004 com melhorias
em sua estrutura original, adições aos processos, termos e domínios do programa e
do portfólio. Atualmente está em sua quarta edição, lançada em 2008, tornando-se a
norma mundial relacionada ao gerenciamento de projetos, sendo um dos melhores e
mais versátil documento disponível para gerência de projetos [PMBOK®, 2004].
O PMBOK® pode ser usado como uma guia, fornecendo aos gerentes
alternativas para se obter sucesso nos projetos.
29
De acordo com o próprio Guia PMBOK® (2004), ele se divide três seções:
 Seção I: A estrutura do gerenciamento de projetos.

Fornece uma estrutura básica para o entendimento sobre
gerenciamento de projetos.
 Seção II: A norma de gerenciamento de projetos de um projeto.

Especifica todos os processos de gerenciamento de projetos
usados pela equipe do projeto para gerenciar um projeto.
 Seção III: As áreas de conhecimento em gerenciamento de projetos.

Organiza os 44 processos de gerenciamento de projetos dos
grupos de processos de gerenciamento de projetos.
O Guia PMBOK® (2004) reconhece 44 processos em cinco grupos de

processos básico e nove áreas de conhecimento. Os cinco grupos de processos do
PMBOK® são: Iniciação, Planejamento, Execução, Controle e Monitoração, e
Fechamento.
As nove áreas de conhecimento em gerência de projetos do PMBOK® são:

Integração, Escopo, Tempo, Custo, Qualidade, Recursos Humanos, Comunicações,
Risco, Aquisições.
Cada uma das áreas de conhecimento do PMBOK® contém os processos

que precisam ser realizados para a gestão dos projetos, sendo que cada processo
pode ser relacionado com uma área de conhecimento e a um grupo de processos.
2.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, em 5 grupos básicos e 9 áreas
de conhecimento.
De acordo com o PMBOK® (2004), 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, resultados ou serviços.” [PMBOK®, 2004, p.
38].
30
A Figura 2 mostra resumidamente os grupos de processos em

gerenciamento de projetos que compõem o PMBOK®.
Figura 2: Os Grupos de Processos do Gerenciamento de Projetos
Fonte: PM Tech Capacitação em Projetos.
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.
 Grupo de Processos de Planejamento: Define e refina os objetivos,
bem como a seleção da melhor alternativa para alcançar os objetivos
do projeto, e o escopo para os quais o projeto foi realizado.
 Grupo de Processos de Execução: Coordena pessoas e outros
recursos para realizar o plano de gerenciamento de projetos.
 Grupo de Processos de Monitoramento e Controle: Assegura que
os objetivos do projeto estão sendo cumpridos, e monitora
regularmente o progresso do projeto a fim de identificar variações em
31
relação ao plano de gerenciamento de projetos, para que se possa

tomar as devidas ações corretivas.
 Grupo de Processos de Encerramento: Formaliza a aceitação do
projeto, serviço ou resultado, e conduz o projeto ou uma fase do
projeto a um final ordenado.
2.2.3 AS NOVE ÁREAS DE CONHECIMENTO DO PMBOK®
O PMBOK® (2004), possui em seu contexto nove áreas de conhecimento.

Cada uma dessas áreas é responsável por uma parte do gerenciamento dos
projetos, e abrange diversos processos de gerenciamento, sendo ao todo 44
processos. A Figura 3 a seguir mostra resumidamente as nove áreas de
conhecimento do PMBOK® (2004) e seus respectivos grupos de processos.
Figura 3: Visão Geral das Áreas de Conhecimento do PMBOK® (2004)

32
As áreas de conhecimento do PMBOK® são os principais pontos a serem

explorados a fim de garantir sucesso nos projetos desenvolvidos. A seguir será
apresentada cada uma das nove áreas de conhecimento que compõem o PMBOK®,
juntamente com seus grupos de processos.
2.2.4 GERENCIAMENTO DE INTEGRAÇÃO DO PROJETO
O Gerenciamento de Integração é composto por processos e atividades

necessárias para identificar, definir, combinar, unificar e coordenar os diversos tipos
de atividades do gerenciamento de projetos, através dos grupos de processos que o
compõem [PMBOK®, 2004].
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®, 2004].
Para VARGAS (2009), o gerenciamento de integração objetiva

principalmente garantir que todas as demais áreas estejam integradas, estruturando
todo o projeto de modo a possibilitar que as necessidades dos envolvidos sejam
atendidas pelo projeto. A Figura 4 a seguir proporciona uma visão geral sobre os
processos que compõem esta área de conhecimento.
Figura 4: Mapeamento do Gerenciamento de Integração
Fonte: Manual Prático do Plano Do Projeto.
 Termo de Abertura do Projeto: Constitui um documento que autoriza

formalmente um projeto. O termo de abertura do projeto concede aos
gerentes o privilégio de aplicar os recursos organizacionais nas atividades do
33
projeto. Trata principalmente da documentação das necessidades de negócio,

do atendimento atual das necessidades do cliente, do novo produto e da
justificativa do projeto [PMBOK®, 2004].
 Declaração do Escopo Preliminar do Projeto: Responsável em fornecer

uma descrição em alto-nível do escopo do projeto.
 Plano de Gerenciamento do Projeto: Responsável em incluir as ações

necessárias em para definir, coordenar e integrar todos os planos auxiliares
em um plano de gerenciamento do projeto.
 Orientar e Gerenciar a Execução do Projeto: É diretamente afetado pela

área de aplicação do projeto, e consiste na execução de todo o trabalho
definido pelo plano de gerenciamento de projetos.
 Monitorar e Controlar o Trabalho do Projeto: Tem o objetivo de monitorar e

controlar todos os processos associados com a iniciação, planejamento,
execução e encerramento, 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. Consiste na identificação, controle, revisão, gerenciamento, e
manutenção das possíveis mudanças que venham a ocorrer, rejeitando ou
aprovando-as, de forma que as mudanças aprovadas sejam incorporadas a
uma linha de base revisada.
 Encerrar o Projeto: Consiste na finalização de todas as atividades e grupos

de processos de gerenciamento de projetos, e posteriormente o
encerramento formal do projeto por completo.
2.2.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. Trata principalmente
da definição e controle do que está e do que não está incluso no projeto [PMBOK®,
2004].
34
Segundo VARGAS (2007), o gerenciamento de escopo tem como principal

objetivo definir e controlar os trabalhos a serem realizados pelo projeto, de modo a
garantir que o produto ou serviço requisitado seja obtido através da menor
quantidade de trabalho possível, sem deixar de realizar nenhum requisito
estabelecido no objetivo do projeto. A Figura 5 a seguir ilustra os processos que
compõem o gerenciamento de escopo.
Figura 5: Mapeamento do Gerenciamento do Escopo
Fonte: Manual Prático do Plano Do Projeto.
 Planejamento do Escopo: Define a criação de um plano de gerenciamento

do escopo do projeto, visando documentar como o escopo do projeto será
definido. Verifica e controla como a estrutura analítica do projeto (EAP) será
criada.
 Definição do Escopo: Consiste na definição detalhada das entregas do

projeto, e o trabalho necessário para realizar essas entregas. A definição do
escopo fornece um entendimento comum do escopo do projeto a todas as
partes interessadas no projeto, descrevendo seus principais objetivos, além
de orientar o trabalho da equipe durante a execução do projeto.
 Criar EAP: Consiste na subdivisão do trabalho a ser executado pela equipe

do projeto, organizando e definindo o escopo total do projeto, e subdividindo
todo o projeto em partes menores visando uma maior facilidade no
gerenciamento. A Figura 6 a seguir exemplifica a estrutura de um projeto de
software através de uma EAP de forma detalhada.
35
Figura 6: Exemplo de um EAP
 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,
juntamente com os motivos da sua reprovação.
 Controle do Escopo: Consiste no controle das mudanças no escopo do

projeto, com intuito de controlar o impacto que essas mudanças geram no
projeto.
2.2.6 GERENCIAMENTO DE TEMPO DO PROJETO
De acordo com o PMBOK® (2004), o Gerenciamento de Tempo do projeto

inclui os processos necessários para garantir o término do projeto dentro dos prazos
estabelecidos.
Para VARGAS (2007), o gerenciamento de tempo juntamente com o

gerenciamento de custos são as áreas mais visíveis do gerenciamento de projetos,
tendo em vista que a maioria das pessoas que se interessam por projetos tem como
objetivo inicial controlar prazos, confeccionar cronogramas e estabelecer custos.
36
Os processos que compõem essa área de conhecimento são os seguintes:

definição de atividade, seqüenciamento de atividades, estimativa de recursos de
atividades, desenvolvimento do cronograma e controle do cronograma. 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.
 Definição da Atividade: Consiste em identificar e documentar as atividades

específicas do cronograma, para produzir as entregas do projeto.
 Seqüenciamento de Atividades: Consiste na identificação e documentação

das dependências entre as atividades do cronograma.
 Estimativa de Recursos da Atividade: Consiste na estimativa do tipo, e

quantidade de recursos necessários para realizar cada atividade do
cronograma.
 Estimativa de Duração da Atividade: Consiste na estimativa do número de

horas necessárias para se termine as atividades individuais do cronograma, 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.
 Desenvolvimento do Cronograma: Visa à análise dos recursos necessários,

restrições do cronograma, durações e seqüências de atividades para criar o
cronograma do projeto. Esse processo determinara as datas de início e
término das atividades, podendo ocasionar a reavaliação das estimativas de
37
duração e recursos, gerando um cronograma para ser aprovado, servindo

como linha de base para o projeto.
 Controle do Cronograma: Consiste no controle das mudanças no

cronograma do projeto.
2.2.7 GERENCIAMENTO DE CUSTOS DO PROJETO
De acordo com o PMBOK® (2004), 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. As definições orçamentárias do projeto devem ser realizadas
por quem irá realizar o projeto. O projeto pode entrar em execução somente após a
aprovação prévia do orçamento.
Segundo VARGAS (2007), 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. A Figura 8 ilustra os
processos que compõem o gerenciamento de custos.
Figura 8: Mapeamento do Gerenciamento de Custos
 Estimativa de Custos: Consiste em desenvolver uma estimativa de custos

necessários para o término de cada atividade do projeto.
 Orçamentação: Consiste em agregar os custos estimados de atividades

individuais ou pacotes de trabalho para estabelecer uma linha de base de
custos.
38
 Controle de Custos: Consiste em controlar os fatores que criam variações de

custos no projeto, e as mudanças no orçamento do projeto.
2.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, garantindo a
satisfação das necessidades de todas as partes envolvidas. O principal responsável
pelo gerenciamento da qualidade é o gerente de projetos, devendo proporcionar
igual prioridade a gestão da qualidade, do custo e do tempo [VARGAS, 2007].
Para o PMBOK® (2004), o gerenciamento de qualidade de um projeto

preocupa-se exclusivamente com a satisfação do cliente, prevenção de erros e a
melhoria continua dos processos. Os processos que compõem o gerenciamento de
qualidade são ilustrados através da Figura 9 a seguir.
Figura 9: Mapeamento do Gerenciamento de Qualidade
 Planejamento de Qualidade: Visa identificar os padrões de qualidade

relevantes para o projeto, e determinação de como fazê-los.
 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.
 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
39
com os padrões relevantes de qualidade, e identificação de maneiras para

eliminar as causas de um desempenho insatisfatório.
2.2.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, pois são elas que definem as metas, os planos, organizam o trabalho,
coordenam e controlam as atividades do projeto, utilizando de suas habilidades
técnicas e sociais.
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, pois o
envolvimento dos membros da equipe desde o início proporciona o fortalecimento do
compromisso com o projeto.
Tendo em vista que os custos sofrem variação significativamente ao longo

do ciclo de vida dos projetos, os recursos humanos são requisitados em vários
níveis de especialidade, dependendo da natureza do trabalho a ser realizado e do
nível de maturidade da equipe do projeto. A Figura 10 a seguir mostra os tipos de
profissionais requisitados ao longo de cada fase do projeto.
Figura 10: Tipos de profissionais requeridos ao longo do projeto

40
O gerenciamento de recursos humanos possui quatro processos principais,

dentre eles, o planejamento de recursos humanos, controlar ou mobilizar a equipe
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.
Figura 11: Mapeamento do Gerenciamento de Recursos Humanos
 Planejamento de Recursos Humanos: Consiste na identificação e

documentação das funções, responsabilidades e relações hierárquicas do
projeto, elém de um plano pessoal de gerenciamento.
 Contratar ou Mobilizar a Equipe do Projeto: Objetiva obter os recursos

humanos necessários para terminar o projeto.
 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.
 Gerenciar a Equipe do Projeto: Visa o acompanhamento de desempenho de

membros da equipe, fornecimento de feedback ,resolução de conflitos e
coordenação de mudanças
2.2.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, coleta, distribuição,
armazenamento, recuperação e destinação das informações sobre o projeto de
forma adequada.
41
O gerenciamento das comunicações é necessário para assegurar que todas

as informações desejadas cheguem às pessoas corretas. 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.
Para VARGAS (2007) a comunicação deve ser vista nas organizações como
uma estratégia de crescimento, tendo em vista que o fluxo de informações está
exigindo cada vez mais agilidade e eficiência nas comunicações, se tornado um dos
fatores principais para garantir o sucesso de um projeto.
O PMBOK® (2004) subdivide o gerenciamento de comunicações em quatro

processos básicos, dentre eles, o planejamento das comunicações, a distribuição
das informações, o relatório de desempenho, e gerenciar as partes interessadas. A
Figura 12 a seguir descreve o mapeamento dos principais processos do
gerenciamento de comunicações.
Figura 12: Mapeamento do Gerenciamento das Comunicações
 Planejamento das Comunicações: Objetiva determinar as necessidades de

informações e comunicações das partes interessadas no 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.
 Relatório de Desempenho: Tem como principal objetivo coletar e distribuir

as informações sobre o desempenho do projeto, através de relatórios de
andamento medição de progresso e previsão. As informações relacionadas
42
ao relatório de desempenho podem incluir os recursos que estão sendo

utilizados para garantir os objetivos do projeto, além de informações sobre o
escopo, cronograma, custo e qualidade do projeto.
 Gerenciar as Partes Interessadas: Consiste no gerenciamento das

informações para satisfazer os requisitos das partes interessadas no projeto,
e resolver problemas com os mesmos. O gerenciamento das partes
interessadas aumenta a probabilidade do projeto não desviar o foco, devido a
problemas com as partes interessadas.
2.2.11 GERENCIAMENTO DOS RISCOS DO PROJETO
Segundo VARGAS (2007), o gerenciamento de riscos do projeto possibilita a

oportunidade de compreender melhor a natureza do projeto, envolvendo os
membros da equipe com intuito de identificar e responder aos possíveis riscos que
podem ocorrer geralmente associados ao tempo, custo, e qualidade.
De acordo com o PMBOK® (2004), o gerenciamento de riscos objetiva

principalmente aumentar probabilidade de acontecer eventos positivos, e minimizar
a probabilidade de ocorrer eventos negativos no projeto.
Os riscos de um projeto constituem um evento incerto, ou seja, é um evento

que pode ou não ocorrer, e se por ventura vier a acontecer poderá ter um efeito
positivo ou negativo sobre pelo menos um dos objetivos do projeto, afetando
principalmente as especificações de tempo, custo, escopo ou qualidade do projeto.
Os riscos podem ocorrer por várias causas, uma das causas pode ser, por
exemplo, a falta de pessoal designado para realizar alguma tarefa exclusiva do
projeto.
O PMBOK® subdivide o gerenciamento de riscos do projeto em seis

principais processos, descritos conforme a Figura 13.
43
Figura 13: Mapeamento do Gerenciamento de Riscos
 Planejamento do Gerenciamento de Riscos: Consiste na tomada de

decisões de como abordar, planejar e executar as atividades de
gerenciamento de riscos de um projeto.
 Identificação de Riscos: Consiste em determinar e documentar as

características dos riscos que por ventura possam afetar o 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.
 Análise Quantitativa dos Riscos: É a análise numérica dos efeitos

identificados nos objetivos gerais do projeto. Após a priorização dos riscos na
análise qualitativa, os mesmos são quantificados através da atribuição de
valores numéricos a estes riscos.
 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.
 Monitoramento e Controle dos Riscos: Tem o objetivo de acompanhar e

monitorar os riscos identificados, e a realização de novas avaliações em
busca de novos riscos que possam afetar os objetivos do projeto.
44
2.2.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, com a finalidade de realizar os objetivos do trabalho.
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 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. 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. A Figura 14 fornece uma visão geral dos principais processos que compõem
o gerenciamento de aquisições.
Figura 14: Mapeamento do Gerenciamento das Aquisições
 Planejar Compras e Aquisições: Consiste na determinação do que comprar

ou adquirir, e quando e como fazer isso. 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. Este processo
também inclui possíveis fornecedores, especialmente se o comprador desejar
ter influência ou controle sobre as decisões de contratação.
45
 Planejar Contratações: Consiste em documentar os requisitos de produtos e

serviços, a fim de identificar possíveis fornecedores e solicitar respostas aos
mesmos. As ferramentas e técnicas utilizadas neste processo incluem
contratos, descrições padrões de itens de aquisição, termos de
confidencialidade, listas de verificação de critérios de avaliação de propostas,
ou versões padronizadas de todas as partes dos documentos de licitação
necessários, além da obtenção de opiniões especializadas.
 Solicitar Respostas de Fornecedores: Consiste na obtenção de

informações, cotações, preços, ofertas ou propostas de produtos com os
fornecedores. Este processo inclui reuniões com licitantes, e reuniões com
possíveis fornecedores, usadas com o propósito de garantir que todos os
fornecedores possuem um entendimento claro sobre a aquisição.
2.3 Desenvolvimento ágil
O desenvolvimento ágil surgiu em meados da década de 90, 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, visando discutir
formas de estabelecer princípios comuns compartilhados a todos os métodos, com o
objetivo de proporcionar melhorias no desempenho dos projetos [SOARES, 2008].
A partir desta reunião conhecida como “Aliança Ágil” foi estabelecido o

“Manifesto Ágil”, cujos conceitos são:
 Indivíduos e interações ao invés de processos e ferramentas.
 Colaboração do cliente ao invés de negociação de contratos.
 Respostar rápidas a mudanças ao invés de seguir planos.
Segundo SOARES (2008), as metodologias ágeis são apontadas como uma

alternativa às abordagens tradicionais. Elas devem ser aplicadas exclusivamente a
projetos onde os requisitos atuais são estáveis e os requisitos futuros podem ser
previstos. Entretanto, em projetos onde ocorrem constantes mudanças nos
46
requisitos, e as equipes são razoavelmente pequenas, as metodologias ágeis são as

mais indicadas.
O conceito de agilidade enfatiza responder aos problemas da equipe de

forma rápida e efetiva, promovendo a união entre a equipe e o cliente, fazendo com
que o mesmo participe continuamente do processo de criação do projeto [SOARES,
2008].
Portanto, o conceito ágil estabeleceu doze princípios para quem deseja

trabalhar com metodologias ágeis, dentre eles são:
“1. A prioridade é satisfazer ao cliente através de entregas de

software de valor contínuas e freqüentes;
2. Entregar softwares em funcionamento com freqüência de algumas
semanas ou meses, sempre na menor escala de tempo;
3. Ter o software funcionando é a melhor medida de progresso;
4. Receber bem as mudanças de requisitos, mesmo em uma fase
avançada, dando aos clientes vantagens competitivas;
5. As equipes de negócio e de desenvolvimento devem trabalhar
juntas diariamente durante todo o projeto;
6. Manter uma equipe motivada fornecendo ambiente, apoio e
confiança necessário para a realização do trabalho;
7. A maneira mais eficiente da informação circular dentro da equipe é
através de uma conversa face a face;
8. As melhores arquiteturas, requisitos e projetos provêm de equipes
organizadas;
9. Atenção contínua a excelência técnica e um bom projeto
aumentam a agilidade;
10. Processos ágeis promovem o desenvolvimento sustentável.
Todos envolvidos devem ser capazes de manter um ritmo de
desenvolvimento constante;
11. Simplicidade é essencial;
12. Em intervalos regulares, a equipe deve refletir sobre como se
tornarem mais eficazes e então se ajustar e adaptar seu
comportamento.” [Reinert, 2008, p.3].
A partir do conhecimento dos conceitos supracitados, inúmeras

metodologias de gerenciamento e desenvolvimento que já existiam começaram a
ganhar espaço no mercado. Com o presente trabalho pretende-se priorizar o
aprimoramento e compreensão das técnicas do Scrum, onde foram apresentadas
suas características e definições nas seções seguintes.
47
2.4 Scrum
O Scrum é uma metodologia ágil de desenvolvimento e gerenciamento de

projetos, criada por Ken Schwaber e Jeff Sutherland, e que possui como premissa
estabelecer um processo de desenvolvimento iterativo e incremental, podendo ser
aplicada no gerenciamento de qualquer atividade. O Scrum tem como base o
desenvolvimento com foco na equipe e com ciclos de iteração curtos [GONÇALVES,
2008].
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, sendo aplicável a ambientes voláteis.
Ele se destaca dos demais métodos ágeis pela maior ênfase dada ao
gerenciamento do projeto. Reúne atividades de monitoramento e feedback,
em geral, reuniões rápidas e diárias com toda a equipe, visando à
identificação e correção de quaisquer deficiências e/ou impedimentos no
processo de desenvolvimento.” [MAÇAL, 2007, p.3].
O Scrum é aplicável tanto a projetos pequenos como grandes, objetivando

conseguir uma melhor avaliação do ambiente em evolução. É indicado ao
desenvolvimento e gerenciamento de projetos em ambientes complexos, onde os
requisitos estão em constante mudança, tornando-se uma alternativa para aumentar
a produtividade das organizações [GONÇALVES, 2008].
Segundo GONÇALVES (2008), 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,
voltadas para o trabalho em equipe e melhoria da comunicação, permitindo que
cada participante da equipe faça o seu melhor.
De acordo com BOSSI (2007), 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, onde o projeto, ou apenas algumas

funcionalidades é desenvolvido.
 Sprint Planning Meeting: Reunião de planejamento.

48
 Sprint Review Meeting: Reunião de revisão.
 Sprint Backlog: Trabalho a ser desenvolvido numa Sprint de modo a criar um

produto ou resultado a ser apresentado ao cliente.
 Dayling Scrum: Reunião diária.
 Scrum Team: Equipe de desenvolvimento de uma Sprint.
 Scrum Master: Elemento da equipe responsável pela gestão do projeto.

Apesar de ser gestor, não tem propriamente autoridade sobre os demais
membros da equipe.
 Product Owner: Proprietário do produto.
Para PEREIRA (2005), o Scrum não é um processo previsível, não define o

que fazer em todos os casos, é utilizado para trabalhos com alto nível e
complexidade, no qual não é possível prever o que irá acontecer, dispondo de um
framework que serve como um guia de boas práticas para gerência de projetos.
2.4.1 Ciclo de Vida do Scrum
O ciclo de vida do Scrum baseia-se no princípio da utilização de equipes

pequenas, no máximo sete pessoas, onde os requisitos são pouco estáveis e as
iterações são curtas. O desenvolvimento é dividido em intervalos de no máximo 30
dias, conhecidos como Sprints.
Segundo SOARES (2008) o ciclo de vida do Scrum é dividido em quatro

fases:
 Planejamento: Visa estabelecer uma visão do projeto, garantindo recursos

para sua execução.
 Stagging: Consiste em avaliar as várias dimensões do projeto criando itens

para o Product Backlog.
 Desenvolvimento: Consiste na criação de várias Sprints para o

desenvolvimento dos incrementos de funcionalidade do produto.
49
 Releasing: Consiste na realização da entrega final ao cliente.
A Figura 15 a seguir ilustra de forma simplificada o ciclo de vida do Scrum.
Figura 15: Ciclo de vida do Scrum
Fonte: http://paoloramos.com/blog/wp-content/uploads/2009/03/ciclo-de-vida.png
Antes da realização de uma Sprint, é feita uma reunião de planejamento

chamada Sprint Planning Meeting, onde a equipe de desenvolvedores obtêm contato
com o cliente, que neste contexto chamado de Product Owner, para decidir como
será feito o trabalho e selecionar as tarefas que a equipe irá realizar dentro da Sprint
[PEREIRA, 2007].
A próxima fase consiste na execução da Sprint, onde a equipe controla o

andamento do desenvolvimento do projeto, através da realização das reuniões
diárias chamadas de Daily Meeting, com duração de no máximo 15 minutos. O
progresso realizado no projeto pode ser visto através de um gráfico chamado Sprint
Burndown.
Ao final da Sprint é realizada uma reunião de revisão, denominada Sprint

Review, onde o time demonstra a parte funcional desenvolvida na Sprint, visando
assegurar que tudo ocorreu de acordo com os requisitos estabelecidos
anteriormente no Product Backlog [PEREIRA, 2007].
Posteriormente realiza-se a reunião de retrospectiva, chamada de Sprint

Retrospective, que consiste em uma reunião voltada para lições aprendidas, visando
à melhoria dos processos para a próxima Sprint [PEREIRA, 2007].
50
2.4.2 Papéis
De acordo com PEREIRA (2007), o Scrum implementa um processo iterativo

e incremental, cujas pessoas envolvidas são divididas em três grupos : o Product
Owner, o Scrum Team, e o Scrum Master, cada um com s sua função em específico,
e todos interagindo entre si.
O Product Owner tem o papel de representar os interesses de todos no

projeto, não sendo necessário que tenha um conhecimento aprofundado sobre o
Scrum, mas deve conhecer bem o trabalho que será desenvolvido.
Deve sempre estar disponível para a equipe, principalmente durante as

reuniões de planejamento (Sprint Planning Meeting), e durante as reuniões de
revisão (Sprint Review), com o intuito de priorizar as tarefas que serão realizadas na
Sprint.
Além de ser o responsável em dividir o trabalho em várias partes menores e

manter o Product Backlog em ordem, também são responsabilidades do Product
Owner segundo PEREIRA (2007):
 Define os requisitos do produto, decide a data de release e o que deve conter

nela.
 É responsável pelo retorno financeiro do produto.
 Prioriza os requisitos de acordo com o seu valor de mercado.
 Pode mudar os requisitos e prioridades a cada Sprint.
 Aceita ou rejeita o resultado de cada Sprint.
Outro papel muito importante do Scrum é o Scrum Máster, 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, e a equipe deve
enxergá-lo como a pessoa que tem conhecimento amplo sobre o Scrum, cuja função
é corrigir qualquer contratempo na utilização de suas práticas, e tirar dúvidas
referentes ao Scrum de qualquer pessoa envolvida no projeto [MAGNO, 2008].
51
Segundo MAGNO (2008), as principais responsabilidades do Scrum Máster

são:
 Permitir que o time seja auto gerenciável.
 Garantir que os caminhos para a comunicação da equipe estejam abertos

permanentemente.
 Garantir e auxiliar equipe a seguir as práticas do Scrum.
 Remover qualquer impedimento que a equipe encontre.
 Proteger a equipe de interferências externas para garantir que sua

produtividade não seja afetada.
Por fim, o Scrum Team, que consiste na equipe de desenvolvimento

composta de no máximo nove membros, responsável por desenvolver as
funcionalidades do projeto. Nele não existe uma divisão através de funções como na
abordagem tradicional, tais como designer, analista, arquiteto, dentre outros. Todos
os membros da equipe trabalham juntos no projeto com a intenção de atender aos
requisitos do Product Backlog, sendo responsável pelo sucesso de cada iteração e
consequentemente do projeto como um todo.
De acordo com PEREIRA (2007), as responsabilidades do Scrum Team são:
 Selecionar entre os itens priorizados os que serão executados durante a

Sprint.
 Tem todo o direito de realizar o que quiser dentro da Sprint para cumprir seus
objetivos.
 Auto - organização do trabalho entre os membros da equipe de forma

participativa.
 Ao final da Sprint, é responsável por realizar a versão de demonstração do

produto finalizado.
52
2.4.3 Artefatos
Os artefatos do Scrum consistem nos documentos que auxiliam no

entendimento do que deve ser feito no projeto, quando deve ser feito e como está o
andamento do trabalho. Os Principais artefatos do Scrum são: o Product Backlog, a
Sprint Backlog e o Burndown Chart.
O Product Backlog é o coração do Scrum. Consiste basicamente em uma

lista de itens priorizados que inclui tudo o que precisa ser realizado no projeto, sendo
associado ao valor de negócio do cliente. Não há necessidade do Product Backlog
estar totalmente completo antes do início do projeto, pois com o tempo pode ser
feito a inclusão de novos requisitos, bem como a remoção de requisitos já existentes
[PEREIRA, 2007]. A priorização das atividades do Product Backlog deve ser feita
pelo Product Owner, que geralmente deve ser a primeira tarefa a se realizar antes
de iniciar uma Sprint. A Figura 16 a seguir exemplifica um Product Backlog.
Figura 16: Exemplo de um Product Backlog
Fonte: Scrum e XP direto das Trincheiras.
Outro artefato de grande importância no Scrum é a Sprint Backlog, que

consiste no conjunto de tarefas a serem executadas pelo time durante uma Sprint. A
equipe juntamente com o Product Owner, prioriza os itens do Product Backlog e
extrai os de maior relevância para serem inseridos na Sprint Backlog.
53
A equipe de desenvolvimento tem a função de estabelecer a quantidade de

itens que serão inseridos no Product Backlog. Esse levantamento e seleção dos
itens são feitos por meio da reunião de planejamento da Sprint [PEREIRA, 2007].
Segundo PEREIRA (2007), para cada item inserido na Sprint, o time inicia o
detalhamento de suas atividades, estimando em horas a duração de cada uma
delas, não permitindo que ultrapasse o limite máximo de tempo que é de 16 horas
para cada tarefa.
Após todas as tarefas estimadas, a equipe de desenvolvimento questiona se

realmente consegue assumir o compromisso de realizar as tarefas dentro da Sprint,
e finalizar o item priorizado. Uma vez decidido o item, a equipe passa para o próximo
item, continuando o processo até que todos os itens da Sprint Becklog sejam
concluídos [PEREIRA, 2007]
Por fim, 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. A
sua principal função é mostrar o ritmo de trabalho que o time está desempenhando,
facilitando a detecção de problemas no andamento da Sprint e a tomada de
providências para a resolução dos mesmos. O Gráfico 3 a seguir exemplifica um
Burndown Chart.
Gráfico 3: Exemplo de um Burndown Chart
Fonte: Entendendo o Scrum para Gerenciar Projetos de forma Ágil.

54
2.4.4 Cerimônias
As cerimônias do Scrum consistem nas reuniões feitas durante todo o ciclo

de desenvolvimento do projeto, tendo como principal objetivo auxiliar no
monitoramento, gerenciamento e desempenho da equipe, possibilitando a detecção
de falhas durante o desenvolvimento e execução do projeto.
O Scrum possui quatro tipos de cerimônias: Sprint Planning Meeting, Daily

Scrum Meeting, Sprint Review e a Sprint Retrospective, cada uma delas com
objetivos bem peculiares e realizadas em momentos específicos do ciclo de vida,
conforme demonstrado através da Figura 17 a seguir [ALMEIDA, 2009].
Figura 17: Cerimônias do Scrum
Fonte: Uma abordagem automatizada para monitorar o desenvolvimento ágil com Scrum.
A reunião de planejamento ou Sprint Planning Meeting,é uma reunião

realizada durante o início de cada Sprint, com duração de aproximadamente 8
horas, objetivando estabelecer o que será feito na próxima iteração. Esta reunião
opcionalmente pode ser dividida em partes, a Sprint Planning 1 e a Sprint Planning 2
cada uma com duração de 4 horas. Na Sprint Planning Meeting, devem estar
presentes o Product Owner, o Scrum Master e todo o Scrum Team.
Durante a Sprint Planning Meeting, é de responsabilidade do Product Owner

descrever as funcionalidades de maior prioridade para a equipe. 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. Essas tarefas
irão dar origem ao Sprint Backlog [ALMEIDA, 2009].
55
Outra cerimônia de grande importância é a Daily Scrum Meeting, que

consiste em uma reunião diária feita no início ou no fim de cada dia. Esta cerimônia
tem como objetivo difundir o conhecimento a todos os membros da equipe,
discutindo que foi feito no dia anterior, proporcionando a todos o conhecimento dos
impedimentos que ocorreram no dia, e priorizando o trabalho que se inicia no dia em
questão [ALMEIDA, 2009].
Segundo PEREIRA (2007), é ideal que a Daily Scrum seja realizada sempre
no mesmo lugar e na mesma hora do dia, geralmente na parte da manhã, ajudando
a estabelecer as prioridades do novo dia de trabalho.
A Daily Scrum deve ter a participação de todos os membros da equipe, e

não deve ser utilizada como uma reunião para resolução de problemas, 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, 2007]. 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, os mesmos devem

ser tratados o mais rápido possível pelo Scrum Master.
Outra cerimônia do Scrum é a Sprint Review, que é uma reunião feita ao

final de cada Sprint, onde o Scrum Team mostra o que foi feito durante a Sprint.
Nesta reunião consiste basicamente em apresentar a versão de demonstração das
funcionalidades do projeto já concluídas. As pessoas que participam da Sprint
Review são tipicamente o Product Owner, o Scrum Team, o Scrum Master.
Ao final da Sprint, ocorre uma reunião chamada Sprint Retrospective, cujo

objetivo é identificar o que funcionou bem, o que pode ser melhorado, e quais as
atitudes vão ser tomadas para melhorar.
56
3 ESTUDO COMPARATIVO: PMBOK® X Scrum
Neste capítulo, 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, apresentado seus pontos de
compatibilidade e diferenças.
A Tabela 2 a seguir demonstra resumidamente uma comparação entre a

abordagem tradicional e a abordagem ágil.
Tabela 2: Comparativo entre a abordagem Tradicional X Ágil
ABORDAGEM TRADICIONAL ABORDAGEM ÁGIL

Preditivo: detalhar o que ainda não é Adaptativo: conhecer o problema,
bem conhecido. resolver antes questões críticas.
Rígido: seguir especificação predefinida, Flexível: adaptar-se a requisitos atuais,
a qualquer custo. que podem mudar.
Burocrático: controlar sempre para Simplista: fazer algo simples agora e
alcançar o objetivo. alterar se necessário.
Orientado a processos: podem garantir a Orientado a pessoas: motivadas e
qualidade. comprometidas.
Documentação gera confiança. Comunicação gera confiança.
Sucesso corresponde a entregar o Sucesso corresponde a entregar o
planejado. desejado.
Gerenciamento no estilo comando e Gerenciamento no estilo liderança/
controle,voltada para o trabalho em orientação, voltada para trabalhadores
massa. do conhecimento.
Ênfase: papel do gerente, planejamento Ênfase: criatividade/flexibilidade e
e disciplina fortes. atenção às pessoas.
Desenvolvedor hábil (variedade). Desenvolvedor ágil (colaborador).
Cliente pouco envolvido. Cliente comprometido (com autonomia
para decidir).
Requisitos conhecidos e estáveis. Requisitos emergentes e mutáveis.
Retrabalho/reestruturação caros. Retrabalho/reestruturação baratos.
Planejamento direciona resultados Resultados direcionam planejamento
(incentiva controlar). (incentiva mudar).
57
Conjunto de processos com metodologia Conjunto de valores com atitudes e

definida. princípios definidos.
Premia a garantia da qualidade. Premia o valor rápido obtido.
Foco: projetos grandes ou que envolvam Foco: projetos de natureza exploratória e
restrição de confiabilidade (exigem mais inovadores, com equipes pequenas
formalismo). /médias (exigem maior adaptação).
Objetivo: controlar em busca de alcançar Objetivo: simplificar processo de
o objetivo planejado (em termos de desenvolvimento, minimizando e
tempo,custo e escopo). dinamizando tarefas e artefatos.
Responsabilidade recai sobre o Responsabilidade recai sobre o
processo da organização (menos envolvimento e a experiência dos
suscetível a falhas) membros da equipe.
Foco na maturidade, decorrente da Foco na disciplina, seguindo valores,
definição e uso de processos e modelos princípios e boas práticas documentados
de maturidade. na literatura.
Foca em questões ligadas ao Foca em questões ligadas ao trabalho
gerenciamento, tanto de projeto quanto técnico e valor agregado ao produto
de processo. (resultado).
Institucionalização de processos é Utilização das práticas é crucial
crucial definidos, escritos, treinados, princípios e boas práticas devem ser
praticados, controlados e cobrados. levadas ao extremo.
Abordagem mais profunda para gerência Abordagem ainda superficial para
de projetos. gerência de projetos.
Fonte: Uma comparação entre o PMBOK® e a XPM.
Tanto a abordagem ágil quanto a abordagem tradicional possuem

características positivas e negativas, a grande diferença entre as duas abordagens
está no conjunto de propósitos de cada uma.
3.1 PMBOK® X Scrum: Ciclo de Vida
No PMBOK®, o ciclo de vida do projeto é dividido em várias fases, e o

planejamento é feito no inicio de cada fase. As fases são executadas uma após a
outra, e é a equipe de gerenciamento a responsável por definir todo o ciclo de vida
do projeto, estabelecendo quais são as ferramentas e técnicas mais adequadas a
serem utilizadas para determinado tipo de projeto. Define geralmente qual o trabalho
deve ser realizado, quem está envolvido no trabalho e como controlar e aprovar
cada fase do projeto [PMBOK®, 2004].
No Scrum, o ciclo de vida do projeto é composto em quatro fases: à fase de

planejamento, Stagging, desenvolvimento e Releasing.
58
O projeto é dividido em Sprints, onde o planejamento é feito no início de

cada Sprint e somente para aquela Sprint específica [MACIEL, 2008].
A Figura 18 abaixo ilustra uma comparação entre o ciclo de vida do

PMBOK® e do Scrum.
Figura 18: Comparação entre o ciclo de vida do PMBOK® e do Scrum
Fonte: http://www.fokasearch.com.br/?p=229
3.2 PMBOK® X Scrum: Gerenciamento de Integração
No PMBOK®, a integração refere-se os objetivos, planejamento e

coordenação das atividades do projeto. O plano do projeto é realizado de forma
bastante formal e detalhada, e somente no início do projeto. Na fase de integração,
o gerente é o responsável pelo projeto e tem o controle total sobre ele [PMBOK,
2004].
59
No Scrum, o plano do projeto é representado pelo Product Backlog e a

Sprint Backlog, onde são constantemente atualizados durante o decorrer do projeto.
No Scrum o gerente de projetos é representado pelo Scrum Master, e atua somente
como um facilitador do projeto, minimizando que possíveis impedimentos venham a
ocorrer.
3.3 PMBOK® X Scrum: Gerenciamento de Escopo
O Gerenciamento de Escopo no PMBOK® não é compatível com o Scrum.

No PMBOK®, o gerenciamento de escopo tem a finalidade de garantir que o projeto
termine apenas com o esforço necessário, definindo o escopo detalhado no início do
projeto. O gerenciamento de escopo deve ser realizado utilizando ferramentas
centralizadas e processos de tomada de decisão, onde toda a informação levantada
deve ser documentada na especificação de requisitos, que servirá de base para a
gestão de mudanças durante o andamento do projeto [PMBOK®, 2004].
No Scrum, o escopo é definido com um alto nível de detalhamento, mas com

a intenção de permitir um melhor entendimento do trabalho, onde após sua definição
os requisitos são estabelecidos e priorizados com a participação de toda a equipe do
projeto, inclusive o cliente, que define e discute as funcionalidades durante cada
ciclo de desenvolvimento.
3.4 PMBOK® X Scrum: Gerenciamento de Tempo
O Gerenciamento de tempo é semelhante entre os dois métodos. No

PMBOK®, os processos de definição, 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®,
2004].
No Scrum, o gerenciamento de tempo também é realizado através da

elaboração de um cronograma, mas com a peculiaridade de ser orientado
exclusivamente ao produto que será produzido em cada iteração, havendo uma
participação direta do cliente que é o responsável em definir a prioridade funcional
de cara iteração [VIANA, 2008].
60
3.5 PMBOK® X Scrum: Gerenciamento de Custos
No PMBOK®, o gerenciamento de custos do projeto tem o objetivo de

garantir que o projeto termine dentro do orçamento estabelecido. 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. O foco está em controlar, monitorar e documentar
as mudanças para que não afete o custo planejado inicialmente no projeto
[PMBOK®, 2004].
No Scrum, as alterações podem ser realizadas mesmo em fases avançadas

do projeto, e são incorporadas na iteração mais apropriada, havendo total
consentimento do cliente. No Scrum existe sempre a preocupação em atender o
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.
3.6 PMBOK® X Scrum: Gerenciamentos de Qualidade
Neste contexto, as duas abordagens são similares, tanto o Scrum como o

PMBOK® reconhecem a importância em planejar a qualidade do projeto, a fim de
garantir a satisfação do cliente, o diferencial entre os dois métodos está na forma de
garantir e controlar a qualidade.
No PMBOK®, 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. Os processos de gerenciamento de qualidade destinam-se
principalmente no monitoramento e controle da qualidade dos resultados do projeto,
e assegurar que estes resultados estejam de acordo com o que o cliente deseja, e
dentro dos padrões de qualidade desejados.
No Scrum, o gerenciamento de qualidade é realizado durante todo o ciclo de

vida do projeto, devido ao fato do projeto estar sendo elaborado de forma
incremental a cada iteração desenvolvida, onde são realizados testes desde o início
do projeto.
61
Ao detectar um problema no projeto o Scrum Master juntamente com

Product Owner são os responsáveis em resolvê-los. Durante a Sprint Review, as
etapas que já foram concluídas são entregues ao Product Owner, onde o mesmo
tem o privilégio de aceitar ou recusar estas entregas realizadas caso elas não
atendam aos requisitos especificados anteriormente.
No Scrum, a cada término de uma Sprint é feita a Sprint Review, onde são
realizadas as entregas das partes do projeto que foram concluídas durante a Sprint
anterior ao Product Owner, que irá verificar se realmente as entregas atendem aos
requisitos estabelecidos. Posteriormente, é feita a Sprint Retrospective, que tem com
principal objetivo melhorar os processos para a próxima Sprint, verificando quais as
práticas serão mantidas e quais deixarão de ser feitas.
3.7 PMBOK® X Scrum: Gerenciamento de Recursos Humanos
Neste contexto as duas abordagens são compatíveis, mas com

características bem peculiares. Tanto no Scrum como no PMBOK®, as premiações
e comemorações pela realização de um projeto bem sucedido são comuns entre
ambas as abordagens.
No PMBOK®, a definição coerente dos papéis e responsabilidades dos

integrantes da equipe é um objetivo primordial dessa área de conhecimento, pois
cada membro é treinado e guiado através dos processos na execução de suas
tarefas. O planejamento de recursos humanos no PMBOK® visa organizar e
gerenciar a equipe, identificando e documentando as funções, responsabilidades e
as relações hierárquicas entre seus integrantes, proporcionando o melhoramento da
interação e o desempenho dos membros da equipe.
No Scrum, a confiança e a colaboração dos integrantes da equipe é um fator

essencial no projeto. O planejamento e a tomada de decisões são realizados em
conjunto entre todos os participantes do projeto, exigindo profissionais habilidosos,
não exigindo necessariamente que toda a equipe tenha o mesmo nível. No Scrum,
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.
62
3.8 PMBOK® X Scrum: Gerenciamento de Comunicações
Nesta área de conhecimento o PMBOK® e o Scrum se divergem. No

PMBOK® o gerenciamento de comunicações é realizado de maneira formal e
documentada, com divulgação e acompanhamento dos resultados do trabalho feitos
no decorrer do 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 Scrum, devido ao fato de ser uma metodologia ágil traz melhorias no

processo de comunicação e na interação entre os envolvidos no projeto,
promovendo um constante feedback durante o processo de construção do projeto.
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, na revisão das Sprints e em todo
processo de desenvolvimento do projeto.
O Scrum por não ter um nível de formalismo mais abrangente como

acontece no PMBOK®, proporciona uma maior aproximação entre as partes
envolvidas no projeto, mas necessita de que as mesmas tenham maturidade
suficiente para que não haja conflitos.
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.
3.9 PMBOK® X Scrum: Gerenciamento de Riscos
Neste contexto, as duas abordagens são similares, tanto o PMBOK® quanto

Scrum a análise, identificação e respostas aos riscos são comuns. No PMBOK®, é
feito um plano formal para o gerenciamento de riscos, garantindo a identificação,
avaliação, quantificação, planejamento de respostas, monitoramento e controle dos
processos durante o ciclo de vida do projeto.
No Scrum, a identificação, análise, monitoramento e respostas aos eventos

de riscos são realizados continuamente durante as reuniões de planejamento de
cada iteração. No monitoramento e controle dos riscos, é feita uma reavaliação
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.
66
4.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 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.
A figura 19 a seguir ilustra o novo ciclo de vida do Scrum agregando

algumas práticas tradicionais importantes do PMBOK®.
Figura 19: Novo ciclo de vida: PMBOK® e Scrum
Fonte: Desenvolvido pelo Autor.

67
Etapa 1- Visão do Projeto: A primeira etapa do framework consiste em uma visão

geral de como será a estrutura do projeto, realizada através da primeira reunião de
planejamento, neste contexto denominada Sprint Planning 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 equipe
de desenvolvimento do projeto, e o gerente de projetos, que consiste na pessoa
responsável pelo setor de TI, cuja competência é garantir que os objetivos do projeto
estão sendo compridos.
Etapa 2 - Product Backlog: Na segunda etapa do framework, 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, e posteriormente desenvolve um quadro, que neste
contexto será denominado Product Backlog, contendo todas as funcionalidades do
projeto que precisam ser atendidas. O Product Backlog será exposto no ambiente de
trabalho para todos os integrantes da equipe tomar conhecimento do que será feito
no projeto.
A figura 20 a seguir ilustra o modelo de um novo Product Backlog que será

utilizado neste framework.
Figura 20: Exemplo do Novo Product Backlog
Fonte: Desenvolvido pelo Autor.

68
Etapa 3 - Documentação: Na terceira etapa do framework, o gerente de projetos

juntamente com a sua equipe de desenvolvimento irá realizar a documentação da
descrição detalhada do projeto, criar uma EAP com base no projeto que será
desenvolvido, detectar e documentar os possíveis riscos que podem ocorrer durante
o andamento do projeto, e irá realizar o planejamento de aquisições e o
planejamento de recursos humanos do projeto.
A figura 21 a seguir ilustra um exemplo de estrutura de uma EAP específica

que será utilizada neste framework.
Figura 21: Exemplo de uma EAP específica
Fonte: Desenvolvido pelo Autor
Etapa 4 - Product Backlog Priorizado: Na quarta etapa do framework, o gerente

de projetos, a equipe de desenvolvimento e o cliente realiza a segunda reunião de
planejamento, chamada Sprint Planning 2, com o objetivo de priorizar os itens de
maior importância do Product Backlog, para então criar a Sprint Backlog contendo
os itens de maior relevância, para posteriormente dar inicio ao ciclo de
desenvolvimento.
69
Etapa 5 - Sprint Backlog: Nesta etapa do framework, a Sprint Backlog deve ser
criada através de um quadro contendo os requisitos em ordem de maior importância,
juntamente com as atividades que devem ser realizadas em cada um destes
requisitos, as atividades em andamento juntamente com o nome da pessoa
responsável por essa atividade, e as tarefas já concluídas.
A figura 22 exemplifica como dever ser o quadro de itens priorizados do

Product Backlog para esse framework.
Figura 22: Quadro de itens priorizados
Fonte: Desenvolvido pelo autor.
O quadro de itens priorizados deve ser colocado pelo gerente de projetos ao

lado do Product Backlog, para que todos os integrantes da equipe tomem
conhecimento dos requisitos e das tarefas mais importantes que devem ser
desenvolvidas primeiramente. 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.
70
Para auxiliar no gerenciamento das atividades das etapas 2 e 5 deste

framework, foi proposto a utilização da ferramenta de gerenciamento de projetos
DotProject, como demonstrado a seguir através do seu tutorial de utilização.
Tutorial de Utilização do DotProject
O DotProject é um sistema de gerência de projetos em software livre de fácil

utilização, com um conjunto de funcionalidades e características que o tornam
indicado para implementação em ambientes corporativos, pois atende a diversas
necessidades de gerentes e Escritórios de Projetos.
O DotProject consiste em uma aplicação web e seu acesso é feito através

de um navegador, assim sua utilização independe de sistema operacional e
instalação na máquina do usuário, pois é executado em um servidor. Em termos
mais técnicos, o DotProject é um sistema escrito em PHP, que utiliza banco de
dados MySQL.
Após instalado o DotProject, deve-se seguir os seguintes passos para

utilizá-lo.
1º Passo: Fazer Login
Fazer o login no sistema, por padrão o DotProject utiliza o usuário “admin” e a senha
é “passwd”.
Preencha o nome do usuário e senha

Clique em login
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.
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
- Coordenação geral (usuários vinculados exclusivamente a administração da
rede)
- Doutorando
- Iniciação científica
- Mestrando
- Pós doutorando
- Técnico administrativo ou informática
- Pesquisador (todos os outros usuários)
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.
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,
basta preenche-los e clicar no botão “enviar”.
73
4º Passo: Criar um Projeto
Para adicionar um novo projeto, basta clicar em “empresa”, selecionar a empresa

que será criado o projeto e em seguida clicar em “novo projeto”.
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, basta preencher os
campos e clicar em “enviar”.
5º Passo: Criando as tarefas.
As tarefas devem ser vinculadas a um projeto e as informações cadastradas nestas,

como datas, dependências e recursos humanos, definem o projeto em que estas
estão vinculadas, ou seja, qualquer alteração nas tarefas, o projeto é alterado.
Para criar uma tarefa, é necessário acessar o projeto onde deseja inserir a tarefa,
clicar em nova tarefa, preencher as informações sobre a tarefa nas abas detalhes,
datas, dependências e recursos humanos, e em seguida clicar em salvar.
74
Para cadastrar uma nova tarefa é necessário acessar o projeto que deseja inserir
esta tarefa.
 Clique no link empresa.
 Selecione a empresa clicando sobre ela.
 Clicar sobre o nome do projeto que deseja inserir a nova tarefa.

75
 Clique sobre o link nova tarefa.
Etapa 6 - Sprint: Nesta etapa, após a priorização de todos os requisitos é dado

inicio ao ciclo de desenvolvimento, dentro do prazo estimado de 2 a 4 semanas para
conclusão de todo o projeto, ou de apenas algumas funcionalidades, ficando a
critério do gerente de projetos decidir o que é melhor para aquele determinado
projeto. 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, para realizar a tomada
de providências.
Etapa 7 - Atualização da documentação: Nesta etapa, após a finalização de cada

ciclo de desenvolvimento é realizado a atualização de toda a documentação do
projeto, descrevendo tudo o que foi feito na Sprint, quais foram às barreiras
encontradas durante andamento do projeto, e o que pode ser melhorado para dar
inicio a próxima Sprint.
Etapa 8 - Retrospectiva: Nesta etapa, o gerente de projetos juntamente com sua

equipe realiza uma reunião de retrospectiva após cada ciclo de desenvolvimento,
neste contexto denominado Sprint Retrospective. O objetivo principal desta reunião
é promover melhorias para o próximo ciclo de desenvolvimento, pois os membros da
equipe irão identificar e priorizar o que consideram que foi bem e o que pode se
melhorado, traçando planos de ação para realizar essas melhorias. 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, dando continuidade ao desenvolvimento até que todos os itens do
Product Backlog tenham sido finalizados.
Etapa 9 - Entrega Final: Nesta fase é realizado o fechamento e documentação do

projeto a partir da conclusão de todos os itens do Product Backlog, e o arquivamento
76
das lições aprendidas durante o projeto com o intuito de minimizar falhas em

projetos futuros.
4.4 Diagnóstico das análises realizadas
Para constatar a viabilidade ou inviabilidade da utilização da proposta deste

trabalho, foram feitas análises presenciais no setor de Tecnologia da Informação de
ambas as instituições citas anteriormente, e entrevistas aplicadas aos responsáveis
pelo setor TI, para o levantamento e coleta de informações, onde foi constatado o
seguinte:
4.4.1 Instituição A
O setor de Tecnologia da Informação da Instituição de Ensino Superior

analisada neste trabalho é composto por 18 colaboradores, dentre eles, analistas de
sistemas, 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, tendo como
principais projetos criados o desenvolvimento de sistemas, e projetos voltados para
a área de redes de computadores, chefiados por 2 analistas de sistemas
responsáveis pelo setor de TI.
Após a análise do setor de TI da Instituição, constatou-se que o mesmo não

utiliza nenhuma metodologia ou procedimento capaz de orientar de forma eficaz os
seus projetos. Quando se é requisitado um novo projeto, ocorre sempre uma
tempestade de idéias desorganizadas (brainstorming) entre os componentes da
equipe, e posteriormente a organização das mesmas para em seguida ocorrer o
planejamento e desenvolvimento do projeto, sempre de forma bastante informal.
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, onde ocorre o detalhamento
do projeto que será executado, o mesmo feito de forma informal. Após a reunião de
planejamento do projeto a equipe define superficialmente o escopo do projeto para
todas as partes envolvidas, ocorrendo sempre inconformidades nos resultados
entregues ocasionadas pela falta de uma descrição detalhada do escopo.
77
Alterações no escopo original do projeto desenvolvido pela equipe do setor

de TI freqüentemente são requisitadas, e realizadas sem algum tipo de
documentação ou revisão. O cronograma do projeto na maioria das vezes possibilita
um acompanhamento eficaz do projeto, 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, sem

nenhum mecanismo capaz de priorizar as atividades de maior importância para
serem desenvolvidas primeiramente.
Os custos relativos aos projetos geralmente são condizentes com o

combinado, mas a equipe não emprega nenhuma ação para garantir a qualidade
das atividades que são desenvolvidas no projeto.
Os projetos realizados não possuem um prazo predeterminado para sua

conclusão, e não há uma forma eficaz de estimar com precisão o tempo de duração
de cada projeto criado. Na fase de conclusão de um projeto não são feitas
documentações de todo o trabalho que foi realizado.
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.
4.4.2 Instituição B
O setor de Tecnologia da Informação da cooperativa de laticínios analisada

neste trabalho é composto por 2 colaboradores, sendo 1 técnico em informática e 1
analista de sistemas. O Setor de TI desenvolve projetos voltados aos interesses da
cooperativa mensalmente, e dentre os principais projetos criados estão o
desenvolvimento de sistemas, implantação de sistemas, treinamentos de
funcionários, e projetos relacionados a banco de dados.
Após a realização da análise no setor em questão, 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. Ao ser requisitado
para o desenvolvimento de um novo projeto, o gerenciamento de suas atividades é
78
feito apenas através da descrição superficial das tarefas a serem executadas por
meio de editores de texto, planilhas eletrônicas e ferramentas de compartilhamento
de arquivos.
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, onde seguindo as etapas do framework constatou-
se o seguinte:
Etapa 1- Visão do Projeto: No projeto NF-e foi realizada uma reunião inicial,
conforme descreve a primeira etapa do framework, 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, onde se obteve uma visão geral de como seria a estrutura deste
projeto.
Etapa 2 - Product Backlog: Ao final da reunião descrita na etapa1 do framework, a

equipe do setor de TI da cooperativa determinou quais as tarefas precisariam ser
executadas para dar andamento ao projeto, caracterizando um Product Backlog.
Etapa 3 - Documentação: No projeto NF-e não houve a construção de uma EAP, o

gerenciamento de riscos não foi levantado formalmente, indicando os possíveis
riscos caso algum prazo fosse extrapolado. Houve o planejamento das aquisições
na área de TI e na área contábil, entretanto nenhuma política de gestão neste
sentido foi realizada.
Etapa 4 - Product Backlog Priorizado: No projeto NF-e foram construídas listas de

tarefas a serem executadas, observando critérios de prazo e custos, entretanto não
houve documentação formal para acompanhar o desenvolvimento delas.
Etapa 5 - Sprint: Os prazos para conclusão de cada funcionalidade estavam

balizados pelo tempo final da entrega de todo o projeto, sendo assim não houve
determinação formal da entrega de cada uma das funcionalidades, gerando atrasos
na iniciação das tarefas posteriores. As reuniões diárias e a gestão de riscos nesta
fase não foram realizadas.
79
Etapa 6 - 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 7 - 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. Também não ocorreram testes funcionais no
projeto visando corrigir possíveis erros, evidenciando assim o atropelamento das
outras tarefas em função do pouco tempo para o cumprimento do projeto final,
ocasionando erros freqüentes na maioria das funcionalidades desenvolvidas.
Etapa 8 - Entrega Final: No projeto NF-e não foram aplicadas nenhuma das
propostas apresentadas pelo framework para o fechamento do projeto, o mesmo foi
entregue informalmente no início da simulação do ambiente operacional.
80
5 CONSIDERAÇÕES FINAIS
Esta pesquisa apresentou um estudo sobre duas abordagens muito

utilizadas atualmente para gerenciamento e desenvolvimento de projetos, com o
intuito de auxiliar aos gerentes ou até mesmo as organizações a entenderem um
pouco melhor sobre estes paradigmas. Neste sentido, busca auxiliá-los a escolher
qual o melhor se adapta a sua realidade ou até mesmo no uso combinado de suas
práticas.
Primeiramente este trabalho concentrou-se em estudar fundamentos

teóricos sobre o tema abordado, principalmente no que se diz respeito aos
processos de gerenciamento de projetos do PMBOK® e da metodologia ágil Scrum.
Em seguida, foi apresentado um estudo comparativo entre as duas

abordagens estudadas, onde pode-se concluir que as nove áreas de conhecimento
do PMBOK® são adaptáveis com a metodologia Scrum. Entretanto existem algumas
atividades que são conflitantes e apresentam particularidades, como é o caso das
reuniões de planejamento, reuniões diárias e reuniões de retrospectiva apresentada
pelo Scrum.
Posteriormente, 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, revelando que o uso
combinado dos dois paradigmas cria um método de gerenciamento preventivo, que
não onera os projetos em termos de documentação, só os torna mais ágeis, eficazes
e preventivos. Porém o único segredo esta em saber adaptá-los corretamente.
Conforme apresentado no inicio deste trabalho de conclusão de curso, o

objetivo geral do mesmo foi analisar a viabilidade de utilização do PMBOK® e o
81
Scrum, como modelo de gestão de projetos no setor de TI de instituições de Teófilo

Otoni, 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, foram mencionadas algumas hipóteses onde
pode-se chegar as seguintes conclusões :
H1: É viável utilizar o PMBOK® e o Scrum, pois proporcionará mais

qualidade aos projetos desenvolvidos.
Essa hipótese foi validada, pois foi comprovado que com a utilização do
modelo proposto, o resultado final dos projetos é satisfatório, uma vez que atende as
necessidades dos usuários, não ocorrendo inconformidades no que foi requisitado.
H2: É viável, pois obrigará a documentação para melhorar a comunicação e

conseqüentemente o conhecimento da equipe sobre o projeto.
Essa hipótese foi validada, pois foi comprovado que em nenhuma das
instituições analisadas possui um processo de documentação eficaz dos projetos
realizados, de forma a contribuir com a disseminação da comunicação entre a
equipe de desenvolvimento.
H3: Não é viável, pois a utilização de testes em cada ciclo de

desenvolvimento poderá ocasionar atrasos na entrega do projeto final.
Esta hipótese não foi validada, pois foi demonstrado que a realização de
testes em cada ciclo de desenvolvimento garante a redução do tempo final do
projeto, uma vez que é mais fácil corrigir erros em cada funcionalidade em particular
do que no projeto como um todo.
Após a realização deste trabalho, conclui-se que é perfeitamente viável a

utilização de ambos os paradigmas em conjunto, aplicados ao setor de Tecnologia
da Informação de instituições de Teófilo Otoni. Neste contexto comprovarmos que o
uso do modelo proposto irá acrescentar inúmeros benefícios ao referido setor,
82
principalmente no que diz respeito ao gerenciamento de seus projetos, 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; o envolvimento de todos os participantes do projeto em todas as fases; e o
melhoramento de habilidades para atender as exigências dos usuários internos da
instituição, proporcionando uma prestação de serviços mais ágil, segura e eficiente.
Porém, somente é necessário saber como aplicar os processos para cada projeto
em particular.
Para finalizar, fica a sugestão para trabalhos futuros o desenvolvimento de

uma aplicação fundamentada nos paradigmas estudados, para auxiliar no
desenvolvimento de projetos no setor de Tecnologia da Informação.
83
REFERÊNCIAS BIBLIOGRÁFICAS
BRAGA, Alcir Rodrigues. Gerência de Projetos: Preparação para a Certificação

PMP. Novembro 2003.
DAVILA, Marcio. Sucessos e Falhas em Projetos de TI. 2010
FRANCO, Eduardo Ferreira. Um modelo de gerenciamento de projetos baseado

nas metodologias ágeis de desenvolvimento de softwares e nos princípios da
produção enxuta. 2007.
GIL, Antonio Carlos. Como Elaborar Projetos de Pesquisa. 4ª Ediçao. São Paulo
2002.
GONÇALVES, André Silva. Gestão de Projetos em Pequenas e Médias

Empresas: Principais dificuldades. 2009. Disponivel em:
http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/677. Ultimo acesso em
13/09/2010 às 10:00
MAGNO, Alexandre. Revista Visão Ágil – Scrum Master por Ele Mesmo. Edição 4
2008. Disponível em: www.visaoagil.com. Ultimo acesso: 11/10/2010.
MARÇAL, Ana Sofia. Estendendo o SCRUM segundo as áreas de processo de

gerenciamento de projetos do CMMI. 2007
MARTINS, Leonardo Vieira. Gestão Profissional de Projetos. 2003. Disponível em:

http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/83. Ultimo acesso em
12/10/2010 às 09:40
MIRANDA, J. M. Metodologias Ágeis para o Desenvolvimento de Software,

Scrum eExtreme Programming X Metodologias Tradicionais RUP. 2008.
NARDI, Kleber. PMBOK x SCRUM: Como gerenciar um projeto de software?

2009.
84
PMBOK - Project Management Body of Knowledge. Um Guia do Conjunto de

Conhecimentos em Gerenciamentos de Projetos. Guia PMBOK. Terceira Edição,
2004.
PEREIRA, Paulo. Entendendo o Scrum para Gerenciar Projetos de Forma Ágil.

Mundo PM. 2007. Disponível: http://www.lapjor.cce.ufsc.br/elgg/html/pg/
file/benhur/read/349/entendendo-scrum-para-gerenciar-projetos-de-forma-gil. Ultimo
acesso em: 25/09/2010 às 16:00
REINERT, Jonatas Davson. Estudo do uso de Metodologias Ágeis no

Desenvolvimento de uma aplicação de governo eletrônico. Departamento de
Informática e Estatística – Universidade Federal de Santa Catarina.
SOARES, Michel dos Santos. Comparação entre metodologias ágeis e

tradicionais para desenvolvimento de software. Disponível em:
http://www.fatecinformatica.com/wp-content/uploads/2010/04/comparacaoentre-
metodologias.pdf. Ultimo acesso em 15/09/2010 às 15:10.
STANLEIGH, Michael. Combinando a Norma ISO 10006 e o Guia PMBOK para

garantir sucesso em projetos. 2005.
TORREÃO, Paula. Ambiente Inteligente de aprendizado para Educação em

Gerenciamento de Projetos. 2005. Dissertação (Pós-Graduação em Ciência da
Computação) – Universidade Federal de Pernambuco, Recife.
VARGAS, Ricardo. Manual prático do plano do projeto. 3ª Ed.Rio de Janeiro.

Brasport, 2007. Disponível em:http://issuu.com/ricardo.vargas/docs/manualprat.
Ultimo acesso em 25/09/2010 às 14:20
VARGAS, Ricardo. Gerenciamento de projetos: estabelecendo diferenciais

competitivos. 3ª Ed.Rio de Janeiro. Brasport, 2009.
VIANA, Antonio Geraldo Gonçalves. Gerenciamento de projetos em processo ágil

de desenvolvimento de software. 2008. Disponível em:
http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/393. ultimo acesso em
26/09/2010às 20:30.
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 - Qual o número de colaboradores que trabalham no setor de Tecnologia da

Informação da Instituição?
1 ( ) 2 ( ) 3 ( ) 4 ( ) 5 ( ) Quantos?...................
R: Instituição A. 18
R: Instituição B. 2
2 - Qual a formação das pessoas da equipe?
( ) Ensino Médio: Quantos da equipe?.......................

( ) Ensino Técnico: Quantos da equipe?.....................
( ) Ensino Superior: Quantos da equipe?............................ Em quais
cursos?..............
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.
89
R: Instituição A. 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.
R: Instituição B. Há claramente duas espécies de projetos na empresa: O
Legal, inserido por alguma normativa Federal, Estadual ou Municipal, e o
Estratégico, inserido por determinação da Direção da Empresa para fins de
melhoria funcional. Todos os projetos têm prazos pré-determinados, entretanto
a prioridade segue a orientação para os atos Legais em função de
penalizações por descumprimento de prazos.
16 - Existe algum mecanismo utilizado para priorizar as funcionalidades mais

importantes a serem desenvolvidas no projeto? Comente.
R: Instituição A. Não existe.
R: Instituição B. Sim. O primeiro mecanismo é externo, são as penalidades,

no caso dos Legais. O segundo mecanismo vale para todos os projetos. Trata-
se de uma reunião semanal entre os Gerentes para deliberação de assuntos de
todas as áreas da empresa. Todos os outros mecanismos não são tratados
formalmente.
17 - As atividades e os prazos de conclusão apresentados são condizentes

com o combinado?
R: Instituição A. Geralmente sim.
R: Instituição B. Sim. Os projetos Legais devem ter seus prazos confirmados

uma vez que há penalizações severas no caso de atrasos. Os projetos
Estratégicos, mesmo com prazo pré-estabelecidos, geralmente não são
completados dentro do cronograma.
18 - Os custos dos projetos são planejados e acompanhados adequadamente,

ou ocorrem custos adicionais nos projetos ocasionados pela falta de uma
gestão eficaz?
90
R: Instituição A. Geralmente os custos são adequados.
R: Instituição B. Sim são planejados, entretanto podem surgir novas

funcionalidades e o planejamento de custo é alterado informalmente.
19 - 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. Nenhuma ação é empregada.
R: Instituição B. 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;
b) Simulação do ambiente operacional: Trata-se de execução das

tarefas implementadas no próprio ambiente de funcionamento das
atividades, utilizando-se material e os recursos humanos que serão
usados diretamente na produção. Nesta fase há treinamentos in loco
deste ambiente.
20 - O responsável pelo setor que necessita dos serviços do Setor de TI da

instituição participa ativamente no projeto. Se sim, como?
R: Instituição A. Sim. Planejando, controlando, e algumas vezes controlando o

projeto.
R: Instituição B. Sim. Direcionando e cobrando as especificações do Projeto.
21 - Os projetos desenvolvidos pelo setor de TI da instituição tem trazido

resultados satisfatórios?
R: Instituição A. Sim.
R: Instituição B. Na medida do possível sim. Entretanto acho que a TI deva

passar por reformulações nas suas atividades primárias, principalmente na
91
área de desenvolvimento, para que haja maior produtividade funcional com

ganhos reais para a empresa.
22 - 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.
R: Instituição B. Política Legal e Estratégica.
23 - 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.
Voçê acha viável utilizar algum destes modelos no setor de TI desta
instituição?
R: Instituição A. Os dois, por auxiliarem na organização e agilizarem as

tarefas.
R: Instituição B. Sim. Acho extremamente necessária algumas produções de

artefatos do PMBOK em conjunto com interatividade e fluidez do Scrum.
92
ANEXO 2
Tutorial de Instalação do DotProject
O dotProject é um programa distruibuido sob licença GNU-GPL

(http://www.gnu.org/licenses/gpl.txt) e tem seu desenvolvimento mantido
principalmalmente pela empresa australiana Saki Computers
(http://www.saki.com.au) a qual trabalha mantendo serviços extras
correlacionados ao mesmo, como customização, suporte técnico e etc.
Como já foi dito anteriormente, o DotProject é um software online, por

isso ele vai precisar ser instalado em um servidor, e esse servidor tem de ter
suporte a PHP e MySQL. Para usuários acessarem o DotProject eles devem
usar um browser (Mozilla firefox, opera, konqueror, internet explorer e etc).
Para resumir, 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 - Download
As etapas de instalação do DotProject a seguir será baseada na

plataforma Linux. Para instalar o dotproject primeiramente precisa-se baixar o
pacote. No site oficial você irá achar o pacote. Se preferir clique no link abaixo.
 http://ufpr.dl.sourceforge.net/sourceforge/dotproject/dotproject-2.0.4.tar.gz
Em seguida deve descompactar em algum diretório que tenha acesso a

web e permissão de escrita. No Debian esse diretório seria o /var/www ou no
public_html. Para outros sistemas existem diretórios diferentes.
Você pode também simplificar esse primeiro passo simplesmente com
os comandos:
 # apt-get install wget

93
 # cd /var/www
 # wget -c -nd http://ufpr.dl.sourceforge.net/sourceforge/dotproject
/dotproject-2.0.4.tar.gz<LI< a> style="text-align:justify;"># tar xzvf dotproject-
2.0.4.tar.gz
Passo 2 - Configurando usuários
Para poder ter privilégios de escrita, leitura etc, você precisa configurar
o usuário para que ele possa fazer o que precisa, 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.
Obs: Essas permissões serão modificadas posteriormente para assegurar a
segurança do sistema.
Passo 3 - Acessando a pasta
Depois que tiver baixado o pacote e modificado as permissões você

deve iniciar a instalação, 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).
94
Passo 4 - Iniciando a Instalação
Depois de ter clicado no link referido acima você vai entrar numa nova
página. Confira os detalhes da pagina, já que Algumas das configurações
podem resultar em falha parcial ou completa da instalação.
Por exemplo, 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.
Se precisar fazer modificações as faça e depois atualize a página. 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, caso contrario siga para o passo 5.
Passo 5 - Criando Banco de dados
Você vai precisar criar um banco de dados para o DotProject, 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 "dp-
user"localhost" IDENTIFIED BY "SENHA"
 FLUSH PRIVILEGES
 Quit
Pronto, o banco de dados está criado com os privilégios necessários.

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

Monografia Pmbok e Scrum PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Monografia Pmbok e Scrum PDF

Uploaded by

Copyright:

Available Formats

KÊNIO DIAS LOYOLA

NICKSON DUTRA PINHEIRO

ESTUDO DA VIABILIDADE DE UTILIZAÇÃO DO PMBOK® E O SCRUM COMO

FACULDADES UNIFICADAS DOCTUM – TEÓFILO OTONI

ESTUDO DA VIABILIDADE DE UTILIZAÇÃO DO PMBOK® E O SCRUM COMO

Trabalho de Conclusão de Curso apresentado

FACULDADES UNIFICADAS DOCTUM – TEÓFILO OTONI

Aprovada em 18 de Novembro de 2010

A presente pesquisa objetiva analisar a viabilidade de utilização das práticas

Palavras-chave: Scrum.PMBOK®. Gerenciamento de Projetos. Metodologia ágil.

Keywords: Scrum.PMBOK ®. Project Management. Agile methodologies.

FIGURA 1 - Relação entre as Partes Interessadas e o Projeto................................ 24

GRÁFICO 1 - Evolução dos Percentuais de sucesso, atraso e falhas ...................... 26

TABELA 1 - Definição das Partes Interessadas em um Projeto ................................ 23

PMBOK - Project Management Body of Knowledge

Diante da evolução dos meios tecnológicos e o mercado cada vez mais

Contudo observa-se um crescente aumento na implantação de projetos nas

Pesquisas realizadas pela Standish Group revelam que a maioria dos

Tendo como base esta realidade e visando melhorias nesses tipos de

Mediante aos fatos supracitados, a presente pesquisa foi desenvolvida no 8º

A pesquisa em questão contempla minimizar os contratempos enfrentados

Este trabalho visa propor a utilização de um método inovador, baseado na

Portanto, tendo como base este cenário o problema motivador desta

As hipóteses criadas para responder a essa pergunta problema foram:

H1: É viável utilizar o PMBOK® e o Scrum, pois proporcionará mais

H2: É viável, pois obrigará a documentação para melhorar a comunicação e

H3: Não é viável, pois a utilização de testes em cada ciclo de

O objetivo geral desta pesquisa foi verificar a viabilidade de utilização do

Os objetivos específicos pretendidos com este trabalho foram:

 Estudar a metodologia ágil de gerência de projetos Scrum.

 Estudar o guia de práticas em gerenciamento de projetos PMBOK®.

 Realizar uma abordagem comparativa entre as áreas de conhecimento

 Conhecer a realidade do setor de TI de Instituições de Teófilo Otoni.

 Criar um framework híbrido utilizando práticas das duas abordagens

Esta pesquisa foi de grande importância, pois além de verificar a viabilidade

Este trabalho também proporcionou um estudo comparativo entre o modelo

Esta pesquisa é classificada quanto aos fins como uma pesquisa

Este trabalho está dividido em quatro capítulos, o primeiro capítulo refere-se

No segundo capítulo denominado referencial teórico, aborda conceitos

No terceiro capítulo foi realizado um estudo comparativo entre as nove áreas

No quarto capítulo foi apresentado um estudo de caso no setor de TI de

Por fim, no quinto capítulo foram realizadas as considerações finais sobre o

2.1 GERÊNCIA DE PROJETOS

2.1.1 O QUE É UM PROJETO?

Segundo o PMBOK® (2004), um projeto constitui um esforço temporário

De acordo com BRAGA (2003), um projeto é um empreendimento com

Para a Norma ISO 10006, um projeto é um processo único, consistindo de

Segundo a Organização das Nações Unidas (ONU), um projeto é um

Um projeto consiste em um empreendimento com objetivo identificável, que

Para MARTINS (2003), um projeto pode ser conceituado como plano,

VARGAS (2009) define um projeto como sendo um empreendimento não

Para CLELAND (2009). um projeto constitui uma combinação de recursos

A criação de um projeto requer uma estrutura organizacional adequada para

A capacidade técnica é outro fator de extrema importância para se obter

2.1.2 O QUE É O GERENCIAMENTO DE PROJETOS?

O Guia PMBOK® (2004) define o conceito de gerenciamento de projetos da

“O Gerenciamento de Projetos é a aplicação de conhecimento, habilidades,

De acordo com BRAGA (2003), gerenciar projetos envolve tomar decisões

 Requisitos identificados (necessidades), e não identificados (expectativas).

Segundo MARTINS (2003), a gestão de projetos é a aplicação de

VARGAS (2009) descreve o gerenciamento de projetos como sendo um

2.1.3 O CICLO DE VIDA DO PROJETO.

Os gerentes de projetos podem dividir os projetos em várias fases com o