Embed Size (px)
Citation preview
UNIVERSIDADE FUMEC
FACULDADE DE CIÊNCIAS EMPRESARIAIS - FACE
ALEXANDER CORREIA MARQUES
MÉTODOS HÍBRIDOS:
Unificando o framework SCRUM e guia o PMBOK para uma gestão ágil de projetos
Belo Horizonte
2015
ALEXANDER CORREIA MARQUES
MÉTODOS HÍBRIDOS:
Unificando o framework SCRUM e o guia PMBOK para uma gestão ágil de projetos
Artigo Científico apresentado à UNIVER-SIDADE FUMEC como requisito parcial para obtenção do certificado de Especia-
lista em Gerenciamento Estratégico de Projetos Orientador: Prof. Renato Ávila Soares
Souza
Belo Horizonte
2015
RESUMO
O termo projetos é caracterizado por incertezas e mudanças. Com isso, é im-
portante se preocupar com o seu gerenciamento. Cada dia que passa, as organiza-
ções possuem a necessidade de resultados mais ágeis. Mesmo possuindo diferentes características e níveis de maturidade, a maioria tem dificuldade em ge-renciar projetos. Sendo assim, o objetivo desse estudo foi a utilização de uma técni-
ca única de gerenciamento de projetos. Para tanto, utilizou-se um estudo bibliográfico das abordagens PMBOK e SCRUM. A coleta de informações foi reali-zada através de um levantamento bibliográfico e os resultados obtidos mostram que
a implementação de uma metodologia ágil de gestão de projetos pode ajudar uma organização a controlar melhor suas entregas, burocratizar menos os projetos e, a-lém disso, gerar mais valor aos seus clientes.
Palavras-chave: Gerenciamento de Projetos. PMBOK. SCRUM.
ABSTRACT
The term projects is characterized by uncertainty and change. Thus, it is im-
supporting worry about their management. Each day that passes, organizes tions have the need for more agile results. Even with difference-ing characteristics and ma-turity levels, most have difficulty managing projects. Thus, the aim of this study was
the use of a single technical project management. For this, we used a bibliographic study of PMBOK and SCRUM approaches. Data collection was conducted through a literature review and the results show that the implementation of an agile project
management can help an organization better control your deliveries, less bureaucra-tized projects and also generate more value to its customers.
Keywords: Project Management. PMBOK. SCRUM.
3
1. INTRODUÇÃO
Gerenciar projetos que estejam dentro do orçamento, prazo e qualidade, e que
atendam as necessidades e os objetivos dos clientes são grandes desafios que te-
mos atualmente. Muitos fatores existentes fazem com que vários projetos não te-
nham o sucesso esperado.
O PMI possui um guia de gerenciamento de projetos que é atualmente um dos
mais utilizados no mundo, porém, muitas pessoas se queixam desse guia ser muito
engessado e complexo. Já o SCRUM é um framework leve para desenvolver e man-
ter produtos complexos, além de ser muito utilizado na área de desenvolvimento de
software. Todavia não possui quase nenhuma formalização e por conta disso não
possui muita aceitação dos clientes envolvidos nesse tipo de projeto.
Os métodos utilizados nesse trabalho são uma pesquisa bibliográfica e um estu-
do sobre o gerenciamento ágil em projetos, usando o método tradicional do guia do
PMI e o framework SCRUM.
O trabalho proposto permite explorar o que melhor existe nas duas técnicas com
objetivo de unificar o gerenciamento de projetos e entregar para o cliente o que de
fato ele considera como importante. Os meios para atingir o objetivo serão discutidos
ao longo deste trabalho.
2. PROJETO
Nas empresas e em nossas vidas pessoais, utilizamos e ouvimos falar cons-
tantemente a palavra projeto. Temos a necessidade de utilizá-la, pois, a todo o mo-
mento buscamos atingir um objetivo no qual não é possível alcançá-lo sem que haja
um esforço. Segundo o PMI (2013, p.03)1, “Projeto é um esforço temporário empre-
endido para criar um produto, serviço ou resultado exclusivo. A natureza dos proje-
tos indica que eles têm um início e um término definidos.”
Para Cruz (2013), os projetos não possuem duração fixa.
Um projeto pode ter duração de horas, semanas ou anos, além de não haver restrições para pessoas envolvidas ou recursos alocados. Um projeto pode ser: A criação de um novo sistema de tecnologia da
1 Project Management Institute, Inc, Um guia do Conhecimento em Gerenciamento de Projetos (Guia
PMBOK), elaborado após consenso de voluntários por meio de um processo para o desenvolvimento desses padrões. Neste artigo será utilizado PMI como referência ao Guia PMBOK.
4
informação; A concepção de um novo modelo de automóvel; Uma pesquisa para o desenvolvimento de um novo medicamento; O lan-çamento de uma nova campanha de marketing. (CRUZ, 2013, p.02).
2.1. Gerenciamento de projetos
De acordo com Kerzner (2007, p15),”A gestão de projetos pode ser definida
como o planejamento, a programação e o controle de uma série de tarefas integra-
das de forma a atingir seus objetivos com êxito, para benefício dos participantes do
projeto”. Para o PMI (2013, p.06), o gerenciamento de um projeto inclui, mas não se
limita a:
Identificação dos requisitos;
Tratamento das diferentes necessidades, preocupações e expectativas
das partes interessadas no planejamento e execução do projeto;
Estabelecimento, manutenção e execução de comunicações ativas, e-
ficazes e colaborativas entre as partes interessadas;
Gerenciamento das partes interessadas visando o atendimento aos re-
quisitos do projeto e a criação das suas entregas;
Equilíbrio das restrições conflitantes do projeto que incluem, mas não
se restringem a:
o Escopo;
o Qualidade;
o Cronograma;
o Orçamento;
o Recursos;
o Riscos.
Segundo Cruz (2013, p11), “O gerenciamento de projetos é a aplicação con-
trolada e coordenada de conhecimentos, habilidades, ferramentas e técnicas aos
eventos do projeto a fim de atingir seus objetivos”.
2.2. Ciclo de vida e fases em gerenciamento de projetos
De acordo com o PMI (2013), no início de um projeto os níveis de custo e
pessoal são baixos, todavia, atingem um valor máximo enquanto o projeto é execu-
tado e caem de forma acelerada quando o projeto é finalizado. Os projetos possuem
5
diferentes características, tamanhos e complexidades, porém podem ser definidos
em uma estrutura genérica apresentada na figura 01.
Figura 01 – Níveis típicos de custo e pessoal em toda estrutura genérica do ciclo de
vida de um projeto
Fonte: PMI, 2013, p.39
De acordo com o PMI (2013), os riscos e incertezas são maiores no início do
projeto. A medida que ocorrem entregas e decisões são tomadas esse risco diminui.
Já o custo de mudanças nos projetos é menor no início e aumenta gradativamente
ao longo do projeto. Na figura 02 é possível ver tal variação.
Figura 02 – Impacto de variável com base no tempo do projeto
Fonte: PMI, 2013, p.40
6
De acordo com Rita (2009), para o gerenciamento nos pequenos projetos uti-
lizam-se os processos de iniciação, planejamento, execução, controle e monitora-
mente e encerramento. Todavia, em grandes projetos se faz necessária a divisão em
fases, onde o processo pode ser repetido diversas vezes. Portanto, a medida que
uma fase é realizada, executam-se todas as etapas do processo, desde a iniciação
até o encerramento. Após a finalização, passa-se para a fase seguinte e executa-se
o processo até o término de todas as fases.
Segundo o PMI (2013, p.42), “não existe uma estrutura ideal que pode ser a-
plicada a todos os projetos. Embora práticas comuns no setor normalmente levem à
utilização de uma estrutura preferida. Na figura 03 é apresentado um exemplo de
projeto com uma única fase”.
Figura 03 – Exemplo de projeto com fase única
Fonte: PMI, 2013, p.42
Conforme o PMI (2013), quando os projetos têm várias fases, estas são par-
tes, em geral, de um processo sequencial projetado para garantir um controle ade-
quado do projeto e obter o produto, serviço ou resultado desejado. Na figura 04 é
apresentado um projeto contendo mais de uma fase de forma sequencial.
7
Figura 04 – Exemplo de projeto com três fases
Fonte: PMI, 2013, p.43
2.2.1. Ciclo de vida iterativo e incremental
Segundo o PMI (2013, p.45), “Ciclos de vida iterativos e incrementais são a-
queles em que a fase do projeto (também chamada de iterações) intencionalmente
repete uma ou mais atividades de projeto à medida que a compreensão do produto
pela equipe do projeto aumenta.”
Ainda de acordo com o PMI (2013), é desenvolvida uma visão de alto nível
sobre o produto ou serviço. Contudo, o escopo é detalhado e elabora uma iteração
de cada vez, permitindo que ocorram diversas entregas e que se somadas resultam
na entrega total do projeto. Este tipo de ciclo é normalmente utilizado quando se tem
muitas mudanças no objetivo e escopo do projeto e quando as entregas realizadas
às partes interessadas por cada iteração são benéficas e geram valor ao negócio.
Para Cruz (2013, p.17), “o incremental vem exatamente do fato que, a cada
entrega (final da fase), o produto ganha mais um pedaço e vai crescendo e sendo
incrementado com mais valor, até que se torne um produto completo”.
2.2.2. Ciclo de vida adaptativo
Segundo Cruz (2013), o ciclo de vida adaptativo também é iterativo e incre-
mental, porém se diferencia pelo fato de possuir iterações bem mais rápidas com
tempo e custo fixo. O PMI da importância para este tipo de ciclo cada vez mais usu-
al. De acordo com o PMI (2013, p.46),”os métodos adaptativos geralmente são pre-
feridos quando se lida com um ambiente de rápida mutação, quando os requisitos e
escopo são difíceis de definir antecipadamente, e quando é possível definir peque-
nas melhorias incrementais que entregarão valor às partes interessadas.” Para o
8
PMI (2013), o intuito deste ciclo é manter as partes interessadas mais altamente in-
fluenciadas reduzindo assim o custo com mudanças.
2.3. Maturidade em gestão de projetos
De acordo com KERZNER (2007), todas as empresas atravessam o processo
de maturidade em gerenciamento de projetos e isto precede o estado da arte.
Existem fases do ciclo de vida para a maturidade em gestão de pro-jetos. Praticamente todas as empresas que alcançaram algum grau de maturidade passaram por estas fases. A cultura da organização e a natureza do negócio irão ditar o tempo gasto em cada uma delas. (KERZNER, 2007, p.45).
Na figura 05 são detalhadas as fases do ciclo de vida para a maturidade em
gestão de projetos.
Figura 05 – Ciclo de vida da maturidade
Fonte: KERZNER, 2007, p.45
Segundo Kerzner (2007 p.52), uma empresa que conclui de forma eficiente
todas as fases de maturidade está apta a responder com um “sim” as questões a
seguir:
Sua organização adotou um sistema de gestão de projetos e o utilizou?
Introduziu uma metodologia que conduziu ao sucesso em gestão de
projetos?
9
Assumiu o sério compromisso com o planejamento ao lançar cada no-
vo projeto?
Minimizou o número de mudanças de escopo mediante o comprometi-
mento com objetivos realistas?
Reconhece que controle de custo e controle de produção são insepa-
ráveis?
Escolheu as pessoas certas para a gestão de projetos?
Os executivos recebem informações em nível de promotor do projeto
em vez de aquelas destinadas aos gerentes de projetos?
Os executivos reforçaram o comprometimento dos gerentes de área e
deram verdadeiro apoio aos seus esforços?
A empresa da mais atenção aos resultados do que aos próprios recur-
sos?
Ela incentiva e recompensa a melhoria na comunicação, cooperação,
trabalho em equipe e confiança?
Os gerentes seniores costumam partilhar o reconhecimento por proje-
tos bem sucedidos com a equipe e com os gerentes de áreas?
A empresa tem por norma concentrar-se na identificação e correção
antecipada, rápida e econômica dos problemas?
Os participantes utilizam software de gestão de projetos mais como
uma ferramenta e não como um substituto do planejamento bem feito e
da comunicação interpessoal?
Sua empresa instituiu um programa de treinamento para todos os fun-
cionários baseado nas experiências aprendidas em projetos?
Ainda segundo Kerzner (2007), o que funciona bem para uma empresa pode
não funcionar bem a outra. As melhores práticas são desenvolvidas internamente
observando o que executou com sucesso e o que tem maior probabilidade de fun-
cionar bem no futuro se for repetido em vários projetos com diversos clientes.
10
3. Metodologia de Gerenciamento de Projetos
Segundo Xavier et al. (2014, p.163), “uma metodologia é apenas uma dimen-
são do que é necessário para aumentar a maturidade em gerenciamento de proje-
tos. Para tal, devemos: sistematizar o gerenciamento de projetos, programas e
portfólio, abordando as seguintes dimensões: pessoas (capacitação), processos
(metodologia), governança (estrutura política) e tecnologia (software)”.
3.1 PMBOK
O guia do PMI é uma referência na área de gerenciamento de projetos. Ele foi
desenvolvimento por voluntários e o seu conteúdo tem por objetivo ajudar as pesso-
as a gerenciarem projetos utilizando as boas práticas. Para Mogollon (2014), o guia
do PMI é uma ótima referência na gestão de projetos.
Um guia de boas práticas em gerenciamento de projetos é o PMI, pois, ele reúne processos, ferramentas, técnicas e artefatos. Em mui-tos anos tem mostrado a sua eficiência no sucesso de um projeto. Além disto, o PMI conta com uma base de vocabulário que permite o intercambio e a troca de experiência entre os gerentes de projetos que praticam este gerenciamento. (MOGOLLON, 2014)
O PMI possui cinco grupos de processos que abrangem dez áreas de conhe-
cimento. A partir desta união o PMI 5ª edição apresenta 47 processos que são suge-
ridos no gerenciamento de um projeto desde o seu início até o seu encerramento.
De acordo com Cruz (2013, p.22 e 23), de forma resumida as 10 áreas de co-
nhecimento do Guia PMI são:
Gerenciamento da integração do projeto:
É a área para consolidar, articular e integrar desde o início do projeto
até o seu final, gerenciando proativamente as expectativas das partes
interessadas e contribuindo para atender os requisitos do negócio.
Gerenciamento do escopo do projeto:
É a are que controla o que está e ou não incluído no projeto.
Gerenciamento do tempo do projeto:
11
É a área destinada a controlar o cronograma do projeto, bem como os
esforços necessários para realizar os trabalhos do mesmo, desde o i-
nício até o final das atividades.
Gerenciamento de custo do projeto:
Inclui atividades para controlar estimativas, orçamentos e custos do
projeto.
Gerenciamento de qualidade do projeto:
É a principal área para contribuição da melhoria contínua de procedi-
mentos, metodologias e políticas envolvidas com a realização e o ge-
renciamento de projetos.
Gerenciamento dos recursos humanos do projeto:
Inclui as atividades que organizam e gerenciam a equipe do projeto.
Gerenciamento das comunicações do projeto:
É uma das áreas mais importantes, pois, o gerente de projetos investe
maior parte do seu tempo na comunicação com os membros da equipe
e outras partes interessadas no projeto, tanto internas quanto externas
a organização.
Gerenciamento de riscos do projeto:
É a principal área e maior responsável por aumentar a probabilidade e
o impacto dos eventos positivos, conhecidos como oportunidades, e
por reduzir a probabilidade e o impacto dos eventos negativos no proje-
to.
Gerenciamento das aquisições do projeto:
É a área responsável por gerenciar e monitorar os contratos do projeto.
Gerenciamento das partes interessadas do projeto:
É a área responsável por manter um diálogo contínuo com os stake-
holders do projeto para atingir suas necessidades e expectativas.
A figura 06 ilustra as áreas de conhecimento, os grupos de processo e os 47
processos existentes no guia PMI.
12
Figura 06 – Grupo de processos de gerenciamento de projetos e mapeamento das áreas de
conhecimento
Fonte: PMI, 2013, p.61
13
Para Cruz (2013), o guia PMI é flexível e muito adaptável, pois, o uso dos
processos varia de projeto para projeto, considerando tamanho, complexidade, ex-
tensão, valor e outras variáveis mensuráveis. Contudo, sua aplicação não é simples
e depende de fatores como experiência da equipe e metodologia utilizada.
3.2 SCRUM
O SCRUM é um framework para gerenciamento de projetos que é muito util i-
zado na área de desenvolvimento de software. Todavia, ele é indicado principalmen-
te para o desenvolvimento de qualquer produto, pois, é um framework iterativo e
incremental. De acordo com Cruz, (2013, p.31), “os projetos são divididos em ciclos
repetitivos (iterativos) e curtos, para que possam ser modificados e adaptados para
corrigir os desvios (incrementais). Estes ciclos podem durar de duas a quatro sema-
nas e são chamados de sprints”. Na figura 07 é possível observar o ciclo clássico do
SCRUM.
Figura 07 – Ciclo de desenvolvimento do SCRUM
Fonte: Alan Braz, 2015
14
Para os criadores do SCRUM, Schwaber e Sutherland (2013, p.3),” o SCRUM
é um framework dentro do qual as pessoas podem tratar e resolver problemas com-
plexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o
mais alto valor possível”. Ainda de acordo com Schwaber e Sutherland (2013), o
SCRUM é definido como um framework leve, simples de entender e extremamente
difícil de dominar. Consistem nos times do SCRUM associados a papéis, eventos,
artefatos e regras.
O SCRUM é fundamentado nas teorias empíricas. Schwaber e Sutherland
(2013) afirmam que
o conhecimento vem da experiência e de tomada de decisões base-adas no que é conhecido. O SCRUM emprega uma abordagem itera-tiva e incremental para aperfeiçoar a previsibilidade e o controle de
riscos. (SCHWABER; SUTHERLAND, 2013, p.4).
De acordo com Schwaber e Sutherland (2013, p.4), três pilares apoiam o con-
trole de processos empírico: transparência, inspeção e adaptação.
Transparência: Aspectos significativos devem estar visíveis aos res-
ponsáveis pelos resultados. Esta transparência requer aspectos defini-
dos por um padrão comum para que os observadores compartilhem um
mesmo entendimento do que está sendo visto;
Inspeção: Os usuários SCRUM devem, frequentemente, verificar os ar-
tefatos SCRUM e o progresso em direção a detectar variações. Esta
inspeção não deve, no entanto, ser tão frequente que atrapalhe a pró-
pria execução das tarefas;
Adaptação: Se um inspetor determina que um ou mais aspectos de um
processo desviou para fora dos limites aceitáveis, e que o produto re-
sultado será inaceitável, o processo ou o material sendo produzido de-
ve ser ajustado;
O time SCRUM é composto por: product owner, time de desenvolvimento e
scrum master. Segundo Schwaber e Sutherland (2013), o produtct owner é o res-
ponsável por maximizar o valor do produto ou do trabalho. Ele gerencia o backlog do
produto e tem a visão geral do produto a ser concebido. O time de desenvolvimento
é composto por pessoas auto-organizadas e responsáveis por transformar o backlog
do produto em incrementos de funcionalidades potencialmente utilizáveis. O SCRUM
15
master é o responsável por garantir que o SCRUM seja entendido e executado. A-
lém disso, ele trabalha para o time de desenvolvimento ajudando a remover impedi-
mentos e para o product owner encontrar técnicas de facilitação no gerenciamento
efetivo do backlog do produto.
De acordo com Schwaber e Sutherland (2013), há eventos e artefatos no
SCRUM usados para criar uma rotina, minimizar a necessidade de reuniões não
planejadas e fornecer transparência e oportunidades para inspeção e adaptação. Os
eventos e artefatos são listados no quadro 01.
Quadro 01 – Eventos e Artefatos do SCRUM
Eventos e Artefatos
SCRUM Propósito Regras
Sprint
Time-boxed de 1 mês ou
menos, durante o qual um
pronto versão incremental
potencialmente utilizável do
produto, é criado
Não são feitas mudanças que possam
por em perigo o objetivo da Sprint;
As metas de qualidade não diminu-
em;
O escopo pode ser clarificado e rene-
gociado entre o Product Owner e o
Time de Desenvolvimento quanto
mais for aprendido.
Reunião de planeja-
mento
O trabalho a ser realizado na
Sprint é planejado na reunião
de planejamento da Sprint.
Este plano é criado com o
trabalho colaborativo de todo
o Time SCRUM
Responde as seguintes questões:
Qual o objetivo da sprint?
O que pode ser entregue como re-
sultado do incremento da próxima
sprint;
Como o trabalho necessário para
entregar o incremento será reali-
zado?
Reunião Diária
A Reunião Diária do SCRUM
é um evento time-boxed de
15 minutos, para que o Time
de Desenvolvimento possa
sincronizar as atividades e
criar um plano para as pró-
ximas 24 horas. Esta reunião
é feita para inspecionar o
Durante a reunião os membros do Time de
Desenvolvimento esclarecem:
O que eu fiz ontem que ajudou o
Time de Desenvolvimento a aten-
der a meta da Sprint?
O que eu farei hoje para ajudar o
Time de Desenvolvimento atender
a meta da Sprint?
16
trabalho desde a última reu-
nião diária, e prever o traba-
lho que deverá ser feito
antes da próxima reunião di-
ária
Eu vejo algum obstáculo que im-
peça a mim ou o Time de Desen-
volvimento no atendimento da
meta da sprint
Revisão da Sprint
A revisão da sprint é execu-
tada no final da sprint para
inspecionar o incremento e
adaptar o Backlog do Produ-
to se necessário.
A reunião de revisão inclui os seguintes
elementos:
Os participantes incluem o Time
SCRUM e os Stakeholders chaves
convidados pelo Product Owner;
O Product Owner esclarece quais
itens do Backlog do produto foram
“Prontos” e quais não foram “Pron-
tos”;
O Product Owner discute o Bac-
klog do Produto tal como está. Ele
(ou ela) projeta as prováveis datas
de conclusão baseado no progres-
so até a data (se necessário);
O grupo todo colabora sobre o que
fazer a seguir, e é assim que a
Reunião de Revisão da Sprint for-
nece valiosas entradas para a Re-
união de Planejamento da próxima
Sprint;
Retrospectiva da Sprint
A retrospectiva da sprint é
uma oportunidade para o
Time SCRUM inspecionar a
si próprio e criar um plano
para melhorias a serem apli-
cadas na próxima Sprint
O propósito da retrospectiva da sprint é:
Inspecionar como a última Sprint
foi em relação às pessoas, aos re-
lacionamentos, aos
processos e às ferramentas;
Identificar e ordenar os principais
itens que foram bem e as potenci-
ais melhorias;
Criar um plano para implementar
melhorias no modo que o Time
SCRUM faz seu trabalho
17
Backlog do produto O Backlog do Produto é uma
lista ordenada de tudo que
deve ser necessário no pro-
duto, e é uma origem única
dos requisitos para qualquer
mudança a ser feita no pro-
duto
O Backlog do Produto lista todas as carac-
terísticas, funções, requisitos, melhorias e
correções que formam as mudanças que
devem ser feitas no produto nas futuras
versões. Os itens do Backlog do Produto
possuem os atributos de descrição, ordem,
estimativa e valor.
Backlog da sprint
O Backlog da Sprint é um
conjunto de itens do Backlog
do Produto selecionados pa-
ra a Sprint, juntamente com
o plano para entregar o in-
cremento do produto e atingir
o objetivo da Sprint.
Conforme o trabalho é realizado ou com-
pletado, a estimativa do trabalho restante é
atualizada. Quando elementos do plano
são considerados desnecessários, eles
são removidos. Somente o Time de De-
senvolvimento pode alterar o Backlog da
Sprint durante a
Sprint. O Backlog da Sprint é altamente vi-
sível, uma imagem em tempo real do tra-
balho que o Time de Desenvolvimento
planeja completar durante a Sprint, e per-
tence exclusivamente ao Time de Desen-
volvimento.
História de usuário Identificar requisitos de ma-
neira simples.
Utilizar informações como: Quem? O que?
Aonde?
Ex.: Como um [ator] eu quero [ação] para
[funcionalidade].
Fonte: Schwaber e Sutherland, 2013, p.12 a 15 (adaptado)
4 UNINDO PMBOK X SCRUM
De acordo com CRUZ (2013, p.46), “o objetivo principal entre o SCRUM e o
guia do PMI é evidenciar de uma forma que se torne natural como uma etapa de um
pode se encaixar em uma fase de outro, sem forçar a barra”. O SCRUM pode ser a-
plicado a qualquer projeto que busque o gerenciamento ágil, desde que ele seja a
engrenagem principal.
18
4.1 Iniciação e planejamento
Segundo Cruz (2013), no primeiro momento é importante a utilização dos pro-
cessos do guia PMI para iniciar um projeto. Os clientes não abrem mão de uma for-
malização inicial, principalmente projetos grandes e complexos. Para isso são
utilizadas técnicas descritas no PMI, tais como:
o TAP (Termo de Abertura do Projeto);
o Identificação das partes interessadas;
o Desenvolvimento do plano do projeto;
o Criação do plano de gerenciamento comunicação;
o Criação do plano de gerenciamento de riscos;
o Criação do plano de gerenciamento qualidade;
o Criação do plano de gerenciamento aquisições;
o Criação do plano de gerenciamento das partes interessadas;
o Criação do plano de gerenciamento do escopo.
Vale ressaltar que os papéis do gerente de projetos, product owner, scrum
master e time de desenvolvimento participam desta fase inicial de planejamento do
projeto e utilizam técnicas do SCRUM, principalmente no plano de comunicação,
como por exemplo, a utilização no projeto do quadro kanban, a realização dos even-
tos de revisão e retrospectiva e a proximidade da equipe para interações de desen-
volvimento do projeto.
De acordo com Cruz (2013), o product owner realiza o levantamento das his-
tórias com os clientes, com o objetivo de coletar e definir o escopo do projeto. Neste
primeiro momento o importante é detalhar as histórias das sprints mais próximas e
que mais geram valor ao cliente. Os pacotes de trabalho levantados fornecem insu-
mos para a criação da EAP (Estrutura Analítica do Projeto), que é uma das ferra-
mentas gráficas mais utilizadas para visualização dos entregáveis do projeto.
Ao final deste levantamento, é definido o time e a quantidade de sprints ne-
cessárias para a execução do trabalho e utilizam-se os processos da área de geren-
ciamento de recursos humanos do PMI. Por fim é gerado o backlog e apresentado
as entregas à equipe do projeto. Na figura 08 é demonstrado o processo de levan-
tamento do escopo.
19
Figura 08 – Processo de levantamento do escopo
Fonte: Criado pelo autor
4.2 Execução
Para Schwaber e Sutherland (2013), após apresentar o backlog do produto ao
time, é priorizada a sprint inicial, preparado o ambiente e definido o conceito de pron-
to. Esse último é uma combinação para esclarecer de fato o que é considerado pron-
to para a equipe do projeto na conclusão de uma história. O product owner
apresenta para o time o backlog contendo as histórias priorizadas referente às pró-
ximas entregas. Cabe ao time realizar a estimativa de esforço necessário para con-
clusão destas histórias, comprometendo-se com as entregas e ao final quebrar as
histórias em tarefas menores e mais fáceis de serem desenvolvidas.
De acordo com Cruz (2013), para gerenciar as entregas do projeto é sugerido
o detalhamento do cronograma definido no quadro 02.
Id. Cronograma Data inicial Data Final
01 Reuniões de detalhamento de requisitos (itens de backlog)
realizados antes da Sprint para definição do escopo
DD/MM/AAAA DD/MM/AAAA
02 Período de aprovação do escopo pelo cliente DD/MM/AAAA DD/MM/AAAA
03 Próxima Sprint (História1, História 2, História 3) DD/MM/AAAA DD/MM/AAAA
04 Finalização da Sprint DD/MM/AAAA DD/MM/AAAA
05 Reunião de revisão da sprint com o cliente DD/MM/AAAA DD/MM/AAAA
06 Período de testes de validação e aceite do cliente DD/MM/AAAA DD/MM/AAAA
07 Período de entrega do produto validado e aceito DD/MM/AAAA DD/MM/AAAA
Fonte: Cruz, 2013, p.26 (adaptado)
20
Segundo Cruz, (2013), a execução da sprint consiste em utilizar um quadro
de tarefas, inserindo as histórias na primeira coluna, as tarefas na segunda, seguido
pelas colunas: a fazer, fazendo e feito. Os integrantes do time pegam as tarefas lo-
calizadas na coluna a fazer e as colocam na coluna fazendo. Assim que todas as a-
tividades forem concluídas, elas devem ser movidas para a coluna feito. Ao final da
sprint o objetivo é ter todas as tarefas de todas as histórias posicionadas na coluna
feito. Na figura 09 é possível visualizar o quadro de tarefas.
Figura 09 – Quadro de Tarefas
Fonte: Cruz, 2013, p.218
4.3 Monitoramento
De acordo com o guia do PMI (2013), o monitoramente contínuo do projeto
deve fornecer a equipe do projeto uma compreensão clara da saúde do mesmo.
Cruz (2013) destaca que o SCRUM sugere que o quadro de tarefas seja atualizado
diariamente. Além disso, a reunião diária de 15 minutos proporciona ao time uma
21
inspeção de progresso na direção da meta da sprint. Uma forma de monitoramento
importante do projeto é a reunião de retrospectiva.
Segundo Cruz (2013), a reunião de retrospectiva da sprint permite:
o Registrar lições aprendidas;
o Gerar painel de maturidade organizacional;
o Atualização do painel de controle;
o Reportar o desempenho;
o Monitorar e controlar os riscos.
4.4 Encerramento
Segundo Cruz (2013), nesta abordagem de gerenciamento unificado a fase é re-
lacionada às entregas. O encerramento de uma fase consiste na entrega de uma
versão planejada, como por exemplo, o término de 4 sprints que pode resultar em
uma entrega do produto real para o cliente de forma que gere valor para o mesmo.
Para Cruz (2013), o encerramento de uma fase geralmente compreende os proces-
sos de:
o Entrega de valor;
o Acompanhamento e orientação da homologação da entrega;
o Controle da qualidade;
o Atualização do painel de controle com o quadro de tarefas (kanban);
o Validação do escopo;
o Gerenciamento de mudanças;
o Controle de aquisições.
Cruz (2013) cita que na fase de homologação o cliente pode identificar mudanças
no projeto. Estas mudanças precisam ser aprovadas pelo comitê de mudanças e en-
tram no escopo da próxima entrega a ser realizada.
Ainda de acordo com Cruz (2013), o encerramento do projeto ocorre quando to-
das as fases forem encerradas e a documentação do projeto for preenchida. Para
projetos com apoio de fornecedores, é importante que os contratos sejam encerra-
dos.
22
3 CONCLUSÃO
O estudo realizado ao longo deste trabalho permite demonstrar que a união do
método tradicional e ágil busca um único objetivo que é o de atender os requisitos
de negócio e qualidade solicitados pelo cliente. Os processos das áreas de conhe-
cimento presente no guia do PMI encaixam perfeitamente nos eventos, artefatos,
papéis e responsabilidades do SCRUM. As ferramentas aqui listadas são técnicas
que podem auxiliar a organização no sucesso do projeto.
Para definir uma metodologia a ser adotada no gerenciamento de projetos é im-
prescindível conhecer os ativos organizacionais de uma empresa. A maturidade é
também extremamente importante para aplicação da metodologia. O que foi desen-
volvido neste trabalho é uma sugestão de utilização. Cabe a organização identificar
o que é melhor pra ela lembrando que o mais importante é a geração de valor para o
cliente.
23
Referências
PROJECT MANAGEMENT INSTITUTE (PMI). Um guia do conhecimento em ge-
renciamento de projeto: PMBOK.Quinta Edição, Project Management Institute, Inc,
2013.
SCHWABER, Ken e SUTHERLAND Jeff. Guia do SCRUM. Um guia definitivo para o
SCRUM: as regras do jogo Disponível em: <http://www.fabiocruz.com.br/wp-
content/uploads/2013/09/SCRUM-Guide-Portuguese-BR2013.pdf>. Acesso em: 01
de mar 2015. Traduzido por Fábio Cruz, 2013
CRUZ, Fábio. SCRUM e PMBOK unidos no gerenciamento de projetos. Brasport,
2013.
KERZNER, H. Gestão de projetos [recurso eletrônico]: as melhores práticas. Dispo-
nível em:
<https://books.google.com.br/books?id=Xe3yFG_81_UC&printsec=frontcover&dq=ke
rzner&hl=pt-
BR&sa=X&ei=VsyMVKuzCJPHsQTS74LIAw&ved=0CCEQ6AEwAA#v=onepage&q&f
=false>. Acesso em: 13 dez. 2014, segunda edição, 2007.
XAVIER, Magno da Silva et al. Metodologia de gestão de projetos Methodware. Dis-
ponível em:
https://books.google.com.br/books?id=FwCoAgAAQBAJ&printsec=frontcover&dq=m
etodologias+de+gerenciamento+de+projetos&hl=pt-
BR&sa=X&ei=9tPrVMfEMfHLsASh9IGQDQ&redir_esc=y#v=onepage&q=metodologi
as%20de%20gerenciamento%20de%20projetos&f=false. Acesso em: 23 fev. 2015,
terceira edição, 2014.
BRAZ, Alan. Precisa-se de Projetos Scrum pra Estudo de Caso. Disponível em:
<https://alanbraz.wordpress.com/2011/05/17/precisa-se-de-projetos-scrum/>.Acesso
em: 07 dez. 2015.
24
MOGOLLON, Miguel Eduardo, As metodologias ágeis no framework do PMBOK. Um
guia para PMP’s,Disponível em:http://blog.octo.com/pt-br/as-metodologias-ageis-no-
framework-do-pmbok/>. Acesso em: 01 out. 2014.
MULCAHY, Rita PMP. Preparatório para o exame de PMP, 7. ed. São Paulo:
RMC Publications, inc, 2011.
