Monografia Pmbok e Scrum PDF

KNIO DIAS LOYOLA
NICKSON DUTRA PINHEIRO
ESTUDO DA VIABILIDADE DE UTILIZAO DO PMBOK E O SCRUM COMO

MODELO DE GESTO DE PROJETOS NO SETOR DE TI DE INSTITUIES DE
TEFILO OTONI
FACULDADES UNIFICADAS DOCTUM TEFILO OTONI

2010
KNIO DIAS LOYOLA
NICKSON DUTRA PINHEIRO
ESTUDO DA VIABILIDADE DE UTILIZAO DO PMBOK E O SCRUM COMO

MODELO DE GESTO DE PROJETOS NO SETOR DE TI DE INSTITUIES DE
TEFILO OTONI
Trabalho de Concluso de Curso apresentado

Comisso Examinadora das Faculdades
Unificadas Doctum - Campus Tefilo Otoni -
como requisito para obteno de ttulo do
Bacharel em Sistemas de Informaes, sob
orientao do Prof. Fabiano Ferreira Santos.
FACULDADES UNIFICADAS DOCTUM TEFILO OTONI

2010
FOLHA DE APROVAO
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 trajetria, dando - nos
fora e inspirao para concluir este
trabalho.
AGRADECIMENTOS
Agradecemos primeiramente a Deus por ter nos dado fora, e nos guiado
para conseguirmos chegar ao fim de mais uma importante etapa de nossas vidas.
Aos nossos familiares, pela base slida 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 dedicao e
disponibilidade em sempre estar sanando nossas dvidas e dificuldades atravs de
uma orientao 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
concluso deste trabalho.
No se deve julgar o mrito de um homem
pelas suas grandes qualidades, mas pelo
uso que sabe fazer delas.
(La Bruyre)
SUMRIO
1 INTRODUO ....................................................................................................... 15
2 REFERNCIAL TERICO ..................................................................................... 19
2.1 GERNCIA 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 Benefcios 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 Gerncia de Integrao do Projeto .......................................................... 32
2.2.5 Gerncia de Escopo do Projeto ............................................................... 33
2.2.6 Gerncia de Tempo do Projeto ................................................................ 35
2.2.7 Gerncia de Custo do Projeto .................................................................. 37
2.2.8 Gerncia de Qualidade do Projeto ........................................................... 38
2.2.9 Gerncia de Recursos Humanos do Projeto ............................................ 39
2.2.10 Gerncia de Comunicaes do Projeto .................................................. 40
2.2.11 Gerncia de Riscos do Projeto .............................................................. 42
2.2.12 Gerncia de Aquisies do Projeto ........................................................ 44
2.3 Desenvolvimento gil ........................................................................................ 45
2.4 Scrum ................................................................................................................ 47
2.4.1 Ciclo de Vida do Scrum ....................................................................... 48
2.4.2 Papis .................................................................................................. 50
2.4.3 Artefatos .............................................................................................. 52
2.4.4 Cerimnias........................................................................................... 54
3 ESTUDO COMPARATIVO: PMBOK x Scrum ..................................................... 56
3.1 PMBOK X Scrum: Ciclo de Vida ............................................................... 57
3.2 PMBOK X Scrum: Gerenciamento de Integrao ..................................... 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 Comunicaes ............................... 62
3.9 PMBOK X Scrum: Gerenciamento de Riscos ............................................ 62
3.10 PMBOK X Scrum: Gerenciamento de Aquisies ................................... 63
3.11 PMBOK X Scrum: Concluso do Projeto................................................. 63
4 ESTUDO DE CASO: Viabilidade da utilizao do PMBOK e o Scrum ............... 64
4.1 Mtodos adotados para o estudo de caso ................................................... 64
4.2 Descrio das instituies analisadas.......................................................... 65
4.2.1 Instituio A ................................................................................................... 65
4.2.2 Instituio B ................................................................................................... 65
4.3 Proposta de utilizao de um framework hbrido ......................................... 66
4.4 Diagnstico das anlises realizadas ............................................................ 71
4.4.1 Instituio A ................................................................................................... 71
4.4.2 Instituio B ................................................................................................... 72
5 CONSIDERAES FINAIS ................................................................................... 75
REFERNCIAS BIBLIOGRFICAS .......................................................................... 78
ANEXOS ................................................................................................................... 80
RESUMO
A presente pesquisa objetiva analisar a viabilidade de utilizao das prticas

tradicionais em gerenciamento de projetos do guia PMBOK em conjunto com a
metodologia gil Scrum, no setor de Tecnologia da Informao de instituies de
Tefilo Otoni. Este trabalho demonstrou o uso dos benefcios proporcionados por um
mtodo inovador, baseado na juno de prticas tradicionais e geis, com o intuito
de apresentar uma nova forma de garantir qualidade e agilidade nos projetos
desenvolvidos pelo setor de Tecnologia da Informao. Para tal objetivo ser
alcanado, foi realizada uma anlise comparativa entre ambos os paradigmas
estudados identificando seus pontos de compatibilidades e diferenas, e
posteriormente a criao de um framework hbrido oriundo das prticas dos dois
mtodos.
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 Tefilo 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 - Relao entre as Partes Interessadas e o Projeto................................ 24

FIGURA 2 - Os Grupos de Processos do Gerenciamento de Projetos .................... 30
FIGURA 3 - Viso Geral das reas de Conhecimento do PMBOK (2004) ............ 31
FIGURA 4 - Mapeamento do Gerenciamento de Integrao ................................... 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 Comunicaes ......................... 41
FIGURA 13 - Mapeamento do Gerenciamento de Riscos ........................................ 43
FIGURA 14 - Mapeamento do Gerenciamento das Aquisies ............................... 44
FIGURA 15 - Ciclo de vida do Scrum ....................................................................... 49
FIGURA 16 - Exemplo de um Product Backlog ........................................................ 52
FIGURA 17 - Cerimnias do Scrum ......................................................................... 54
FIGURA 18 - Comparao 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 Especfica ....................................................... 68
FIGURA 22 - Product Backlog Priorizado ................................................................ 69
LISTA DE GRFICOS
GRFICO 1 - Evoluo dos Percentuais de sucesso, atraso e falhas ...................... 26

GRFICO 2 - Evoluo dos credenciados PMP no Mundo ...................................... 27
GRFICO 3 - Exemplo de um Burndown Chart ........................................................ 53
LISTA DE TABELAS
TABELA 1 - Definio 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 Informao
ONU - Organizao das Naes Unidas
PMI - Project Management Institute
PMO - Project Management Office
PMP - Project Management Professional
ANSI - American National Standard
EAP - Estrutura Analtica de Projetos
NFe - Nota Fiscal Eletrnica
15
1. INTRODUO
Diante da evoluo dos meios tecnolgicos e o mercado cada vez mais

globalizado e competitivo, surge necessidade das organizaes estarem se
adequando a essa nova realidade, buscando obter o aprimoramento de suas
habilidades e tcnicas, a fim de se submeter a uma constante atualizao,
proporcionando assim a garantia de um diferencial competitivo.
Contudo observa-se um crescente aumento na implantao de projetos nas

organizaes, tendo em vista que os mesmos esto cada vez mais modernos
requerendo uma alta diversidade de habilidades, grande complexidade tcnica, alm
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 no cumprem o cronograma, as
funcionalidades no atendem s necessidades dos usurios ou porque no
cumprem o oramento especificado. Apenas 26% dos projetos so bem sucedidos,
o restante ou so abortados ou no 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 atravs do fornecimento de um somatrio 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 gerncia de projetos inicialmente de
software, porm 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

perodo do curso de Sistemas de Informaes, como requisito para obteno do
ttulo de bacharel em Sistemas de Informaes, e abrange algumas reas do curso
como a Engenharia de Software e a Gerncia de Projetos.
A pesquisa em questo contempla minimizar os contratempos enfrentados

pelas empresas de Tefilo Otoni, principalmente no setor de Tecnologia da
Informao (TI), que devido acirrada concorrncia, se cada vez mais exigido
uma maior produtividade e qualidade, e que freqentemente 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 utilizao de um mtodo inovador, baseado na

juno de prticas tradicionais e geis para gerncia de projetos com o intuito de
proporcionar benefcios 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 cenrio o problema motivador desta

pesquisa foi: vivel utilizar o PMBOK e o Scrum em conjunto, como modelo
de gesto de projetos no setor de TI de Instituies de Tefilo Otoni?
As hipteses criadas para responder a essa pergunta problema foram:
H1: vivel utilizar o PMBOK e o Scrum, pois proporcionar mais

qualidade aos projetos desenvolvidos.
H2: vivel, pois obrigar a documentao para melhorar a comunicao e

conseqentemente o conhecimento da equipe sobre o projeto.
H3: No vivel, pois a utilizao 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 utilizao do

PMBOK e o Scrum em conjunto como modelo de gesto de projetos no setor de
Tecnologia da Informao de Instituies de Tefilo Otoni, onde permitir o uso dos
benefcios proporcionados pelas prticas das duas abordagens em questo para
auxiliar nos processos do setor de TI.
17
Os objetivos especficos pretendidos com este trabalho foram:
Estudar a metodologia gil de gerncia de projetos Scrum.
Estudar o guia de prticas em gerenciamento de projetos PMBOK.
Realizar uma abordagem comparativa entre as reas de conhecimento

do PMBOK com a metodologia gil de gerncia de projetos Scrum.
Conhecer a realidade do setor de TI de Instituies de Tefilo Otoni.
Criar um framework hbrido utilizando prticas das duas abordagens

estudadas.
Esta pesquisa foi de grande importncia, pois alm de verificar a viabilidade

da utilizao das prticas em gerenciamento de projetos de um mtodo tradicional
em conjunto com uma metodologia gil, tambm contribuir como fonte para tomada
de decises no que se diz respeito ao desenvolvimento e implantao de futuros
projetos, possibilitando um maior entendimento relacionado ao tema abordado,
oferecendo uma gama de conhecimentos de como adaptar e usar as prticas em
gerenciamento de projetos da melhor forma possvel, com o auxilio de um framework
hbrido oriundo das duas abordagens estudadas.
Este trabalho tambm 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 organizao ou no projeto que ser desenvolvido, ou at na
utilizao das caractersticas combinadas de ambas as abordagens que melhor
adaptam-se ao seu projeto.
Esta pesquisa classificada quanto aos fins como uma pesquisa

exploratria por objetivar uma maior familiarizao com o problema e na construo
de hipteses que possa resolv-los, e tambm constitui uma pesquisa aplicada, pois
consiste em investigar, comprovar ou rejeitar hipteses construdas pelos modelos
tericos.
18
Pode-se definir esta pesquisa quanto aos meios como uma pesquisa
bibliogrfica, pois desenvolvida com base em materiais j elaborados oriundos
principalmente de livros, artigos e revistas, e tambm como uma pesquisa de campo,
caracterizada como um estudo de caso, pois complementada por um estudo de
caso da utilizao de uma tcnica ou abordagem j estudada e na anlise
aprofundada de instituies em particular.
Este trabalho est dividido em quatro captulos, o primeiro captulo refere-se

introduo da pesquisa, expondo o que o tema aborda a problemtica do trabalho,
as hipteses criadas, e o objetivo geral e objetivos especficos pretendidos com o
mesmo.
No segundo captulo denominado referencial terico, aborda conceitos

iniciais sobre projetos, gerncia de projetos e metodologias geis, dando enfoque
principalmente a apresentao do PMBOK e do Scrum, dentre outras definies
tcnicas que sero utilizadas no decorrer do trabalho.
No terceiro captulo foi realizado um estudo comparativo entre as nove reas

de conhecimento do PMBOK com as prticas adotadas pela metodologia gil
Scrum, mostrando seus pontos de compatibilidade e diferenas.
No quarto captulo foi apresentado um estudo de caso no setor de TI de

duas instituies de Tefilo Otoni, com o intuito de verificar a viabilidade de
utilizao das prticas em gerenciamento de projetos oferecidas pelo PMBOK em
conjunto com a metodologia gil Scrum, e propor um framework hbrido atravs das
prticas das duas abordagens.
Por fim, no quinto captulo foram realizadas as consideraes finais sobre o

trabalho e apresentao de propostas para trabalhos futuros.
19
2. REFERENCIAL TERICO
2.1 GERNCIA DE PROJETOS
Este captulo tem como objetivo apresentar alguns conceitos iniciais sobre
projetos, gerenciamento de projetos e metodologias geis dando enfoque
principalmente as prticas de gerncia de projetos do PMBOK e do Scrum.
2.1.1 O QUE UM PROJETO?
Segundo o PMBOK (2004), um projeto constitui um esforo temporrio

empreendido para criar um produto, servio ou resultado exclusivo.
De acordo com BRAGA (2003), um projeto um empreendimento com

caractersticas prprias, tendo incio e fim, conduzido por pessoas com a finalidade
atingir metas estabelecidas dentro de parmetros 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 incio e trmino,
voltados para alcance de um objetivo conforme requisitos especficos, incluindo
limitaes de tempo, custo e recursos [STANLEIGH, 2005].
Segundo a Organizao das Naes Unidas (ONU), um projeto um

empreendimento planejado, que conjulga-se em um conjunto de atividades
intercaladas e coordenadas a fim de alcanar objetivos especficos dentro dos
limites de um oramento e de um perodo de tempo estabelecido [I.S.A, 2001].
20
Um projeto consiste em um empreendimento com objetivo identificvel, que

consome recursos e opera sobre condies de custo, prazo e qualidade. Para cada
projeto deve-se definir uma misso, 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, propsito que se forma para realizar algo. Diferentemente das operaes
baseadas em processos contnuos e repetitivos, projetos so temporrios e nicos,
devido s suas caractersticas ou condies exclusivas.
VARGAS (2009) define um projeto como sendo um empreendimento no

repetitivo, caracterizado por uma seqncia clara e lgica de eventos, com incio,
meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido
por pessoas dentro de parmetros predefinidos de tempo, custo, recursos
envolvidos e qualidade.
Para CLELAND (2009). um projeto constitui uma combinao de recursos

organizacionais, colocados de forma conjunta para criar ou desenvolver algo que
no existia previamente, de modo a proporcionar um aperfeioamento da
capacidade de desempenho no planejamento e na realizao de estratgias
organizacionais.
A criao de um projeto requer uma estrutura organizacional adequada para

desenvolvimento de novas idias, requer tempo e pacincia para que se possa
trabalhar em conjunto, alm de algumas variveis importantes como a distino do
papel do lder no grupo, que o profissional responsvel por descobrir talentos
individuais de cada participante, ajudando no desenvolvimento da criatividade e na
participao de todos.
A capacidade tcnica outro fator de extrema importncia para se obter

resultados positivos, proporcionando o desenvolvimento de boas idias e
estratgias. E por fim a criatividade e o comprometimento, que so essenciais para
que se tenham caminhos criativos para realizao 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 aplicao de conhecimento, habilidades,

ferramentas e tcnicas s atividades do projeto a fim de atender aos seus
requisitos. O gerenciamento de projetos realizado atravs da aplicao e da
integrao dos seguintes processos de gerenciamento de projetos: iniciao,
planejamento, execuo, monitoramento e controle, e encerramento.
[PMBOK, 2004, p.8].
De acordo com BRAGA (2003), gerenciar projetos envolve tomar decises

sobre:
Escopo, Tempo, Custo e Qualidade.
Diferentes necessidades e expectativas dos clientes e partes interessadas.
Requisitos identificados (necessidades), e no identificados (expectativas).
Segundo MARTINS (2003), a gesto de projetos a aplicao de

conhecimento, habilidades, ferramentas e tcnicas na administrao eficiente das
atividades do projeto. O conhecimento obtido com estudos e prticas dinamiza os
processos de iniciao, planejamento, execuo, controle e encerramento que
compem 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 no repetitivos, nicos e complexos, dentro de um
cenrio de qualidade, tempo e custo predeterminado.
2.1.3 O CICLO DE VIDA DO PROJETO.
Os gerentes de projetos podem dividir os projetos em vrias fases com o

intuito de obter melhor controle gerencial. Estas fases so conhecidas como ciclo de
vida dos projetos.
Segundo a PMI (2004). o ciclo de vida de um projeto foca basicamente em

definir o comeo e o trmino do projeto, estabelecendo qual a atividade deve ser
realizada em cada fase, e quem deve estar envolvido. O ciclo de vida tambm o
22
responsvel 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 benefcios para
qualquer tipo de projeto. Dentre eles, podem ser citados os seguintes:
A anlise correta do ciclo de vida determina o que foi, ou no 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 descries do ciclo de vida de um projeto podem ser resumidas ou muito

detalhadas. As descries com alto nvel de detalhamento envolvem a criao de
formulrios, grficos, e listas de verificao 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 execuo e a fase de
concluso ou encerramento.
2.1.4 PARTES INTERESSADAS EM UM PROJETO
De acordo com o Guia PMBOK (2004), as partes interessadas em um

projeto so as pessoas e organizaes ativamente envolvidas no projeto, cujos
interesses podem ser afetados com o resultado da execuo ou do trmino do
projeto.
Baseado no guia PMBOK (2004), a Tabela 1 a seguir mostra a definio

das principais partes interessadas em um projeto.
23
Tabela 1: Definio das Partes Interessadas em um Projeto
PARTE INTERESSADA DESCRIO

Consiste na pessoa responsvel pelo gerenciamento do
GERENTE DE PROJETOS projeto.
Consiste na pessoa ou organizao que utilizar o
CLIENTE/USURIO produto desenvolvido pelo projeto.
Consiste na empresa cujos funcionrios esto mais
ORGANIZAO diretamente envolvidos na execuo 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 esto
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 no esto
diretamente relacionados aquisio ou ao uso do
produto do projeto, mas que, devido posio de uma
INFLUENCIADORES
pessoa na organizao do cliente ou na organizao
executora, podem influenciar, positiva ou
negativamente, no andamento do projeto.
Consiste no departamento ou grupo que define e
PMO mantm os padres de processo, geralmente
relacionados com a gesto dos projetos , dentro da
organizao.
Fonte: Desenvolvido pelo autor.
O termo Stakeholders refere-se a todas as partes interessadas no projeto,

incluindo prprio 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 organizao.
A equipe de gerenciamento precisa identificar as partes interessadas,

determinar suas necessidades e expectativas, e gerenciar sua influncia em relao
aos requisitos para garantir um projeto bem sucedido.
A Figura 1 descreve as principais partes interessadas e sua relao com o

projeto.
24
Figura 1: Relao entre as Partes Interessadas e o Projeto
Fonte: PMBOK, 2004.
As partes interessadas em um projeto podem ocasionar influncias 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 responsvel pela realizao dos objetivos

do projeto. Um gerente de projetos deve ter a capacidade de trabalhar em equipe,
liderana, habilidade para aplicar seus conhecimentos na prtica, facilidade nos
relacionamentos interpessoais e boa comunicao.
De acordo com MARTINS (2003), a pessoa para alcanar o nvel de

maturidade condizente com a funo de um gerente de projetos deve possuir
conhecimentos de conceitos bsicos, tcnicas e ferramentas de gerenciamento, bem
como a capacidade prtica e aplicvel destes conhecimentos.
Para MARTINS (2003), o gerente de projetos se destaca dentro das

organizaes devido evoluo e relevncia do gerenciamento dos projetos. A
25
profisso 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 organizaes esto designando pessoas sem qualquer
formao e capacitao para exercerem a funo de gerente de projetos, que
eventualmente possui remunerao inferior a de um profissional qualificado,
ocasionando aumento do custo final do projeto, levando em considerao as
deficincias na gesto de recursos, alm das entregas serem geralmente efetuadas
fora dos prazos estabelecidos [MARTINS, 2003].
2.1.6 BENEFCIOS DO GERENCIAMENTO DE PROJETOS
Segundo MARTINS (2003), a gesto de projetos tem-se destacado nos

ltimos tempos devido a sua eficcia, conseguindo alcanar resultados desejados
dentro dos prazos, e oramentos definidos. O gerenciamento de projetos pode ser
aplicado em empreendimentos de qualquer complexidade, e para qualquer tipo de
negcio.
Para MARTINS (2003), os benefcios proporcionados pelo gerenciamento de

projetos so os seguintes:
Controle efetivo de prazos, custos e recursos, permitindo a

identificao prvia de desvios, e imediata tomada de aes corretivas
ou pr-ativas, podendo inclusive resultar em possveis redues;
Eficcia na integrao e comunicao necessria durante todo o
projeto;
Monitoramento e controle dos riscos e da qualidade do projeto;
Retorno do investimento, com entrega conforme a especificao;
Segundo estudos realizados pela Standish Group em 2001, revelam que

apenas 16% dos projetos so bem sucedidos, 28% so realizados no prazo e
oramento especificados, 23% so cancelados, 94% so reiniciados pelo menos
uma vez excedendo o oramento original em 188% e o prazo original em 222%, e
apenas 61% mantm o escopo original [SOTILLE, 2004]. O Grfico 1 mostra a
evoluo dos percentuais de sucesso, atraso e falhas de 1994 at 2008.
26
Grfico 1: Evoluo 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 no uma
economia de recursos [SOTILLE, 2004].
Diante deste cenrio, as organizaes esto cada vez mais optando por
profissionais de gerncia de projetos que possuem algum certificado que comprove
o conhecimento na rea, tornando um diferencial e requisito em relao
especializao no assunto.
A certificao PMP (Project Management Professional) comprova o

conhecimento aprofundado sobre o PMBOK, e das regras impostas pela PMI para
exercer a profisso de gerente de projetos [PMI, 2004].
O Grfico 2 a seguir mostra a importncia do gerenciamento de projetos

vista atravs da evoluo do nmero de profissionais certificados PMP no mundo.
27
Grfico 2: Evoluo dos credenciados PMP no Mundo
Fonte: http://www.ietecnet.com.br/pmp/credenciados.asp
Para TORREO (2005), o sucesso na gesto de projetos pode ser

mensurado atravs do alcance dos seguintes objetivos: entregas dentro do prazo
estabelecido, dentro do oramento previsto com nvel de desempenho adequado,
controle eficaz nas mudanas do escopo, respeito cultura da organizao e
aceitao prvia do cliente.
De acordo com VARGAS (2007), o gerenciamento de projetos proporciona

inmeras vantagens em relao s demais formas de gerenciamento, tendo se
mostrado bastante eficaz em conseguir os resultados desejados, dentro dos
oramentos e prazos definidos pela organizao. A grande vantagem do
gerenciamento de projetos o fato de no ser restrito apenas a projetos grandes,
com alto nvel de complexidade, podendo ser aplicado a empreendimentos de
qualquer natureza.
A gesto profissional de projetos a forma mais indicada a ser aderida pelas

organizaes para a realizao de projetos, utilizando recursos eficientes dentro das
limitaes de custo, tempo e desempenho. O gerente de projetos a pessoa
responsvel 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 seo objetiva demonstrar uma viso 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 padro formado a partir de um conjunto de

conhecimentos e melhores prticas sobre a gerncia de projetos. O PMBOK
reconhecido pela ANSI (American National Standard), e foi desenvolvido pelo PMI
(Project Management Institute), que a principal referncia para as organizaes
que esto 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 prtica. Identificar significa fornecer
uma viso geral, e no uma descrio completa. Amplamente reconhecido
significa que o conhecimento e as prticas descritas so aplicveis maioria
dos projetos na maior parte do tempo, e que existe um consenso geral em
relao ao seu valor e sua utilidade. Boa prtica significa que existe acordo
geral de que a aplicao correta dessas habilidades, ferramentas e tcnicas
podem aumentar as chances de sucesso em uma ampla srie de projetos
diferentes. Uma boa prtica no significa que o conhecimento descrito dever
ser sempre aplicado uniformemente em todos os projetos; a equipe de
gerenciamento de projetos responsvel por determinar o que adequado
para um projeto especfico. [PMBOK, 2004, p.3].
O PMBOK teve sua primeira publicao no ano de 1987. Logo mais tarde
baseado nos comentrios positivos recebidos pelos membros da PMI foi publicada a
sua segunda verso. A sua terceira verso teve publicao em 2004 com melhorias
em sua estrutura original, adies aos processos, termos e domnios do programa e
do portflio. Atualmente est em sua quarta edio, lanada em 2008, tornando-se a
norma mundial relacionada ao gerenciamento de projetos, sendo um dos melhores e
mais verstil documento disponvel para gerncia 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 prprio Guia PMBOK (2004), ele se divide trs sees:
Seo I: A estrutura do gerenciamento de projetos.

Fornece uma estrutura bsica para o entendimento sobre
gerenciamento de projetos.
Seo 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.
Seo 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 bsico e nove reas de conhecimento. Os cinco grupos de processos do
PMBOK so: Iniciao, Planejamento, Execuo, Controle e Monitorao, e
Fechamento.
As nove reas de conhecimento em gerncia de projetos do PMBOK so:

Integrao, Escopo, Tempo, Custo, Qualidade, Recursos Humanos, Comunicaes,
Risco, Aquisies.
Cada uma das reas de conhecimento do PMBOK contm os processos

que precisam ser realizados para a gesto 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) constituda por 44 processos estruturados, em 5 grupos bsicos e 9 reas
de conhecimento.
De acordo com o PMBOK (2004), a definio de processo : Um processo

um conjunto de aes e atividades inter-relacionadas realizadas para obter um
conjunto pr-especificado de produtos, resultados ou servios. [PMBOK, 2004, p.
38].
30
A Figura 2 mostra resumidamente os grupos de processos em

gerenciamento de projetos que compem o PMBOK.
Figura 2: Os Grupos de Processos do Gerenciamento de Projetos
Fonte: PM Tech Capacitao em Projetos.
O Guia PMBOK (2004) caracteriza os grupos de processos estruturados

da seguinte forma:
Grupo de Processos de Iniciao: Define e autoriza o projeto e as

fases do projeto.
Grupo de Processos de Planejamento: Define e refina os objetivos,
bem como a seleo da melhor alternativa para alcanar os objetivos
do projeto, e o escopo para os quais o projeto foi realizado.
Grupo de Processos de Execuo: 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 esto sendo cumpridos, e monitora
regularmente o progresso do projeto a fim de identificar variaes em
31
relao ao plano de gerenciamento de projetos, para que se possa

tomar as devidas aes corretivas.
Grupo de Processos de Encerramento: Formaliza a aceitao do
projeto, servio 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 responsvel 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: Viso Geral das reas de Conhecimento do PMBOK (2004)
Fonte: PMBOK, 2004.

32
As reas de conhecimento do PMBOK so 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 compem o PMBOK,
juntamente com seus grupos de processos.
2.2.4 GERENCIAMENTO DE INTEGRAO DO PROJETO
O Gerenciamento de Integrao composto por processos e atividades

necessrias para identificar, definir, combinar, unificar e coordenar os diversos tipos
de atividades do gerenciamento de projetos, atravs dos grupos de processos que o
compem [PMBOK, 2004].
O Gerenciamento de Integrao responsvel por fornecer processos

necessrios para assegurar que todos os elementos do projeto esto sendo
gerenciados de forma correta [PMBOK, 2004].
Para VARGAS (2009), o gerenciamento de integrao 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 viso geral sobre os
processos que compem esta rea de conhecimento.
Figura 4: Mapeamento do Gerenciamento de Integrao
Fonte: Manual Prtico 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 privilgio de aplicar os recursos organizacionais nas atividades do
33
projeto. Trata principalmente da documentao das necessidades de negcio,

do atendimento atual das necessidades do cliente, do novo produto e da
justificativa do projeto [PMBOK, 2004].
Declarao do Escopo Preliminar do Projeto: Responsvel em fornecer

uma descrio em alto-nvel do escopo do projeto.
Plano de Gerenciamento do Projeto: Responsvel em incluir as aes

necessrias em para definir, coordenar e integrar todos os planos auxiliares
em um plano de gerenciamento do projeto.
Orientar e Gerenciar a Execuo do Projeto: diretamente afetado pela

rea de aplicao do projeto, e consiste na execuo 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 iniciao, planejamento,
execuo e encerramento, atendendo aos objetivos definidos pelo plano de
gerenciamento de projetos.
Controle Integrado de Mudanas: realizado desde o incio do projeto at

o seu trmino. Consiste na identificao, controle, reviso, gerenciamento, e
manuteno das possveis mudanas que venham a ocorrer, rejeitando ou
aprovando-as, de forma que as mudanas aprovadas sejam incorporadas a
uma linha de base revisada.
Encerrar o Projeto: Consiste na finalizao 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 necessrios para garantir

que o projeto se complete somente com o trabalho necessrio. Trata principalmente
da definio e controle do que est e do que no 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 servio requisitado seja obtido atravs da menor
quantidade de trabalho possvel, sem deixar de realizar nenhum requisito
estabelecido no objetivo do projeto. A Figura 5 a seguir ilustra os processos que
compem o gerenciamento de escopo.
Figura 5: Mapeamento do Gerenciamento do Escopo
Fonte: Manual Prtico do Plano Do Projeto.
Planejamento do Escopo: Define a criao de um plano de gerenciamento

do escopo do projeto, visando documentar como o escopo do projeto ser
definido. Verifica e controla como a estrutura analtica do projeto (EAP) ser
criada.
Definio do Escopo: Consiste na definio detalhada das entregas do

projeto, e o trabalho necessrio para realizar essas entregas. A definio do
escopo fornece um entendimento comum do escopo do projeto a todas as
partes interessadas no projeto, descrevendo seus principais objetivos, alm
de orientar o trabalho da equipe durante a execuo do projeto.
Criar EAP: Consiste na subdiviso 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 atravs de uma EAP de forma detalhada.
35
Figura 6: Exemplo de um EAP
Fonte: PMBOK, 2004.
Verificao do Escopo: Consiste na formalizao atravs de um documento

consistindo entregas que foram aceitas e entregas que no foram aceitas,
juntamente com os motivos da sua reprovao.
Controle do Escopo: Consiste no controle das mudanas no escopo do

projeto, com intuito de controlar o impacto que essas mudanas 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 necessrios para garantir o trmino do projeto dentro dos prazos
estabelecidos.
Para VARGAS (2007), o gerenciamento de tempo juntamente com o

gerenciamento de custos so as reas mais visveis 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 compem essa rea de conhecimento so os seguintes:

definio de atividade, seqenciamento 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 Prtico do Plano do Projeto.
Definio da Atividade: Consiste em identificar e documentar as atividades

especficas do cronograma, para produzir as entregas do projeto.
Seqenciamento de Atividades: Consiste na identificao e documentao

das dependncias entre as atividades do cronograma.
Estimativa de Recursos da Atividade: Consiste na estimativa do tipo, e

quantidade de recursos necessrios para realizar cada atividade do
cronograma.
Estimativa de Durao da Atividade: Consiste na estimativa do nmero de

horas necessrias para se termine as atividades individuais do cronograma, a
previso da quantidade de recursos necessrios para a finalizao da
atividade e o nmero de perodos de trabalho necessrios.
Desenvolvimento do Cronograma: Visa anlise dos recursos necessrios,

restries do cronograma, duraes e seqncias de atividades para criar o
cronograma do projeto. Esse processo determinara as datas de incio e
trmino das atividades, podendo ocasionar a reavaliao das estimativas de
37
durao e recursos, gerando um cronograma para ser aprovado, servindo

como linha de base para o projeto.
Controle do Cronograma: Consiste no controle das mudanas 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 concludo dentro das limitaes de
oramento previstas. As definies oramentrias do projeto devem ser realizadas
por quem ir realizar o projeto. O projeto pode entrar em execuo somente aps a
aprovao prvia do oramento.
Segundo VARGAS (2007), o principal objetivo do gerenciamento de custos

de um projeto garantir que o capital disponvel ser suficiente para obter todos os
recursos necessrios para se realizar os trabalhos do projeto. A Figura 8 ilustra os
processos que compem o gerenciamento de custos.
Figura 8: Mapeamento do Gerenciamento de Custos
Estimativa de Custos: Consiste em desenvolver uma estimativa de custos

necessrios para o trmino de cada atividade do projeto.
Oramentao: 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 variaes de

custos no projeto, e as mudanas no oramento do projeto.
2.2.8 GERNCIAMENTO DE QUALIDADE DO PROJETO
O objetivo mais importante desta rea de conhecimento assegurar que o

projeto ser concludo dentro dos nveis de qualidade previstos, garantindo a
satisfao das necessidades de todas as partes envolvidas. O principal responsvel
pelo gerenciamento da qualidade o gerente de projetos, devendo proporcionar
igual prioridade a gesto 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 satisfao do cliente, preveno de erros e a
melhoria continua dos processos. Os processos que compem o gerenciamento de
qualidade so ilustrados atravs da Figura 9 a seguir.
Figura 9: Mapeamento do Gerenciamento de Qualidade
Planejamento de Qualidade: Visa identificar os padres de qualidade

relevantes para o projeto, e determinao de como faz-los.
Realizar a Garantia da Qualidade: Consiste na aplicao das atividades de

qualidade planejadas e sistemticas para garantir que o projeto emprega
todos os processos necessrios para atender aos requisitos.
Realizar o Controle da Qualidade: Consiste no monitoramento de resultados

especficos do projeto com o intuito de determinar se eles esto de acordo
39
com os padres relevantes de qualidade, e identificao de maneiras para

eliminar as causas de um desempenho insatisfatrio.
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 possvel dos indivduos envolvidos no
projeto.
VARGAS (2007) afirma que as pessoas so a parte mais importante de um

projeto, pois so elas que definem as metas, os planos, organizam o trabalho,
coordenam e controlam as atividades do projeto, utilizando de suas habilidades
tcnicas e sociais.
De acordo com o guia PMBOK (2004) todos os membros da equipe devem

ter intensa participao no processo de tomada de deciso do projeto, pois o
envolvimento dos membros da equipe desde o incio proporciona o fortalecimento do
compromisso com o projeto.
Tendo em vista que os custos sofrem variao significativamente ao longo

do ciclo de vida dos projetos, os recursos humanos so requisitados em vrios
nveis de especialidade, dependendo da natureza do trabalho a ser realizado e do
nvel 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 identificao e

documentao das funes, responsabilidades e relaes hierrquicas do
projeto, elm de um plano pessoal de gerenciamento.
Contratar ou Mobilizar a Equipe do Projeto: Objetiva obter os recursos

humanos necessrios para terminar o projeto.
Desenvolver a Equipe do Projeto: Consiste em garantir a melhoria de

competncias e a iterao 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 ,resoluo de conflitos e
coordenao de mudanas
2.2.10 GERENCIAMENTO DAS COMUNICAES DO PROJETO
Segundo o PMBOK (2004) esta rea de conhecimento emprega os

processos necessrios que garantem a gerao, coleta, distribuio,
armazenamento, recuperao e destinao das informaes sobre o projeto de
forma adequada.
41
O gerenciamento das comunicaes necessrio para assegurar que todas

as informaes desejadas cheguem s pessoas corretas. O gerente de projetos
utiliza a comunicao para garantir de que o time do projeto trabalhe de maneira
integrada para resolver os problemas do projeto.
Para VARGAS (2007) a comunicao deve ser vista nas organizaes como
uma estratgia de crescimento, tendo em vista que o fluxo de informaes est
exigindo cada vez mais agilidade e eficincia nas comunicaes, se tornado um dos
fatores principais para garantir o sucesso de um projeto.
O PMBOK (2004) subdivide o gerenciamento de comunicaes em quatro

processos bsicos, dentre eles, o planejamento das comunicaes, a distribuio
das informaes, o relatrio de desempenho, e gerenciar as partes interessadas. A
Figura 12 a seguir descreve o mapeamento dos principais processos do
gerenciamento de comunicaes.
Figura 12: Mapeamento do Gerenciamento das Comunicaes
Planejamento das Comunicaes: Objetiva determinar as necessidades de

informaes e comunicaes das partes interessadas no projeto.
Distribuio das Informaes: O processo de distribuio das informaes

consiste em colocar as informaes necessrias a disposio das partes
interessadas no momento adequado.
Relatrio de Desempenho: Tem como principal objetivo coletar e distribuir

as informaes sobre o desempenho do projeto, atravs de relatrios de
andamento medio de progresso e previso. As informaes relacionadas
42
ao relatrio de desempenho podem incluir os recursos que esto sendo

utilizados para garantir os objetivos do projeto, alm de informaes sobre o
escopo, cronograma, custo e qualidade do projeto.
Gerenciar as Partes Interessadas: Consiste no gerenciamento das

informaes 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 no 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 possveis 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 no 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 especificaes de tempo, custo, escopo ou qualidade do projeto.
Os riscos podem ocorrer por vrias 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

decises de como abordar, planejar e executar as atividades de
gerenciamento de riscos de um projeto.
Identificao de Riscos: Consiste em determinar e documentar as

caractersticas dos riscos que por ventura possam afetar o projeto.
Anlise Qualitativa dos Riscos: Prioriza e avalia a probabilidade de

ocorrncia e dos impactos dos riscos a partir de mtodos que priorizam os
riscos identificados para uma anlise qualitativa.
Anlise Quantitativa dos Riscos: a anlise numrica dos efeitos

identificados nos objetivos gerais do projeto. Aps a priorizao dos riscos na
anlise qualitativa, os mesmos so quantificados atravs da atribuio de
valores numricos a estes riscos.
Planejamento de Respostas a Riscos: Consiste no desenvolvimento de

opes e aes para aumentar as oportunidades e reduzir as ameaas aos
objetivos do projeto.
Monitoramento e Controle dos Riscos: Tem o objetivo de acompanhar e

monitorar os riscos identificados, e a realizao de novas avaliaes em
busca de novos riscos que possam afetar os objetivos do projeto.
44
2.2.12 GERENCIAMENTO DE AQUISIES DO PROJETO
De acordo com o PMBOK (2004) o gerenciamento de aquisies inclui os

processos necessrios para comprar ou adquirir produtos ou servios de fora da
equipe do projeto, com a finalidade de realizar os objetivos do trabalho.
Para VARGAS (2007) o gerenciamento de aquisies possui como

caracterstica assegurar de que todo elemento externo participante do projeto ir
garantir o fornecimento do seu produto ou servio para o projeto.
O gerenciamento de aquisies possui tcnicas que possibilitam a compra

de mercadorias ou a aquisio de algum servio especfico de forma adequada para
dar andamento ao projeto. O gerenciamento de aquisies dispe de processos que
propiciam o gerenciamento de contratos e o controle de mudanas necessrias para
administrar os contratos e pedidos de compra emitidos por algum dos membros do
projeto. A Figura 14 fornece uma viso geral dos principais processos que compem
o gerenciamento de aquisies.
Figura 14: Mapeamento do Gerenciamento das Aquisies
Planejar Compras e Aquisies: Consiste na determinao do que comprar

ou adquirir, e quando e como fazer isso. O planejamento de compras e
aquisies identifica quais as necessidades do projeto podem ser melhor
atendidas pela compra ou aquisio de algum produto. Este processo
tambm inclui possveis fornecedores, especialmente se o comprador desejar
ter influncia ou controle sobre as decises de contratao.
45
Planejar Contrataes: Consiste em documentar os requisitos de produtos e

servios, a fim de identificar possveis fornecedores e solicitar respostas aos
mesmos. As ferramentas e tcnicas utilizadas neste processo incluem
contratos, descries padres de itens de aquisio, termos de
confidencialidade, listas de verificao de critrios de avaliao de propostas,
ou verses padronizadas de todas as partes dos documentos de licitao
necessrios, alm da obteno de opinies especializadas.
Solicitar Respostas de Fornecedores: Consiste na obteno de

informaes, cotaes, preos, ofertas ou propostas de produtos com os
fornecedores. Este processo inclui reunies com licitantes, e reunies com
possveis fornecedores, usadas com o propsito de garantir que todos os
fornecedores possuem um entendimento claro sobre a aquisio.
2.3 Desenvolvimento gil
O desenvolvimento gil surgiu em meados da dcada de 90, quando um

grupo de dezessete especialistas em processos de desenvolvimento de software se
reuniu em uma estao de esqui nos Estados Unidos da Amrica, visando discutir
formas de estabelecer princpios comuns compartilhados a todos os mtodos, com o
objetivo de proporcionar melhorias no desempenho dos projetos [SOARES, 2008].
A partir desta reunio conhecida como Aliana gil foi estabelecido o

Manifesto gil, cujos conceitos so:
Indivduos e interaes ao invs de processos e ferramentas.
Colaborao do cliente ao invs de negociao de contratos.
Respostar rpidas a mudanas ao invs de seguir planos.
Segundo SOARES (2008), as metodologias geis so apontadas como uma

alternativa s abordagens tradicionais. Elas devem ser aplicadas exclusivamente a
projetos onde os requisitos atuais so estveis e os requisitos futuros podem ser
previstos. Entretanto, em projetos onde ocorrem constantes mudanas nos
46
requisitos, e as equipes so razoavelmente pequenas, as metodologias geis so as

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

forma rpida e efetiva, promovendo a unio entre a equipe e o cliente, fazendo com
que o mesmo participe continuamente do processo de criao do projeto [SOARES,
2008].
Portanto, o conceito gil estabeleceu doze princpios para quem deseja

trabalhar com metodologias geis, dentre eles so:
1. A prioridade satisfazer ao cliente atravs de entregas de

software de valor contnuas e freqentes;
2. Entregar softwares em funcionamento com freqncia 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 mudanas de requisitos, mesmo em uma fase
avanada, dando aos clientes vantagens competitivas;
5. As equipes de negcio e de desenvolvimento devem trabalhar
juntas diariamente durante todo o projeto;
6. Manter uma equipe motivada fornecendo ambiente, apoio e
confiana necessrio para a realizao do trabalho;
7. A maneira mais eficiente da informao circular dentro da equipe
atravs de uma conversa face a face;
8. As melhores arquiteturas, requisitos e projetos provm de equipes
organizadas;
9. Ateno contnua a excelncia tcnica e um bom projeto
aumentam a agilidade;
10. Processos geis promovem o desenvolvimento sustentvel.
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 ento se ajustar e adaptar seu
comportamento. [Reinert, 2008, p.3].
A partir do conhecimento dos conceitos supracitados, inmeras

metodologias de gerenciamento e desenvolvimento que j existiam comearam a
ganhar espao no mercado. Com o presente trabalho pretende-se priorizar o
aprimoramento e compreenso das tcnicas do Scrum, onde foram apresentadas
suas caractersticas e definies nas sees 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 iterao curtos [GONALVES,
2008].
Segundo Maral (2007) o Scrum pode ser descrito da seguinte forma:
O Scrum um mtodo que aceita que o desenvolvimento de software

imprevisvel e formaliza a abstrao, sendo aplicvel a ambientes volteis.
Ele se destaca dos demais mtodos geis pela maior nfase dada ao
gerenciamento do projeto. Rene atividades de monitoramento e feedback,
em geral, reunies rpidas e dirias com toda a equipe, visando
identificao e correo de quaisquer deficincias e/ou impedimentos no
processo de desenvolvimento. [MAAL, 2007, p.3].
O Scrum aplicvel tanto a projetos pequenos como grandes, objetivando

conseguir uma melhor avaliao do ambiente em evoluo. indicado ao
desenvolvimento e gerenciamento de projetos em ambientes complexos, onde os
requisitos esto em constante mudana, tornando-se uma alternativa para aumentar
a produtividade das organizaes [GONALVES, 2008].
Segundo GONALVES (2008), o Scrum dispe de um conjunto de regras e

prticas de gesto que devem ser adotadas para garantir o sucesso dos projetos,
voltadas para o trabalho em equipe e melhoria da comunicao, permitindo que
cada participante da equipe faa o seu melhor.
De acordo com BOSSI (2007), existe um vocabulrio especfico utilizado na

metodologia Scrum:
Product Backlog: Lista de todas as funcionalidades a serem desenvolvidas

durante o projeto completo.
Sprint: Perodo no superior a 30 dias, onde o projeto, ou apenas algumas

funcionalidades desenvolvido.
Sprint Planning Meeting: Reunio de planejamento.

48
Sprint Review Meeting: Reunio de reviso.
Sprint Backlog: Trabalho a ser desenvolvido numa Sprint de modo a criar um

produto ou resultado a ser apresentado ao cliente.
Dayling Scrum: Reunio diria.
Scrum Team: Equipe de desenvolvimento de uma Sprint.
Scrum Master: Elemento da equipe responsvel pela gesto do projeto.

Apesar de ser gestor, no tem propriamente autoridade sobre os demais
membros da equipe.
Product Owner: Proprietrio do produto.
Para PEREIRA (2005), o Scrum no um processo previsvel, no define o

que fazer em todos os casos, utilizado para trabalhos com alto nvel e
complexidade, no qual no possvel prever o que ir acontecer, dispondo de um
framework que serve como um guia de boas prticas para gerncia de projetos.
2.4.1 Ciclo de Vida do Scrum
O ciclo de vida do Scrum baseia-se no princpio da utilizao de equipes

pequenas, no mximo sete pessoas, onde os requisitos so pouco estveis e as
iteraes so curtas. O desenvolvimento dividido em intervalos de no mximo 30
dias, conhecidos como Sprints.
Segundo SOARES (2008) o ciclo de vida do Scrum dividido em quatro

fases:
Planejamento: Visa estabelecer uma viso do projeto, garantindo recursos

para sua execuo.
Stagging: Consiste em avaliar as vrias dimenses do projeto criando itens

para o Product Backlog.
Desenvolvimento: Consiste na criao de vrias Sprints para o

desenvolvimento dos incrementos de funcionalidade do produto.
49
Releasing: Consiste na realizao 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 realizao de uma Sprint, feita uma reunio de planejamento

chamada Sprint Planning Meeting, onde a equipe de desenvolvedores obtm 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 prxima fase consiste na execuo da Sprint, onde a equipe controla o

andamento do desenvolvimento do projeto, atravs da realizao das reunies
dirias chamadas de Daily Meeting, com durao de no mximo 15 minutos. O
progresso realizado no projeto pode ser visto atravs de um grfico chamado Sprint
Burndown.
Ao final da Sprint realizada uma reunio de reviso, 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 reunio de retrospectiva, chamada de Sprint

Retrospective, que consiste em uma reunio voltada para lies aprendidas, visando
melhoria dos processos para a prxima Sprint [PEREIRA, 2007].
50
2.4.2 Papis
De acordo com PEREIRA (2007), o Scrum implementa um processo iterativo

e incremental, cujas pessoas envolvidas so divididas em trs grupos : o Product
Owner, o Scrum Team, e o Scrum Master, cada um com s sua funo em especfico,
e todos interagindo entre si.
O Product Owner tem o papel de representar os interesses de todos no

projeto, no sendo necessrio que tenha um conhecimento aprofundado sobre o
Scrum, mas deve conhecer bem o trabalho que ser desenvolvido.
Deve sempre estar disponvel para a equipe, principalmente durante as

reunies de planejamento (Sprint Planning Meeting), e durante as reunies de
reviso (Sprint Review), com o intuito de priorizar as tarefas que sero realizadas na
Sprint.
Alm de ser o responsvel em dividir o trabalho em vrias partes menores e

manter o Product Backlog em ordem, tambm so responsabilidades do Product
Owner segundo PEREIRA (2007):
Define os requisitos do produto, decide a data de release e o que deve conter

nela.
responsvel 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 Mster, que consiste na

pessoa que trabalha exclusivamente com a equipe. O Scrum mster o responsvel
em garantir a boa aplicabilidade das prticas do Scrum no projeto, e a equipe deve
enxerg-lo como a pessoa que tem conhecimento amplo sobre o Scrum, cuja funo
corrigir qualquer contratempo na utilizao de suas prticas, e tirar dvidas
referentes ao Scrum de qualquer pessoa envolvida no projeto [MAGNO, 2008].
51
Segundo MAGNO (2008), as principais responsabilidades do Scrum Mster

so:
Permitir que o time seja auto gerencivel.
Garantir que os caminhos para a comunicao da equipe estejam abertos

permanentemente.
Garantir e auxiliar equipe a seguir as prticas do Scrum.
Remover qualquer impedimento que a equipe encontre.
Proteger a equipe de interferncias externas para garantir que sua

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

composta de no mximo nove membros, responsvel por desenvolver as
funcionalidades do projeto. Nele no existe uma diviso atravs de funes como na
abordagem tradicional, tais como designer, analista, arquiteto, dentre outros. Todos
os membros da equipe trabalham juntos no projeto com a inteno de atender aos
requisitos do Product Backlog, sendo responsvel pelo sucesso de cada iterao e
consequentemente do projeto como um todo.
De acordo com PEREIRA (2007), as responsabilidades do Scrum Team so:
Selecionar entre os itens priorizados os que sero executados durante a

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

participativa.
Ao final da Sprint, responsvel por realizar a verso de demonstrao 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 so: o Product Backlog, a
Sprint Backlog e o Burndown Chart.
O Product Backlog o corao 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 negcio do cliente. No h necessidade do Product Backlog
estar totalmente completo antes do incio do projeto, pois com o tempo pode ser
feito a incluso de novos requisitos, bem como a remoo de requisitos j existentes
[PEREIRA, 2007]. A priorizao 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 importncia 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 relevncia para serem inseridos na Sprint Backlog.
53
A equipe de desenvolvimento tem a funo de estabelecer a quantidade de

itens que sero inseridos no Product Backlog. Esse levantamento e seleo dos
itens so feitos por meio da reunio 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 durao de cada uma
delas, no permitindo que ultrapasse o limite mximo de tempo que de 16 horas
para cada tarefa.
Aps 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 prximo
item, continuando o processo at que todos os itens da Sprint Becklog sejam
concludos [PEREIRA, 2007]
Por fim, o Burndown Chart, que consiste em um grfico que representa a

quantidade de horas que faltam ser completadas para atingir o objetivo da Sprint. A
sua principal funo mostrar o ritmo de trabalho que o time est desempenhando,
facilitando a deteco de problemas no andamento da Sprint e a tomada de
providncias para a resoluo dos mesmos. O Grfico 3 a seguir exemplifica um
Burndown Chart.
Grfico 3: Exemplo de um Burndown Chart
Fonte: Entendendo o Scrum para Gerenciar Projetos de forma gil.

54
2.4.4 Cerimnias
As cerimnias do Scrum consistem nas reunies feitas durante todo o ciclo

de desenvolvimento do projeto, tendo como principal objetivo auxiliar no
monitoramento, gerenciamento e desempenho da equipe, possibilitando a deteco
de falhas durante o desenvolvimento e execuo do projeto.
O Scrum possui quatro tipos de cerimnias: Sprint Planning Meeting, Daily

Scrum Meeting, Sprint Review e a Sprint Retrospective, cada uma delas com
objetivos bem peculiares e realizadas em momentos especficos do ciclo de vida,
conforme demonstrado atravs da Figura 17 a seguir [ALMEIDA, 2009].
Figura 17: Cerimnias do Scrum
Fonte: Uma abordagem automatizada para monitorar o desenvolvimento gil com Scrum.
A reunio de planejamento ou Sprint Planning Meeting, uma reunio

realizada durante o incio de cada Sprint, com durao de aproximadamente 8
horas, objetivando estabelecer o que ser feito na prxima iterao. Esta reunio
opcionalmente pode ser dividida em partes, a Sprint Planning 1 e a Sprint Planning 2
cada uma com durao 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 tcnicas aps a reunio. Essas tarefas
iro dar origem ao Sprint Backlog [ALMEIDA, 2009].
55
Outra cerimnia de grande importncia a Daily Scrum Meeting, que

consiste em uma reunio diria feita no incio ou no fim de cada dia. Esta cerimnia
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
questo [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 participao de todos os membros da equipe, e

no deve ser utilizada como uma reunio para resoluo de problemas, pois as
questes abordadas devem ser levadas para fora da reunio 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 trs 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 rpido possvel pelo Scrum Master.
Outra cerimnia do Scrum a Sprint Review, que uma reunio feita ao

final de cada Sprint, onde o Scrum Team mostra o que foi feito durante a Sprint.
Nesta reunio consiste basicamente em apresentar a verso de demonstrao das
funcionalidades do projeto j concludas. As pessoas que participam da Sprint
Review so tipicamente o Product Owner, o Scrum Team, o Scrum Master.
Ao final da Sprint, ocorre uma reunio chamada Sprint Retrospective, cujo

objetivo identificar o que funcionou bem, o que pode ser melhorado, e quais as
atitudes vo ser tomadas para melhorar.
56
3 ESTUDO COMPARATIVO: PMBOK X Scrum
Neste captulo, 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 diferenas.
A Tabela 2 a seguir demonstra resumidamente uma comparao 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 no Adaptativo: conhecer o problema,
bem conhecido. resolver antes questes crticas.
Rgido: seguir especificao predefinida, Flexvel: adaptar-se a requisitos atuais,
a qualquer custo. que podem mudar.
Burocrtico: controlar sempre para Simplista: fazer algo simples agora e
alcanar o objetivo. alterar se necessrio.
Orientado a processos: podem garantir a Orientado a pessoas: motivadas e
qualidade. comprometidas.
Documentao gera confiana. Comunicao gera confiana.
Sucesso corresponde a entregar o Sucesso corresponde a entregar o
planejado. desejado.
Gerenciamento no estilo comando e Gerenciamento no estilo liderana/
controle,voltada para o trabalho em orientao, voltada para trabalhadores
massa. do conhecimento.
nfase: papel do gerente, planejamento nfase: criatividade/flexibilidade e
e disciplina fortes. ateno s pessoas.
Desenvolvedor hbil (variedade). Desenvolvedor gil (colaborador).
Cliente pouco envolvido. Cliente comprometido (com autonomia
para decidir).
Requisitos conhecidos e estveis. Requisitos emergentes e mutveis.
Retrabalho/reestruturao caros. Retrabalho/reestruturao baratos.
Planejamento direciona resultados Resultados direcionam planejamento
(incentiva controlar). (incentiva mudar).
57
Conjunto de processos com metodologia Conjunto de valores com atitudes e

definida. princpios definidos.
Premia a garantia da qualidade. Premia o valor rpido obtido.
Foco: projetos grandes ou que envolvam Foco: projetos de natureza exploratria e
restrio de confiabilidade (exigem mais inovadores, com equipes pequenas
formalismo). /mdias (exigem maior adaptao).
Objetivo: controlar em busca de alcanar 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 organizao (menos envolvimento e a experincia dos
suscetvel a falhas) membros da equipe.
Foco na maturidade, decorrente da Foco na disciplina, seguindo valores,
definio e uso de processos e modelos princpios e boas prticas documentados
de maturidade. na literatura.
Foca em questes ligadas ao Foca em questes ligadas ao trabalho
gerenciamento, tanto de projeto quanto tcnico e valor agregado ao produto
de processo. (resultado).
Institucionalizao de processos Utilizao das prticas crucial
crucial definidos, escritos, treinados, princpios e boas prticas devem ser
praticados, controlados e cobrados. levadas ao extremo.
Abordagem mais profunda para gerncia Abordagem ainda superficial para
de projetos. gerncia de projetos.
Fonte: Uma comparao entre o PMBOK e a XPM.
Tanto a abordagem gil quanto a abordagem tradicional possuem

caractersticas positivas e negativas, a grande diferena entre as duas abordagens
est no conjunto de propsitos de cada uma.
3.1 PMBOK X Scrum: Ciclo de Vida
No PMBOK, o ciclo de vida do projeto dividido em vrias fases, e o

planejamento feito no inicio de cada fase. As fases so executadas uma aps a
outra, e a equipe de gerenciamento a responsvel por definir todo o ciclo de vida
do projeto, estabelecendo quais so as ferramentas e tcnicas 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 incio de

cada Sprint e somente para aquela Sprint especfica [MACIEL, 2008].
A Figura 18 abaixo ilustra uma comparao entre o ciclo de vida do

PMBOK e do Scrum.
Figura 18: Comparao 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 Integrao
No PMBOK, a integrao refere-se os objetivos, planejamento e

coordenao das atividades do projeto. O plano do projeto realizado de forma
bastante formal e detalhada, e somente no incio do projeto. Na fase de integrao,
o gerente o responsvel 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 so 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 possveis impedimentos venham a
ocorrer.
3.3 PMBOK X Scrum: Gerenciamento de Escopo
O Gerenciamento de Escopo no PMBOK no compatvel com o Scrum.

No PMBOK, o gerenciamento de escopo tem a finalidade de garantir que o projeto
termine apenas com o esforo necessrio, definindo o escopo detalhado no incio do
projeto. O gerenciamento de escopo deve ser realizado utilizando ferramentas
centralizadas e processos de tomada de deciso, onde toda a informao levantada
deve ser documentada na especificao de requisitos, que servir de base para a
gesto de mudanas durante o andamento do projeto [PMBOK, 2004].
No Scrum, o escopo definido com um alto nvel de detalhamento, mas com

a inteno de permitir um melhor entendimento do trabalho, onde aps sua definio
os requisitos so estabelecidos e priorizados com a participao 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 mtodos. No

PMBOK, os processos de definio, estimativa de esforo e durao das
atividades so definidos atravs da elaborao de um cronograma detalhado
contendo todas as atividades necessrias para a execuo do projeto [PMBOK,
2004].
No Scrum, o gerenciamento de tempo tambm realizado atravs da

elaborao de um cronograma, mas com a peculiaridade de ser orientado
exclusivamente ao produto que ser produzido em cada iterao, havendo uma
participao direta do cliente que o responsvel em definir a prioridade funcional
de cara iterao [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 oramento estabelecido. As alteraes
ocorridas durante o ciclo de desenvolvimento do projeto so crticas e afetam todo o
projeto, para isso existe uma estimativa de custos dos recursos necessrios para
terminar as atividades do projeto. O foco est em controlar, monitorar e documentar
as mudanas para que no afete o custo planejado inicialmente no projeto
[PMBOK, 2004].
No Scrum, as alteraes podem ser realizadas mesmo em fases avanadas

do projeto, e so incorporadas na iterao mais apropriada, havendo total
consentimento do cliente. No Scrum existe sempre a preocupao em atender o
cliente, mas o valor final do projeto pode sofrer variaes muito grandes se no
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 so similares, tanto o Scrum como o

PMBOK reconhecem a importncia em planejar a qualidade do projeto, a fim de
garantir a satisfao do cliente, o diferencial entre os dois mtodos est na forma de
garantir e controlar a qualidade.
No PMBOK, o gerenciamento de qualidade voltado para criao de

planos de testes a partir das especificaes de requisitos e nos processos de
verificao e validao. 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 padres 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 iterao desenvolvida, onde so realizados testes desde o incio
do projeto.
61
Ao detectar um problema no projeto o Scrum Master juntamente com

Product Owner so os responsveis em resolv-los. Durante a Sprint Review, as
etapas que j foram concludas so entregues ao Product Owner, onde o mesmo
tem o privilgio de aceitar ou recusar estas entregas realizadas caso elas no
atendam aos requisitos especificados anteriormente.
No Scrum, a cada trmino de uma Sprint feita a Sprint Review, onde so

realizadas as entregas das partes do projeto que foram concludas 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 prxima Sprint, verificando quais as
prticas sero mantidas e quais deixaro de ser feitas.
3.7 PMBOK X Scrum: Gerenciamento de Recursos Humanos
Neste contexto as duas abordagens so compatveis, mas com

caractersticas bem peculiares. Tanto no Scrum como no PMBOK, as premiaes
e comemoraes pela realizao de um projeto bem sucedido so comuns entre
ambas as abordagens.
No PMBOK, a definio coerente dos papis e responsabilidades dos

integrantes da equipe um objetivo primordial dessa rea de conhecimento, pois
cada membro treinado e guiado atravs dos processos na execuo de suas
tarefas. O planejamento de recursos humanos no PMBOK visa organizar e
gerenciar a equipe, identificando e documentando as funes, responsabilidades e
as relaes hierrquicas entre seus integrantes, proporcionando o melhoramento da
interao e o desempenho dos membros da equipe.
No Scrum, a confiana e a colaborao dos integrantes da equipe um fator

essencial no projeto. O planejamento e a tomada de decises so realizados em
conjunto entre todos os participantes do projeto, exigindo profissionais habilidosos,
no exigindo necessariamente que toda a equipe tenha o mesmo nvel. No Scrum,
todos os integrantes da equipe tm 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 Comunicaes
Nesta rea de conhecimento o PMBOK e o Scrum se divergem. No

PMBOK o gerenciamento de comunicaes realizado de maneira formal e
documentada, com divulgao e acompanhamento dos resultados do trabalho feitos
no decorrer do projeto. O objetivo primordial do gerenciamento das comunicaes
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 comunicao e na interao entre os envolvidos no projeto,
promovendo um constante feedback durante o processo de construo do projeto.
No Scrum o processo de comunicao feito de forma colaborativa e direta entre os
envolvidos no projeto atravs das reunies dirias, na reviso das Sprints e em todo
processo de desenvolvimento do projeto.
O Scrum por no ter um nvel de formalismo mais abrangente como

acontece no PMBOK, proporciona uma maior aproximao entre as partes
envolvidas no projeto, mas necessita de que as mesmas tenham maturidade
suficiente para que no 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 so de
extrema importncia durante o decorrer do projeto.
3.9 PMBOK X Scrum: Gerenciamento de Riscos
Neste contexto, as duas abordagens so similares, tanto o PMBOK quanto

Scrum a anlise, identificao e respostas aos riscos so comuns. No PMBOK,
feito um plano formal para o gerenciamento de riscos, garantindo a identificao,
avaliao, quantificao, planejamento de respostas, monitoramento e controle dos
processos durante o ciclo de vida do projeto.
No Scrum, a identificao, anlise, monitoramento e respostas aos eventos

de riscos so realizados continuamente durante as reunies de planejamento de
cada iterao. No monitoramento e controle dos riscos, feita uma reavaliao
63
durante as reunies de retrospectiva das iteraes, onde os riscos so analisados e

revistos para que sejam eliminados para as prximas iteraes.
3.10 PMBOK X Scrum: Gerenciamento de Aquisies
No PMBOK, todo o processo de aquisies realizado a partir do escopo

e da documentao 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 negociaes

atravs de contratos, devido ao fato da ocorrncia constante de alteraes no
escopo original do projeto. Neste contexto no ha preocupao em definir
detalhadamente o processo de aquisio de mercadorias.
3.11 PMBOK X Scrum: Concluso do Projeto
No PMBOK, o projeto s finalizado aps todas as entregas tiverem sido

realizadas e documentadas.
No Scrum, o trmino do projeto se da somente aps todos os requisitos do

Product Backlog estiverem sido concludos.
64
4 ESTUDO DE CASO: Viabilidade de Utilizao do PMBOK e Scrum
Neste captulo foi apresentado um estudo de caso com a finalidade de

verificar a viabilidade de utilizao das prticas tradicionais do PMBOK em
conjunto com a metodologia gil Scrum, como modelo de gesto de projetos no
setor de Tecnologia da Informao de instituies de Tefilo Otoni, propondo um
framework hbrido utilizando as duas abordagens.
4.1 Mtodos adotados para o estudo de caso
O mtodo utilizado como estratgia 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 anlise de forma aprofundada e bem definida
de um programa, uma instituio, um sistema educativo, uma pessoa ou uma
unidade social [GIL, 2002].
A princpio, para a realizao do estudo de caso que esta pesquisa

contempla, foi realizada uma anlise aprofundada a respeito do tema estudado, para
posteriormente a construo de hipteses, e problematizar as situaes envolvidas
no cenrio atual da organizao.
O Estudo de caso em questo foi caracterizado como uma pesquisa

descritiva e uma pesquisa de campo, pois foi realizado atravs da anlise presencial
do setor de Tecnologia da Informao de instituies de Tefilo Otoni e de
entrevistas realizadas atravs de questionrios aplicados aos responsveis pelo
setor, para o levantamento e coleta de dados.
Posteriormente a fase de coleta de dados, foi feita uma anlise e

interpretao dos dados coletados, voltados aos objetivos da pesquisa, para em
seguida a comprovao e validao do framework.
65
4.2 Descrio das Institues analisadas
O estudo de caso proposto por esta pespesa foi realizado em duas

instituies da cidade de Tefilo Otoni, sendo a primeira uma Instituio de Ensino
Superior, e a segunda, uma cooperativa do ramo de laticinios, que por motivos de
segurana no tiveram seu nome e nem localizao divulgados, por isso neste
contexto sero denominadas respectivamente instituio A e instituio B.
4.2.1 Instituio A
Fundada em 30 de setembro de 1953 por Juscelino Kubitschek de Oliveira, e

federalizada em 17 de dezembro de 1960. A Instituio de Ensino Superior
constituda de trs campus, abrigando seis faculdades e 23 cursos de graduao. O
Campus Avanado da instituio localizado na cidade de Tefilo Otoni (MG) e
abriga trs faculdades com nove cursos de graduao.
A instituio conta com aproximadamente 500 servidores, entre professores,

tcnicos administrativos etc. Desde a sua criao, a Instituio vem desenvolvendo
um importante trabalho de ensino, pesquisa e extenso, priorizando sempre a
prestao de servios s comunidades dos Vales do Jequitinhonha e do Mucuri.
4.2.2 Instituio B
Fundada em 16 de dezembro de 1961, pelo idealismo de seus pioneiros, tem

por misso disseminar princpios cooperativistas de produo, absorvendo e
transformando os produtos agropecurios de seus associados em bens de consumo,
de forma a satisfazer exigncias de mercado realizando obras que possam viabilizar
o crescimento e desenvolvimento scio-econmico prprio e de seus cooperados,
dotando-lhes de estmulos cultura, ao uso de novas tecnologias e da conscincia
de cidado de um novo tempo.
A Instituio contribui para o abastecimento de lcteos, principalmente, das
regies nordeste e sudeste brasileira. Seus produtos industrializados, que levam a
marca Cisne e Papagaio, tm o padro de qualidade reconhecido em todo o
territrio brasileiro.
66
4.3 Proposta de utilizao de um framework hbrido
Esta pesquisa demonstra que as diversas reas de conhecimento do

PMBOK so completamente ou parcialmente adaptveis com a metodologia
Scrum, porm existem algumas prticas que so conflitantes. A seguir foi
apresentada uma proposta de utilizao de um modelo de gesto contendo as
melhores prticas de ambas as abordagens atravs de um framework hbrido.
A figura 19 a seguir ilustra o novo ciclo de vida do Scrum agregando

algumas prticas tradicionais importantes do PMBOK.
Figura 19: Novo ciclo de vida: PMBOK e Scrum
Fonte: Desenvolvido pelo Autor.

67
Etapa 1- Viso do Projeto: A primeira etapa do framework consiste em uma viso

geral de como ser a estrutura do projeto, realizada atravs da primeira reunio de
planejamento, neste contexto denominada Sprint Planning 1, onde sero reunidos o
cliente que representado por uma pessoa responsvel pelo departamento que
necessita dos servios do setor de tecnologia da informao da instituio, a equipe
de desenvolvimento do projeto, e o gerente de projetos, que consiste na pessoa
responsvel pelo setor de TI, cuja competncia garantir que os objetivos do projeto
esto sendo compridos.
Etapa 2 - Product Backlog: Na segunda etapa do framework, o gerente de projetos

com base nas idias expostas pelos demais integrantes da Sprint Planning 1 cria
uma lista inicial de necessidades que devem ser produzidas para que a viso 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 - Documentao: Na terceira etapa do framework, o gerente de projetos

juntamente com a sua equipe de desenvolvimento ir realizar a documentao da
descrio detalhada do projeto, criar uma EAP com base no projeto que ser
desenvolvido, detectar e documentar os possveis riscos que podem ocorrer durante
o andamento do projeto, e ir realizar o planejamento de aquisies e o
planejamento de recursos humanos do projeto.
A figura 21 a seguir ilustra um exemplo de estrutura de uma EAP especfica

que ser utilizada neste framework.
Figura 21: Exemplo de uma EAP especfica
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 reunio de
planejamento, chamada Sprint Planning 2, com o objetivo de priorizar os itens de
maior importncia do Product Backlog, para ento criar a Sprint Backlog contendo
os itens de maior relevncia, para posteriormente dar inicio ao ciclo de
desenvolvimento.
69
Etapa 5 - Sprint Backlog: Nesta etapa do framework, a Sprint Backlog deve ser
criada atravs de um quadro contendo os requisitos em ordem de maior importncia,
juntamente com as atividades que devem ser realizadas em cada um destes
requisitos, as atividades em andamento juntamente com o nome da pessoa
responsvel por essa atividade, e as tarefas j concludas.
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. Aps a concluso de todas as atividades do primeiro
requisito, automaticamente a equipe passa para o prximo requisito at que todos os
requisitos sejam concludos e a finalizao do projeto ocorra.
70
Para auxiliar no gerenciamento das atividades das etapas 2 e 5 deste

framework, foi proposto a utilizao da ferramenta de gerenciamento de projetos
DotProject, como demonstrado a seguir atravs do seu tutorial de utilizao.
Tutorial de Utilizao do DotProject
O DotProject um sistema de gerncia de projetos em software livre de fcil

utilizao, com um conjunto de funcionalidades e caractersticas que o tornam
indicado para implementao em ambientes corporativos, pois atende a diversas
necessidades de gerentes e Escritrios de Projetos.
O DotProject consiste em uma aplicao web e seu acesso feito atravs

de um navegador, assim sua utilizao independe de sistema operacional e
instalao na mquina do usurio, pois executado em um servidor. Em termos
mais tcnicos, o DotProject um sistema escrito em PHP, que utiliza banco de
dados MySQL.
Aps instalado o DotProject, deve-se seguir os seguintes passos para

utiliz-lo.
1 Passo: Fazer Login
Fazer o login no sistema, por padro o DotProject utiliza o usurio admin e a senha
passwd.
Preencha o nome do usurio e senha

Clique em login
71
Ao clicar em login aparecer seguinte tela:
2 Passo: Criar Usurio
Deve-se cadastrar os usurios administradores que iro utilizar o sistema, e

adicionar os projetos em que os mesmos iro trabalhar.
Para adicionar um usurio necessrio:
Acessar o link Administrar Usurios
Clicar em adicionar usurio
Preencher os campos
Nome de usurio: deve possuir no mnimo quatro caracteres

Grupo de usurios: selecione a categoria que este pertence
- Coordenao geral (usurios vinculados exclusivamente a administrao da
rede)
- Doutorando
- Iniciao cientfica
- Mestrando
- Ps doutorando
- Tcnico administrativo ou informtica
- Pesquisador (todos os outros usurios)
72
Senha: deve conter no mnimo quatro caracteres

Confirm Password: repetir a senha
Nome: nome do pesquisador
Instituio: selecione a Instituio que o usurio possui vnculo
Diviso: selecionar o n que o usurio possui o vinculo
Clicar no boto
3 Passo: Cadastrar Empresa
Para cadastrar uma empresa no sistema DotProject basta clicar a aba empresa e
posteriormente em nova empresa.
Aps clicar na aba nova empresa ir aparecer um formulrio contendo os campos

que devem ser preenchidos com as informaes da empresa a ser cadastrada,
basta preenche-los e clicar no boto 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.
Aps clicar em novo projeto ir aparecer um formulrio que dever ser preenchido
com as informaes 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 informaes cadastradas nestas,

como datas, dependncias e recursos humanos, definem o projeto em que estas
esto vinculadas, ou seja, qualquer alterao nas tarefas, o projeto alterado.
Para criar uma tarefa, necessrio acessar o projeto onde deseja inserir a tarefa,
clicar em nova tarefa, preencher as informaes sobre a tarefa nas abas detalhes,
datas, dependncias e recursos humanos, e em seguida clicar em salvar.
74
Para cadastrar uma nova tarefa necessrio 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, aps a priorizao de todos os requisitos dado

inicio ao ciclo de desenvolvimento, dentro do prazo estimado de 2 a 4 semanas para
concluso de todo o projeto, ou de apenas algumas funcionalidades, ficando a
critrio do gerente de projetos decidir o que melhor para aquele determinado
projeto. Durante o ciclo de desenvolvimento da Sprint sero realizadas diariamente
reunies de no mximo 20 minutos objetivando disseminar a todos os componentes
da equipe as barreiras encontradas naquele dia de trabalho, para realizar a tomada
de providncias.
Etapa 7 - Atualizao da documentao: Nesta etapa, aps a finalizao de cada

ciclo de desenvolvimento realizado a atualizao de toda a documentao 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 prxima Sprint.
Etapa 8 - Retrospectiva: Nesta etapa, o gerente de projetos juntamente com sua

equipe realiza uma reunio de retrospectiva aps cada ciclo de desenvolvimento,
neste contexto denominado Sprint Retrospective. O objetivo principal desta reunio
promover melhorias para o prximo ciclo de desenvolvimento, pois os membros da
equipe iro identificar e priorizar o que consideram que foi bem e o que pode se
melhorado, traando planos de ao para realizar essas melhorias. Nesta reunio
tambm so realizados testes funcionais no produto desenvolvido. Aps a reunio
de retrospectiva o ciclo de desenvolvimento retorna a fase de priorizao 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 documentao do

projeto a partir da concluso de todos os itens do Product Backlog, e o arquivamento
76
das lies aprendidas durante o projeto com o intuito de minimizar falhas em

projetos futuros.
4.4 Diagnstico das anlises realizadas
Para constatar a viabilidade ou inviabilidade da utilizao da proposta deste

trabalho, foram feitas anlises presenciais no setor de Tecnologia da Informao de
ambas as instituies citas anteriormente, e entrevistas aplicadas aos responsveis
pelo setor TI, para o levantamento e coleta de informaes, onde foi constatado o
seguinte:
4.4.1 Instituio A
O setor de Tecnologia da Informao da Instituio de Ensino Superior

analisada neste trabalho composto por 18 colaboradores, dentre eles, analistas de
sistemas, tcnicos em informtica, chefes de diretoria de Tecnologia da Informao
e monitores de Informtica. O setor de TI desenvolve projetos voltados aos
interesses da instituio comumente em um perodo 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
responsveis pelo setor de TI.
Aps a anlise do setor de TI da Instituio, constatou-se que o mesmo no

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 idias desorganizadas (brainstorming) entre os componentes da
equipe, e posteriormente a organizao 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

reunies bem superficiais entes do incio de cada etapa, onde ocorre o detalhamento
do projeto que ser executado, o mesmo feito de forma informal. Aps a reunio 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 descrio detalhada do escopo.
77
Alteraes no escopo original do projeto desenvolvido pela equipe do setor

de TI freqentemente so requisitadas, e realizadas sem algum tipo de
documentao ou reviso. O cronograma do projeto na maioria das vezes possibilita
um acompanhamento eficaz do projeto, mas tambm so feitos de forma informal
sem nenhuma documentao ou controle de mudanas.
As atividades realizadas pela equipe so feitas de forma seqencial, sem

nenhum mecanismo capaz de priorizar as atividades de maior importncia para
serem desenvolvidas primeiramente.
Os custos relativos aos projetos geralmente so condizentes com o

combinado, mas a equipe no emprega nenhuma ao para garantir a qualidade
das atividades que so desenvolvidas no projeto.
Os projetos realizados no possuem um prazo predeterminado para sua

concluso, e no h uma forma eficaz de estimar com preciso o tempo de durao
de cada projeto criado. Na fase de concluso de um projeto no so feitas
documentaes de todo o trabalho que foi realizado.
O setor de TI da Instituio de Ensino Superior analisada no possui

polticas burocrticas para implantao de novos projetos e na maioria das vezes
tm trazido resultados satisfatrios, porm com alguns contratempos ocasionados
pela falta de um procedimento capaz de gerenciar suas atividades de forma eficaz.
4.4.2 Instituio B
O setor de Tecnologia da Informao da cooperativa de laticnios analisada

neste trabalho composto por 2 colaboradores, sendo 1 tcnico em informtica e 1
analista de sistemas. O Setor de TI desenvolve projetos voltados aos interesses da
cooperativa mensalmente, e dentre os principais projetos criados esto o
desenvolvimento de sistemas, implantao de sistemas, treinamentos de
funcionrios, e projetos relacionados a banco de dados.
Aps a realizao da anlise no setor em questo, constatou-se que o

mesmo tambm no 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 atravs da descrio superficial das tarefas a serem executadas por
meio de editores de texto, planilhas eletrnicas e ferramentas de compartilhamento
de arquivos.
A fase de execuo foi baseada atravs da utilizao do framework proposto

no projeto de implantao do sistema de nota fiscal eletrnica (NF-e) j desenvolvido
pela equipe de TI da cooperativa, onde seguindo as etapas do framework constatou-
se o seguinte:
Etapa 1- Viso do Projeto: No projeto NF-e foi realizada uma reunio 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
determinaes legais e conseqncias fiscais da no realizao do projeto da nota
fiscal eletrnica, onde se obteve uma viso geral de como seria a estrutura deste
projeto.
Etapa 2 - Product Backlog: Ao final da reunio 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 - Documentao: No projeto NF-e no houve a construo de uma EAP, o

gerenciamento de riscos no foi levantado formalmente, indicando os possveis
riscos caso algum prazo fosse extrapolado. Houve o planejamento das aquisies
na rea de TI e na rea contbil, entretanto nenhuma poltica de gesto neste
sentido foi realizada.
Etapa 4 - Product Backlog Priorizado: No projeto NF-e foram construdas listas de

tarefas a serem executadas, observando critrios de prazo e custos, entretanto no
houve documentao formal para acompanhar o desenvolvimento delas.
Etapa 5 - Sprint: Os prazos para concluso de cada funcionalidade estavam

balizados pelo tempo final da entrega de todo o projeto, sendo assim no houve
determinao formal da entrega de cada uma das funcionalidades, gerando atrasos
na iniciao das tarefas posteriores. As reunies dirias e a gesto de riscos nesta
fase no foram realizadas.
79
Etapa 6 - Atualizao da documentao: No houve atualizao na documentao

criada em funo da falta de procedimentos que monitorasse estas ocorrncias.
Etapa 7 - Retrospectiva: No projeto NF-e no ocorreu nenhuma reunio de

retrospectiva objetivando realizar o levantamento dos pontos positivos e negativos
em cada funcionalidade desenvolvida. Tambm no ocorreram testes funcionais no
projeto visando corrigir possveis erros, evidenciando assim o atropelamento das
outras tarefas em funo do pouco tempo para o cumprimento do projeto final,
ocasionando erros freqentes na maioria das funcionalidades desenvolvidas.
Etapa 8 - Entrega Final: No projeto NF-e no foram aplicadas nenhuma das

propostas apresentadas pelo framework para o fechamento do projeto, o mesmo foi
entregue informalmente no incio da simulao do ambiente operacional.
80
5 CONSIDERAES 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 organizaes 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
prticas.
Primeiramente este trabalho concentrou-se em estudar fundamentos

tericos 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 so adaptveis com a metodologia Scrum. Entretanto existem algumas
atividades que so conflitantes e apresentam particularidades, como o caso das
reunies de planejamento, reunies dirias e reunies de retrospectiva apresentada
pelo Scrum.
Posteriormente, foi visto a criao de um modelo de gerncia de projetos

atravs do uso combinado das prticas do PMBOK em conjunto com a
metodologia gil Scrum atravs de um framework hbrido, revelando que o uso
combinado dos dois paradigmas cria um mtodo de gerenciamento preventivo, que
no onera os projetos em termos de documentao, s os torna mais geis, eficazes
e preventivos. Porm o nico segredo esta em saber adapt-los corretamente.
Conforme apresentado no inicio deste trabalho de concluso de curso, o

objetivo geral do mesmo foi analisar a viabilidade de utilizao do PMBOK e o
81
Scrum, como modelo de gesto de projetos no setor de TI de instituies de Tefilo

Otoni, onde foi levantada uma proposta de investigao que buscou responder a
seguinte questo problema:
vivel utilizar o PMBOK e o Scrum em conjunto como modelo de

gesto de projetos no Setor de TI de instituies de Tefilo Otoni?
Para tal modelo ser utilizado, foram mencionadas algumas hipteses onde
pode-se chegar as seguintes concluses :
H1: vivel utilizar o PMBOK e o Scrum, pois proporcionar mais

qualidade aos projetos desenvolvidos.
Essa hiptese foi validada, pois foi comprovado que com a utilizao do
modelo proposto, o resultado final dos projetos satisfatrio, uma vez que atende as
necessidades dos usurios, no ocorrendo inconformidades no que foi requisitado.
H2: vivel, pois obrigar a documentao para melhorar a comunicao e

conseqentemente o conhecimento da equipe sobre o projeto.
Essa hiptese foi validada, pois foi comprovado que em nenhuma das
instituies analisadas possui um processo de documentao eficaz dos projetos
realizados, de forma a contribuir com a disseminao da comunicao entre a
equipe de desenvolvimento.
H3: No vivel, pois a utilizao de testes em cada ciclo de

desenvolvimento poder ocasionar atrasos na entrega do projeto final.
Esta hiptese no foi validada, pois foi demonstrado que a realizao de

testes em cada ciclo de desenvolvimento garante a reduo do tempo final do
projeto, uma vez que mais fcil corrigir erros em cada funcionalidade em particular
do que no projeto como um todo.
Aps a realizao deste trabalho, conclui-se que perfeitamente vivel a

utilizao de ambos os paradigmas em conjunto, aplicados ao setor de Tecnologia
da Informao de instituies de Tefilo Otoni. Neste contexto comprovarmos que o
uso do modelo proposto ir acrescentar inmeros benefcios ao referido setor,
82
principalmente no que diz respeito ao gerenciamento de seus projetos, podendo-se

destacar: o aumento do controle gerencial pela subdiviso das principais etapas do
projeto em componentes menores e mais facilmente gerenciveis 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 exigncias dos usurios internos da
instituio, proporcionando uma prestao de servios mais gil, segura e eficiente.
Porm, somente necessrio saber como aplicar os processos para cada projeto
em particular.
Para finalizar, fica a sugesto para trabalhos futuros o desenvolvimento de

uma aplicao fundamentada nos paradigmas estudados, para auxiliar no
desenvolvimento de projetos no setor de Tecnologia da Informao.
83
REFERNCIAS BIBLIOGRFICAS
BRAGA, Alcir Rodrigues. Gerncia de Projetos: Preparao para a Certificao

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 princpios da
produo enxuta. 2007.
GIL, Antonio Carlos. Como Elaborar Projetos de Pesquisa. 4 Ediao. So Paulo

2002.
GONALVES, Andr Silva. Gesto de Projetos em Pequenas e Mdias

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 Viso gil Scrum Master por Ele Mesmo. Edio 4
2008. Disponvel em: www.visaoagil.com. Ultimo acesso: 11/10/2010.
MARAL, Ana Sofia. Estendendo o SCRUM segundo as reas de processo de

gerenciamento de projetos do CMMI. 2007
MARTINS, Leonardo Vieira. Gesto Profissional de Projetos. 2003. Disponvel 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 Edio,
2004.
PEREIRA, Paulo. Entendendo o Scrum para Gerenciar Projetos de Forma gil.

Mundo PM. 2007. Disponvel: 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 aplicao de governo eletrnico. Departamento de
Informtica e Estatstica Universidade Federal de Santa Catarina.
SOARES, Michel dos Santos. Comparao entre metodologias geis e

tradicionais para desenvolvimento de software. Disponvel 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.
TORREO, Paula. Ambiente Inteligente de aprendizado para Educao em

Gerenciamento de Projetos. 2005. Dissertao (Ps-Graduao em Cincia da
Computao) Universidade Federal de Pernambuco, Recife.
VARGAS, Ricardo. Manual prtico do plano do projeto. 3 Ed.Rio de Janeiro.

Brasport, 2007. Disponvel 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 Gonalves. Gerenciamento de projetos em processo gil

de desenvolvimento de software. 2008. Disponvel em:
http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/393. ultimo acesso em
26/09/2010s 20:30.
85
ANEXO 1
Roteiro de Entrevista
(questionrio utilizado para o levantamento e coleta de informaes)
Identificao da Empresa
Nome:
Endereo:
Cidade:
Ramo de Atuao:
Identificao do Entrevistado
Nome:
Email:
Formao:
Cargo na Empresa:
Atividade que Desenvolve:
Questionrio
1 - Qual o nmero de colaboradores que trabalham no setor de Tecnologia da

Informao da Instituio?
1 ( ) 2 ( ) 3 ( ) 4 ( ) 5 ( ) Quantos?...................
R: Instituio A. 18
R: Instituio B. 2
2 - Qual a formao das pessoas da equipe?
( ) Ensino Mdio: Quantos da equipe?.......................

( ) Ensino Tcnico: Quantos da equipe?.....................
( ) Ensino Superior: Quantos da equipe?............................ Em quais
cursos?..............
86
R: Instituio A. 12 com ensino mdio, 2 com ensino tcnico, 3 com ensino

superior em Sistemas de Informaes e 1 em cincia da computao.
R: Instituio B. 1 com ensino mdio, e 1com ensino superior completo em

cincia da computao.
2 - Quantos so os responsveis pela gesto de projetos no setor de TI da

instituio?
R: Instituio A. 3 pessoas.
R: Instituio B. 1 pessoa.
3 - Qual a freqncia mdia de implantao de projetos desenvolvidos pelo
setor de TI da instituio?
( ) Semanal ( ) Mensal ( ) Bimestral ( ) Semestral ( ) Anual
R: Instituio A. Bimestral.
R: Instituio B. Mensal.
4 - Qual o tipo de projeto mais desenvolvido pela equipe de Tecnologia da

Informao da Instituio?
( ) Desenvolvimento de Sistemas.
( ) Implantao de Sistemas.
( ) Banco de dados.
( ) Treinamentos.
Outros? .....................................................................
R: Instituio A. Desenvolvimento de Sistemas e redes de computadores.
R: Instituio B. Desenvolvimento de Sistemas, Implantao 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 instituio a adotar
esse modelo?
87
R: Instituio A. No.
R: Instituio B. No.
6 - Como se da o gerenciamento de projetos no setor de TI da instituio? Cite

as etapas, funes desempenhadas e ferramentas utilizadas.
R: Instituio A. 1 - Tempestade de idias (brain storming), 2 - organizao da

idias, 3 - Planejamento, 4 - Ao, 5 - Manuteno.
R: Instituio B. O gerenciamento se pauta apenas em descries de tarefas

a serem executadas utilizando-se de um editor de texto, planilhas eletrnicas e
ferramentas de compartilhamento de arquivos.
7 - O setor de Tecnologia da Informao realiza alguma reunio de

planejamento com todas as partes envolvidas no projeto antes do inicio de
cada etapa do projeto? Justifique.
R: Instituio A. Sim, antes de ter as idias iniciais so feitas reunies de

planejamento.
R: Instituio B. Apenas na etapa inicial, entretanto no h controle

automatizado dos cumprimentos dos prazos, tarefas e custos estabelecidos
nesta reunio. As demais ocorrem h medida que surgem problemas que
impeam o andar do projeto.
8 - Como feito o detalhamento do projeto a ser executado?
R: Instituio A. Deforma informal.
R: Instituio B. Informalmente, utilizando-se de ferramentas eletrnicas ou

no.
9 - Como so documentadas as etapas de realizao de cada projeto?
R: Instituio A. No so, e quando so somente realizado eletronicamente.
R: Instituio B. No h documentao.
10 - O Escopo do projeto definido claramente para todos os envolvidos, ou

ocorrem inconformidades nos resultados entregues, ocasionados pela falta de
uma especificao detalhada do escopo?
88
R: Instituio A. Sempre h inconformidades.
R: Instituio B. O Escopo de projeto definido, entretanto no detalhado o

suficiente para que os resultados dos entregveis produzam algo sem erros.
11 - Como so controladas as solicitaes de mudanas e alteraes no

escopo do projeto e qual forma de registro destas alteraes?
R: Instituio A. Informalmente, sem reviso.
R: Instituio B. No so controladas e sim impostas, isto , as alteraes que

surgem no decorrer do projeto geralmente so regidas por normativas legais
e/ou estratgicas, sem que haja documentao formal para registr-las.
12 - A instituio possui algum tipo de cronograma para auxiliar no

gerenciamento do tempo das entregas do projeto?
R: Instituio A. Sim, bem informal e impresso.
R: Instituio B. No possui.
14 - Como so controladas e documentadas as mudanas no cronograma do

projeto?
R: Instituio A. No so controladas.
R: Instituio B. No so controladas.
13 - Se possui, o cronograma possibilita o acompanhamento eficaz do projeto?
R: Instituio A. Na maioria das vezes sim.
R: Instituio B. No possui um cronograma.
15 - Os projetos possuem algum prazo mximo predeterminado para sua

concluso? Comente.
89
R: Instituio A. No possui um prazo mximo de concluso predeterminado

devido ao fato de que nem sempre possvel estimar com preciso o tempo de
durao de cada projeto.
R: Instituio B. H claramente duas espcies de projetos na empresa: O
Legal, inserido por alguma normativa Federal, Estadual ou Municipal, e o
Estratgico, inserido por determinao da Direo da Empresa para fins de
melhoria funcional. Todos os projetos tm prazos pr-determinados, entretanto
a prioridade segue a orientao para os atos Legais em funo de
penalizaes por descumprimento de prazos.
16 - Existe algum mecanismo utilizado para priorizar as funcionalidades mais

importantes a serem desenvolvidas no projeto? Comente.
R: Instituio A. No existe.
R: Instituio B. Sim. O primeiro mecanismo externo, so as penalidades,

no caso dos Legais. O segundo mecanismo vale para todos os projetos. Trata-
se de uma reunio semanal entre os Gerentes para deliberao de assuntos de
todas as reas da empresa. Todos os outros mecanismos no so tratados
formalmente.
17 - As atividades e os prazos de concluso apresentados so condizentes

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

uma vez que h penalizaes severas no caso de atrasos. Os projetos
Estratgicos, mesmo com prazo pr-estabelecidos, geralmente no so
completados dentro do cronograma.
18 - Os custos dos projetos so planejados e acompanhados adequadamente,

ou ocorrem custos adicionais nos projetos ocasionados pela falta de uma
gesto eficaz?
90
R: Instituio A. Geralmente os custos so adequados.
R: Instituio B. Sim so planejados, entretanto podem surgir novas

funcionalidades e o planejamento de custo alterado informalmente.
19 - Durante a fase de execuo de um projeto na instituio quais aes so

realizadas com o intuito de garantir que o projeto emprega todos os processos
de qualidade necessrios para atender aos requisitos especificados?
R: Instituio A. Nenhuma ao empregada.
R: Instituio B. So duas polticas claras adotadas pelo setor de TI:
a) Testes das funcionalidades: Bateria de testes visando validar os

resultados alcanados com os requisitos especificados;
b) Simulao do ambiente operacional: Trata-se de execuo das

tarefas implementadas no prprio ambiente de funcionamento das
atividades, utilizando-se material e os recursos humanos que sero
usados diretamente na produo. Nesta fase h treinamentos in loco
deste ambiente.
20 - O responsvel pelo setor que necessita dos servios do Setor de TI da

instituio participa ativamente no projeto. Se sim, como?
R: Instituio A. Sim. Planejando, controlando, e algumas vezes controlando o

projeto.
R: Instituio B. Sim. Direcionando e cobrando as especificaes do Projeto.
21 - Os projetos desenvolvidos pelo setor de TI da instituio tem trazido

resultados satisfatrios?
R: Instituio A. Sim.
R: Instituio B. Na medida do possvel sim. Entretanto acho que a TI deva

passar por reformulaes nas suas atividades primrias, principalmente na
91
rea de desenvolvimento, para que haja maior produtividade funcional com

ganhos reais para a empresa.
22 - Quais so as polticas adotadas pela instituio para a implantao de

novos projetos?
R: Instituio A. No h polticas.
R: Instituio B. Poltica Legal e Estratgica.
23 - O Scrum e o PMBOK so metodologias de gerenciamento de projetos

que vem ganhando adeptos em todo o mundo devido ao seu feedback positivo.
Vo acha vivel utilizar algum destes modelos no setor de TI desta
instituio?
R: Instituio A. Os dois, por auxiliarem na organizao e agilizarem as

tarefas.
R: Instituio B. Sim. Acho extremamente necessria algumas produes de

artefatos do PMBOK em conjunto com interatividade e fluidez do Scrum.
92
ANEXO 2
Tutorial de Instalao do DotProject
O dotProject um programa distruibuido sob licena 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 servios extras
correlacionados ao mesmo, como customizao, suporte tcnico 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 usurios 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 instalao 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 diretrio que tenha acesso a

web e permisso de escrita. No Debian esse diretrio seria o /var/www ou no
public_html. Para outros sistemas existem diretrios diferentes.
Voc pode tambm 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 usurios
Para poder ter privilgios de escrita, leitura etc, voc precisa configurar
o usurio 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 permisses 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 permisses esto liberadas para que voc instale o DotProject na
sua mquina.
Obs: Essas permisses sero modificadas posteriormente para assegurar a
segurana do sistema.
Passo 3 - Acessando a pasta
Depois que tiver baixado o pacote e modificado as permisses voc

deve iniciar a instalao, para isso entre na pasta citada anteriormente usando
o browser. Basta digitar o endereo seguinte na barra de endereo do seu
browser:
http://localhost/dotproject
Feito isso vai aparecer uma tela para voc clicar no link para iniciar a
instalao e configurao do DotProject (Star Installation).
94
Passo 4 - Iniciando a Instalao
Depois de ter clicado no link referido acima voc vai entrar numa nova
pgina. Confira os detalhes da pagina, j que Algumas das configuraes
podem resultar em falha parcial ou completa da instalao.
Por exemplo, se voc no tiver modificado as permisses no passo 2

ter que faz-lo para suportar upload de arquivos ou para permitir escrita na
configurao principal.
Se precisar fazer modificaes as faa e depois atualize a pgina. 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 privilgios necessrios.

Feito isso v at o navegador que est na pgina de instalao e digite a senha
que voc definiu na criao do banco de dados no campo DATABASE USER
PASSWORD.
Clique no boto install db & write cfg

Monografia Pmbok e Scrum PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Monografia Pmbok e Scrum PDF

Hochgeladen von

Copyright:

Verfügbare Formate

KNIO DIAS LOYOLA

NICKSON DUTRA PINHEIRO

ESTUDO DA VIABILIDADE DE UTILIZAO DO PMBOK E O SCRUM COMO

FACULDADES UNIFICADAS DOCTUM TEFILO OTONI

ESTUDO DA VIABILIDADE DE UTILIZAO DO PMBOK E O SCRUM COMO

Trabalho de Concluso de Curso apresentado

FACULDADES UNIFICADAS DOCTUM TEFILO OTONI

Aprovada em 18 de Novembro de 2010

A presente pesquisa objetiva analisar a viabilidade de utilizao das prticas

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

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

FIGURA 1 - Relao entre as Partes Interessadas e o Projeto................................ 24

GRFICO 1 - Evoluo dos Percentuais de sucesso, atraso e falhas ...................... 26

TABELA 1 - Definio das Partes Interessadas em um Projeto ................................ 23

PMBOK - Project Management Body of Knowledge

Diante da evoluo dos meios tecnolgicos e o mercado cada vez mais

Contudo observa-se um crescente aumento na implantao 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 questo contempla minimizar os contratempos enfrentados

Este trabalho visa propor a utilizao de um mtodo inovador, baseado na

Portanto, tendo como base este cenrio o problema motivador desta

As hipteses criadas para responder a essa pergunta problema foram:

H1: vivel utilizar o PMBOK e o Scrum, pois proporcionar mais

H2: vivel, pois obrigar a documentao para melhorar a comunicao e

H3: No vivel, pois a utilizao de testes em cada ciclo de

O objetivo geral desta pesquisa foi verificar a viabilidade de utilizao do

Os objetivos especficos pretendidos com este trabalho foram:

Estudar a metodologia gil de gerncia de projetos Scrum.

Estudar o guia de prticas em gerenciamento de projetos PMBOK.

Realizar uma abordagem comparativa entre as reas de conhecimento

Conhecer a realidade do setor de TI de Instituies de Tefilo Otoni.

Criar um framework hbrido utilizando prticas das duas abordagens

Esta pesquisa foi de grande importncia, pois alm de verificar a viabilidade

Este trabalho tambm proporcionou um estudo comparativo entre o modelo

Esta pesquisa classificada quanto aos fins como uma pesquisa

Este trabalho est dividido em quatro captulos, o primeiro captulo refere-se

No segundo captulo denominado referencial terico, aborda conceitos

No terceiro captulo foi realizado um estudo comparativo entre as nove reas

No quarto captulo foi apresentado um estudo de caso no setor de TI de

Por fim, no quinto captulo foram realizadas as consideraes finais sobre o

2.1 GERNCIA DE PROJETOS

2.1.1 O QUE UM PROJETO?

Segundo o PMBOK (2004), um projeto constitui um esforo temporrio

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

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

Segundo a Organizao das Naes Unidas (ONU), um projeto um

Um projeto consiste em um empreendimento com objetivo identificvel, que

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

VARGAS (2009) define um projeto como sendo um empreendimento no

Para CLELAND (2009). um projeto constitui uma combinao de recursos

A criao de um projeto requer uma estrutura organizacional adequada para

A capacidade tcnica outro fator de extrema importncia 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 aplicao de conhecimento, habilidades,

De acordo com BRAGA (2003), gerenciar projetos envolve tomar decises

Requisitos identificados (necessidades), e no identificados (expectativas).

Segundo MARTINS (2003), a gesto de projetos a aplicao 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 vrias fases com o