Gerenciamento de Projetos de Software Com Scrum e Pmbok

1
Faculdades Integradas do Vale do Iva

Instituto Superior de Educao - ICEI
Recredenciada pela Portaria n. 545 de 11/05/2012 D.O.U. 14/05/2012
ALEXANDRE BOEING
DIEIMES NUNES DE SOUZA
GERENCIAMENTO DE PROJETOS DE SOFTWARE COM

SCRUM E PMBOK
IVAIPOR
2013
ALEXANDRE BOEING

SCRUM E PMBOK
Trabalho
de
Concluso
de
Curso
apresentado a Faculdade Integrada do Vale

do Iva, como requisito parcial para obteno
do
ttulo de Tecnlogo
em Anlise e
Desenvolvimento de Sistemas.
Orientador: Prof. Paulo Ricardo de Arajo
IVAIPOR/PR
2013
ALEXANDRE BOEING

SCRUM E PMBOK
Trabalho de Concluso de Curso

apresentado a Faculdade Integrada do
Vale do Iva, como requisito parcial para
obteno do ttulo de Tecnlogo em
Anlise e Desenvolvimento de Sistemas,
sob apreciao da seguinte banca
examinadora:
Aprovado(a) em _____/_____/_____
________________________________________________
Professor:
________________________________________________
Professor:
________________________________________________
Professor:
Voc precisa encontrar o que ama. E essa verdade

se
aplica
tanto
aos
amantes
quanto
aos
trabalhadores. O trabalho preenche boa partede sua

vida, e a nica maneira de se sentir verdadeiramente
satisfeito fazer o que acredita ser um timo
trabalho. E a nica maneira devoc fazer um timo
trabalho amar o que faz. (...) No se acomode.
(Steven Paul Jobs Steve Jobs)
As nicas grandes companhias que conseguiro ter

xito so aquelas que consideram os seus produtos
obsoletos antes que os outros o faam.
(William Henry Gates III Bill Gates)
5
DEDICATRIA
Dedico este trabalho a todos que me ajudaram a cumprir esta rdua

tarefa, com muito esforo e luta.
A minha famlia, especialmente minha me que sempre me incentivou e
apoiou em todas as etapas da minha vida at agora.
Aos amigos que nunca deixaram eu desistir ou desanimar, sempre me
animando e fazendo com que eu seguisse em frente.
Alexandre Boeing
Dedico este trabalho primeiramente a Deus, pois sem Ele, nada seria
possvel. Me iluminou todos estes anos que me fez no desistir do meu sonho.
A minha famlia pelo incentivo, cooperao nesta jornada, pois eles
estavam sempre no do meu lado dando todo apoio e me ensinaram os valor da
vida, da honestidade, humildade e do amor.
Aos meus amigos, em especial aos da Juventude Mariana, pelas
oraes e pensamentos positivos para que eu pudesse alcanar meus
objetivos.
Dieimes Nunes de Souza
AGRADECIMENTOS
Eu Alexandre Boeing
agradeo a minha famlia por me manter alegre e
inspirado por toda essa caminhada, minha me que me apoiou desde o incio da
faculdade at agora, me mantendo focado e no deixando abater pelas dificuldades
encontradas no caminho.
Ao meu amigo Dieimes, que enfrentou comigo esse desafio, pesquisando,
aprendendo e se superando a cada etapa do projeto.
Aos amigos que sempre estiveram comigo durante a faculdade, que tambm
passaram pelas dificuldades de um trabalho de concluso de curso.
Ao professor Paulo Ricardo de Arajo, por orientar o curso do trabalho
sempre adiante, com muita sabedoria. Um exemplo de dedicao e persistncia.
A todo corpo docente, por colaborar com minha formao no s profissional
mas tambm pessoal.
Eu Dieimes Nunes de Souza agradeoa Jesus, pelo dom da vida e pela

oportunidade de estar realizando este trabalho. Agradeo por guiar os meus passos,
nos momentos mais difceis e nos momentos de alegrias e conquistas
A minha famlia que lutaram junto comigo para que este sonho torna-se
realidade, que se no fosse eles eu no conseguiria concluir este curso, que muitas
vezes eu pensei em desistir mais eles esto sempre do meu lado me dando todo
apoio e falando coisas bonitas como: Voc capaz. Obrigado.
Ao meu amigo e irmo Alexandre Boeing, pelas palavras amigas nas horas
difceis, pelo auxilio nos trabalhos e dificuldades e principalmente por estarem
comigo nesta caminhada tornando-a mais fcil e agradvel.
Ao professor Paulo Ricardo de Arajo por me orientar nesse trabalho, e pelo
exemplo contnuo de dedicao, sabedoria durante o perodo de nossa convivncia.
Para mim, ser orientado por voc foi uma satisfao imensa e motivo de muito
orgulho. Obrigado por tudo.
A todo o corpo docente pelos ensinamentos transmitidos. Tenham certeza de
aprendi muito com vocs e que levo em minha bagagem um pouco de cada um.
RESUMO
Boeing, Alexandre. Nunes, Dieimes.Gerenciamento de projetos de software com

scrum e pmbok. Trabalho de concluso de curso (superior de tecnologia em
Anlise e Desenvolvimento de Sistemas) - Faculdades Integradas do Vale do Iva.
Ivaipor, 2013.
A necessidade de projetar softwares que tenham qualidade e sejam desenvolvidos

rapidamente desafiador, devido a este fato utiliza-se mtodos de desenvolvimento
gil. Nesse sentido, a finalidade deste trabalho identificar os pontos de
compatibilidade entre PMBOK e Scrum. Para isto foram realizados estudos
bibliogrficos que identificaram caractersticas e tcnicas que apontam os laos de
compatibilidade entre esses dois mtodos. Como resultado da pesquisa sero
analisados os processos do PMBOK que se encaixam no modelo de projeto Scrum
sem que este perda suas caractersticas distintas das metodologias tradicionais. Ao
final, como resultado de pesquisa e estudo, ser apresentado um modelo hbrido
contendo o ciclo de vida Scrum incorporado processos do guia de referncia de
projetos PMBOK.
Palavras chave: Gerenciamento de Projetos. Scrum. PMBOK.
ABSTRACT
Boeing, Alexandre. Nunes, Dieimes.Project management software with scrum

and PMBoK. Trabalho de concluso de curso (superior de tecnologia em Anlise e
Desenvolvimento de Sistemas) - Faculdades Integradas do Vale do Iva. Ivaipor,
2013.
The need to design software that have quality and are developed quickly is
challenging, due to this fact we use agile development methods. Accordingly, the
purpose of this work is to identify the points of compatibility between PMBOK and
Scrum. For this bibliographical studies were conducted that identified characteristics
and techniques that link the bonds of compatibility between these two methods. As a
result of the research will consider the PMBOK processes that fit the Scrum project
template without it losing its distinct features of traditional methodologies. Finally, as
a result of research and study, will be presented a hybrid model containing the Scrum
lifecycle processes incorporated into some of the reference guide PMBOK project.
Keywords: Project Management. Scrum. PMBOK.
SUMRIO
Contedo
2. FUNDAMENTAO TERICA ........................................................................... 15
2.1 O QUE PMBOK ............................................................................................. 15
2.1.1 Processos do Guia PMBOK ..................................................................... 16
2.2 GERENCIAMENTO DE ESCOPO ................................................................. 17
2.2.1 Coletar os requisitos .............................................................................. 18
2.2.2 Definir o Escopo ...................................................................................... 19
2.2.3 Criar EAP - Estrutura Analtica do Projeto ............................................. 19
2.2.4 Verificar Escopo ......................................................................................... 19
2.2.5 Controlar Escopo ....................................................................................... 20
2.3 Gerenciamento de Integrao............................................................................ 21
2.3.1 Desenvolver o termo de abertura do projeto ............................................ 22
2.3.2 Desenvolver o termo de abertura do projeto ............................................ 23
2.3.3 Business Case ............................................................................................... 23
2.3.4 Termo de abertura ...................................................................................... 24
2.3.5 Desenvolver o plano de gerenciamento do projeto ................................... 24
2.3.6 Orientar a execuo do projeto .................................................................. 25
2.3.7 Realizar o controle integrado de mudanas .................................... 25
2.3.8 Encerrar projeto ou fase ........................................................................... 26
2.4 GERENCIAMENTO DE QUALIDADE ........................................................... 28
2.4.1 Planejar a qualidade .................................................................................. 30
2.4.2 Realizar a garantia da qualidade............................................................. 31
2.4.3 Auditoria de qualidade .............................................................................. 32
2.4.4 Realizar o controle da qualidade ............................................................. 32
2.5 GERENCIAMENTO DO TEMPO DO PROJETO......................................... 34
2.5.1 Definir as atividades .................................................................................. 35
2.5.2 Sequenciar as atividades ......................................................................... 36
2.5.3 Estimar os recursos da atividade ............................................................ 36
2.5.4 Estimar as duraes da atividade ........................................................... 36
2.5.5 Desenvolver o cronograma ...................................................................... 37
2.5.6 Controlar o cronograma ............................................................................ 38
2.7 GERENCIAMENTO DOS CUSTOS DO PROJETO.................................... 38
2.7.1 Estimar os custos....................................................................................... 39
10
2.7.2 Determinar o oramento ........................................................................... 40
2.7.3 Controlar os custos .................................................................................... 40
2.8 GERENCIAMENTO DAS COMUNICAES DO PROJETO ................... 41
2.8.1 Identificar as partes interessadas ........................................................... 42
2.8.2 Planejar as comunicaes ....................................................................... 42
2.8.3 Distribuir informaes ............................................................................... 43
2.8.4 Gerenciar as expectativas das partes interessadas ............................ 43
2.8.5 Reportar o desempenho ........................................................................... 43
2.9 GERENCIAMENTO DE RECURSOS HUMANOS ...................................... 44
2.9.1 Desenvolver o plano de recursos humanos .......................................... 45
2.9.2 Mobilizar a equipe do projeto ................................................................... 45
2.9.3 Desenvolver a equipe do projeto............................................................. 46
2.9.4 Gerenciar a equipe do projeto ................................................................. 46
2.10 GERENCIAMENTO DOS RISCOS DO PROJETO................................... 47
2.10.1 Planejar o gerenciamento dos riscos ................................................... 47
2.10.2 Identificar os riscos .................................................................................. 48
2.10.3 Realizar a anlise qualitativa dos riscos .............................................. 49
2.10.4 Realizar a anlise quantitativa de riscos ............................................. 49
2.10.5 Planejar as respostas aos riscos .......................................................... 49
2.10.6 Monitorar e controlar os riscos .............................................................. 49
2.11 GERENCIAMENTO DAS AQUISIES DO PROJETO ......................... 50
2.11.1 Planejar as aquisies ............................................................................ 50
2.11.2 Realizar as aquisies ............................................................................ 51
2.11.3 Administrar as aquisies ...................................................................... 51
2.11.4 Encerrar as aquisies ........................................................................... 51
2.12 SCRUM - METODOLOGIA GIL ............................................................... 52
2.12.1 Surgimento ............................................................................................... 52
2.12.2 Caractersticas do Scrum ....................................................................... 53
2.13 SCRUM - METODOLOGIA AGIL PARA DESENVOLVIMENTO DE
SOFTWARE ............................................................................................................. 54
2.13.1 Product Backlog .................................................................................... 55
2.13.2 Sprint Backlog ......................................................................................... 56
2.13.3 Product Increment................................................................................. 57
2.13.4 Sprint Planning Meeting ......................................................................... 57
2.13.5 Scrum Master ........................................................................................... 57
2.13.6 Product Owner ......................................................................................... 58
2.13.7 O Scrum Team ........................................................................................ 58
11
2.13.8 Daily Scrum .............................................................................................. 59
3. DESENVOLVIMENTO ............................................................................................ 61
3.1 SCRUM X PMBOK ........................................................................................... 61
3.1.1 Ciclo de vida Scrum ................................................................................ 61
3.2 INICIO DO PROJETO ...................................................................................... 62
3.2.1 Termo de abertura do projeto .............................................................. 62
3.2.2 Identificao dos Stakeholders ........................................................... 63
3.2.3 Desenvolver o plano de gerenciamento do projeto ....................... 63
3.3 EXECUTANDO O SCRUM .............................................................................. 64
3.4 PLANEJAMENTO SPRINT PRIMEIRA ETAPA ...................................... 69
3.5 PLANEJAMENTO DA SPRINT SEGUNDA ETAPA............................... 74
3.6 NOVA SPRINT .................................................................................................. 83
3.7 CICLO DE VIDA SCRUM COM PROCESSOS PMBOK ............................ 88
Figura 14 - Ciclo de vida Scrum com PMBOK..................................................... 88
CONCLUSO ............................................................................................................... 89
REFERENCIAS BIBLIOGRFICAS ......................................................................... 91
12
Lista de figuras
Figura 1 - reas do conhecimento - Fonte: guia PMBOK ............................... 16
Figura 2 - Processos do guia PMBOK ................. Erro! Indicador no definido.
Figura 3 - Gerenciamento de escopo - Fonte: Guia PMBOK ........................... 21
Figura 4 - Gerenciamento de integrao - Fonte: Guia PMBOK ...................... 28
Figura 5 - Gerenciamento de qualidade .............. Erro! Indicador no definido.
Figura 6 - Gerenciamento de tempo - Fonte: Guia PMBOK ............................. 38
Figura 7 - Gerenciamento de custos - Fonte: Guia PMBOK............................. 41
Figura 8 - gerenciamento da comunicao - Fonte: Guia PMBOK................... 44
Figura 9 - Gerenciamento de recursos humanos - Fonte: Guia PMBOK ......... 47
Figura 10 - Gerenciamento de riscos - Fonte: Guia PMBOK............................ 50
Figura 11 - Gerenciamento de aquisies - Fonte: Guia PMBOK .................... 52
Figura 12 - Ciclo de vida SCRUM - Fonte: http://desenvolvimentoagil.com.br/ 55
Figura 13 - Ciclo de vida Scrum Fonte: www.fabiocruz.com ............................ 62
Figura 14 - Ciclo de vida Scrum com PMBOK- fonte: www.fabiocruz.com ..... 89
13
1. INTRODUO
O processo de gerenciamento de projetos de software algo complexo devido

ao seu alto nvel de abstrao. As caractersticas dos projetos de software podem
variar dependendo da caracterstica do software ou do prprio cliente requerente.
Diante dessa necessidade, metodologias de gerenciamento de projetos so
utilizadas.Existem as mais variadas metodologias de projetos para os mais diversos
segmentos da sociedade. Este trabalho ir apresentar duas metodologias de
gerenciamento de projetos (PMBOK e SCRUM), sendo a ltima conhecida como
metodologia gil, que prezam por fatores como indivduos e as suas interaes,
constante aproximao e feedback dos clientes alm de resposta imediata a
mudanas. Dentre as metodologias geis uma voltada especificamente para o
setor de TI (Tecnologia da Informao), no segmento de desenvolvimento de
software, e a outra pode ser aplicada em outros segmentos. Aps apresent-las,
este estudo confronta seus pontos fortes e prticas utilizadas por cada uma delas
alm de extrair o que h de melhor, a fim que atendam s necessidades de gestores
que buscam gerenciar projetos de forma efetiva com o mnimo de prazo possvel.
Devido alta complexidade que exigida no gerenciamento de projetos, uma
grande dose de experincia e assertividade, so fundamentais para aos gerentes de
projetos. Para tal temos uma enorme gama de metodologias a serem aplicadas em
projetos. Com isso gerentes de projeto tendem a ter dificuldades em definir qual a
melhor metodologia a ser aplicada em seu projeto. Alguns gerentes optam pela
metodologia que ele possui mais experincia, outros optam pela metodologia de
acordo com o perfil do projeto e das premissas reportadas no contrato, alegando que
muitas metodologias no podem ser aplicadas simultaneamente.
14
1.2 OBJETIVOS
1.2.1 Objetivo geral
Este trabalho objetiva identificar os pontos de compatibilidade entre a

metodologias de gerenciamento de projetos Scrum e PMBOK.
1.2.2 Objetivos especficos
Criar um modelo hbrido utilizando as duas abordagens estudadas.
Estudar a metodologia gil de gerncia de projetos Scrum.
Estudar o guia de prticas em gerenciamento de projetos PMBOK
Realizar
uma
abordagem
comparativa
entres
as
reas
conhecimento do PMBOK com a metodologia gil de projetos Scrum
de
15
2. FUNDAMENTAO TERICA
2.1 O QUE PMBOK

O Project Management Body of Knowledge, tambm conhecido como PMBOK um
conjunto de prticas em gerncia de projetos levantado pelo Project Management
Institute (Instituto de Gerenciamento de projetos) e constituem a base da
metodologia de gerncia de projetos do PMI. Estas prticas so compiladas na
forma de um guia, chamado de Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos, ou Guia PMBOK.
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 significaque 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 (Guia PMBOK 4 edio).
Figura 1 - reas do conhecimento
16
Fonte: guia PMBOK, 2008
2.1.1 Processos do Guia PMBOK
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 de processos, usando
conhecimento, habilidades, ferramentas e tcnicas do gerenciamento de projetos.A
figura abaixo apresenta a natureza dos processos de gerenciamento de projetos em
termos da integrao entre os processos, das interaes dentro deles e dos
objetivos a que atendem. Esses processos so agregados em cinco grupos,
definidos como os grupos de processos de gerenciamento de projetos(Guia PMBOK
4 edio):
a) Grupo de processos de iniciao

b) Grupo de processos de planejamento
c) Grupo de processos de execuo
d) Grupo de processos de monitoramento e controle
e) Grupo de processos de encerramento.
Figura 2 - Processos do guia PMBOK
17
Fonte: gestaodainformacao-ufpr.blogspot.com.br
2.2 GERENCIAMENTO DE ESCOPO
Segundo o Guia PMBOK O gerenciamento do escopo do projeto inclui os processos

necessrios para assegurar que o projeto inclui todo o trabalho necessrio, e apenas
o necessrio, para terminar o projeto com sucesso. Com base no Guia PMBOK, o
gerenciamento de escopo contm todos os processos para que o projeto seja
bemsucedido, tendo apenas o trabalho necessrio e apenas o necessrio para que
todos os objetivos sejam atendidos com sucesso, tambm controlando o que est e
o que no est no projeto. Os processos do Gerenciamento de Escopo so os
seguintes:
a) Coletar os requisitos- O processo de definio e documentao das

necessidades das partes interessadas para alcanar os objetivos do projeto.
b) Definir o escopo- O processo de desenvolvimento de uma descrio detalhada
do projeto e do produto.
c) Criar a EAP- O processo de subdiviso das entregas e do trabalho do projeto em
componentes menores e mais facilmente gerenciveis.
d) Verificar o escopo-O processo de formalizao da aceitao das entregas
18
terminadas do projeto.
e) Controlar o escopo- O processo de monitoramento do progresso do escopo do
projeto e escopo do produto e gerenciamento das mudanas feitas na linha de base
do escopo. (Guia PMBOK)
Estes processos interagem entre si e tambm com outras reas de conhecimento.
Dependendo da necessidade do projeto, cada processo envolve o esforo de uma
ou mais pessoas. Cada processo ocorre pelo menos uma vez em todo o projeto.
Apesar das interfaces bem definidas de cada processo, na prtica eles interagem
entre si e se sobrepem. Dentro de um projeto, a palavra escopo pode se referir ao:
a) Escopo do produto. As caractersticas e funes que descrevem um produto,
servio ou resultado; e/ou
b) Escopo do projeto. O trabalho que precisa ser realizado para entregar um
produto, servio ou resultado com as caractersticas e funes especificadas. (Guia
PMBOK)
Os processos usados para gerenciar o escopo variam de rea de aplicao
do projeto, normalmente sendo isso definido no ciclo de vida. A definio
detalhada do escopo e a subdiviso do trabalho a linha de base do
escopo do projeto, aps sua definio, ela monitorada e controlada no
ciclo de vida do projeto. Apesar de no ser um processo distinto no
gerenciamento de escopo, o trabalho de produo do escopo do projeto
precedido pelo plano de gerenciamento do projeto, que fornece as diretrizes
de como o escopo ser definido, documentado, verificado, gerenciado e
controlado [...] O plano de gerenciamento do escopo pode ser formal ou
informal, altamente detalhado ou conciso, dependendo das necessidades
do projeto(Dinsmore, 2004).
2.2.1 Coletar os requisitos
Este processo serve para definir e documentar as funes do projeto e do produto

necessrias para atender s necessidades e expectativas das partes interessadas.
De acordo com o guiaO sucesso do projeto diretamente influenciado pela ateno
na captura e gerenciamento dos requisitos do projeto e do produto (Guia PMBOK).
Os requisitos incluem todas as necessidades quantificadas e documentadas,
contendo tambm as expectativas das partes interessadas, todos os requisitos
obtidos precisam ser analisados, revisados e registrados para serem medidos assim
que o projeto se iniciar. Se os requisitos no forem atendidos, o projeto alcanar os
19
resultados esperados. Coletar os requisitos tambm inclui gerenciar as expectativas
do cliente. Com base neles, feito o planejamento de qualidade e custo e o
cronograma.
2.2.2 Definir o Escopo
Neste processo, desenvolvida uma descrio detalhada do projeto e do produto.

Segundo o Guia PMBOK:
Definir o escopo processo de desenvolvimento de uma descrio
detalhada do projeto e do produto. A preparao detalhada da declarao
do escopo critica para o sucesso e baseia-se nas entregas principais,
premissas e restries que so documentadas durante a iniciao do
projeto (Vargas, 2009).
Conforme o que foi citado do Guia PMBOK, o processo de definir o escopo

extremamente importante para o projeto, pois nele est documentado todas as
premissas,
riscos
restries
que
devero
ser
cumpridas
durante
desenvolvimento.
2.2.3 Criar EAP - Estrutura Analtica do Projeto

EAP a estrutura analtica do projeto, criar a EAP um processo que subdivide o
trabalho e as entregas do projeto para componentes menores, de gerenciamento
mais fcil, a EAP totalmente orientada s entregas do trabalho pela equipe. Cada
nvel da EAP representa uma definio gradualmente detalhada da definio do
trabalho do projeto (Guia PMBOK 4 edio).
Todo o trabalho divido em pacotes de trabalho[] O trabalho planejado
contido dentro dos componentes de nvel mais baixo da EAP, que so
chamados de pacotes de trabalho. Um pacote de trabalho pode ser
agendado, ter seu custo estimado, monitorado e controlado[] com o
planejamento de pacotes de trabalho o gerenciamento torna-se mais fcil e
aprimorado (Menezes, 2003).
2.2.4 Verificar Escopo
20
O processo de verificar o escopo o processo de aceitao das entregas concludas
do projeto, o processo inclui a reviso das entregas com o cliente ou patrocinador,
afim de verificar se esto satisfazendo as necessidades e para receber a aceitao
formal das mesma. De acordo com o Guia PMBOK, o processo de verificar o Escopo
difere com o controle de qualidade, pois o controle de qualidade est interessado na
preciso das entregas e no alcance dos requisitos de qualidade especificados por
ela mesmo, normalmente a controle de qualidade feito antes da verificao do
escopo, mas estes processos podem ser executados paralelamente. (Guia PMBOK
4 edio).
2.2.5 Controlar Escopo

O processo de controlar o escopo responsvel pelo monitoramento do andamento
do escopo do projeto e tambm por suas mudanas. Este processo tambm
assegura que qualquer mudana na linha de base do projeto, passe pelo processo
de Realizar o controle integrado de mudanas. Ele integrado com os outros
processos de mudanas. Mudanas de escopo costumam ser inevitveis, portanto,
exigindo algum tipo de controle de mudanas (Guia PMBOK 4 edio).
Figura 3 - Gerenciamento de escopo
21
Fonte: Guia PMBOK, 2008
2.3 Gerenciamento de Integrao

Segundo o Guia PMBOK o O Gerenciamento da integrao do projeto inclui os
processos e as atividades necessrias para identificar, definir, combinar, unificar e
coordenar os vrios processos e atividades dos grupos de processos de
gerenciamento. Conforme o que foi citado, o Gerenciamento de Integrao serve
para ter-se o controle e melhor coordenar as fases e atividades que so necessrias
para o termino do projeto, gerenciar as expectativas das partes interessadas quanto
ao atendimento dos requisitos. O gerenciamento de integrao resume-se em vrios
processos, sendo eles:
a) Desenvolver o termo de abertura do projeto - Documento que formaliza o incio
do projeto, tendo nele toda a documentao e requisitos iniciais que sero atendidos
satisfazendo as partes interessadas.
b) Desenvolver o plano de gerenciamento do projeto - Documentao das aes
que sero realizadas para definir, integrar e coordenar todos os planos auxiliares.
c) Orientar e gerenciar a execuo do projeto - A realizao do trabalho descrito
no plano de gerenciamento de projeto.
22
d) Monitorar e controlar o trabalho do projeto - Reviso e regulao do progresso
em atender os objetivos de desempenho propostos no plano de gerenciamento de
projeto.
e) Realizar o controle integrado de mudanas - Controle de todas as solicitaes
de mudanas do projeto, abrangendo desde requisitos at o plano de gerenciamento
de projeto.
f) Encerrar o projeto ou fase - Finalizao formal de todas as atividades ou grupo
de processos de alguma parte do plano de gerenciamento do projetos.
Um bom gerenciamento de integrao evidentemente necessrio quando

processos distintos interagem, necessitando por exemplo, de uma estimativa de
risco, custo e tempo de desenvolvimento de um projeto, sendo que trs diferentes
setores vo ter que trabalhar juntos para obter-se um nico resultado.
A maioria dos praticantes de gerenciamento de projetos aplicam as tcnicas
e habilidades de gerenciamento para obter o desempenho esperado dos
processos, entretanto, a ideia de que um processo distinto no exigido
no significa que ele no deve ser discutido com a equipe, o gerente
sempre deve discutir todos os processos e nvel de execuo para cada
fase do projeto, mantendo o mesmo rigor para todos os processos e
fases(Kerzner, 2002).
A seguir, ser explicado com mais detalhes cada um dos processos do

gerenciamento de integrao, expondo as partes mais importantes de cada um
deles.
2.3.1 Desenvolver o termo de abertura do projeto
O documento de abertura de projeto estabelece uma parceria entre organizao

executora (empresa desenvolvedora) e organizao solicitante (cliente), que
formalmente inicia o projeto. Um gerente de projeto solicitado preferencialmente
antes do incio do desenvolvimento do termo de abertura do projeto para
acompanhar o desenvolvimento do mesmo, muito importante o que o gerente de
23
projetos participe do desenvolvimento do termo, uma vez que este supre o gerente
com autoridade para usar recursos nas atividades do projeto.
O termo de projeto desenvolvido por algum externo a ele, que normalmente so
as pessoas que vo financiar o projeto. Eles criam o termo ou passam a tarefa para
o gerente de projetos, assim que o termo estiver pronto, o iniciador do projeto o
assina e d o incio formal do projeto. De acordo com o Guia PMBOK:
Projetos so autorizados devido a necessidade de negcios internos ou a
influncia externa, muitas vezes necessrio uma anlise de necessidades
ou a descrio da situao que o projeto tratar, pois uma vez assinado, o
projeto se conecta estratgia e ao trabalho em progresso da organizao.
2.3.2 Desenvolver o termo de abertura do projeto
A primeira coisa a ser feita a declarao do trabalho (DT), que uma descrio
dos produtos e servios que o projeto ir oferecer. Para projeto internos a
declarao feita pelo iniciador ou patrocinador do trabalho com base nos requisitos
das necessidades de negcios, produtos ou servios. Para projetos externos a
declarao pode vir por meio de uma licitao feita pelo cliente, por exemplo,
solicitao de preos, solicitao de informaes ou at como parte de um contrato.
A declarao de trabalho informa (Kerzner, 2002):
a) Necessidade de negcios: A necessidade de negcios de uma organizao

pode ser definida por demanda de mercado, regulamentao do governo, avano
tecnolgico ou requisito legal.
b) Descrio de escopo do produto: Documenta as caractersticas do produto que
ser resultado do projeto, deve documentar tambm a relao entre o que est
sendo criado com a necessidade de negcios que o projeto se dedicar.
c) Plano estratgico: Todos os projetos devem contribuir com os objetivos
estratgicos da organizao. O plano estratgico levado em conta quando forem
feitas decises em selees de prioridade dos projetos.
2.3.3 Business Case
24
O business case muito semelhante a uma anlise de viabilidade. um documento
que fornece as informaes de negcio, focando sempre no custo benefcio, nele ao
contidas tambm a necessidade do projeto e anlise de custo. O business case
pode ser escrito pelo cliente em algumas situaes.
2.3.4 Termo de abertura
Segundo o Guia PMBOK 4 edio o termo de abertura do projeto documenta as

necessidades do negcio, o entendimento atual das necessidades do cliente,
portanto, ele deve documenta o propsito do projeto, o servio ou resultado que o
projeto pretende satisfazer, tais como:
a) Propsito ou justificativa do projeto;
b) Requisitos de alto nvel;
c) Objetivos mensurveis do projeto;
d) Descrio do projeto em alto nvel;
e) Riscos de alto nvel;
f) Resumo do cronograma de marcos;
g) Resumo do oramento;
h) Requisitos de aprovao de projeto;
i) Gerente do projeto, responsabilidade, nvel de autoridade designados;
j) Nome da autoridade ou patrocinador ou outra pessoa que autoriza o
termo de abertura do projeto;
2.3.5 Desenvolver o plano de gerenciamento do projeto
Desenvolver o plano de gerenciamento do projeto o processo de documentao

das aesnecessrias para definir, preparar, integrar e coordenar todos os planos
auxiliares. Com base no que foi citado, o Guia PMBOK diz que desenvolver o plano
de gerenciamento do projeto documentar como ele executado, monitorado e
encerrado. O contedo do plano de gerenciamento do projeto varia dependendo da
rea de aplicao do mesmo. Atravs de uma srie de processos integrados o plano
25
de gerenciamento do projeto desenvolvido, sendo progressivamente elaborado por
meio de atualizaes controladas e aprovadas pelo controle integrado de
mudanas(Kerzner, 2002).
2.3.6 Orientar a execuo do projeto
A orientao da execuo do projeto o processo de realizao do trabalho definido

no plano de gerenciamento do projeto para atingir os objetivos. A seguir, algumas
atividades que incluem a orientao da execuo do projeto:
a) Criar as entregas do projeto;
b) Formar, treinar e gerenciar os membros da equipe designados para o
projeto;
c) Obter, gerenciar e usar recursos, inclusive materiais, ferramentas,
equipamentos e instalaes;
d) Implementar os padres e os mtodos planejados;
e) Estabelecer e gerenciar os canais de comunicao do projeto, tanto
externos como internos equipe do projeto;
f) Gerar dados do projeto, tais como custo, cronograma, progresso tcnico e
da qualidade e informaes sobre o andamento do projeto para facilitar
previses;
g) Emitir solicitaes de mudanas e adaptar mudanas aprovadas no escopo
do projeto, planos, e ambiente;
h) Gerenciar riscos e implementar atividades de resposta a riscos;
i) Gerenciar vendedores e fornecedores;
j) Coletar e documentar lies aprendidas e implementar as atividades de
melhorias nos processos aprovados. (Guia PMBOK 4)
2.3.7 Realizar o controle integrado de mudanas
26
Realizar o controle integrado de mudanas o processo que controla e

gerncia todas as solicitaes, aprovao, gerenciamento em entregas,
ativos de processos organizacionais, documentos do projeto e plano de
gerenciamento do projeto. O processo de realizar o controle integrado de
mudanas mantido do incio ao fim do projeto. O plano de gerenciamento
de projeto, a declarao do escopo e outras entregas s so incorporadas
no projeto aps passarem pelo controle integrado de mudanas, garantindo
assim que somente mudanas aprovadas e revisadas sero aceitas no
projeto (Keelling, 2002).
O processo de realizar o controle integrado de mudanas inclui as seguintes

atividades de gerenciamento de mudanas, diferenciando o nvel de detalhes em
cada atividade:
a) Influenciar os fatores que tentam evitar o controle integrado de mudanas
para que somente as mudanas aprovadas sejam implementadas;
b) Revisar, analisar e aprovar as solicitaes de mudana imediatamente, que
essencial j que uma deciso lenta pode afetar negativamente o tempo,
custo ou viabilidade de uma mudana;
c) Gerenciar as mudanas aprovadas;
d) Manter a integridade das linhas de base liberando somente as mudanas
aprovadas para
serem incorporadas ao plano de gerenciamento do projeto e aos documentos
do projeto;
e) Revisar, aprovar ou rejeitar todas as aes corretivas e preventivas
recomendadas;
f) Coordenar as mudanasatravs de todo o projeto (por exemplo, uma
mudana propostano cronograma frequentemente afetar o custo, o risco, a
qualidade e a equipe);
g) Documentar o impacto completo das solicitaes de mudana. (Guia
PMBOK 4 edio)
2.3.8 Encerrar projeto ou fase
De acordo com Keelling (2002)Encerrar o projeto ou fase o processo de
27
finalizao de todas as atividades, de todos os grupos de processos de
gerenciamento do projeto, para encerrar formalmente o projeto ou a fase. Conforme
o que citado, o Guia PMBOK determina que no processo de encerrar projeto ou fase
o gerente revisa todas as fases anteriores do projeto e certifica que o mesmo
alcanou os objetivos. Esse processo tambm serve para documentar e investigar
os motivos de aes realizadas caso o mesmo tenha sido encerrado antes do seu
trmino. Isso inclui todas as atividades para administrar o encerramento do projeto
ou de uma fase, inclusive metodologias passo a passo que tratam das:
a) Aes e atividades necessrias para satisfazer a concluso ou critrios de
sada para a fase ou o projeto;
b) Aes e atividades necessrias para transferir os produtos, servios ou
resultados do projeto para a prxima fase ou produo e/ou operaes e
c) Atividades necessrias para coletar registros do projeto ou da fase, auditar o
sucesso ou fracasso do projeto, coletar lies aprendidas e arquivar
informaes do projeto para ouso futuro da organizao. (Guia PMBOK 4
edio)
Figura 1 - Gerenciamento de integrao
28
2.4 GERENCIAMENTO DE QUALIDADE
O gerenciamento de qualidade inclui os processos responsveis pela garantia que o

projeto satisfaa as necessidades do cliente. Os processos deste gerenciamento so
iterativos, eles procuram garantir a melhoria contnua das atividades durante todo o
projeto. A seguir, um resumo dos trs processos que envolvem este gerenciamento,
segundo o Guia PMBOK 4 edio:
a) Planejar a qualidade - O processo de identificar os requisitos e/ou padres

de qualidade do projeto e do produto, bem como documentar de que modo o
projeto demonstrar a conformidade.
b) Realizar a garantia da qualidade - O processo de auditoria dos requisitos

de qualidade e dos resultados das medies de controle de qualidade para
garantir
que
sejam
usados
definiesoperacionais apropriadas.
os
padres
de
qualidade
as
29
c) Realizar o controle da qualidade - O processo de monitoramento e

registro dos resultados da execuo das atividades de qualidade para avaliar
o desempenho e recomendar as mudanas necessrias.
O gerenciamento de qualidade aplicado em projetos de qualquer origem,
no entanto, as medidas e tcnicas de qualidade do produto variam de
acordo com sua natureza, por exemplo, as tcnicas e medidas de qualidade
de um desenvolvimento de software diferem do projeto de uma construo
de uma usina nuclear, mas as abordagens de gerenciamento so as
mesmas paras as duas situaes, se algum requisito deixar de ser atendido,
poder acarretar graves prejuzos a qualquer parte interessada(Keelling,
2002).
De acordo com o Guia PMBOK, o gerenciamento de qualidade moderno, os

seguintes tpicos so abordados:
a) Satisfao do cliente: Entender, avaliar, definir e gerenciar as expectativas para

que os requisitos do cliente sejam atendidos. Para isso, necessria uma
combinao de conformidade com os requisitos (para garantir que o projeto produza
o que ele foi criado para produzir) e adequao ao uso (o produto ou servio devem
satisfazer as necessidades reais).
b) Preveno ao invs de inspeo: Um dos princpios fundamentais do moderno

gerenciamento da qualidade determina que a qualidade deve ser planejada,
projetada e incorporada em vez de inspecionada. O custo de prevenir os erros
geralmente muito menor do que o custo de corrig-ls quando so encontrados
pela inspeo.
c) Melhoria continua: O ciclo PDCA (planejar-fazer-verificar-agir) a base para a

melhoria da qualidade conforme definida por Shewhart e modificada por Deming.
Alm disso, as iniciativas de melhoria da qualidade empreendidas pela organizao
executora, tais como GQT e Seis Sigma devem aprimorar a qualidade do
gerenciamento do projeto e tambm a qualidade do produto do projeto. Os modelos
de melhoria de processos incluem Malcolm Baldrige, Modelo organizacional de
maturidade em gerenciamento de projetos (Organizational Project Management
Maturity Model, OPM3) e Modelo integrado de maturidade da capacidade
30
(Capability Maturity Model Integrated, CMMI).
d) Responsabilidade da gerncia: O sucesso exige a participao de todos os

membros da equipe do projeto, mas continua sendo a responsabilidade da gerncia
fornecer os recursos necessrios ao xito.
2.4.1 Planejar a qualidade
O processo de planejar a qualidade, de acordo com o Guia PMBOK tem a seguinte

definio: [...]identificao dos requisitos e/ou padres de qualidade do projeto e do
produto,
alm
da
documentao
de
como
projeto
demonstrar
conformidade.Este processo dever ser executado em paralelo com o restantes

processos de planejamento do projeto. Toda mudana no projeto para atender a
qualidade, pode exigir custo, ajustes no cronograma e deve receber uma anlise de
riscos de seus impactos nos planos (Guia PMBOK 4 e dio). A seguir, estaro
descritas algumas tcnicas utilizadas para execuo deste processo:
a) Anlise de custo-benefcio: De acordo com o Guia PMBOK Os principais

benefcios de cumprir os requisitos de qualidade podem incluir menos retrabalho,
maior produtividade, custos mais baixos e aumento da satisfao das partes
interessadas. realizado um business case para cada atividade de qualidade, para
comparar o custo da etapa com o benefcio esperado.
b) Custo da qualidade: O custo da qualidade inclui todos os gastos com
investimentos na preveno contra falhas nos requisitos e o no cumprimento dos
mesmos. De acordo com o Guia PMBOK os custos com falhas de qualidade so
categorizados da seguinte maneira: Os custos de falhas geralmente so
categorizados como internos (encontrados pelo projeto) e externos (encontrados
pelo cliente). Os custos de falhas tambmso chamados de custos da m
qualidade. (Guia PMBOK).
c) Benchmarking: De acordo com o Guia PMBOK"Benchmarking envolve a
comparao de prticas de projetos reais ou planejados com as de projetos
31
comparveis para identificar as melhores prticas, gerar ideias para melhorias e
fornece uma base para medir o desempenho".
No fim desse processo de planejar a qualidade, se obtm o plano de gerenciamento
de qualidade, que ter as informaes de como a equipe de gerenciamento de
projeto implementar a poltica de qualidade da organizao executora. Tambm
um documento auxiliar do plano de gerenciamento de projetos. De acordo com
Keeling:
O plano de gerenciamento da qualidade pode ser formal ou informal,
altamente detalhado ou estruturado em termos gerais. O estilo e os detalhes
so determinados pelos requisitos do projeto. O plano de gerenciamento da
qualidade deve ser revisado na parte inicial do projeto para garantir que as
decises sejam baseadas em informaes precisas. As vantagens dessa
reviso incluem a reduo dos custos e dos atrasos no cronograma
causados pelo retrabalho(Keelling, 2002).
2.4.2 Realizar a garantia da qualidade
Realizar a garantia da qualidade tem como objetivo auditar os requisitos de

qualidade e os resultados das medies do controle de qualidade, para certificar que
estejam usando os padres de qualidade e definies operacionais apropriados.
O suporte da garantia da qualidade, independentemente do ttulo da
unidade, pode ser fornecido equipe do projeto, gerncia da organizao
executora, ao cliente ou ao patrocinador, bem como a outras partes
interessadas que no estejam envolvidas ativamente no trabalho do projeto
(Vargas, 2009)
O processo de realizar a garantia de qualidade tambm inclui a melhoria contnua do

processo, que uma forma iterativa de melhorar a qualidade de todos os processos.
Essa melhoria contnua elimina processos que no agregam valor ao projeto,
permitindo que os processos sejam operados com nveis mais altos de eficincia e
eficcia.
32
2.4.3 Auditoria de qualidade
Esta tcnica consiste numa reviso estruturada afim de determinar se as atividades

do projeto esto cumprindo as polticas, os processos e os procedimentos da
organizao e do projeto.
De acordo com o Guia PMBOK, os objetivos dessa
auditoria so:
a)
Identificar
todas
as
boas/melhores
prticas
que
esto
sendo
implementadas;
b) Identificar todas as lacunas/deficincias;
c) Compartilhar as boas prticas utilizadas ou implementadas em projetos
similares na organizao e/ou no setor;
d) Oferecer apoio proativo de forma positiva para melhorar a implementao
de processos, a fim de ajudar a equipe a aumentar a produtividade e
e) Destacar as contribuies de cada auditoria no repositrio de lies
aprendidas da organizao.
Por fim, este processo inclui adotar aes para aumentar a eficcia e a eficincia
dos processos e procedimentos da organizao executora. Solicitaes de
mudanas so muito comuns com o trmino deste processo, por meio do controle
integrado de mudanas, so aderidas ou rejeitadas as alteraes solicitadas.
2.4.4 Realizar o controle da qualidade
Este processo tem como objetivo o monitoramento e registro dos resultados da

execuo das atividades de qualidade para avaliar o desempenho e recomendar as
mudanas necessrias. De acordo com o guia PMBOK, 2008:
Os padres de qualidade incluem os processos do projeto e as metas do
produto. Os resultados do projeto incluem as entregas e os resultados do
gerenciamento do projeto, tais como desempenho de custos e de prazos. O
controle da qualidade em geral realizado por um departamento de controle
de qualidade ou uma unidade da organizao com nome semelhante.
33
As aes do processo de realizar o controle da qualidade, identificam as causas da
baixa qualidade e recomendam e/ou executam aes paraelimina-las. necessrio
que a equipe de gerenciamento de projeto tenha conhecimento prtico de controle
estatstico de qualidade, para ajudar a avaliar as sadas do controle da qualidade.
De acordo com o Vargas (2009), a equipe precisa conhecer a diferena entre os
seguintes termos:
a) Preveno (manter os erros fora do processo) e inspeo (manter os erros

fora do alcance do cliente).
b) Amostragem de atributos (o resultado est em conformidade ou no est em
conformidade) e amostragem de variveis (o resultado classificado em uma
escala continua que mede o grau de conformidade).
c) Tolerncias (intervalo especificado de resultados aceitveis) e limites de
controle (limites que podem indicar se o processo est fora de controle).
Figura 5 - Gerenciamento de qualidade
34
2.5 GERENCIAMENTO DO TEMPO DO PROJETO

O gerenciamento do tempo do projeto lida com os processos que garantiro o
termino pontual do projeto. De acordo com o Guia PMBOK, os processos que fazem
parte desse gerenciamento so os seguintes:
a)
Definir
as
atividades:
processo
de
identificao
das
aesespecficas a serem realizadas para produzir as entregas do

projeto.
b) Sequenciar as atividades: O processo de identificao e
documentao dos relacionamentos entre as atividades do projeto.
c) Estimar os recursos da atividade: O processo de estimativa dos
tipos e quantidades de material, pessoas, equipamentos ou suprimentos
que seronecessrios para realizar cada atividade.
d) Estimar as duraes da atividade: O processo de estimativa do
nmero de perodos de trabalho que seronecessrios para terminar
atividades especficas com os recursos estimados.
e) Desenvolver o cronograma: O processo de anlise das sequncias
das atividades, suas duraes, recursos necessrios e restries do
cronograma visando criar o cronograma do projeto.
f) Controlar o cronograma: O processo de monitoramento do
andamento
do
projeto
para
atualizao
do
seu
progresso
gerenciamento das mudanas feitas na linha de base do cronograma.
Estes processos interagem entre si e tambm com outras reas de conhecimento.

Dependendo da necessidade do projeto, cada processo envolve o esforo de uma
ou mais pessoas. Cada processo ocorre pelo menos uma vez em todo o projeto.
35
Apesar das interfaces bem definidas de cada processo, na prtica eles interagem
entre si e se sobrepem (Keelling, 2002).
2.5.1 Definir as atividades

O processo de definir as atividades tem como funo identificar as aes especficas
para serem realizadas para produzir as entregas do projeto. Aps o processo da
criao da EAP (estrutura analtica do projeto), so identificadas as entregas do nvel
mais baixo da EAP, os pacotes de trabalho. Estes so decompostos em atividades
que representam o que ter de ser feito para completar o pacote de trabalho. As
atividades fornecem uma base para estimativa, desenvolvimento do cronograma,
execuo, monitoramento e controle do trabalho do projeto.Com o trmino desse
processo so gerados trs itens, o primeiro a lista de atividades (Vargas, 2009):
A lista das atividades uma lista abrangente que inclui todas as atividades
necessrias no projeto. Inclui o identificador e uma descrio do escopo do
trabalho de cada atividade em detalhe suficiente para assegurar que os
membros da equipe entendam qual trabalho precisa ser executado (Guia
PMBOK 4 edio).
O segundo item gerado por este processo so os atributos das atividades. Que de
acordo com o Guia PMBOK o seguinte:
Os atributos ampliam a descrio da atividade atravs da identificao dos
mltiplos componentes associados a cada atividade. Os componentes de
cada atividade evolvem atravs do tempo. Durante os estgios iniciais do
projeto, eles incluem o identificador (ID) da atividade, o ID da EAP e o nome
da atividade; quando completos podem incluir cdigos das atividades e sua
descrio, atividades predecessoras, sucessoras, relaeslgicas,
antecipaes e esperas, requisitos de recursos, datas impostas, restries e
premissas. Podem ser usados para identificar a pessoa responsvel pela
execuo do trabalho, reageogrfica, ou local onde o trabalho tem que ser
realizado e o tipo de atividades como o nvel de esforo (NDE), esforo
distinto e esforodistribudo.
Por fim, o terceiro e ltimo item gerado pelo processo de definir as atividade ,
segundo o Guia PMBOK, a lista de marcos:
36
Um marco um ponto ou evento significativo no projeto. A lista dos
marcos identifica todos os marcos do projeto e indica se os mesmos
soobrigatrios, tais como aqueles exigidos por contrato, ou
opcionais, tais como os baseados em informaohistrica.
2.5.2 Sequenciar as atividades

De acordo com Vargas (2009) sequenciar as atividades processo de identificao
e documentao dos relacionamentos entre as atividades do projeto. Conforme o
que foi citado, aps o processo de definir as atividades, feito a documentao dos
relacionamentos entre elas. Estas so ligadas por relaes lgicas, cada atividade
relacionada com sua antecessora e sua sucessora, com exceo da primeira e da
ltima atividade. O sequenciamento pode ser feito atravs de ferramentas
automatizadas(softwares) ou tcnicas manuais.
2.5.3 Estimar os recursos da atividade

O processo de estimar os recursos da atividade utilizado para estimar os tipos e
quantidades de materiais, pessoas, equipamentos ou suprimentos para realizar uma
atividade. Um software de gerenciamento de recursos pode ser utilizado para auxiliar
no processo, ele capaz de auxiliar no planejamento, organizao e gerenciamento
do pool de recursos e no desenvolvimento das estimativas dos recursos. O Guia
PMBOK 4 tambm afirma que Dependendo da sofistica o do software, a estrutura
analtica de recursos, a disponibilidade de recursos, as taxas dos recursos e os
vrioscalendrios dos recursos podem ser definidos para apoiar a otimizao do seu
uso.
2.5.4 Estimar as duraes da atividade

Segundo o Vargas (2009) o processo de estimar as duraes das atividades definese em: "Estimar as duraes da atividade o processo de estimativa do nmero de
perodos de trabalho que sero necessrios para terminar as atividades especficas
com os recursos estimados".
Para se fazer a estimativa da durao das atividades, so utilizadas informaes do
escopo do projeto, tipos de recursos necessrios, quantidades estimadas de
37
recursos e calendrios de recursos. A estimativa feita progressivamente e
considera a qualidade e a disponibilidade dos dados de entrada, ou seja, quanto
mais elabora j estiver o projeto, mais precisa ser a estimativa. Exemplo de
estimativa retirado do Guia PMBOK, 2008:
Conforme o trabalho de engenharia e planejamento do projeto se
desenvolve, dados mais detalhados e precisos se tornam disponveis e a
preciso das estimativas de durao melhora. Portanto, a estimativa da
durao pode ser assumida como sendo progressivamente mais precisa e
de melhor qualidade.
De acordo com o Guia PMBOK pode-se usar um software para gerenciar este
processo:
A maior parte dos softwares de gerenciamento de projetos para elaborao
de cronogramas manipular essa situaoatravs do uso de um calendrio
do projeto e calendrios alternativos de recursos de trabalho-perodo que
so normalmente identificados pelos recursos que requerem perodos de
trabalho especficos. Alm da lgica de sequenciamento, as atividades
sero executadas de acordo com o calendrio do projeto e os calendrios
de recurso apropriados.
2.5.5 Desenvolver o cronograma

O processo de desenvolvimento do cronograma um dos mais importantes do
Gerenciamento de tempo, pois nele definido a data de incio e trmino de todas as
atividades planejadas no projeto. O Guia PMBOK define este processo da seguinte
maneira:
Desenvolver o cronograma o processo de anlise de sequncias das
atividades, suas duraes, recursos necessrios e restries do cronograma
visando criar o cronograma do projeto. A entrada das atividades, duraes e
recursos na ferramenta de elaborao de cronograma gera um cronograma
com datas planejadas para completar as atividades do projeto.
O desenvolvimento de um cronograma frequentemente iterativo, devido

dificuldade na previso de quanto tempo a equipe levar para cumprir cada
atividade. A preciso de um cronograma est diretamente relacionada ao nvel de
experincia da pessoa que estimar as duraes das atividades, quanto mais
preciso for, mais realista ser o cronograma. Um cronograma realista revisado e
mantido durante todo o decorrer do projeto.
38
2.5.6 Controlar o cronograma

Controlar o cronograma o processo que faz o monitoramento do andamento do
projeto, para atualizao do seu progresso e gerenciamento das mudanas feitas na
linha de base do cronograma. O controle de cronograma est relacionado a:
a) Determinao da situao atual do cronograma do projeto;

b) Influencia nos fatores que criam mudanas no cronograma;
c) Determinao de que o cronograma do projeto mudou;
d) Gerenciamento das mudanas reais conforme ocorrem.
Figura 6 - Gerenciamento de tempo -
2.7 GERENCIAMENTO DOS CUSTOS DO PROJETO

O gerenciamento de custos do projeto inclui processos de estimativa, oramentos e
controle de custos, a seguir, um resumo dos processos que envolvem este
gerenciamento, segundo o Guia PMBOK, 2008:
a) Estimar os custos - O processo de desenvolvimento de uma estimativa de

custos dos recursos monetriosnecessrios para terminar as atividades do
39
projeto.
b) Determinar o oramento - O processo de agregao dos custos

estimados de atividades individuais ou pacotes de trabalho para estabelecer
uma linha de base autorizada dos custos.
c) Controlar os custos - O processo de monitoramento do andamento do

projeto para atualizao do seu oramento e gerenciamento das mudanas
feitas na linha de base dos custos.
Em projetos de menor escopo, os processos de gerenciamento de custo so to

fortemente interligados que geralmente so feitos por uma nica pessoa, em um
curto prazo de tempo. Tambm esto associados com um trabalho j produzido pela
equipe de gerenciamento, que de acordo com Vargas (2009) so:
Esse esforo parte do processo Desenvolver o plano de gerenciamento do
projeto, que produz um plano de gerenciamento dos custos que delimita o
formato e estabelece o critrio para o planejamento, estruturao,
estimativa, oramento e controle dos custos do projeto.
2.7.1 Estimar os custos

Segundo o Guia PMBOK, estimar os custos o processo de desenvolvimento de
uma estimativa dos recursos monetrios necessrios para executar as atividades do
projeto. As estimativas de custo so baseadas nas informaes conhecidas em um
determinado momento, elas incluem a identificao e as consideraes das
alternativas de custo para iniciar e terminar um projeto.
Os custos geralmente so expressados atravs de unidades de alguma moeda
(dlar, real, euro, etc.). Mas podem ser representados atravs de horas ou dias de
servio, afim de eliminar os efeitos das flutuaes das moedas. Estimar os custos
um processo iterativo, ele se refina e aprimora de acordo com o avano do ciclo de
vida do projeto, dificilmente os custos estimados no incio do projeto sero precisos.
As fontes de informaes para este processo, derivam dos resultados obtidos de
outras reas de conhecimento, aps serem levantadas, essas informaes sevem
como entradas para a estimativa de custo. Os custos que sero estimados so para
40
todo o projeto, no limitando-se apenas a mo de obra, materiais, equipamentos,
servios e instalaes mas tambm para provises em caso de inflao e recursos
de contingncia. Conforme diz o Guia PMBOK, Uma estimativa de custo uma
avaliao quantitativa dos custos provveis dos recursos necessrios para completar
a atividade.
2.7.2 Determinar o oramento

O processo de determinar o oramento tem a finalidade de agregar os custos
estimados de atividades individuais ou pacotes de trabalho para estabelecer uma
linha de base dos custos autorizada, linha que inclui todos os oramentos
autorizados mas exclui as reservas de oramento.
De acordo com o Guia PMBOK Os oramentos do projeto compem os recursos
financeiros autorizados para executar o projeto. O desempenho dos custos do
projeto ser medido em relao ao oramento autorizado.O do processo de
determinar o oramento a linha de base do desempenho de custos, que segundo o
Guia PMBOK o seguinte:
A linha de base do desempenho de custos um oramento no termino
autorizado, sincronizado com o tempo, para medir, monitorar e controlar o
desempenho de custos geral do projeto. desenvolvido como um acumulo
dos oramentos aprovados por perodo de tempo e tipicamente mostrado
numa curva com formato em S. Na tcnica de gerenciamento do valor
agregado, a linha de base do desempenho de custos chamada de linha de
base da medio do desempenho.
2.7.3 Controlar os custos

Controlar os custos o processo de monitoramento de controle do progresso do
projeto para a atualizao dos custos e oramentos feitos na linha de base de
custos. Qualquer aumento no oramento autorizado s pode ser alterado aps
passar pelo Controle integrado de mudanas. Segundo Dinsmore (2004):
Monitorar os gastos dos recursos financeiros sem se considerar o valor do
trabalho sendo realizado para tais gastos tem pequeno valor para o projeto,
a no ser permitir que a equipe fique dentro dos limites dos recursos
financeiros autorizados. Consequentemente, muito do esforo desprendido
no controle de custos envolve a anlise da relao entre o consumo dos
fundos do projeto e o trabalho fsico sendo realizado para tais gastos. A
41
chave para o controle eficaz de custos o gerenciamento da linha de base
do desempenho de custos aprovada e as mudanas na mesma.
O processo de controlar os custos tambm inclui:
a) Influenciar os fatores que criam mudanas na linha de base de custos autorizada;

Assegurar que todas as solicitaes de mudanas sejam feitas de maneira oportuna;
b) Gerenciar as mudanas reais conforme ocorrem;
c) Assegurar que os gastos de custos no excedam os recursos financeiros
autorizados, por perodo e total do projeto;
d) Monitorar o desempenho de custos para isolar e entender as variaes a partir da
linha de base de custos;
e) Monitorar o desempenho do trabalho em relao aos recursos financeiros gastos;
f) Prevenir que mudanasno aprovadas sejam includasno relato do custo ou do
uso de recursos;
g) Informar as partes interessadas apropriadas a respeito de mudanas aprovadas e
custos associados;
h) Agir para manter os excessos de custos no previstos dentro de limites
aceitveis.(Guia PMBOK, 2008)
Figura 7 - Gerenciamento de custos
2.8 GERENCIAMENTO DAS COMUNICAES DO PROJETO
O gerenciamento das comunicaes responsvel de assegurar que as

informaes do projeto sejam geradas, coletadas, distribudas, armazenadas,
recuperadas de formar oportuna e apropriada. As comunicaes se resume em
cinco processos que so: Identificar as partes interessadas, Planejar as
42
comunicaes, Distribuir informaes, Gerenciar as expectativas das partes
interessadas e Reportar o desempenho.
Segundo o Guia PMBOK esses processos interagem entre si e com os
processos de outras reas tambm. Cada processo ocorre pelo menos uma
vez em todos os projetos. A atividade de comunicao inclui mtodo interno
e externo, formal, vertical, oficial, escrita e oral, e verbal e no verbal.
2.8.1 Identificar as partes interessadas

o processo que identifica todas as pessoas ou empresas que fazem partes
do projeto. A maior parte dos projetos tem grande nmeros de partes interessadas e
podem exercer influncia sobre o projeto e suas entregas.
As partes interessadas so pessoas e organizaes, tais como cliente,
patrocinadores, a organizao executora, e o pblico, que esto ativamente
envolvidos no projeto ou cujos interesses podem ser positiva ou negativa
afetados pela execuo ou pelo trmino do projetoDinsmore (2004).
2.8.2 Planejar as comunicaes

De acordo com Dinsmore (2004), "planejar as comunicaes o processo de
determinar quais as necessidades de informaes das partes interessadas no
projeto e definir uma abordagem de comunicao".
Identificar necessidades de informaes e determinar meios apropriados, para
atender as necessidades, so fatores importantes para o sucesso do projeto. O
processo Planejar as comunicaes reponde s necessidades de informaes e
comunicao das partes interessadas; por exemplo, quem precisa de quais
informaes, quando elas sero necessrias, como sero fornecidas e por quem.
O mal planejamento das comunicaes pode causar problemas, como atrasa
a entrega de mensagens comunicaes de informaes confidenciais para o pblico
incorreto ou falta de comunicao para algumas das partes interessadas.
43
2.8.3 Distribuir informaes
o processo que disponibiliza as informaes necessrias das partes

interessadas no projeto. O processo executado durante todo o ciclo de vida e em
todos os projetos de gerenciamento.
2.8.4 Gerenciar as expectativas das partes interessadas
o processo de comunicao e interao com as partes interessas do

projeto, que tem por finalidade atender s necessidades e solucionar medida que
ocorrerem.
O gerenciamento das expectativas ajuda a aumentar a probabilidade de
sucesso do projeto do projeto, garantindo que as partes interessadas
entendam os benefcios e os riscos do projeto. Isso permite que elas apoiem
ativamente o projeto e ajudem na avaliao de riscos das escolhas do
projetoDinsmore (2004).
2.8.5 Reportar o desempenho
o processo de coleta e fornecimento de informaes sobre o desempenho,

ou seja, distribui informaes da situao atual dos riscos e questes, trabalhos a
serem concludos, resumo de mudanas e entre outros.
44
Figura 8 - gerenciamento da comunicao
2.9 GERENCIAMENTO DE RECURSOS HUMANOS
o gerenciamento que cuida da equipe do projeto, onde documenta as

funes, responsabilidades, habilidades e hierarquias. Tambm responsvel de
obter equipe necessria para concluir as designaes do projeto, melhoria de
competncias, interao da equipe e ambiente global, acompanhar o desempenho
de membros da equipe, fornece feedback, resolver questes de mudanas para
otimizar o desempenho do projeto.A equipe do projeto consiste nas pessoas com
papis e responsabilidade, o guia PMBOK nos diz que a equipe responsvel pelas
atividades de gerenciamento do projeto e liderana, como iniciao, planejamento,
execuo, monitoramento, controle e encerramento das vrias fases do projeto.
a) Desenvolver um plano de recursos humanos: o processo

responsvel
de
identificar
documentar
responsabilidades e relao hierrquica do projeto.
funes
habilidades,
45
b) Mobilizar a equipe do projeto: responsvel para obter a equipe
necessria para o desenvolvimento do projeto.
c) Desenvolver a equipe do projeto: o processo de melhoria da equipe,
onde envolve interao e o ambiente global para o melhor desempenho do
projeto.
d) Gerenciar a equipe do projeto: como o nome j diz, o processo que
gerencia a equipe do projeto, tem como responsabilidade de acompanhar e
otimizar o desempenho e resolver questes.
Os processo apresentados acima e tambm todos os processos de

gerenciamento de projetos so apresentados no guia PMBOK como processos
distintos mas so bem definidos. J na prtica o guia mostra que os processos
sobrepem e interagem de formas que no podem ser completamente detalhadas.
2.9.1 Desenvolver o plano de recursos humanos

Esse processo com dito em resumo acima tem por funo identificar,
documentar, gerenciar responsabilidades, relaes hierrquicas entres planos desse
processo. Nesse processo tambm pode incluir a identificao de necessidades de
treinamento, estratgias para desenvolver uma equipe e questes de segurana
(Kerzner, 2002).
2.9.2 Mobilizar a equipe do projeto
Mobilizar a equipe do projeto o processo de confirmao de disponibilidade

de recursos humanos para concluir o projeto. o processo de obteno dos
recursos humanos necessrios para terminar o projeto. A equipe de gerenciamento
de projetos pode ter ou no controle sobre os membros da equipe selecionados para
o projeto. A mobilizao da equipe do projeto inclui (Kerzner, 2002):
a) Disponibilidade. Quem est disponvel e quando estar disponvel;
46
b) Capacidade. Quais competncias as pessoas possuem;
c) Experincia. Qualidade e caractersticas de cada membro;
d) Interesses. As pessoas esto interessadas em trabalhar neste projeto;
e) Custo. Quanto receber cada membro da equipe, especialmente se for
contratado de fora da organizao;
2.9.3 Desenvolver a equipe do projeto
Segundo o Guia PMBOK, 2008, esse processo de melhoria de

competncia, interao e ambiente global da equipe para aprimorar o desempenho
do projeto. Deve-se motivar a equipe continuamente fornecendo desafios e
oportunidades, oferecendo feedback e apoio conforme necessrio e reconhecendo e
recompensando o bom desempenho.
2.9.4 Gerenciar a equipe do projeto

o processo de acompanhar o desempenho de membros da equipe, fornece
feedback e otimizar o projeto. A equipe observa o comportamento e assim gerencia
os conflitos, resolve questes e avalia o desempenho dos membros da
equipe.Gerenciar a equipe do projeto requer diversas habilidades de gerenciamento
para estimular o trabalho em equipe e integrar os esforos dos membros da equipe
para criar equipes de alto desempenho. (Guia PMBOK4 edio)
47
Figura 2 - Gerenciamento de recursos humanos
2.10 GERENCIAMENTO DOS RISCOS DO PROJETO
Este gerenciamento tem por seus processos de planejamento, identificao,

anlise, planejamento de resposta, monitoramento e controle de riscos. Seu objetivo
aumentar probabilidade de eventos positivos reduzir a probabilidade de eventos
negativos do projeto.Segundo o PMBOK "todos os processos que fazem parte da
gerencia de risco interagem entre si e com processos das outras reas tambm. Os
processo ocorre pelo menos uma vez a cada projeto em uma ou mais fase do
projeto".
O risco do projeto sempre futuro. O risco um evento ou uma condio

incerta que, se ocorrer, tem um efeito em pelo menos um objetivo do
projeto. Os objetivos podem incluir escopo, cronograma, custo e qualidade.
Um risco pode ter uma ou mais causas e, se ocorrer, pode ter um ou mais
impactos(Kerzner, 2002).
2.10.1 Planejar o gerenciamento dos riscos
48
O gerenciamento de riscos do projeto inclui os processos que tratam da
realizao de identificao, anlise, respostas, monitoramento e controle e
planejamento do gerenciamento de riscos em um projeto; a maioria desses
processos atualizada durante todo o projeto. Os objetivos do gerenciamento de
riscos do projeto so aumentar a probabilidade e o impacto dos eventos positivos e
diminuir a probabilidade e o impacto dos eventos adversos ao projeto. Os processos
de gerenciamento de riscos do projeto incluem os seguintes (Guia PMBOK, 2008):
a) Planejamento do gerenciamento de riscos deciso de como abordar,

planejar e executar as atividades de gerenciamento de riscos de um projeto.
b) Identificao de riscos determinao dos riscos que podem afetar o
projeto e documentao de suas caractersticas.
c) Anlise qualitativa de riscos priorizao dos riscos para anlise ou
ao adicional subsequente atravs de avaliao e combinao de sua
probabilidade de ocorrncia e impacto.
d) Anlise quantitativa de riscos anlise numrica do efeito dos riscos
identificados nos objetivos gerais do projeto.
e) Planejamento de respostas a riscos desenvolvimento de opes e
aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do
projeto.
f)
Monitoramento e controle de riscos acompanhamento dos riscos
identificados, monitoramento dos riscos residuais, identificao dos novos riscos,

execuo de planos de respostas a riscos e avaliao da sua eficcia durante todo o
ciclo de vida do projeto.
2.10.2 Identificar os riscos

o processo de determinao dos riscos, segundo o Guia PMBOK, 2008, os
participantes deste processos podem incluir o gerente de projeto, membros da
equipe, clientes, especialistas no assuntos esternos equipe do projeto, outros
gerentes de projetos que estejam estimulado a identificar riscos.
49
2.10.3 Realizar a anlise qualitativa dos riscos
o processo de priorizao de riscos para anlise ou ao adicional.

Segundo o guia PMBOK, 2008,"Este processo avalia a prioridade dos riscos
identificados usando a relativa probabilidade ou plausibilidade de ocorrncia, o
impacto, custo, cronograma, escopo e qualidade do projeto".
2.10.4 Realizar a anlise quantitativa de riscos

Atualizaes do registro dos riscos faz parte do processo do realizar a anlise
quantitativa de riscos no gerenciamento de riscos. Segundo o PMBOK, 2008, os
registro de riscos so atualizado para poder incluir no relatrio quantitativo dos
riscos, detalhando as abordagens quantitativas, sadas e recomendaes. Esta
sada incluem quatros componentes que so anlise probabilstica do projeto,
probabilidade de atingir os objetivos de custo e tempo, lista priorizada de riscos
quantificados e tendncia nos resultados da anlise quantitativas de riscos.
2.10.5 Planejar as respostas aos riscos
De acordo com o PMBOK, 2008, o planejamento para resposta aos riscos faz
parte do gerenciamento de riscos, o processo responsvel de desenvolvimento de
opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos
do projeto.
As resposta planejadas devem ser adequadas relevncia do risco, ter
eficcia de custos para atender ao desafio, ser realista dentro do contexto
do projeto, acordadas por todas as partes envolvidas e ter um responsvel
designado. Tambm devem ser oportunas. Em geral necessrio
selecionar a melhor resposta ao risco entre as diversas opes possveis
(Dinsmore, 2004).
2.10.6 Monitorar e controlar os riscos
50
o processo de implementao dos planos de resposta a riscos o que diz o
PMBOK, 2008, tambm acompanhamento dos riscos identificados, monitoramento
dos riscos residuais, identificao de novos riscos e avaliao da eficcia do
processo de riscos. O monitoramento e o controle dos riscos podem envolver a
escolha de estratgias alternativas, a execuo de um plano alternativo ou de
contingncia, a adoo de aes corretivas e a modificao do plano de
gerenciamento do projeto.
.
Figura 3 - Gerenciamento de riscos
2.11 GERENCIAMENTO DAS AQUISIES DO PROJETO

o gerenciamento responsvel por adquirir produtos, servios ou resultados
externos equipe do projeto. Est dividido por quarto processo que so planejar,
realizar, administrar e encerrar as aquisies.
O gerenciamento das aquisies do projeto abrange os processos de
gerenciamento de contratos e controle de mudanas que so necessrios
para desenvolver e administrar contratos e controle de mudanas que so
necessrios para desenvolver e administrar contratos ou pedidos de
compras emitidos por membros autorizados da equipe do projeto (Vargas,
2009).
Um contrato de aquisies inclui termo e condies e pode incorporar outros

itens especificados pelo comprador para estabelecer o que deve fornecer ou realizar.
Assegurar que todas as aquisies atendam s necessidades do projeto
responsabilidade da equipe de gerenciamento, sendo assim que atenda as polticas
de aquisio da organizao.
2.11.1 Planejar as aquisies
51
o processo de documentao, que registra as decises de compras do
projeto e identificando seus fornecedores. Engloba tambm a considerao de
fornecedores, principalmente se o comprador deseja exercer algum grau de
influncia ou controle sobre as decises de aquisies (Guia PMBOK, 2008).
2.11.2 Realizar as aquisies

o processo de obter reposta de fornecedores, seleo de um fornecedor e
adjudicao de um contrato segundo o guia de boas prticas de gerenciamento de
projeto PMBOK.O guia fala ainda [...]nesse processo, a equipe receber licitaes
ou proposta e aplicar critrios de seleo previamente definidos para escolher um
ou mais fornecedores que sejam qualificados para realizar o trabalho e aceitao
com fornecedor. (Guia PMBOK, 2008).
2.11.3 Administrar as aquisies

o processo de gerencia das relaes de aquisies, monitoramento do
desempenho do contrato e realizao de mudanas e correes.
Tanto o com o comprador como o fornecedor administram o contrato de
aquisies para objetivos semelhantes. Cada um precisa assegurar que as
duas partes cumpram suas obrigaes contratuais e que seus prprios
direitos legais sejam protegidos. O processo de administrao das
aquisies garante que o desempenho do fornecedor cumpra os requisitos
da aquisio e que o comprador cumpra os termos do contrato legal
(Menezes, 2003).
Administrar aquisies engloba a aplicao dos processos de gerenciamento de

projetos, isso ocorre em vrios nveis quando existem vrios fornecedores e quando
h o envolvimento de vrios produtos, servios e resultados. Pode incluir os
processos, orientar a gerenciar a execuo do projeto, reportar o desempenho,
realizar o controle da qualidade, realizar o controle integrado de mudana e
monitorar e controlar os riscos.
2.11.4 Encerrar as aquisies
52
Como nome diz, o processo que finaliza todas as aquisies do projeto, envolve a
verificao dos trabalhos e as entregas so aceitveis.O processo de encerramento
das aquisies tambm envolve atividades administrativas como finalizao das
reivindicaes em aberto, atualizaes dos registros para refletir os resultados finais
e arquivamento dessas informaes para uso futuro (Menezes, 2003).
Figura 4 - Gerenciamento de aquisies
2.12 SCRUM - METODOLOGIA GIL
2.12.1 Surgimento
53
Segundo Schwaber (2002) a metodologia SCRUM" uma metodologia de
desenvolvimento de software considerada gil, que foi fortemente influenciada pelas
boas prticas adotadas pela indstria japonesa, especialmente pelos princpios de
manufatura adotadas pelas empresas Honda e Toyota".
A denominao dessa metodologia deve-se a um evento do jogo esportivo Rugby,
quando a bola sai de campo ou ocorre algum incidente, uma formao denominada
Scrum utilizada para reiniciar o jogo, reunindo todos os jogadores. A utilizao
desse nome pareceu adequado porque no Rugby o time age em conjunto, com cada
membro desempenhando um papel especifico em busca do benefcio comum. Mais
tarde Jeff Sutherland, vice- presidente da Easel, necessitava de uma forma mais
rpida e adequada de desenvolvimento de aplicaes, ento Sutherland, contando
com o apoio de John Scumniolates e Jeff Mackenna, documentaram e
implementaram o SCRUM, incorporando os estilos de gerenciamento observados
por Takeuchi e Nokata no artigo The new product development game pela Harvard
Business Review em 1986. Posteriormente, Ken Schwaber e Sutherland contanto
com o apoio de Mike Beedle a pedido da Object Magenament Group (OMG),
formalizaram e definiram a metodologia SCRUM que hoje conhecemos (Schwaber,
2002).
2.12.2 Caractersticas do Scrum

De acordo com o Guia Scrum (2002),"o SCRUM baseia-se em seis caractersticas:
flexibilidade dos resultados, flexibilidade dos prazos, times pequenos, revises
frequentes, colaborao e orientao a objetos". No existe soluesfceis para
problemas complexos, mas existe um consenso de que pode-se usar o SCRUM para
desenvolvimento complexos em que os requisitos mudam rapidamente e
constantemente, gerenciar e controlar o desenvolvimento do trabalho, tornar a
equipe autogerencivel e funcional, implementar o conceito iterativo e incremental
no desenvolvimento de software e/ou produtos, identificar causas de problemas e
remover impedimentos e valorizar os indivduos. Segundo os autores, o SCRUM
pode ser utilizado como forma de gerencia de qualquer projeto ou trabalho, que
possua caracterstica iterativa e incremental.
54
O SCRUM tambm conhecido por estruturar seu funcionamento por
ciclos, chamados de Sprint, eles duram de duas a quatro semanas e
representam as iteraes de trabalho. Dentro dos Sprint, os componentes
da equipe tem um especifico papel, sendo os trs principais : o Product
Owner que o dono do produto, ele representa o cliente e responsvel
por manter a equipe funcional e produtiva, o SCRUM Master que
desempenha o papel de lder, representando a gerncia do projeto,
responsvel pelo uso correto do processo SCRUM e a aplicao de suas
regras e o Team, que o time de desenvolvedores, eles que vo
desenvolver o produto e garantir a qualidade do mesmo(Guia Scrum, 2002).
Sbrocco cita tambm que Muitos acreditam ser prudente tambm incluir a figura do
cliente entre os papis, uma vez que de fato ele tem uma participao importante no
processo de desenvolvimento. Uma forte caracterstica do SCRUM, so as
cerimonias que so realizadas, elas so realizadas antes, durante e depois dos
Sprint, a seguir, o nome e sua deciso.
2.13 SCRUM -METODOLOGIA AGIL PARA DESENVOLVIMENTO DE

SOFTWARE
Scrum uma metodologia gil e todo o trabalho dividido em iteraes, cada uma
delas chamada de Sprint. O Sprint representa um ciclo, ele pode durar de duas a
quatro semanas, mas tipicamente mensal, pois 30 dias fornecem uma melhor
visibilidade dos objetivos do projeto e comprometimento da equipe. No final de cada
Sprintdeve-se ter uma parte do produto concluda que possa ser apresentada ao
cliente, segundoKen Schwaber, 2002.
Estas entregas parciais vo sendo implementadas at o produto final estar
concludo, e medida que forem surgindo novas funcionalidades desejadas,
novos Sprintsvo sendo realizados. Um projeto Scrum comea mesmo que
ainda se tenha uma viso superficial no princpio, talvez expressa em
termos de marketing ou uma viso tcnica, mas que se esclarece melhor
medida que o projeto evolui.
A partir dessa viso inicial se elabora uma lista enxuta dos principais itens, de tudo o
que se deseja para o software, contendo funcionalidades e requisitos que precisaro
ser desenvolvidos at a finalizao do projeto. Esta lista de itens conhecida como
Product Backlogou Backlogdo Produto. Cada item tem uma prioridade de entrega
que indica o quanto de valor ele gera para o negcio. Esta lista no precisa estar
completa logo no comeo, ela pode ganhar outros itens no decorrer do projeto.
55
Scrum uma metodologia gil para gesto e planejamento de projetos de

software. No Scrum, os projetos so dividos em ciclos (tipicamente mensais)
chamados de Sprints. O Sprintrepresenta um Time-Box
Time
dentro do qual um
conjunto de atividades deve ser executado. Metodologias geis de
desenvolvimento de software so iterativas, ou seja, o trabalho dividido
em iteraes, que so chamadas de Sprints no caso do Scrum (Alves,
2011)
2011).
As funcionalidades a serem
erem implementadas em um projeto so mantidas em uma
lista que conhecida como Product Backlog.. No incio de cada Sprint, faz-se um
Sprint Planning Meeting,
Meeting, ou seja, uma reunio de planejamento na qual o Product
Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que
ela ser capaz de implementar durante o Sprint que se inicia. As tarefas alocadas
em um Sprint so transferidas do Product Backlog para o Sprint Backlog.A cada dia
de uma Sprint,, a equipe faz uma breve reunio (normalmente
(normalmente de manh), chamada
Daily Scrum.. O objetivo disseminar conhecimento sobre o que foi feito no dia
anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.Ao final
de umaSprint,, a equipe apresenta as funcionalidades implementadas
implementad em uma Sprint
Review Meeting.. Finalmente, faz-se
faz
uma Sprint Retrospective e a equipe parte para
o planejamento do prximo Sprint. Assim reinicia-se
se o ciclo. Veja a ilustrao abaixo
(Alves 2011):
Figura 12 - Ciclo de vida SCRUM
Fonte:: http://desenvolvimentoagil.com.br, 2005
2.13.1 Product Backlog
56
Product Backlog uma lista contendo todas as funcionalidades desejadas para um
produto. O contedo desta lista definido pelo Product Owner. O Product Backlog
no precisa estar completo no incio de um projeto. Pode-se comear com tudo
aquilo que mais bvio em um primeiro momento. Com o tempo, o Product Backlog
cresce e muda medida que se aprende mais sobre o produto e seus usurios.
Durante o Sprint Planning Meeting (Reunio de planejamento), o Product
Owner prioriza os itens do Product Backlog e os descreve para a equipe. A
equipe ento determina que itens ser capaz de completar durante a Sprint
que est por comear. Tais itens so, ento, transferidos do Product
Backlog para o SprintBacklog. Ao fazer isso, a equipe quebra cada item do
Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a
dividir o trabalho entre os membros da equipe. Podem fazer parte do
Product Backlog tarefas tcnicas ou atividades diretamente relacionadas s
funcionalidades solicitadas (desenvolvimentoagil.com.br).
2.13.2Sprint Backlog
O Sprint Backlog uma lista de tarefas que o Scrum Team se compromete a fazer
em um Sprint. Os itens do Sprint Backlog so extrados do Product Backlog, pela
equipe, com base nas prioridades definidas pelo Product Owner e a percepo da
equipe
sobre
tempo
que
ser
necessrio
para
completar
as
vrias
funcionalidades.Cabe a equipe determinar a quantidade de itens do Product Backlog

que sero trazidos para o Sprint Backlog, j que ela quem ir se comprometer a
implement-los.
Durante um Sprint, o Scrum Master mantm o Sprint Backlog atualizando-o
para refletir que tarefas so completadas e quanto tempo a equipe acredita
que ser necessrio para completar aquelas que ainda no esto prontas. A
estimativa do trabalho que ainda resta a ser feito no Sprint calculada
diariamente e colocada em um grfico(Alves, 2011).
No incio de cada Sprint(iterao) a equipe seleciona os itens do Product Backlog,

de acordo com as suas prioridades e o tempo que ser gasto para completar as
suas funcionalidades. Esta nova lista conhecida como Sprint Backlog. importante
que a equipe identifique os itens e tamanho do Sprint Backlog, porque ela
estarcomprometida a finalizar tais tarefas. Os seus membros so quem devero
57
escolher com o que iro se comprometer. Nesse momento as tarefas maiores so
subdivididas em partes menores.
2.13.3 Product Increment

A finalizao das funcionalidades definidas para um determinado Sprint
marca a realizao de um Product Increment. Os membros da equipe trabalham de
maneira colaborativa de forma a realizar todas as metas definidas para aquele Sprint
2.13.4Sprint Planning Meeting
o incio de uma Sprint, onde o Product Owner(representante do cliente ou o

prprio cliente) tem a oportunidade de atualizar a priorizao dos itens do Product
Backlog e definir juntamente com a equipe um Product Increment(uma parte do
produto) a ser entregue ao cliente ao final do Sprint
O Sprint Planning Meeting uma reunio na qual esto presentes o Product
Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa
interessada que esteja representando a gerncia ou o cliente.Durante o
Sprint Planning Meeting, o Product Owner descreve as funcionalidades de
maior prioridade para a equipe. A equipe faz perguntas durante a reunio de
modo que seja capaz de quebrar as funcionalidades em tarefas tcnicas,
aps a reunio. Essas tarefas iro dar origem ao Sprint
Backlog(http://desenvolvimentoagil.com.br).
2.13.5Scrum Master
O Scrum Master procura assegurar que a equipe respeite e siga os valores e as

prticas do Scrum. Ele tambm protege a equipe assegurando que ela no se
comprometa excessivamente com relao quilo que capaz de realizar durante um
Sprint.O Scrum Master atua como facilitador do Daily Scrum e torna-se responsvel
por remover quaisquer obstculos que sejam levantados pela equipe durante essas
reunies. O papel de Scrum Master tipicamente exercido por um gerente de
projeto ou um lder tcnico, mas em princpio pode ser qualquer pessoa da equipe
(http://desenvolvimentoagil.com.br).
58
2.13.6 Product Owner
O Product Owner a nica pessoa responsvel pelo gerenciamento do Backlog do

Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantm
o Backlog do Produto e garante que ele est visvel para todos. Todos sabem quais
itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar. O
Product Owner uma pessoa, e no um comit. Podem existir comits que
aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade de
um item, ter que convencer o Product Owner. Empresas que adotam Scrum podem
perceber que isso influencia seus mtodos para definir prioridades e requisitos ao
longo do tempo (Schwaber, 2002).
O Product Owner a pessoa que define os itens que compem o Product
Backlog e os prioriza nas Sprint Planning Meetings.O Scrum Team olha
para o Product Backlog priorizado, seleciona os itens mais prioritrios e se
compromete a entreg-los ao final de um Sprint (iterao). Estes itens
transformam-se no Sprint Backlog (desenvolvimentoagil.com.br).
A equipe se empenha a executar um conjunto de atividades no Sprint e o Product

Owner se compromete a no trazer novos requisitos para a equipe durante o Sprint.
Requisitos podem mudar (e mudanas so encorajadas), mas apenas fora do Sprint.
Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece
concentrada no objetivo traado para o Sprint e novos requisitos no so aceitos.
2.13.7 O Scrum Team
a equipe de desenvolvimento. Nela, no existe necessariamente uma diviso
funcional atravs de papis tradicionais, tais como programador, designer, analista
de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto
de trabalho com o qual se comprometeram conjuntamente para um Sprint.Um Scrum
Team tpico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com
equipes maiores. A principal abordagem para trabalhar com equipes grandes no
Scrum usando o conceito de "Scrum ofScrums". Cada Scrum Team trabalha
normalmente, mas cada equipe tambm contribui com uma pessoa que dever
frequentar o Scrum of Scrums Meeting para coordenar o trabalho de mltiplas
equipes Scrum. Esses encontros so anlogos aos DailyScrums, mas no
59
acontecem necessariamente todos os dias. Fazer essa reunio duas ou trs vezes
por semana tende a ser suficiente na maioria das organizaes(Alves, 2011).
2.13.8 Daily Scrum
A cada dia do Sprint a equipe faz uma reunio diria, chamada Daily Scrum. Ela tem
como objetivo disseminar conhecimento sobre o que foi feito no dia anterior,
identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
um encontro dirio realizado pela equipe e o Scrum Masteronde os membros
discutem aquilo em que trabalharam, no que iro trabalhar e possveis impedimentos
que estejam atrapalhando o progresso do trabalho. Esta reunio uma maneira
eficiente de manter os membros cientes dos objetivos e impedir que o projeto saia
do rumo.So tipicamente rpidas e objetivas, realizadas em p, preferencialmente
pelamanh, duram de 15 a 30 minutos, para evitar perder o foco do que est sendo
desenvolvido e possveis divergncias de assuntos(Alves, 2011).
Os Daily Scrums normalmente so realizadas no mesmo lugar, na mesma hora do
dia. O ideal quese realizem na parte da manh, para ajudar a estabelecer as
prioridades do novo dia de trabalho.Todos os membros da equipe devem participar
do Daily Scrum. Outras pessoas tambm podem estar presentes, mas s podero
escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe
disseminar informaes sobre o estado do projeto.
O Daily Scrum no deve ser usado como uma reunio para resoluo de problemas.
Questes levantadas devem ser levadas para fora da reunio e normalmente
tratadas por um grupo menor de pessoas que tenham a ver diretamente com o
problema ou possam contribuir para solucion-lo. Durante o Daily Scrum, cada
membro da equipe(Alves, 2011).
Utilizao do Scrum pelas empresas.

A seguir, uma pesquisa realizada em 2009, afim de descobrir a porcentagem de
empresas que utilizam metodologias geis para o desenvolvimento de seus projetos.
60
61
3. DESENVOLVIMENTO
3.1 SCRUM X PMBOK
Neste captulo, ser descrito o ciclo de vida Scrum com a adio de processos do
PMBOK para refora-lo, constituindo uma metodologia mista. O Scrum possui um
ciclo de vida mais simplificado e menor que o PMBOK, por isso, ser mais fcil
acompanhar, entender como encaixar e utilizar os processos do Guia PMBOK dentro
do Scrum.
Enquanto oScrum rodado, podemos visualizar os efeitos da aplicao dos
processos do PMBOK e onde podem ser encaixados, formando uma metodologia
unificada de trs formas distintas: internamente, externamente e paralelamente ao
ciclo Scrum.(Cruz, 2012)
3.1.1 Ciclo de vida Scrum
Existem vrias abordagens, entretanto, seguiremos a proposta de Fbio Cruz para a

unio das metodologias do Guia PMBOK e do Scrum, nesta partiremos do princpio
que o Scrum mais simples e possui um ciclo de vida mais fcil de acompanhar.
Com isso, o objetivo visualizar o Scrum sendo aplicado, e principalmente
rodando segundo suas regras, e encaixar o Guia PMBOK conforme o Scrum
acontece, porm, para o ciclo do Scrum iniciar preciso que alguns
processos sejam executados antes, bem como outros depois do seu
termino(Cruz, 2012).
Alguns processos do Guia PMBOK devem ser executados antes, durante e depois
das cerimnias e atividades do Scrum. Ser possvel visualizar claramente como as
ferramentas e tcnicas do Guia daro pleno suporte a equipe Scrum. Evidenciando
como benfico a unio das metodologias.
Figura 5 - Ciclo de vida Scrum
62
Fonte: www.fabiocruz.com, 2013
3.2 INICIO DO PROJETO
O fato de o ambiente de desenvolvimento ser gil, no dispensa alguns

procedimentos formais, por exemplo, a oficializao do incio do projeto. Grandes
clientes costumam aderir bem s metodologias geis, mas no abrem mo de
processos contidos nas metodologias tradicionais. Os modelos tradicionais do guia
PMBOK resolvem este problema.(Cruz, 2012)
A seguir, os processos do guia PMBOK e do Scrum, que so utilizados para a
oficializao do incio de um projeto:
3.2.1 Termo de abertura do projeto
Este processo formaliza e oficializa o comeo de um projeto, dando permisso e

liberao para equipe comear os trabalhos, segundo Cruz, um termo de abertura do
projeto deve conter no mnimo:
a) Propsito ou justificativa do projeto;
b) Requisitos de alto nvel;
c) Riscos de alto nvel;
d) Resumo do cronograma de marcos;
e) Resumo do oramento;
f) Requisitos para aprovao do projeto e quem responsvel por decidir se o
63
projeto bem sucedido ou no;
g) Gerente do projeto, responsabilidade, nvel de autoridade e designados;
h) Nome e autoridade do patrocinador que autoriza o termo de abertura.(Cruz
2012)
3.2.2 Identificao dos Stakeholders
Em um projeto, a identificao das partes interessadas de suma importncia, pois

so essas pessoas ou organizaes que provavelmente fornecero as informaes
necessrias para a execuo do projeto, alm eles so responsveis pela aprovao
do produto. Os stakeholders tem influncia no projeto, segundo Cruz, 2012:
Lembrando que as partes interessadas podem influenciar o projeto de forma
positiva ou negativamente, e/ou serem afetadas pelo projeto, tambm de
forma positiva ou negativa. Portanto, dar ateno a este processo
fundamental para qualquer tipo de ambiente de projeto, seja gil ou
waterfall.
Neste processo, o Gerente de Projetos e o Product Owner trabalham juntos, afim de

realizar a mesma atividade.
3.2.3 Desenvolver o plano de gerenciamento do projeto
Este documento tem a finalidade de orientar todos os trabalhos de gerenciamento de

projeto, tambm formaliza como o projeto ser conduzido em todas suas etapas. De
acordo com Cruz, 2012:
Este inclusive o momento ideal, e o documento perfeito, para deixar bem
claro para todos os stakeholders do projeto que sero utilizadas ferramentas
e tcnicas do waterfall combinados com o gil, e principalmente em que
momento cada um ser aplicado e quais seus benefcios.
Conforme o que foi citado, esta etapa ideal para explicar s partes interessadas
que o projeto ser gerenciado com a mistura de duas metodologias, deixando claro
quais so as vantagens dessa aplicao e formalizando todo o plano de
gerenciamento do projeto.
Recomenda-se a publicao deste documento para todas as partes interessadas,
contendo no mnimo os seguintes itens:
a) O ciclo de vida do projeto e os processos que sero aplicados em cada fase;
64
b) Como o trabalho ser executado para completar os objetivos do projeto;
c) Como sero gerenciadas as mudanas no projeto;
d) Como sero gerenciadas as configuraes do projeto;
e) Como sero gerenciados os requisitos do projeto;
f) O que ser feito para manter a integridade das linhas de base do projeto;
g) Quais as necessidades para as comunicaes entre as partes interessadas.
(Cruz, 2012)
3.3 EXECUTANDO O SCRUM
Aps a execuo de algumas tarefas formais do PMBOK, o gerente de projetos e a

equipe formada pelos papis do Scrum, podem dar incio ao projeto pela tica do
Scrum. Durante a execuo do Scrum, o time ir trabalhar na realizao de tarefas
da metodologia gil e nas atividades de planejamento, realizando testes, entregas e
outras etapas. Sobre as entregas das tarefas, Cruz, 2013, afirma:Tudo ao seu
tempo, mas, devido ao ambiente gil, de uma forma mais dinmica, mais breve e
mais recorrente, seguindo um estilo de ciclos com iteraes de durao mais curtas.
Quando se fala de Scrum, logo vem uma de suas principais caractersticas, as
Sprints, que segundo Sbrocco:
Projetos que utilizam o Scrum progridem por intermdio de uma srie
sequencial de Sprints, que correspondem a interaes. O objetivo gerar
um produto entregvel de valor ao cliente, que foi previamente com ele.
Cada Sprint deve ocorrer em um perodo de duas a quatro semanas. O
produto projetado, codificado e testado durante a Sprint.(Sbrocco, 2012)
Antes do incio de uma Sprint, necessrio fazer um planejamento dos itens do

Product Backlog que sero desenvolvidos. necessrio coletar, entender, analisar e
detalhar os itens antes de manda-los para a Sprint. O PMBOK pode ajudar o Scrum
nessa etapa, pois possui um bom gerenciamento de trabalhos com os requisitos do
projeto, o Product Backlog so os requisitos de um projeto, no Scrum.
A seguir, estaro descritos os processos do PMBOK e do Scrum que sero
utilizados nesta etapa do projeto:
3.3.1 Coletar os requisitos
65
Processo bsico para a realizao de qualquer projeto, este processo obrigatrio para
ser possvel aplicar o Scrum, e onde o Product Owner procura os Stakeholders e identifica
todos os requisitos necessrios para se entregar o projeto. (Cruz, 2012). Neste processo,
a principal atividade a delimitao dos requisitos, que pode ser complementado

pelo documento conhecido como Matriz de Rastreabilidade de Requisitos.
3.3.2 Definir o escopo
Aps a coleta dos requisitos, sua definio e detalhamento vem logo em seguida,
com mesma importncia para o projeto. Com o escopo detalhado, pode-se saber o
quais os requisitos que devero ser atendidos no final do projeto, ou, no momento
da entrega. Segundo Cruz, 2012:"Este processo conhecido pelo Guia PMBOK
como definir o escopo. Para o Scrum, definir o escopo nada mais do que o
detalhamento dos requisitos que s assim vo formar o Backlog do produto.
Aps a definio do escopo, o Product Owner ter o material para criar as Estrias,
artefato j bem conhecido pelo Scrum. Alm disso, podero ser feitas prottipos de
telas, para descrever de forma visual as aes do sistema, e documentos de apoio
com as definies de regras de negcio. (Cruz, 2013)
Quanto as regras de negcio, altamente recomendvel que se registre e confirme
todas as regras no sistema, sem exceo, independente da metodologia utilizada
para o desenvolvimento. Um bom documento para isso, so os Casos de Uso, do
modelo UML (Unified Modeling Language).
3.3.3 Criar a EAP (estrutura analtica do projeto)
A EAP(Estrutura Analtica de Projeto) tem como objetivo mostrar graficamente todo o

escopo definido para o projeto, utilizada para que o gerente de projeto e a equipe de
gesto, saibam os objetos precisam ser construdos, e de forma hierrquica, como
so distribudos. A EAP uma tima ferramenta de acompanhamento, com ela, o
time no deixa de construir nenhuma funcionalidade descrita no escopo. Para
facilitar sua construo nesta metodologia mista, usar o conceito dos pacotes de
trabalho da EAP quando estiver definindo as estrias, com isso, o esforo de
construir a EAP ser somente colocar as estrias em formato visual e seguir os
66
padres estruturais da EAP. (Cruz, 2012)
3.3.4 Definio do Scrum Team
Este um processo do Scrum, o ideal que ele seja realizado apenas uma vez,
durante a preparao da primeira Sprint, o ideal que ele se mantenha com os
mesmos e a mesma quantidade de membros, isto importante para que o Time
Scrum consiga o autogerenciamento, auto monitorao, autocontrole e a automelhoria constante. Infelizmente projetos so instveis, e a equipe pode mudar a
qualquer momento, mas o processo de Definio do time Scrum poder ser
executado novamente entre as iteraes.
Este processo o responsvel por estimar os recursos das atividades
conforme as estrias definidas, e determinar o tamanho do Time, o tamanho
das Sprints, e se ter a primeira ideia de quantas Sprintsseronecessrias
para completar o trabalho do projeto. Para o Guia PMBOK este processo
conhecido como Estimar os recursos das atividades. Juntamente com esta
estimativa de recursos, o gerente de projetos pode preparar um plano de
recursos humanos, que outro processo contido no Guia PMBOK, e visa
principalmente atender e gerenciar preocupaes com recompensas e
treinamentos do Time. Este mesmo um processo que pode ser revisto
outras vezes ao longo de outras iteraes, porque ao longo do projeto
podero surgir novas necessidades de treinamentos e recompensas
especiais. (Cruz, 2012)
3.3.5 Apresentao do Backlog do Produto
Assim que o Product Owner termina de preparar o Backlog do Produto, chega a hora
de apresenta-lo para o Time e transforma-lo em funcionalidade ou parte
potencialmente entregvel. Este o momento de definir quais sero as prximas
entregas, e a distribuio das Sprints para concluir todo o trabalho necessrio para
realizar as entregas. Em alguns casos, o planejamento de entrega feito e
detalhado no incio projeto, junto ao termo de abertura e ao plano de gerenciamento
de projeto, na fase de apresentao de Backlog do Produto, ele apenas detalhado
e associado s funcionalidades especficas que o compem e as estrias criadas. A
seguir, os processos do Scrum e do PMBOK que compe essa fase do projeto:
3.3.5.1Mobilizar equipe do projeto
Por meio deste processo, o gerente de projetos oficializa a formao do Time Scrum.
Apesar da equipe ter seus papis e responsabilidades estimados no processo
67
Definindo o time Scrum, as pessoas participantes das equipes sero mobilizadas
para dentro do projeto, ou seja, sero colocadas efetivamente e oficialmente para
trabalhar dentro dele. (Guia PMBOK, 2008)
3.3.5.2Limpar o Backlog
Este processo tem como funo o entendimento do Backlog, por parte do Time com
ajuda do Product Owner. De acordo com Cruz 2012, o ideal para a realizao deste
exerccio o agendamento de uma reunio de entrega da verso, na qual o Product
Owner ir apresentar todos os itens que devero ser entregues ao cliente no final de
um perodo.
3.3.5.3Definindo o tamanho das estrias
Aps o entendimento do Backlog, o Time ter condies de analisar as estrias, afim

de definir seu tamanho de acordo com sua complexidade. Depois que os tamanhos
das estrias estiverem definidos, j pode-se comear a pensar no trabalho do
Backlog, e nas estimativas de durao e quantidade de Sprints. O time tambm
pode reforar a estimativa de recursos com base no tamanho das estrias. (Cruz,
2013)
3.3.5.4Planejar as aquisies
Neste processo o Time realiza uma anlise conhecida como Fazer ou Comprar,
onde com base no tamanho e complexidade das estrias, nessa anlise, o Time
avalia se vale mais a pena a compra de uma soluo pronta que atenda a
necessidade do cliente, ou o desenvolvimento dela em casa mesmo. Quanto a
participao do gerente de projetos nessa etapa, Cruz afirma o seguinte: A
participao do gerente de projetos opcional aqui, mas se torna obrigatria caso
haja a necessidade de realizar compras, pois ele que analisar o oramento do
projeto e dar a palavra final sobre a compra ou no. (Cruz, 2013)
3.3.5.5Velocidade do time
68
Os resultados do processo de limpar o Backlog so utilizados em diversos outros
processos. Neste processo, o time verifica j possui uma velocidade definida, ou
seja, a quantidade de estrias que consegue realizar por Sprint, considerando seu
tamanho e complexidade. Caso no haja a definio precisa de velocidade neste
processo, aps a primeira Sprint o Time armazenar a velocidade e poder usa-la
para os prximos planejamentos e comparaes com o resultado de futuras Sprints.
3.3.5.6 Identificar os Riscos
Nesta etapa, realizado o primeiro trabalho com riscos no projeto. O processo de

entender as estrias de suma importncia no Scrum, pois outros processos sero
executados com seus resultados. A primeira identificao de riscos realizada
quase no final dos trabalhos com o Product Backlog.
3.3.5.7Gerenciamento de Custos
Na metodologia hbrida entre Scrum e PMBOK, o gerente de projetos poder

trabalhar paralelamente no gerenciamento de custos, preparao do Product
Backlog, definido pelo PMBOK. Esta uma etapa muito importante para qualquer
projeto, sendo tambm considerada uma das mais difceis.
[...] preciso lembrar que a economia na execuo de um projeto pode
acarretar o encarecimento da manuteno do produto resultado no projeto.
Sendo assim, no se pode gastar descontroladamente nem economizar
excessivamente. preciso realizar um gerenciamento de custos. (Cruz,
2013. p.152)
Este uma das reas de gerenciamentos do PMBOK que mais justificam a unio
das metodologias, ela tem o seguinte objetivo:
O objetivo deste processo estabelecer polticas, procedimentos e uma
documentao para planejar, gerenciar, consumir e controlar os custos,
tendo como chave para o sucesso o fornecimento de uma orientao e
direo de como os custos sero gerenciados ao longo de todo o projeto.
(Cruz, 2013. P.153)
3.3.5.8 Estimar os custos
No fim dos trabalhos com o Product Backlog, o gerente de projetos conseguir
69
estimar os custos da
prxima entrega do projeto, podendo tambm, de acordo
com o tamanho do projeto ou a diviso de fases, o gerente de projetos poder

fornecer o custo para todo ele, no s da prxima etapa. O custo poder ser
estimado por atividade, tendo como base as informaes fornecidas pelo Time.
(Cruz, 2012).
Essencialmente, o processo ser utilizado para desenvolver uma estimativa dos
recursos monetrios s atividades do projeto, incluindo a identificao e a
considerao de alternativas de custos do incio at o fim do projeto.
3.3.5.9Determinar o Oramento
Junto com a estimativa de custos, o gerente de projetos poder mostrar oramentos

previstos para o projeto, ou para a prxima entrega. Este processo muito
importante para o gerente conseguir autorizao no mbito financeiro, e o cliente
possuir dados mais precisos quanto o custo do projeto.
3.3.5.10Planejar o gerenciamento de Riscos no projeto
Nesta etapa do projeto, o gerente poder elaborar o gerenciamento de riscos, com

base nas informaes reunidas no Product Backlog. O gerenciamento de riscos tem
a seguinte finalidade: [...] Os objetivos do gerenciamento dos riscos so aumentar a
probabilidade e o impacto dos eventos positivos e reduzir a probabilidade e o
impacto dos eventos negativos no projeto. (Guia PMBOK, 2008)
Com o plano de gerenciamento de riscos, o gerente de projetos poder mostrar aos
Stakeholders os riscos identificados, e como ir trata-los com o desenvolvimento do
projeto.
3.4 PLANEJAMENTO SPRINT PRIMEIRA ETAPA
O planejamento da Sprint um processo do Scrum muito importante, onde todas as

suas etapas precisam ser cumpridas para que o projeto siga adiante. O tempo de
execuo dura em mdia 8 horas, sendo assim dividido em duas reunies de 4
70
horas. Neste planejamento so realizados uma ou mais cerimnias, com o intuito de
definir os trabalhos que sero realizados durante ela. Os seguintes processos so
sugeridos para esta etapa do processo:
3.4.1 Preparar o ambiente de trabalho
Este processo responsvel pela infraestrutura requerida pela equipe para

desenvolver o projeto, tudo que est relacionado equipamentos, salas, ferramentas,
softwares, dentre outras coisas que sero necessrias para a iniciao da
Sprint.Segundo Cruz, 2012, este um processo que tem como objetivo diminuir
riscos, pois muitos consideram este processo como automtico, no tendo a
necessidade de constar nos planejamentos.
3.4.2 Identificar a velocidade do Time
O processo de identificar a velocidade do Time responsvel pela oficializao da

mesma, e/ou por sua definio. Durante os trabalhos com o Product Backlog,
sugerido que o Time defina sua velocidade, mas caso ele no tenha definido uma
ainda, o momento agora. Entretanto, a chance do Time errar a estimativa de
velocidade na primeira Sprint alta, podero ser feitas alteraes na velocidade a
qualquer momento durante a Sprint, retirando ou adicionando trabalho. Conforme
seguem as iteraes as estimativas vo ficando mais precisas. (Cruz, 2012).
3.4.3 Definir o tamanho da Sprint
Esta uma pequena e muito importante etapa para o projeto, pois o tamanho da
Sprint que ser definido agora, valer para o resto todas as outras. Caso o Time
errar no tamanho, ele ter de identificar o erro e concerta-lo o mais rpido possvel,
porque neste momento o projeto poder sofrer alteraes no cronograma, assim o
Gerente de Projetos poder fazer as alteraes necessrias.
Por meio dos resultados obtidos com os processos de preparar o ambiente de
trabalho, reunir a equipe, identificao da velocidade do Time e a preparao do
Product Backlog, possvel determinar o tamanho e a quantidade de Sprints que
sero necessrias para a concluso dos trabalhos do Backlog.
71
3.4.4 Revisar os Riscos
Nesta etapa do projeto, sero revisados e atualizados os riscos j identificados.

Considerando tambm os possveis impactos causados pelos processos de
preparao do ambiente, definio da velocidade do time e tamanho das Sprints.
(Cruz, 2012)
3.4.5 Objetivo da Sprint
O objetivo da Sprint deixar claro que ser realizada a implementao do Product

Backlog, este processo tem como finalidade a orientao do Time, acerca sobre a
razo pela qual est sendo desenvolvido o incremento.
3.4.6 Definir as atividades primeira etapa
Neste processo, o Time selecionar os itens do Product Backlog que sero

desenvolvidas, a seleo feita conforme a capacidade e velocidade do Time,
determinadas anteriormente. De acordo com Cruz, este processo est presente
tanto no Scrum quanto no PMBOK.
Note que este mais um processo que, apesar de nomes diferentes no
Scrum e no Guia PMBOK, o propsito de ambos exatamente o mesmo:
selecionar os itens de Backlog (atividades) que sero trabalhados na
prxima Sprint. Sem perceber, o Time Scrum realiza o processo Definindo
as atividades, que sugerido pelo Guia PMBOK.(Cruz, 2013)
A escolha das atividades deve ser baseada na velocidade do Time, se ainda no

possurem essa informao, o Time precisar definir uma velocidade e a partir desta
reunio, calibra-la a cada Sprint concluda.
3.4.7 Entendendo o Backlog
Com o apoio do Product Owner, o time ir entender todos os itens que sero
trabalhos na Sprint. O Product Owner explica item a item, o Time faz os
questionamentos necessrios. O bom entendimento tambm ser til quando o Time
for determinar o tamanho de cada item.
Durante esta reunio, o Time dever consultar e questionar ao mximo o Product
72
Owner, para aprimorar o conhecimento sobre o Backlog. Como auxlio, o Time
poder ler documentos que o Product Owner produziu junto ao cliente, tais como
especificaes funcionais, prottipos, casos de uso, e outro materiais que venham a
ajudar no entendimento dos itens.
3.4.8 Priorizando o Backlog
O Product Owner em conjunto com o Time, coloca em ordem os itens do Backlog da

Sprint, definindo o caminho crtico com a escolha dos itens de maior importncia e
impacto (Cruz, 2013). Esta priorizao j foi feita inicialmente pelo Product Owner.
Nesta etapa o Time que trabalha com a prioridade, para verificar casos de um item
depender do outro para ser desenvolvido.
3.4.9 Sequenciar as atividades
Com base nos resultados dos processos de definio da importncia das estrias
realizada pelo Product Owner, e priorizao do Backlog realizado pelo Time, o
gerente de projetos ir sequenciar as atividades, e assim comea a preparar o
cronograma do projeto.O gerente de projetos tambm tem a necessidade de definir
as atividades mais, ou menos, crticas, de acordo com informaes referentes ao
projeto ou ao cliente. Uma boa prtica, segundo Cruz, a seguinte:
Pelas boas prticas, os itens mais crticos devem ser realizados

primeiro, ento qualquer informao que o gerente de projetos tenha
que possa alterar a criticidade de qualquer item do Backlog deve ser
repassada ao Time o mais breve possvel. (Cruz, 2013)
Uma boa prtica colocar os itens mais crticos na frente da fila, eles costumam ser
os que mais agregam valor ao final do produto. Como fortalecimento dessa
sugesto, vale lembrar que com certeza o cliente gostaria de receber as
funcionalidades mais importantes primeiro.O processo de ordenao dos itens a
serem desenvolvidos por prioridade, uma das mais importantes tarefas no
gerenciamento do escopo, e por consequncia da Sprint. Com isso, o gerente de
projetos e o Product Owner podem se ajudar nesta tarefa.
3.4.10 Registrar, Qualificar e quantificar os Riscos
73
O trabalho com o gerenciamento de Riscos comea na primeira parte da reunio da

Sprint, com isso, nessa etapa o Time com a ajuda do gerente de projetos, e do
Product Owner registram novos erros encontrados e reviso os j listados.Este o
momento ideal para fazer uma anlise quantitativa e qualitativa dos riscos, pois o
Time inteiro est focado nos trabalhos com os itens do Backlog para a Sprint, neste
momento os riscos surgem e podem ser analisados.
3.4.11 Planejar as respostas aos riscos
Com os riscos analisados e quantificados, o Time e o gerente de projetos planejar

como sero tratados tais riscos, antecipando problemas e prevendo como manter o
projeto sob controle.
3.4.12 Desenvolvendo o cronograma
Com base em todas as informaes produzidas no projeto at o momento, o gerente

de projetos pode desenvolver o cronograma da fase que est se iniciando. O
desenvolvimento de um cronograma aceitvel uma tarefa iterativa, e sugestivo
conter somente o detalhamento da fase em que o projeto se encontra, no o
andamento do projeto inteiro.
O incio da fase pode ter um cronograma de marcos, ele poder ser acompanhado
junto ao cliente durante o projeto. Para Cruz, o objetivo maior dessa etapa :
Neste ponto o objetivo principal detalhar o cronograma com datas, tarefas
e recursos apenas para esta fase, definindo e servindo de documento de
comunicao dos trabalhos que sero realizados dentro da prxima Sprint.
Isto faz com que o cronograma seja mais simples, alm de crescer e ganhar
mais detalhes gradativamente seguindo o conceito de ondas
sucessivas.(Cruz, 2012)
3.4.13 Distribuir informaes
Este processo tem como responsabilidade a disponibilizao da informao corretas

disposio dos interessados, a fim de comunicar o projeto conforme planejado.
Esta distribuio de informaes deve ser executada durante todo o projeto e em
74
todos os processos, pois tanto o gerente de projetos quanto o Time Scrum devem
considerar as comunicaes um ponto chave para o sucesso do projeto.
3.5 PLANEJAMENTO DA SPRINT SEGUNDA ETAPA
Conforme dito na primeira etapa do planejamento da Sprint, a cerimnia de

planejamento da Sprint dividido em duas reunies de 4 horas, cada uma com
objetivos distintos. Na primeira etapa da Sprint determinado o que ser feito, na
segunda etapa ser descrito como ser feito.
3.5.1 Definindo atividades segunda etapa
As tarefas so pedaos detalhados do trabalho necessrio para converter os itens

do Backlog em produto pronto para entrega. Para isso, as tarefas precisam ser
decompostas para que o time consiga desenvolve-la em um dia de Sprint, esta lista
de tarefas complementa o Backlog da Sprint.O prprio Time deve se auto-organizar
e realizar os trabalhos com o Backlog da Sprint. Este processo est presente nas
duas metodologias, tanto no Scrum e no PMBOK, somente muda a nomenclatura.
No Scrum o processo de decompor os itens de Backlog equivale ao processo de
definir as atividades no PMBOK.
3.5.2 Realizando a garantia de qualidade
Este processo responsvel por verificar se os padres de qualidade esto sendo

seguidos. O ponto forte deste processo na execuo, mas no planejamento que
se garante que a qualidade ser atendida.Na garantia de qualidade necessrio
conferir se foram includos tarefas de testes, e qualidade e se estas fizeram parte
das estimativas de cada tarefa. de extrema importncia que a garantia de
qualidade tenha sido includa nas estimativas, pois diversas vezes o Time lembra de
que para realizar as tarefas sero necessrios esforos de desenvolvimento, mas
esquecem que ser preciso fazer as validaes e testes.
3.5.3 Montando o painel de controle
75
O Quadro de Tarefa, tambm conhecido como Taskboard, uma das principais

ferramentas do Scrum para exercitar a transparncia do que est sendo
desenvolvido e o que aguarda o desenvolvimento. O Taskboard deve ter no mnimo
duas reas, uma para as estrias que esto sendo desenvolvidas, e outra para as
que aguardam desenvolvimento. Para Cruz, uma terceira rea seria destinada para
tarefas que no foram planejadas. (Cruz, 2013)
Outra ferramenta que utilizada como controle, o Grfico de Burndown, que
representa visualmente a soma das estimativas dos esforos restantes para
completar o Backlog. O Taskboard e o Grfico de Burndown podem ser distribudos
aos stakeholders do projeto.
3.5.4 Realizando o controle integrado de mudanas
Este processo proveniente do PMBOK, possui a seguinte definio:O processo de

reviso de todas as solicitaes de mudana, aprovao de mudanas e
gerenciamento de mudanas nas entregas, ativos de processos organizacionais,
documentos de projeto e plano de gerenciamento do projeto. (PMBOK, 2008).Ele
responsvel neste momento como parte do planejamento para que seja dada a
devida importncia necessidade de controle efetivo sobre as mudanas que
podem ocorrer a partir deste ponto. No plano de gerenciamento do projeto,
necessrio uma seo somente para a descrio de como funcionar o tratamento
das mudanas ao longo do projeto, ela pode ser adicionada no incio do projeto, ou
se no tiver sido criada ainda, pode ser feita nesta etapa.
3.5.5 Revisando os riscos
Aps os processos de planejamento da Sprint e dos trabalhos realizados com as

estrias e atividades, o Time tem uma nova oportunidade de registrar, quantificar,
qualificar e planejar as respostas aos riscos. Este processo ser executado diversas
vezes ao longo do projeto, com o auxlio das cerimnias do Scrum, que so aliadas
para os trabalhos de gerenciamento de risco.
3.5.6 Executando a Sprint
76
Nesta etapa do projeto o Time comea a colocar a mo na massa, dando o ponta

p inicial no desenvolvimento do produto, aplicando os planejamentos realizados
nas fases iniciais.
Este grupo de processos representa os dias em que o Time est transformando
estrias em partes incrementais do produto, construindo e preparando uma prxima
entrega. Ao passo que o produto desenvolvido, oportunidades de inspeo surgem
naturalmente e permitem que o Time monitore o seu prprio andamento e tenha uma
percepo real da evoluo dos trabalhos que est realizando.A seguir, a descrio
dos trabalhos de cada papel durante a execuo do Scrum:
3.5.7 O Time Scrum na execuo
O time obrigatoriamente deve estar livre para realizar as tarefas diretamente

relacionadas ao objetivo da Sprint, consequentemente, do projeto. Neste processo, o
prprio Time o responsvel por se auto-orientar e auto-gerenciar, proporcionando
uma agilidade que facilitar os trabalhos necessrio que a Sprint seja completada.
3.5.8 O Scrummaster na execuo
A principal funo do Scrummaster atuar fortemente para remover os obstculos

para que o Time consiga completar suas tarefas. Ele tambm fica com suas outras
responsabilidades, conforme o Guia Scrum:
O ScrumMaster responsvel por garantir que o Time Scrum esteja
aderindo aos valores do Scrum, s prticas e s regras. O ScrumMaster
ajuda o Time Scrum e a organizao a adotarem o Scrum. O ScrumMaster
educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a
desenvolver produtos de maior qualidade.(Guia Scrum, 2009. p.06)
Cruz afirma que na prtica, o Scrummaster geralmente realiza atividades objetivas

com o Time, como atualizar o Quadro de Tarefas e o Grfico Burndown.
3.5.9 O ProductOwner na execuo
O ProductOwner responsvel pela remoo de obstculos que envolvem regras de
77
negcio, dvidas ou problemas de definio de escopo ou entendimento de
requisitos e comunicaes com Stakeholders.
Uma das suas tarefas mais importantes, que geralmente o ProductOwner realiza
ao longo da execuo do projeto, a pr-confirmao e validao das construes
que o Time est realizando, especialmente a conferncia do atendimento aos
padres de qualidade estipulados com o cliente.
3.5.10 O gerente do projeto na execuo
O gerente de projetos auxilia o Scrummaster na remoo de impedimentos que

estejam ligados com o macrogerenciamento do projeto, alm de influenciar o cliente
e comunica-lo sobre o progresso do projeto sempre que necessrio. Algumas
atividades de monitoramento e controle so de responsabilidade do gerente de
projetos, tais como:
a) Formar, treinar e gerenciar os membros do Time do Projeto.
b) Obter, gerenciar e suar os recursos (pessoas e equipamentos).
c) Estabelecer e gerenciar os canais de comunicao do projeto.
d) Gerar dados do projeto e informaes sobre o andamento do projeto, para
facilitar previses
e) Emitir solicitaes de mudana e adaptar mudanas aprovadas.
f) Gerenciar riscos e implementar as respostas aos riscos.
g) Gerenciar fornecedores. (Cruz, 2013)
3.5.11 Atualizando e verificando o painel de controle
Com a atualizao do painel, o Time demonstrar que est cumprindo algumas

tarefas de acompanhamento e controle e dando insumos ao gerente de projetos
para que ele realize alguns processos de monitoramento e controle. sugestivo que
o prprio Time mantenha o painel de controle atualizado diariamente.
1. Quadro de tarefas: assim que um integrante do Time inicia uma tarefa, ele
deve mover esta tarefa para da coluna A fazer para a Fazendo no Quadro
de Tarefas. Cada integrante deve estar fazendo somente uma tarefa por vez.
2. Grfico Burndown: o grfico mostrar como o Time est avanando no
Projeto, em relao ao planejado. O grfico dever mostrar duas linhas, a
primeira com o avano esperado aps o planejamento da Sprint ou verso e a
78
segunda com o real avano dirio do projeto.
3.5.12 Monitorando e controlando o trabalho do projeto
Neste processo o painel prover insumos para que o Time e/ou o gerente de
projetos acompanhe, revise e ajuste o progresso do projeto para atender aos
objetivos de desempenho definidos no plano de gerenciamento de projeto (Cruz,
2013)
Tanto o PMBOK quanto o Scrum so compatveis neste ponto de monitoramento do
projeto. O PMBOK sugere que o monitoramento contnuo fornea equipe de
gerenciamento uma compreenso clara da vitalidade do projeto. O Scrum sugere
que o painel de controle seja atualizado diariamente, sendo assim, o painel de
controle do Scrum fornece uma compreenso transparente do andamento do
projeto, mais uma vez evidenciando a eficincia da abordagem da metodologia
mista.
3.5.13 Controlando o escopo
Este o momento onde o gerente de projetos e o Time monitoram o andamento do

escopo do projeto e gerenciem as mudanas na linha de base. um dos principais
processos que tratam as mudanas do escopo e seus impactos dessas mudanas
no projeto. Seu objetivo assegurar que todas as solicitaes de mudana e aes
corretivas ou preventivas sejam tratados pelo processo de realizar o controle
integrado de mudanas.
As mudanas no escopo tem diversas origens, podem ser fatores externos como
medidas de rgos regulamentadores (Aneel, Banco Central, Receita Federal, etc),
ou falhas internas, como erros de planejamento (especificaes incorretas) e/ou
alteraes no produto realizadas pelo prprio cliente. (Cruz, 2013)
3.5.14 Controlando o cronograma
Uma tarefa quase exclusiva do gerente de projetos, tendo em alguns casos, o apoio
do Time. O gerente compara o cronograma com os painis de andamento e
monitora o andamento do projeto, com o intuito de atualizar o seu progresso e
79
gerenciar as mudanas feitas na linha de base do cronograma.Para obter o
andamento do cronograma do projeto, o gerente realiza uma anlise de
desempenho que pode ser feita com coleta de dados dos painis de controle.
3.5.15 Controlando os custos
Durante a execuo do projeto, de suma importncia ter o controle da sade

financeira do projeto. Assim como o controle de cronograma, o controle de custos
realizado pelo gerente de projetos.
O gerente precisa controlar os custos a uma distncia prxima o suficiente para que,
quando necessrio, seja possvel agir para manter os excessos de custos no
previstos dentro de limites aceitveis em tempo hbil para no ter perdas maiores do
que as estimadas durante o planejamento.
3.5.16 Realizando o controle integrado de mudanas
Segundo Cruz, 2012, este o processo responsvel por revisar todas as solicitaes
de mudanas, gerenciando-as e garantindo que apenas as mudanas aprovadas
sejam realizadas e incorporadas linha de base revisada.
Este processo tem foco na identificao, documentao e no controle das mudanas
e das linhas de base do produto, envolvendo atividades relacionadas ao
gerenciamento de mudanas com base na execuo do projeto.
3.5.17 Conduzindo aquisies
Caso o Time tenha errado no primeiro trabalho com as aquisies e faltou algum
recurso necessrio, ou at mesmo nesta etapa do projeto, este processo acionado
afim de iniciar novamente as atividades de aquisio.
As aquisies costumam ser planejadas anteriormente, neste processo, obtm a
resposta de fornecedores, como cotaes, propostas e licitaes sobre como os
requisitos podem ser atendidos por eles.
3.5.18 Monitorando e controlando a Sprint
A partir desta etapa, o ciclo de desenvolvimento comea a tomar uma forma mais
80
conhecida pelas equipes de desenvolvimento tradicional, porm seguindo o fluxo e
as regras do Scrum.A seguir, os processos que compe essa fase do projeto.
3.5.19 Reunies dirias (Stand up meeting)
A proposta da reunio diria e fornecer ao Timeuma oportunidade de inspecionar o

prprio trabalho e compartilha-lo com todos os integrantes deste mesmo Time,
fornecendo informaes para que seja possvel controlar o andamento do projeto,
monitorar riscos e problemas e acompanhar a velocidade do projeto. (Cruz,
2013)Segundo o Guia Scrum, os benefcios da reunio diria so:As Reunies
Dirias melhoram a comunicao, eliminam outras reunies, identificam e removem
impedimentos para o desenvolvimento, ressaltam e promovem a tomada rpida de
decises e melhoram o nvel de conhecimento de todos acerca do projeto. (Guia
Scrum, 2009)
3.5.20 Desenvolvendo a equipe do projeto
Este processo um dos que deixa muito claro e evidente a importncia da unio da
abordagem gil do Scrum com a tradicional do Guia PMBOK. O processo visa
melhoria das competncias, interao e ambiente global da equipe para aprimorar o
desempenho do projeto, e a reunio diria um dos melhores momentos em que o
Time Scrum e o gerente de projetos tm a oportunidade de observar e coletar
informaes para aplicar a melhoria contnua no prprio Time.
A capacidade do Time aumenta atravs de treinamentos ou formas de alinhar e
sincronizar os conhecimentos de todos, sendo que cada um do Time poder sugerir
e solicitar capacitaes especficas para desenvolver a equipe do projeto. Tendo
como foco aumentar as capacidades individuais e de grupo, para que a equipe
realmente funcione como um Time.
3.5.21 Realizando a garantia de qualidade
Neste momento do projeto o Time poder consultar os documentos iniciais do

projeto, afim de verificar os padres de qualidade que deviam ser atendidos e
81
verificar se esto sendo colocados em prtica.
O ProductOwner participa das reunies dirias afim de reunir informaes a respeito
de como esto sendo atendidos os requisitos do projeto, alm de obter informaes
acerca dos padres de qualidade, podendo inclusive influenciar para que estes
sejam atendidos.
3.5.22 Identificando novos riscos
Durante a reunio diria Time tem uma tima oportunidade de identificar novos
riscos, sendo isso possvel atravs da reposta pergunta sobre impedimento e do
dilogo de todo o Time sobre os trabalhos que sero realizados at a prxima
reunio diria.O gerente de projetos participa da reunio diria afim de colher e ser
informado de riscos que podem afetar ou influenciar o andamento do projeto e que
podem ser tratados ou direcionados pelo prprio gerente do projeto. (Cruz, 2013)
3.5.23 Reviso da Sprint
Nas fases finais do ciclo de desenvolvimento dentro da Sprint, temos a reviso da

mesma. Onde pode ser resumida como validao e verificao dos requisitos, se
foram atendidos com o desenvolvimento, assim, disponibilizando o pacote ao
cliente.A reviso da Sprint tem a durao de 4 horas, com o objetivo de apresentar
ao ProductOwner o que foi construdo e transformado em produto, permitindo assim
que como responsvel, ele aprove ou reprove os trabalhos completados.
3.5.24 Reunio de reviso da Sprint
Este processo realizado no final da Sprint, ele tem o objetivo de avaliar o que est
sendo entregue e o que deveria ser entregue. Nesta etapa todos os envolvidos no
projeto devem participar. Esta reunio conhecida como apresentao da Sprint,
nesta apresentao realizada uma reviso, pelo ProductOwner, dos itens
concludos pelo Time. Uma boa prtica que o Time demostre o funcionamento do
produto. Com isso, o ProductOwner poder avaliar o que est sendo considerado
como pronto, levando em conta o que est sendo entregue versus o que deveria ser
82
entregue.
3.5.25 Controlando a qualidade
Este processo ocorre naturalmente durante a reunio de reviso da Sprint, o

ProductOwner pode controlar a qualidade do projeto, verificando se os padres de
qualidade anteriormente definidos esto sendo atendidos com a entrega realizada.
Com o monitoramento dos resultados especficos do projeto, possvel verificar se
esse resultados atendes aos padres de qualidade pretendidos, permitindo
assegurar a conformidade com os atributos, as caractersticas e as funcionalidades,
alm de identificar formas de eliminar as causas dos resultados insatisfatrios.
3.5.26 Retrospectiva da Sprint
Nesta etapa o projeto est chegando ao final de uma Sprint e vem um pensamento
em tona de forma forte e imponente mais importante melhorar na prxima Sprint
do que simplesmente terminar a Sprint atual. Segundo Cruz:
Terminar a Sprint atual e entregar um produto ao cliente importante

e sempre ser. Porm, sem olhar para trs, inspecionar o que
ocorreu e buscar melhorar no prximo ciclo, no haver evoluo e
caminhada na direo de uma melhoria contnua constante e da
criao de um Time de alta performance. (Cruz, 2013. p.289)
Com isso, realizada a ltima cerimnia de um ciclo do Scrum, chamada

Retrospectiva da Sprint, e esta deve ocorrer sempre aps a reunio de reviso e
antes da reunio de planejamento da prxima Sprint. Todos os envolvidos com o
projeto devem participar dessa reunio (Scrummaster, ProductOwner, Time e
Gerente de Projetos).
3.5.27 Registrando as lies aprendidas
Este processo pode ser realizado em qualquer etapa do projeto, mas na cerimnia
de retrospectiva o momento ideal para sua execuo. O registro das lies
aprendidas tem como objetivo a documentao dos acontecimentos que
83
influenciaram ou impediram algum avano do projeto ao longo da fase anterior, bem
como as experincias ruins e boas que foram percebidas.
3.6 NOVA SPRINT
Assim que a reunio de retrospectiva encerrada, o Time Scrum juntamente com o

Gerente de Projetos, devero considerar o inicio de uma nova Sprint. Lembrando
que devem seguir as regras do Scrum, afirmando que no pode haver intervalo entre
uma Sprint e outra.Deve-se continuar o ciclo Scrum, dando incio aos processos de
planejamento da Sprint, recomeando uma nova rodada de processos e reunies, e
assim sucessivamente at que o projeto seja terminado ou o produto esteja
completado.A seguir, os processos que o Time do Projeto realizar antes de iniciar
uma nova Sprint:
3.6.1 Gerenciando as comunicaes do projeto
Com a Sprint finalizada e o painel de controle atualizado, o gerente de projetos tem

o material de apoio suficiente para coletar e disseminar as informaes de
desempenho do projeto e com isso realizar mais uma vez o gerenciamento das
comunicaes do projeto.O gerente dever coletar esses dados atravs do prprio
painel de controle atualizado, aps a coleta do que necessrio, o gerente dever
compilar os dados podendo gerar diversos relatrios de desempenho. Tais como:
a) Desempenho do cronograma planejado em relao ao real.
b) Desempenho dos custo planejados em relao aos reais.
c) Desempenho tcnico planejado em relao ao real.
3.6.2 Controlando os riscos
Nesta etapa, so aplicadas as repostas aos riscos, acompanhamento aos risco

identificados, monitoramento dos riscos residuais, identificao de novos riscos e de
avaliao de eficcia do processo de gerenciamento de riscos durante o projeto.
84
Relembrando que estes processos do gerenciamento de riscos podem ser aplicados
qualquer hora do projeto. (Cruz, 2013)
Este processo est destacado neste ponto do projeto devido as reunies de reviso
e retrospectiva da Sprint, pois nessas duas cerimnias provvel que apaream
novos riscos e/ou mudana de situao de riscos j planejados.
Por fim, esse processo vai determinar se:
a) As premissas ainda so validas.
b) Houve modificao ou possibilidade de desativao de um risco.
c) Polticas e procedimentos de gerenciamento dos riscos esto sendo seguidos.
d) As reservas de contingncia devem ser modificadas conforme a avaliao
atualizada dos riscos.
e) Novos riscos foram identificados.
f) Ocorreram sintomas de riscos.
3.6.3 Gerenciando a equipe do projeto
Este processo consiste em acompanhar o desempenho do Time do projeto, fornecer

feedback, resolver questes e gerenciar mudanas para otimizar o desempenho do
projeto, especialmente atravs da melhoria das condies para aumento do
desempenho individual. O gerenciamento de uma equipe envolve uma srie de
combinaes de habilidade, onde se mais destacam, o gerenciamento de conflitos, a
negociao e a liderana. (Cruz, 2013)
Para gerenciar a equipe, o gerente de projeto precisa observar o comportamento do
Time, contribuir para a resoluo de conflitos, resolver as questes pendentes e
avaliar o desempenho dos membros da equipe. Durante a Sprint, o gerente e os
outros membros do Time possuem condies de avaliar de forma incremental todos
os demais integrantes, especialmente por meio da tcnica de observao.
3.6.4 Encerrando a Fase
Como j foi dito anteriormente, assim que uma Sprint termina, ou comea
imediatamente, o Time no realiza nenhuma atividade entre elas. Isso acontece
porque, exceto quando for a ltima Sprint e o projeto terminar, h mais incrementos
85
do produto a serem realizados.
Entretanto, enquanto o Time segue para outra Sprint, h outras atividades a serem
realizadas que envolvem tanto o cliente quanto os incrementos do produto a serem
realizados, nesta abordagem, o encerramento da fase simplesmente a entrega da
verso planejada. De acordo com o planejado, pode ser que este processo no seja
executado todas as vezes que o Time do projeto passar por esta etapa no ciclo.
A seguir, os processos que compem essa fase.
3.6.5 Entregando o valor
Este processo marca o momento em que oficialmente realizada a entrega de valor

ao cliente, que se d pela liberao do incremento de produto at o momento para
que o cliente o utilize.Este processo se encontra fora do ciclo Scrum, ou seja, fora da
Sprint. Isso ocorre porque um importante conceito deve ser observado: a
possibilidade de uma ou mais Sprints gerarem o resultado esperado de valor ao
cliente, sendo assim, somente quando este valor for alcanado a entrega dever ser
realizada. (Cruz, 2013)
3.6.6 Orientando e acompanhando a homologao da entrega
Ao se entregar um valor ao cliente, ou seja, um incremento do produto pronto para o

usurio final, recomenda-se testar, validar e conferir tudo que foi entregue em
comparao com tudo que foi planejado e definido para ser entregue.
A homologao precisa ser coordenada de maneira que os trabalhos sejam
realizados em um tempo determinado, com retornos e documentaes de registro de
questes, erros ou inconformidades para que o Time possa responder o mais rpido
possvel, afim de que a homologao termine o mais rpido possvel, gerando a
aprovao da verso de entrega. A execuo deste processo deve ser realizada
pelo gerente de projetos.
3.6.7 Controlando a qualidade
Durante a homologao do produto entregue aparece mais uma oportunidade para

controlar a qualidade do projeto e verificar se os padres de qualidade anteriormente
86
definidos esto sendo prontos.
Durante este processo o cliente costuma produzir uma documentao de registro de
erros ou inconformidades que precisar ser encaminhada para o Time de
desenvolvimento trabalhar e retornar para o cliente conferir novamente as correes
e assim finalizar a homologao.
3.6.8 Validando o escopo
Este processo tem como objetivo formalizar a aceitao das entregas concludas,
incluindo principalmente a reviso das entregas com o cliente ou patrocinador, para
assegurar que foram concludas satisfatoriamente e obter deles uma aceitao
formal.
A conferncia atravs de uma inspeo tambm chamada de reviso, se o trabalho
entregue atente aos requisitos e aos critrios de aceitao do produto realizado
neste processo. Ele tambm praticado no mesmo momento do controle de
qualidade, pois ao realizar o processo de homologao o cliente j realiza a
inspeo dos requisitos e critrios de aceitao.
3.6.9 Gerenciando mudanas
Caso o cliente encontre alguma necessidades que no foram caracterizadas como

erros ou inconformidades, mas precisam ser realizadas no produto antes de sua
concluso, esses itens precisam ser designados como solicitaes de mudanas e
ser tratados como tal.Segundo Cruz, este processo se prope ao seguinte:
[...] este processo tambm poder gerar solicitaes de mudana que iro
compor o Backlog da prxima Sprint, podendo at j entrar como itens no
previstos da Sprint que est em andamento paralelamente ao encerramento
da fase. (Cruz, 2013. p.327)
3.6.10 Controlando as aquisies
Nesta etapa, com a fase (Sprint) j fechada, o gerente de projetos tem condio de
administrar as aquisies, que o processo de gerenciar as relaes de aquisio,
87
monitorar o desempenho do contrato e fazer mudanas conforme necessrio,
contudo o objetivo principal garantir que o desempenho do fornecedor esteja
adequado aos requisitos contratuais.
Os fornecedores tratados neste processo no envolve os fornecedores que esto
executando o projeto, e sim fornecedores terceiros que so responsveis por
produtos ou servios relacionados ao projeto em execuo.
3.6.11 Nova fase
Assim que uma fase terminar, ou deve comear. No entanto, como alguns processos
so executados entre uma fase e outra, este processo tem como objetivo
caracterizar que todo o Time do Projeto est pronto para iniciar uma nova fase.
Ao conectar o Time uma nova fase, o ciclo retorna ao incio da fase de
planejamento da Sprint e executa novamente todos os processos contidos no ciclo
at chegar a este ponto novamente, continuando nessas iteraes at a ltima fase.
Quando esta for a ltima fase do projeto, o ciclo deve ser encerrado e o Time do
Projeto deve caminhar para a ltima etapa, que o encerramento do projeto.
3.6.12 Encerrando o Projeto
Este processo tem como objetivo formalizar o encerramento do projeto, garantindo

que todo trabalho foi realizado e aceito pelo cliente.
Para isso, algumas atividades devem ser realizadas, tais como:
a) Assinatura de encerramento de contratos ou termo de aceite das entregas.
b) Atualizao de toda a documentao do projeto.
c) Transferncia dos produtos completados, incluindo documentaes, para o
cliente.
d) Coleta final de lies aprendidas e registro para uso futuro em novos projetos.
Neste momento, o gerente deve revisar todas as informaes prvias dos
encerramentos anteriores, conferindo e assegurando que todo o trabalho do projeto
est completo e que este atingiu seus objetivos. (Cruz, 2013. p.332)
88
3.6.13 Encerrando as aquisies
Este o processo que tem como objetivo encerrar cada aquisio do projeto.
Envolve atividades administrativas como finalizao de reinvindicaes abertas,
atualizaes dos registros para refletir os resultados finais e arquivamento dessas
informaes para uso futuro.A seguir uma imagem com os ciclos de vida mistos e
com todos os seus processos :
3.7 CICLO DE VIDA SCRUM COM PROCESSOS PMBOK
Figura 6 - Ciclo de vida Scrum com PMBOK
89
Fonte: www.fabiocruz.com
Figura 15 - Ciclo de vida Scrum com reas de conhecimendo do PMBOK
Fonte: Autoria prpria.
CONCLUSO
90
Esta reviso bibliogrfica apresentou o estudo de duas abordagens utilizadas para o
desenvolvimento de softwares e projetos, com o intuito de ajudar gerentes ou
equipes a entenderem estas duas metodologias unidas.
Primeiramente esta reviso concentrou-se em estudar fundamentos terios
sobre o tema, no que se diz a respeito aos processos de gerenciamento de projetos
do PMBOK e do mtodo gil Scrum.
Depois, foi apresentado um estudo com adio entre os dois mtodos,
denominado um estudo hibrido, onde pode-se concluir que as noves areas de
conhecimento do PMBOK so compatveis de alguma forma com a metodologia
Scrum. Entretanto como este trabalho uma compilao de diversos estudos como
monografias, dissertaes e teses, no foi realizado testes para se terresultados
prticos e absolutos.
Em seguida, foi visto com detalhes os processos do PMBOK sendo
incrementados no Scrum, que no sobrecarrega em termos de documentao, s os
torna mais robusto. O segredo de tudo isso saber adapt-los corretamente.
No incio deste trabalho de concluso de curso, o objetivo geral do mesmo foi
analisar a viabilidade de utilizar o PMBOK na metodologia Scrum, onde foi levantado
uma proposta que buscou respondera seguinte questo problema: vivel utilizar o
Scrum em conjunto com o PMBOK para ter progresso no desenvolvimento de
software?
Conclui-se que h duas hipteses onde pode-se chegar as seguintes

consideraes:
Hiptese 1:No vivel utilizar o Scrum com mtodos tradicional PMBOK,

pois no ir proporcionar agilidade na entrega, com isto o Scrum ir perder
performance na entrega do produto, como idealizado no manifesto gil (2001).
Esta hiptese no foi validada, pois atravs da fundamentao e estudos foi
demonstrado no desenvolvimento que a utilizao dos processos do PMBOK ajudam
corrigir erros de todo projeto, com isso garante reduo do tempo final. Vale tambm
ressaltar que o projeto documentado ser de fcil manuteno, no dependo
exclusive de um time ou equipe de desenvolvimento, o que gera extrema agilidade
em manuteno e testes.
91
Hiptese 2: Sim, vivel, pois proporcionar mais qualidade no
desenvolvimentode software trazendo melhorias significativas no gerenciamento e
planejamento de projetos de software.
Essa hiptese foi validada, pois em nossa reviso comprova que com a
utilizao dos processos de conhecimento do PMBOK com a metodologia Scrum o
resultado final do desenvolvimento do projeto pode ser considerado satisfatrio,
tendo em vista que os processos do PMBOK trazem melhorias significativas. Como
vimos no desenvolvimento atende as necessidades do cliente, no ocorrendo falta
de interao com as partes interessadas. Tambm essa hiptese contribui com a
divulgao da comunicao entre a equipe de desenvolvimento.
Aps
realizao
deste
trabalho,
conclui-se
que
somente
com
fundamentao bibliogrfica no possvel afirmar absolutamente que as

metodologias so compatveis. H uma necessidade de ser testada, realizando uma
pesquisa quantitativa para tal abordagem.
Para finalizar, fica a sugesto para trabalhos futuros o desenvolvimento de
uma pesquisa de testes dos paradigmas estudados, para continuar trazendo
melhorias no processo de desenvolvimento de software.
REFERENCIAS BIBLIOGRFICAS
92
ALVES, Renata de Souza. Scrum - Revista Engenharia de Software. Edio 23 2011.
CRUZ, Fbio. PMBOK e Scrum, como uni-los?.Engenharia de Software
Magazine. 47 vol. pg 6-13, 2012.
CRUZ, Fbio. Scrum e Guia PMBOK unidos no gerenciamento de projetos.
1 ed. Rio de Janeiro: Brasport, 2013.
DISNMORE, P. C. e Silveira Neto F. H. Gerenciamento de Projetos, Como
Gerenciar seu Projeto com Qualidade, dentro do Prazo e Custos Previstos.
Rio de Janeiro : Qualitymark, 2004
HTTP://DESENVOLVIMENTOAGIL.COM.BR/ - Aprendendo sobre metodologias
geis
KEELLING, R, Gesto de projetos, uma abordagem global; Traduo Cid

Knipel Moreira; Saraiva, 2002. Titulo Original: Project management: an
international perspective.
KERZNER, H, Gesto de Projetos, As Melhores prticas. Traduo.: Marco
Antonio Viana Borges, Marcelo Klippel e Gustavo Severo de Borba. Porto
Alegre: Bookman, 2002 Ttulo Original Applied project management: best
pratices on implementation.
MENEZES, Luis Cesar de Moura. Gesto de projetos. 2. ed. So Paulo: Atlas,
2003.
Project Management Institute. Project Management Guide of Knowledged
(PMPOK), Quarta Edio, 2008.
SBROCCO, J. H; MACEDO, P. H. Metodologias geis: engenharia de
software sob medida. 1 ed. So Paulo: rica 2012
SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum. New
Jersey: Prentice Hall, 2002. Traduzido para o portugus.
VARGAS, Ricardo. Manual Prtico do Plano de Projeto (4a. edio). Editora
BRASPORT (2009).

Gerenciamento de Projetos de Software Com Scrum e Pmbok

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Gerenciamento de Projetos de Software Com Scrum e Pmbok

Загружено:

Авторское право:

Доступные форматы

1

Faculdades Integradas do Vale do Iva

GERENCIAMENTO DE PROJETOS DE SOFTWARE COM

GERENCIAMENTO DE PROJETOS DE SOFTWARE COM

apresentado a Faculdade Integrada do Vale

GERENCIAMENTO DE PROJETOS DE SOFTWARE COM

Trabalho de Concluso de Curso

Voc precisa encontrar o que ama. E essa verdade

trabalhadores. O trabalho preenche boa partede sua

(Steven Paul Jobs Steve Jobs)

As nicas grandes companhias que conseguiro ter

(William Henry Gates III Bill Gates)

Dedico este trabalho a todos que me ajudaram a cumprir esta rdua

agradeo a minha famlia por me manter alegre e

Eu Dieimes Nunes de Souza agradeoa Jesus, pelo dom da vida e pela

Boeing, Alexandre. Nunes, Dieimes.Gerenciamento de projetos de software com

A necessidade de projetar softwares que tenham qualidade e sejam desenvolvidos

Boeing, Alexandre. Nunes, Dieimes.Project management software with scrum

O processo de gerenciamento de projetos de software algo complexo devido

1.2.1 Objetivo geral

Este trabalho objetiva identificar os pontos de compatibilidade entre a

1.2.2 Objetivos especficos

Criar um modelo hbrido utilizando as duas abordagens estudadas.

Estudar a metodologia gil de gerncia de projetos Scrum.

Estudar o guia de prticas em gerenciamento de projetos PMBOK

conhecimento do PMBOK com a metodologia gil de projetos Scrum

2.1 O QUE PMBOK

Figura 1 - reas do conhecimento

Fonte: guia PMBOK, 2008

2.1.1 Processos do Guia PMBOK

O gerenciamento de projetos a aplicao de conhecimento, habilidades,

a) Grupo de processos de iniciao

Figura 2 - Processos do guia PMBOK

2.2 GERENCIAMENTO DE ESCOPO

Segundo o Guia PMBOK O gerenciamento do escopo do projeto inclui os processos

a) Coletar os requisitos- O processo de definio e documentao das

2.2.1 Coletar os requisitos

Este processo serve para definir e documentar as funes do projeto e do produto

2.2.2 Definir o Escopo

Neste processo, desenvolvida uma descrio detalhada do projeto e do produto.

Conforme o que foi citado do Guia PMBOK, o processo de definir o escopo

2.2.3 Criar EAP - Estrutura Analtica do Projeto

2.2.4 Verificar Escopo

2.2.5 Controlar Escopo

Figura 3 - Gerenciamento de escopo

Fonte: Guia PMBOK, 2008

2.3 Gerenciamento de Integrao

Um bom gerenciamento de integrao evidentemente necessrio quando

A seguir, ser explicado com mais detalhes cada um dos processos do

2.3.1 Desenvolver o termo de abertura do projeto

O documento de abertura de projeto estabelece uma parceria entre organizao

2.3.2 Desenvolver o termo de abertura do projeto

a) Necessidade de negcios: A necessidade de negcios de uma organizao

2.3.3 Business Case

2.3.4 Termo de abertura

Segundo o Guia PMBOK 4 edio o termo de abertura do projeto documenta as

2.3.5 Desenvolver o plano de gerenciamento do projeto

Desenvolver o plano de gerenciamento do projeto o processo de documentao

2.3.6 Orientar a execuo do projeto

A orientao da execuo do projeto o processo de realizao do trabalho definido

2.3.7 Realizar o controle integrado de mudanas

Realizar o controle integrado de mudanas o processo que controla e

O processo de realizar o controle integrado de mudanas inclui as seguintes

2.3.8 Encerrar projeto ou fase