Sie sind auf Seite 1von 52

GERENCIAMENTO GIL DE

PROJETOS COM SCRUM + PMBOK

Sumrio
Introduo

Scrum +PMBOK

Ciclo de vida Scrum + Guia PMBOK

10

O Scrum como engrenagem para encaixar o Guia PMBOK

13

Ciclo de vida Scrum

16

Incio do projeto

18

Rodando o Scrum

25

Backlog do Produto

27

Implementando Ferramentas e Prticas Adequadas

42

Concluso

46

Introduo
As ideias do Fbio Cruz sobre como gerenciar projetos geis com PMBOK tm
ajudado organizaes a ter uma estrutura de gesto de projeto que permite alcanar
resultados positivos no que diz respeito a satisfao do cliente e ao aumento de
produtividade. Buscamos seguir esse princpio bsico na Project Builder, promovendo-o
para nossos leitores e clientes.
O Manifesto gil foi escrito h mais de 10 anos, o que tempo suciente para ter
passado por vrios ciclos completos de desenvolvimento e aperfeioamento. A agilidade
tornou-se uma indstria em si mesma e deu origem a vrias sub-metodologias que
foram aderidas aos princpios do manifesto original.
Este e-book mostra como unir as boas prticas do Guia PMBOK ao Framework
Scrum, baseado nos conceitos do livro Scrum e PMBOK unidos no gerenciamento
de projetos

Esse movimento vai muito alm de s colar post its na parede e fazer reunies em
p - prtica que todas as empresas deveriam adotar. Ele implica em investir de forma
proativa e inteligente no sucesso da sua rea de projeto, combinando desenvolvimento
gil com uma gesto de portflio, e mtricas importantssimas como atingimento de
metas, aumento da receita, reduo de custos e evoluo da maturidade em gesto
de projetos - que agora podem ser medidas de forma clara - o que contribuir para
alavancar o aumento de faturamento e produtividade de todo o time.
Temos aqui na Project Builder uma tima experincia com esse processo, inclusive
combinando-o com metodologias de planejamento como o Project Model Canvas.
Espero que este e-book seja uma inspirao para que voc comece a pensar
em gerenciar seus projetos de forma gil.
Aproveite o contedo!
Thiago Reis
Diretor de Sucesso do Cliente

Scrum + PMBOK

Para um entendimento mais simplicado de como a unio proposta por este


e-book possvel, preciso relembrar que o Guia PMBOK possui inmeros processos
que abrangem todo o ciclo de vida de um projeto e suas fases. Todo o projeto,
incluindo todas as fases entre a iniciao e o encerramento, coberto pelo Guia
PMBOK, sendo que vrios processos podem ser aplicados em diversos nveis de
profundidade, podendo tambm ser realizados em etapas distintas e sequncias
alternadas, de acordo com cada projeto.
Assim, o Guia PMBOK sugere tudo que pode ser realizado para gerenciar um
projeto do incio ao m, mas no diz como isso pode ser feito e - algumas vezes no muito claro na denio dos momentos ideais para cada aplicao.

Exemplo:
A fase de planejamento longa e com inmeros trabalhos a realizar, desde a
denio de escopo com o detalhamento de requisitos at a identicao dos riscos, o
planejamento da qualidade e das aquisies. Apenas analisando essas reas de conhecimento
mencionadas possvel vericar o surgimento de algumas dvidas preliminares, tais
como:
1. Qual o planejamento que deve ser feito primeiro: requisitos ou riscos?
2. Em qual momento cada planejamento deve ser disparado ou nalizado?
3. Como os planejamentos se afetam e como eles so executados dentro do ciclo de
vida do projeto?

4. Como a ordem de cada planejamento, a frequncia ou as repeties do uso de


cada um podem se modicar quando se usa Ondas Sucessivas funcionando como
iteraes menores e recorrentes.
Observando o exemplo anterior, possvel perceber que os processos so muitos, os
detalhes so muitas vezes vastos e a imensido de possibilidades se propaga com a
experincia de cada prossional e com a maturidade de cada time de projeto. O Guia
PMBOK pode ser completo na sua abrangncia e proposta de contedo gerencial,
porm no se prope a denir uma metodologia de aplicao de suas prprias boas
prticas.
Quando se olha apenas para o Guia PMBOK algumas questes preocupantes
podem pairar no ar, tais como:
Como executo parcialmente ou completamente todos os processos contidos no
Guia PMBOK?
Qual o momento certo de realizar cada um dos processos?
Com o objetivo de apoiar o ponto fraco do Guia PMBOK aqui mencionado, que
a ausncia de informaes sobre como fazer, sugerido o Scrum.
O Scrum no to abrangente e no to extenso quanto o Guia PMBOK, mas, por
outro lado, possui regras, cerimnias e sequenciamentos bem denidos para a aplicao
do seu contedo em gerenciamento de projetos. Devido a essas caractersticas e a
proposta de unio das duas abordagens apresentadas neste e-book, utilizaremos o
Scrum como perspectiva para analisar o processo como um todo.

Ciclo de vida Scrum + Guia PMBOK

A gura ilustra como as abordagens se encaixam de uma maneira natural, conectando-se


perfeitamente com o objetivo de unio dos pontos fortes com o intuito de diminuir as
fraquezas ou limitaes.

Reunio
Diria

Monitoramento
e Controle

a cada
24 horas
Ciclos de
monitoramento
e controle

Sprint

durao entre 2 e 4 semanas


( Ciclo de vida do projeto )

BackLog
do Protuto

Produto
Pronto

Iniciao
Planejamento

BackLog
da Sprint

Planejamento
da Sprint

Reunio de
Reviso

Execuo da
Sprint
(Construo do Protudo)

Execuo

Encerramento
Reunio de
Retrospectva
11

O Scrum como engrenagem


para encaixar o Guia PMBOK

Como a engrenagem principal e o ponto de partida da unio proposta,


pressupe-se que o Scrum pode ser aplicado a qualquer projeto que busque um
gerenciamento gil. No entanto, partindo tambm do pressuposto de que o Scrum
sozinho no pode resolver todos os problemas de todos os projetos, e que muitos
projetos no podem ser gerenciados 100% de forma gil do seu incio ao m (como
o Scrum prope), o Guia PMBOK sugerido como a principal ferramenta de
complementao e apoio ao Scrum.
Com a engrenagem do Scrum rodando e impulsionando o projeto, o gerenciamento
gil toma uma nova forma, sem perder a agilidade proposta pelo Scrum, e ganha
foras, ferramentas e tcnicas complementares oferecidas pelo Guia PMBOK
defendendo as seguintes regras:
1. No burocratizar.
2. No documentar excessivamente.
3. No realizar processos desnecessrios.
4. No acrescentar lentido ao Time Scrum e aos seus trabalhos.
5. No deixar o gerente de projetos como nico brao gerencial.
Para que isso seja possvel, a proposta aqui no denir uma receita de bolo para
a aplicao do Scrum juntamente com todos os 47 processos do Guia PMBOK
sempre, e em todos os projetos, mas sim permitir que as equipes que optem por utilizar
esta unio consigam identicar de forma natural os pontos de ligao entre as duas
abordagens de gerenciamento, podendo denir os processos que oferecem apoio ao
Scrum e em quais momentos dentro do ciclo do Scrum estes sero aplicados, de

14

acordo com cada projeto especco.


Assim, a proposta que, antes de ligar os motores e colocar a engrenagem do
Scrum para funcionar, a equipe analise em que pontos sero encaixados os processos
do Guia PMBOK e quais sero os processos utilizados para o projeto em questo.
A partir desse pressuposto, ao rodar o Scrum os processos do Guia PMBOK
selecionados sero disparados como ferramentas de apoio nos pontos que foram
pendurados, permitindo ainda que o time remova processos inicialmente escolhidos
e/ou pendure novos processos na engrenagem que j est rodando. Esta tcnica
simples de encaixar e desencaixar ligaes, como se fosse uma brincadeira de Lego,
possibilita um alto grau de adaptabilidade equipe e de exibilidade ao projeto, alm
de se tornar um processo vivo de melhoria contnua que ser alimentado durante
todo o projeto.

15

Ciclo de vida Scrum

H mais de uma abordagem para unio das tcnicas, ferramentas e papis do


Guia PMBOK com o Scrum. Porm, aqui partiremos do entendimento que o Scrum
mais simples e possui um ciclo menor e 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 trmino.
Reforando o entendimento, para um time comear a rodar o Scrum em um
projeto, atividades anteriores contidas no Guia PMBOK precisam ser realizadas.
Durante a execuo do Scrum e de suas vrias cerimnias, outras atividades do Guia
PMBOK devem ser aplicadas, e por m, aps o encerramento de um ciclo Scrum,
mais tarefas ligadas ao Guia PMBOK tambm podem ser utilizadas.
Ser possvel visualizar como fcil e benco unir estas duas prticas, principalmente
porque algumas das ferramentas e tcnicas do Guia PMBOK se encaixaro perfeitamente
dentro do ciclo Scrum, e outras faro total sentido fornecendo pleno apoio equipe
de gerenciamento quando utilizadas paralelamente ao Scrum.
a partir deste momento que o gerente de projetos entra em um ambiente gil,
sem interferir na execuo propriamente dita do Scrum, mas apoiando todas as
outras reas que o Scrum no suporta diretamente.

17

Incio do projeto

13

Mesmo em um ambiente gil preciso realizar algumas atividades formais,


principalmente para registrar certas passagens importantes do projeto, como a
ocializao do seu incio.
A maioria dos mdios e grandes clientes aceita bem a implantao de metodologias
geis, mas no abre mo de processos contidos no gerenciamento tradicional,
principalmente no que diz respeito a formalizaes, controles de alto nvel para viso
da gerncia snior, incluindo alternativas para garantir legalmente que certas aes
so realizadas e outras no. Por isso precisamos do apoio de boas prticas e
modelos mais tradicionais como o Guia PMBOK.
As primeiras formalizaes acontecem antes do incio do projeto, e continuam
durante a etapa de iniciao. Dessa maneira, abaixo comearemos a listar os processos
da fase de iniciao de um projeto, e desta mesma maneira continuaremos a listar
todos os processos que precisam ser realizados durante todo o projeto, separados
por etapa ou fases do projeto.
Todos os pontos de relacionamento e conexo entre o Scrum o Guia PMBOK
sero marcados aqui atravs de legendas de sugesto de uso, ou seja, nenhuma
ligao entre o framework gil do Scrum e as boas prticas do Guia PMBOK ser
obrigatria, mas sugerida como forma de aplicao conjunta para melhorar e trazer
benefcios toda a equipe do projeto.

20

Descrio das legendas:


[GP]: atividades a serem realizadas pelo Gerente de Projetos, segundo a viso do Guia
PMBOK.
[PO]: Atividades a serem realizadas pelo Product Owner, segundo a viso do Scrum.
[SM]: atividades a serem realizadas pelo Scrummaster, segundo a viso do Scrum.
[TM]: atividades a serem realizadas pelo Time, segundo a viso combinada do Scrum e
do Guia PMBOK.
[1..42]: Para referncia, ser colocado ao lado dos nomes dos processos do Guia
PMBOK um nmero para identicar que o processo pertence ao Guia PMBOK e no
ao Scrum, e para fornecer uma informao de quantos processos do Guia PMBOK
conseguem ser aplicados de forma conjunta ao Scrum.

21

Termo de Abertura do Projeto:


O termo de abertura do projeto formaliza ocialmente o incio do mesmo,
permitindo e liberando a equipe para comear os trabalhos, e independente do ambiente
do projeto, altamente recomendvel se publicar um termo de abertura do projeto que
contenha pelo menos o seguinte contedo:
1. Propsito ou justicativa do projeto;
2. Requisitos de alto nvel;
3. Riscos de alto nvel;
4. Resumo do cronograma de marcos;
5. Resumo do oramento;
6. Requisitos para aprovao do projeto e quem responsvel por decidir se o projeto
bem sucedido ou no;
7. Gerente do projeto, responsabilidade, nvel de autoridade e designados;
8. Nome e autoridade do patrocinador que autoriza o termo de abertura.
Responsvel por esta realizao: [GP]

Identicao dos Stakeholders :


Ao iniciar um projeto, a primeira coisa que se deve fazer identicar todas as partes
interessadas, porque a maioria destas pessoas ou organizaes sero as responsveis
por fornecer as informaes para que o projeto possa ser realizado, alm de serem

22

tambm os Stakeholders que vo aprovar e usar o produto do projeto.


Lembrando que as partes interessadas podem inuenciar o projeto 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.
Responsvel por esta realizao: [GP] / [PO].

Note que este o primeiro momento em que os papis de Gerente de Projetos,


seguindo o conceito do Guia PMBOK, e o Product Owner, segundo o Scrum, trabalham
juntos em uma mesma atividade.

Desenvolver o plano de gerenciamento do projeto:


Este um importante documento para nortear todos os trabalhos de gerenciamento
de projeto, e tambm para formalizar como o projeto ser conduzido em todas as suas
etapas.
altamente recomendvel se publicar o plano de projeto para todas as partes
interessadas, e que contenha pelo menos o seguinte contedo:
1. O ciclo de vida do projeto e os processos que sero aplicados em cada fase;
2. Como o trabalho ser executado para completar os objetivos do projeto;

23

3. Como sero gerenciadas as mudanas no projeto;


4. Como sero gerenciadas as conguraes do projeto;
5. Como sero gerenciados os requisitos do projeto;
6. O que ser feito para manter a integridade das linhas de base do projeto;
7. Quais as necessidades para as comunicaes entre as partes interessadas.
Juntamente com o desenvolvimento do plano de gerenciamento do projeto, o Gerente
de Projetos, o Product Owner e o Scrum Master podem realizar tambm as atividades
contidas nos seguintes processos:
1. Planejar as comunicaes;
2. Planejar o gerenciamento dos riscos;
3. Planejar a qualidade;
4. Planejar as aquisies.
Frisando que todos estes planejamentos podem incluir as atividades geis que proporcionam
comunicar, gerenciar os riscos, controlar a qualidade e prever as aquisies para o
projeto.
Responsvel por esta realizao: [GP] / [PO] / [SM]

24

Rodando o Scrum

13

Realizando as primeiras atividades formais e externas ao Scrum, o gerente de


projetos e a equipe do projeto formada pelos papis do Scrum podem iniciar
a execuo do projeto pela tica do mesmo, o que vamos chamar aqui de
colocando o Scrum para rodar.
Ao colocarmos o Scrum para rodar, estamos ao mesmo tempo trabalhando na
execuo do projeto, dando continuidade a atividades de planejamento, realizando
testes, entregas e outras etapas. Tudo ao seu tempo, mas devido ao ambiente gil, de
uma forma mais dinmica, mais breve e mais recorrente seguindo um estilo de ciclos.
Estes ciclos combinam muito com o conceito de Planejamento por Ondas
Sucessivas, que o Guia PMBOK sugere, ou seja, o projeto ser dividido em vrias
fases de acordo com a entrega de valor acordada com o cliente. Com isso temos
nada mais nada menos do que as Sprints do Scrum atuando como as fases das Ondas
Sucessivas do Guia PMBOK.
Nesta combinao dada, por exemplo, o Guia PMBOK sugere a aplicao das
Ondas Sucessivas para evitar que o projeto seja todo planejado primeiro, depois todo
executado, e depois todo testado e aceito. No entanto, o Guia no diz explicitamente
como a equipe do projeto deve fazer isso. Ento por que no podemos assumir que
as Ondas Sucessivas sero as Sprints de trs semanas? Em resumo, no h porqu
no ser.

26

Backlog do Produto

13

Quando falamos de Sprint, logo pensamos no seu planejamento, onde so denidos,


estimados e separados os itens do Backlog do Produto que sero transformados em
funcionalidade, ou seja, completados dentro da prxima Sprint para entrega ao
cliente. No entanto, antes disso preciso se planejar e se preparar para a Sprint.
Alguns esquecem que para se trabalhar nos itens, preciso antes colet-los, analis-los,
entend-los e detalh-los.
neste ponto que os processos do Guia PMBOK podem orientar e ajudar a
equipe de gerenciamento do projeto, principalmente porque preciso ter um
mnimo de organizao e controle sobre os trabalhos de gerenciamento de requisitos.
O Backlog do Produto so os requisitos do projeto para o Scrum.
Para que o time Scrum possa trabalhar no Backlog do Produto e transform-lo
em funcionalidades prontas e potencialmente entregveis, preciso que se
tenham detalhes sucientes sobre os itens do Backlog, e para isso necessrio realizar
algumas etapas descritas no Guia PMBOK.
Responsvel pelo Backlog: [GP] / [PO]

A regra do Scrum que determina que o nico responsvel pelo Backlog do


Produto o PO deve ser respeitada. O GP entra aqui para controlar e acompanhar
como as atividades no Backlog do Produto esto sendo executadas em comparao
com todos os trabalhos do projeto, alm de dar suporte e facilitar as tarefas do PO.

28

Coletar os requisitos:
um processo obrigatrio para se poder aplicar o Scrum, e onde o Product
Owner procura os Stakeholders e identica todos os requisitos necessrios para se
entregar o projeto. Neste processo a principal atividade a elicitao de requisitos,
que pode ser complementada pelo documento conhecido como Matriz de
Rastreabilidade de Requisitos.
Responsvel por esta realizao: [PO]

Denir o escopo:
Ao se coletar os requisitos, o processo automaticamente posterior e de igual
importncia o detalhamento destes requisitos, obtendo-se o escopo detalhado que
o produto deve atender ao nal do projeto, ou no momento da entrega. Este
processo conhecido pelo Guia PMBOK como denir o escopo. J para o Scrum,
denir o escopo nada mais do que o detalhamento dos requisitos que vo formar o
Backlog do produto.
Ao denir o escopo, o PO ter material e entendimento para gerar as Estrias,
que so artefatos bem conhecidos pelo Scrum. Alm deste objeto, o PO poder
aprontar prottipos de tela para descrever o formato e as aes do sistema de forma

29

visual, e documentos de apoio com as denies de regras de negcio.


As regras de negcio merecem um comentrio a mais, que se refere sugesto
de que altamente recomendvel se registrar e conrmar todas as regras de negcio
do sistema, sem exceo, independente de estar usando o Scrum ou um mtodo
mais tradicional. Um bom documento para isso o conhecido Caso de Uso, oriundo
do modelo UML (Unied Modeling Language).
Responsvel por esta realizao: [PO]

Criar a EAP:
A EAP uma Estrutura Analtica do Projeto que tem a funo de mostrar
gracamente todo o escopo denido para o projeto, permitindo que o gerente
de projetos e a equipe de gesto saibam visualmente todos os objetos que
precisam ser construdos, e hierarquicamente como eles esto distribudos.
uma tima ferramenta para acompanhamento, e funciona muito bem para o
time no se esquecer de construir nada. Uma tima dica para se desenvolver
facilmente uma EAP nesta metodologia mista usar o conceito dos pacotes de
trabalho da EAP quando estiver denindo as estrias, principalmente no que
tange a granularidade. Com isso o esforo para construir a EAP ser apenas de
colocar as estrias em formato visual e seguindo os padres estruturais da EAP.

30

Responsvel por esta realizao: [GP] / [PO]

O PO fornece apoio para o GP montar a EAP e entender os pacotes de trabalho.

Denio do time Scrum


Este um processo que para no infringir as regras do Scrum, a sugesto ideal
que ele seja realizado apenas uma vez, na primeira Onda, ou seja, na preparao
da primeira Sprint.
Esta uma observao importante, porque para que o Time Scrum consiga
realizar um auto-gerenciamento, uma auto-monitorao, um auto-controle e
principalmente uma auto-melhoria constante, preciso que o Time se mantenha
do mesmo tamanho e com os mesmos integrantes.
Porm, projetos no so estveis, e nem sempre possvel garantir que isso
seja mantido, ento em casos de necessidade este processo pode ser realizado
novamente entre as iteraes.
Este processo o responsvel por estimar os recursos das atividades
conforme as estrias denidas, e determinar o tamanho do Time, o tamanho das
Sprints, e se ter a primeira ideia de quantas Sprints sero necessrias para
completar o trabalho do projeto. Para o Guia PMBOK este processo conhecido

31

como Estimar os recursos das atividades.


Juntamente com esta estimativa de recursos, o GP 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.
Responsvel por estas realizaes: [GP] / [PO]
O PO fornece apoio para o GP estimar os recursos e denir o plano de recursos
humanos.

Apresentao do Backlog do Produto


Aps o Product Owner preparar o Backlog do Produto, hora de apresent-lo
para o Time que ir transform-lo em funcionalidade(s) potencialmente
entregvel(is).
Lembrando que, de acordo com o projeto, este Backlog do Produto pode estar
completo, ou parcial, respeitando o planejamento em Ondas Sucessivas.
Contudo, geralmente, independente do Backlog do Produto estar completo ou

32

parcial, este o momento de denir o planejamento da prxima entrega, e como


as Sprints sero distribudas para completar todo o trabalho necessrio at l.
Em alguns projetos este planejamento da entrega denido em alto nvel na
iniciao do projeto, junto ao termo de abertura e ao plano de gerenciamento do
projeto, e aqui ele apenas detalhado e associado s funcionalidades especcas
que o compem e as estrias criadas.
Responsvel por apresentar o Backlog do Produto: [PO] / [TM]
Na apresentao do Backlog do Produto, o Product Owner, com apoio do
Gerente de Projeto, realiza as seguintes atividades junto com o Time:
Mobilizar a equipe do projeto:
Este o momento de ocializar a formao do Time Scrum com seus papis e
responsabilidades. Alm de ocializar para todo o Time qual o papel e importncia
do gerente de projeto atuando neste modelo misto.
Lembrando que a equipe foi estimada e seus papis e responsabilidades j
previstos no passo Denio do Time Scrum, e que neste processo a equipe ser
mobilizada e alocada ao projeto, apesar de poder haver pequenas alteraes na
sua congurao.
Responsvel por esta realizao: [PO] / [GP]

33

Planejar as aquisies:
Com o entendimento das estrias e a denio de seus tamanhos, o Time
realiza uma anlise conhecida como fazer ou comprar. Em outras palavras,
signica que de acordo com o tamanho e complexidade de uma estria, pode ser
mais interessante comprar uma soluo pronta que atenda plenamente o
requisito do cliente, do que constru-la em casa.
A participao do gerente de projetos opcional aqui, mas se torna
obrigatria caso haja a necessidade de realizar compras, pois ele que analisar
oramento do projeto e dar a palavra nal sobre a compra ou no.
Responsvel por esta realizao: [TM] / [PO] / [GP]

34

Identicar os Riscos:
Mais uma vez a atividade de entendimento das estrias se mostra
fundamental, pois com a limpeza do Backlog do Produto o Time Scrum
consegue identicar riscos, realizando o primeiro trabalho importante de
gerenciamento de riscos.
Responsvel por esta realizao: [TM] / [PO] / [GP ]

Gerenciamento de custos
Paralelamente aos trabalhos no Backlog do Produto, o Gerente de Projeto tem
condies de trabalhar no gerenciamento de custos e focar nos dois seguintes
processos:

Estimar custos:
Por m, ao se nalizar os trabalhos de entendimento do Backlog do Produto,
mobilizar o Time, denir a velocidade e as aquisies, o gerente de projeto consegue
estimar os custos da prxima entrega do projeto. De acordo com a diviso de fases
ou tamanho do projeto, ser possvel realizar esta estimativa para todo ele e no s
para a prxima etapa.

35

Tendo sempre como base todas as informaes fornecidas pelo Time, o GP poder
estimar o custo para cada atividade (ou estria).
Responsvel por esta realizao: [GP]

Determinar o oramento:
Juntamente com a estimativa de custos, o gerente de projeto determina o
oramento previsto para o projeto, ou para a prxima entrega. Este processo
importante para autorizar a realizao do projeto no mbito nanceiro, e publicar
como se daro as aprovaes peridicas.
Responsvel por esta realizao: [GP]

Planejar o gerenciamento de riscos:


Com as primeiras anlises e identicaes de risco realizadas ao limpar o Backlog
do Produto, o gerente de projetos pode realizar o primeiro trabalho formal de
planejamento do gerenciamento de riscos.
Montando um plano de gerenciamento de riscos, o GP poder apresentar a todos os

36

Stakeholders do projeto que riscos j foram identicados e principalmente como eles


sero tratados ao longo do projeto.
Responsvel por esta realizao: [GP] / [PO]
Neste caso o PO ser apenas um apoio para o GP, caso seja necessrio.

Planejamento da Sprint
Esta uma etapa que nem todos aplicam de forma independente, e alguns no a
vem como um passo distinto. O planejamento da Sprint uma cerimnia em que a
equipe deve planejar em conjunto todos os trabalhos da prxima Sprint, e deve ser
realizada completamente, ou seja, no se pode interromp-la antes de todos os itens
serem discutidos e plenamente entendidos.
Entretanto, a etapa 0 (zero) o momento de preparar o ambiente de trabalho
antes de iniciar a reunio de planejamento da Sprint, com o objetivo de evitar que
algo no planejado interra com a execuo da Sprint, e envolver o gerente do
projeto. Para a etapa 0 (zero) do planejamento da Sprint, os seguintes processos so
sugeridos:

37

Preparar o ambiente de trabalho


O primeiro passo aqui deixar tudo pronto para a Sprint ser rodada, ou seja,
infraestrutura incluindo equipamentos, sala, ferramentas, softwares e, principalmente,
conferir a disponibilidade da equipe e reuni-la.
Muitos realizam esta etapa de forma automtica e at mecnica, sem consider-la
no planejamento, mas como sugesto, bom t-la em mente para mitigar riscos.
Responsvel por esta realizao: [PO] / [GP] / [SM]

38

Denir o tamanho das Sprints


Esta pequena etapa j justica a criao e separao da etapa 0 de planejamento
da Sprint, porque esta denio valer para todas as Sprints e no apenas para a
prxima.
O tamanho das Sprints deve ser o mesmo para todo o projeto, porque este um
dos indicadores de desempenho e melhoria que o Scrum proporciona, e tambm um
dos mais importantes.
Com o resultado da preparao do ambiente, reunindo a equipe, adicionado a
identicao da velocidade do Time e os itens do Backlog da entrega que a equipe
precisar trabalhar, possvel determinar o tamanho das Sprints e o nmero de
Sprints que sero necessrias para completar o trabalho do Backlog.
Responsvel por esta realizao: [TM] / [PO] / [GP]

O Gerente de Projetos precisa ser includo neste momento de denio de


tamanho e nmero de Sprints, porque neste momento o projeto poder sofrer
alteraes de cronograma, e o GP ser necessrio para adequar o que o Time pode
entregar com os requisitos estratgicos do cliente.

39

Revisar os Riscos:
Este o momento de revisar os riscos j identicados, atualizando esta lista
conforme as etapas anteriores, e levando em conta os possveis impactos gerados
pela preparao do ambiente, denio da velocidade do Time e tamanho das
Sprints.
Se for necessrio, o GP j pode iniciar a execuo de processos como quanticar,
qualicar e planejar as respostas aos riscos.
Responsvel por esta realizao: [GP] / [TM] / [PO]

Planejamento da Sprint
A reunio de planejamento da Sprint deve ter oito horas de durao, porm o
formato mais usual a sua diviso em duas partes de quatro horas com objetivos
distintos. Na primeira metade da cerimnia, o objetivo decidir o que ser feito na
Sprint, sem desrespeitar o limite de tempo.
Para a etapa 1 do planejamento da Sprint, os seguintes processos so sugeridos:

40

Planejamento da Sprint
A meta da Sprint um objetivo claro que ser atingido atravs da implementao
do Backlog do Produto, e esta deve ser uma descrio que fornece orientao ao
Time sobre a razo pela qual est sendo desenvolvido o incremento.
Responsvel por esta realizao: [PO] / [GP]
Denir as atividades Parte 1 [19]:

Na primeira parte do trabalho de denir as atividades, o Time seleciona os itens


do Backlog do produto de acordo com a prioridade denida pelo PO e com a capacidade
do Time, denida anteriormente como velocidade.
Responsvel por esta realizao: [PO]

Entendimento do Backlog
Ao selecionar todos os itens que o Time ir trabalhar durante a Sprint, o mesmo
realiza o entendimento destes itens juntamente com o apoio do PO. O caminho mais
utilizado para isso quando o PO explica item a item ao Time, e este realiza todos os
questionamentos ao PO.
Responsvel por esta realizao: [PO] / [TM]

41

Implementando Ferramentas
e Prticas Adequadas

O gerenciamento gil de projetos se baseia na utilizao de um conjunto de


processos interrelacionados de gerenciamento de negcios, que facilita a tomada
de deciso e a realizao de investimentos.
A adoo de ferramentas e prticas deve auxiliar a execuo dos processos geis
e gerar maior conabilidade, assim como, otimizar operaes manuais.
Na ferramenta adotada deve ser possvel gerenciar projetos no s no modelo
tradicional, como tambm orientados a metodologias geis como Scrum e combina-los
aos processos de uma gesto integrada de portflio e os processos, de forma a gerar
benefcios claros organizao. Portanto, a seleo de prticas e ferramentas de
gerenciamento de portflios ser uma deciso estratgica.
Enquanto algumas empresas optam por acompanhar seus projetos com planilhas
eletrnicas ou softwares instalados localmente, outras j sabem que isso tem um
impacto muito signicativo no tempo investido na qualidade das informaes geradas
e, por este motivo, investem em uma soluo que faa esse trabalho de forma mais
prossional.
A nossa recomendao o Project Builder, uma criao nossa, que atende
desde os 20 maiores grupos econmicos do Brasil at pequenas empresas e
consultores individuais.
O Project Builder permite acompanhar, dentro de um nico ambiente, sua estrutura
organizacional, recursos humanos, seu portflio de projetos e seus projetos, de forma

44

muito simples. Com essa estrutura possvel gerar de forma dinmica relatrios que
evidenciam como est a gesto de projetos dentro das diferentes reas de negcios
da sua organizao. Tudo isso dentro de um ambiente colaborativo em que cada
recurso do projeto informa sua execuo, publicando documentos e automatizando
a comunicao.

45

Concluso
O objetivo deste e-book foi demonstrar como unir as boas prticas do Guia
PMBOK ao Framework Scrum, buscando o mesmo e nico objetivo de entregar um
produto de um projeto atendendo aos requisitos de qualidade. possvel observar
que apenas com a metade deste e-book, fcil observar que o Guia PMBOK e o
Scrum podem ser aplicados em conjunto e de forma complementar em projetos de
desenvolvimento de software na rea de tecnologia da informao. Simplesmente
isso se evidencia quando os projetos de desenvolvimento se mostram no serem
apenas projetos com uma nica equipe, voltada para construir cdigos sem ligao
com o mundo externo, mas sim, vrios Times multifuncionais, com diversas
responsabilidades, ligados a mais de uma empresa como parceiros, fornecedores,
contratada e contratante trabalhando em conjunto para entregar um nico produto.
preciso ter sempre em mente que por trs de um simples projeto de
desenvolvimento h custos, oramentos, contrataes, aquisies, formalidades e
ocializaes que so minimamente necessrias mesmo em pequenos projetos e
dentro de apenas uma empresa.

46

O Guia PMBOK fornece boas prticas para todas as reas de gerenciamento


envolvidas com projetos pequenos e grandes, mas em alguns momentos precisa de
uma contribuio mais gil, justamente para mostrar mais exibilidade em projetos
especcos ligados rea de tecnologia da informao, e neste momento que o
Scrum entra como apoio.
J o Scrum se fortalece cada vez mais no mercado de tecnologia, principalmente
na rea de desenvolvimento de software, onde sua aceitao cresce dia aps dia.
Entretanto, o Guia do Scrum, suas aplicaes e algumas bibliograas complementares
no fornecem suporte ao gerenciamento de reas como custo, aquisies, riscos e
recursos humanos, e neste momento que o Guia PMBOK entra como apoio.
Com isso, observa-se que ambas as abordagens so excelentes, mas no perfeitas,
e possuem fraquezas em reas especcas ou em determinados tipos de aplicaes
em projetos distintos. No entanto, quando aplicadas em conjunto, podem fortalecer
uma a outra, e juntas contriburem para a obteno do sucesso na realizao de
projetos ligados rea de tecnologia da informao. Esta no a melhor e muito
menos a nica sugesto de metodologia para aplicao destas duas abordagens em
conjunto.

47

Sobre o Fbio Cruz


Scio e consultor especialista em gerenciamento de projetos na FabioCruz.com
Com mais de 20 anos de experincia profissional, Fbio Cruz atuou sempre na rea
de pesquisa, desenvolvimento e implantao de sistemas empresarias e solues de
negcios em TI, passando por vrios papis, funes e responsabilidades ao longo
do ciclo de vida de projetos de desenvolvimento de sistemas. Nos ltimos 10 anos
se especializou em gerenciamento de projetos, se dedicando e investindo em
liderana de equipes e projetos, trabalhando com equipes multifuncionais
pequenas, mdias e grandes. Atualmente Fbio Cruz scio e consultor especialista
em gerenciamento de projetos na FabioCruz.com, onde combina Scrum, PMBOK,
PRINCE2 e modelos de maturidade, alm de atuar como professor em MBA,
Instrutor em treinamentos, capacitaes e Workshops, Voluntrio e VP de
Comunicaes no PMI-SC, Voluntrio na Scrum.org, palestrante, autor do livro
Scrum e PMBOK unidos no Gerenciamento de Projetos, e blogueiro em
FabioCruz.com, onde contribui para as boas prticas em gerenciamento de projetos
de maneira voluntria.
Fale com o Fbio: contato@fabiocruz.com

48

Sobre a Project Builder


H mais de 15 anos no mercado, a Project Builder tem como objetivo ajudar
empresas de diversos portesa entender e aproveitar os benefcios da Gesto de
Projetos,
conseguindo
assim
atingir
a
alta
performance
em seus negcios. Para isto, trabalhamos trs formas principais:
Nossa soluo, o Project Builder, foi testado e aprovado por milhares de
gerentes de projetos e, por isso, se tornou uma plataforma indispensvel para o
ganho de eficincia e a alta performance em projetos.
Temos uma metodologia passo a passo de implementao da Gesto de
Projetos. Oferecemos pacotes de consultoria baseadas nesta metodologia para o
uso efetivo do Project Builder.
Produzimos muito contedo educativo na rea de Gesto de Projetos, estratgia
e desenvolvimento de produto. Eles so disponibilizados como posts no blog,
eBooks, Webinars gratuitos e palestras presenciais na Academia Project Builder.
Aproveite para conhecer as funcionalidades de nossa soluo atravs de uma
demonstrao por vdeo ou realize um teste gratuito!

49

Para colocar as dicas em prtica, esteja atento s novidades


em se tratando de defnio de indicadores de desempenho,
alm de contar com softwares ecientes e uma equipe bem
treinada.
Ultilize o Project Builder gratutamente por 15 dias e veja como
sua simplicidade pode ajudar a promover uma mudana na sua
empresa.

TESTE GRATUITO

GOSTOU?
COMPARTILHE!

Das könnte Ihnen auch gefallen