GERENCIAMENTO GIL DE

PROJETOS COM 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 PMBOKaqui 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.
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
Sumrio
10
4
7
13
16
18
27
Scrum +PMBOK
Ciclo de vida Scrum + Guia PMBOK
O Scrum como engrenagem para encaixar o Guia PMBOK
42
46
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 PMBOKaqui 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.
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
Introduo
Ciclo de vida Scrum
Incio do projeto
Rodando o Scrum
Backlog do Produto
Implementando Ferramentas e Prticas Adequadas
Concluso
25
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
4
Introduo
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 PMBOKaqui 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.
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
5
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
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 PMBOKaqui 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.
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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 PMBOKaqui 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.
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
7
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 PMBOKaqui 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.
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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?
8
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 PMBOKaqui 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.
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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.
9
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
6
Ciclo de vida Scrum + Guia 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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
11
BackLog
do Protuto
a cada
24 horas
Produto
Pronto
Ciclos de
monitoramento
e controle
Sprint
durao entre 2 e 4 semanas
( Ciclo de vida do projeto )
Reunio
Diria
Iniciao
Monitoramento
e Controle
Planejamento
da Sprint
Planejamento
BackLog
da Sprint
Execuo
Execuo da
Sprint
(Construo do Protudo)
Reunio de
Reviso
Reunio de
Retrospectva
Encerramento
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.
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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
6
O Scrum como engrenagem
para encaixar o Guia 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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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.
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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
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 do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
6
Ciclo de vida Scrum
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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
13
Incio do projeto
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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
Para um entendimento mais simplicado de como a unio proposta por esse
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, inclu-
indo 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 conheci-
mento 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 itera-
es 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 ex-
perincia 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.
Termo de Abertura do Projeto [1]:
O termo de abertura do projeto formaliza ocialmente o incio do mesmo,
permitindo e liberando a equipe para comear os trabalhos, e independente do ambi-
ente 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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]

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 [3]:
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 interes-
sadas, 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;
3. Como sero gerenciadas as mudanas no projeto;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.

b. Esses processos internos normalmente sero realizados no mesmo espao tempo-
ral da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.

b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de nenhuma
das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao temporal e
tambm no ter vnculo algum com as cerimnias.
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
Frisando que todos estes planejamentos podem incluir as atividades geis que proporc-
ionam comunicar, gerenciar os riscos, controlar a qualidade e prever as aquisies para
o projeto.

Responsvel por esta realizao: [GP] / [PO] / [SM]
Momento de realizao: [FC]
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados natu-
ralmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A sugesto
que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time Scrum, o(s)
processo(s) do Guia PMBOK ser(o) executados simultaneamente pela equipe de
gerenciamento do projeto.

O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar de um modo que se torne natural o fato de uma etapa de um pode se en-
caixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises ex-
istem para que um no interra no funcionamento do outro, e que os papis e re-
sponsabilidades de ambos sejam respeitados, alm de manter a integridade da pro-
posta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.

A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o ciclo de vida do Scrum permite que os processos do Guia PMBOK sejam su-
portados, podendo de uma maneira gurativa ser pendurados no Scrum, dando
apoio e sendo apoiados um ao outro.
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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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 PMBOKaqui 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.
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 [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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 PMBOKaqui 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.
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].
Momento de realizao: [FC]
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 [3]:
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;
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
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 PMBOKaqui 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.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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
1. Internamente ao ciclo do Scrum.
a. Este caso ser ilustrado nas situaes em que os processos do Guia PMBOK se
encaixam e rodam perfeitamente dentro do ciclo do Scrum, ou seja, durante uma
cerimnia do Scrum alguns processos do Guia PMBOK so executados no mesmo
momento e normalmente pelo mesmo Time.
b. Esses processos internos normalmente sero realizados no mesmo espao
temporal da cerimnia do Scrum, mas isso no uma regra.
2. Externamente ao ciclo do Scrum.
a. Este caso se caracterizar pelas situaes em que os processos do Guia PMBOK
no se encaixam naturalmente dentro do ciclo do Scrum, ou seja, nenhuma das
cerimnias do Scrum suporta o processo do Guia PMBOK de forma natural. Porm,
dependendo do tipo de projeto que estiver sendo gerenciado, poder ser importante
a realizao do processo em questo, mesmo que fora do ciclo do Scrum.
b. O fora do ciclo do Scrum neste caso signica que o momento de realizao do
processo do Guia PMBOK no pertencer ao momento de realizao de
nenhuma das cerimnias do Scrum, ou seja, no precisar ser o mesmo espao
temporal e tambm no ter vnculo algum com as cerimnias.
c. Neste caso, ser sugerido o momento de realizao deste processo externo ao
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
ciclo do Scrum, permitindo que a rea de gerenciamento seja coberta pela equipe de
gesto, minimizando possveis confuses de equipes inexperientes que no sabem o
momento exato de execuo dos processos do Guia PMBOK.
3. Paralelamente ao Ciclo do Scrum.
a. Este ltimo caso ser visto na situao em que os processos do Guia PMBOK,
apesar de estarem fora do ciclo do Scrum, devem ser executados no mesmo espao
temporal de uma cerimnia especca, por haverem dependncias ou vnculos atrelados.
b. Neste caso, um ou mais processos do Guia PMBOK no sero realizados
naturalmente durante uma cerimnia do Scrum, e nem pelo mesmo Time. A
sugesto que enquanto a cerimnia do Scrum estiver sendo realizada pelo Time
Scrum, o(s) processo(s) do Guia PMBOK ser(o) executados simultaneamente
pela equipe de gerenciamento do projeto.
O objetivo principal dessas formas de conexo entre o Scrum e o Guia PMBOK
evidenciar, de uma maneira que se torne natural, o fato de uma etapa de um poder
se encaixar em uma fase do outro, sem forar a barra. Em contrapartida, as divises
existem para que um no interra no funcionamento do outro, e que os papis e
responsabilidades de ambos sejam respeitados, alm de manter a integridade da
proposta de cada cerimnia do Scrum e de cada processo do Guia PMBOK.
A gura abaixo ilustra como a tica do Scrum o ponto de partida desta unio e
como o seu ciclo de vida permite que os processos do Guia PMBOK sejam suportados,
podendo de uma maneira gurativa ser pendurados no Scrum, apoiando um ao
outro.
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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
13
Rodando o Scrum
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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
13
Backlog do Produto
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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 [8]:
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]
Momento de realizao: [DC]
Denir o escopo [9]:
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
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]
Momento de realizao: [DC]
Criar a EAP [10]:
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.
Responsvel por esta realizao: [GP] / [PO]
Momento de realizao: [DC]
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
como Estimar os recursos das atividades [11].
Juntamente com esta estimativa de recursos, o GP pode preparar um plano de
recursos humanos [12], 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]
Momento de realizao: [DC]
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
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]
Momento de realizao: [DC]
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 [13]:
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]
Momento de realizao: [DC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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]
Momento de realizao: [DC]
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.
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]
Momento de realizao: [DC]
Criar a EAP [10]:
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.
Responsvel por esta realizao: [GP] / [PO]
Momento de realizao: [DC]
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
como Estimar os recursos das atividades [11].
Juntamente com esta estimativa de recursos, o GP pode preparar um plano de
recursos humanos [12], 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]
Momento de realizao: [DC]
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
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]
Momento de realizao: [DC]
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 [13]:
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]
Momento de realizao: [DC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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]
Momento de realizao: [DC]
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.
Coletar os requisitos [8]:
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]
Momento de realizao: [DC]
Denir o escopo [9]:
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
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]
Momento de realizao: [DC]
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
como Estimar os recursos das atividades [11].
Juntamente com esta estimativa de recursos, o GP pode preparar um plano de
recursos humanos [12], 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]
Momento de realizao: [DC]
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
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]
Momento de realizao: [DC]
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 [13]:
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]
Momento de realizao: [DC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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]
Momento de realizao: [DC]
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.
Coletar os requisitos [8]:
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]
Momento de realizao: [DC]
Denir o escopo [9]:
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
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]
Momento de realizao: [DC]
Criar a EAP [10]:
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.
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 [11].
Juntamente com esta estimativa de recursos, o GP pode preparar um plano de
recursos humanos [12], 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]
Momento de realizao: [DC]
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
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]
Momento de realizao: [DC]
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 [13]:
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]
Momento de realizao: [DC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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]
Momento de realizao: [DC]
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.
Coletar os requisitos [8]:
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]
Momento de realizao: [DC]
Denir o escopo [9]:
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
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]
Momento de realizao: [DC]
Criar a EAP [10]:
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.
Responsvel por esta realizao: [GP] / [PO]
Momento de realizao: [DC]
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
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]
Momento de realizao: [DC]
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 [13]:
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]
Momento de realizao: [DC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
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]
Momento de realizao: [DC]
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.
Coletar os requisitos [8]:
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]
Momento de realizao: [DC]
Denir o escopo [9]:
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
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]
Momento de realizao: [DC]
Criar a EAP [10]:
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.
Responsvel por esta realizao: [GP] / [PO]
Momento de realizao: [DC]
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
como Estimar os recursos das atividades [11].
Juntamente com esta estimativa de recursos, o GP pode preparar um plano de
recursos humanos [12], 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]
Momento de realizao: [DC]
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
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
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
Limpar o Backlog
Limpar o Backlog um exerccio bem interessante e imprescindvel para que
o Time passe esta etapa, pois quando o Time, com o apoio do Product Owner,
entende todo o Backlog que ter que trabalhar.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Denindo o tamanho das estrias
Com o entendimento dos itens do Backlog do produto, o Time tem condies
de denir o tamanho de cada estria analisada. Com os tamanhos denidos
possvel comear a prever qual ser o esforo necessrio para realizar o trabalho
do Backlog e j pensar nas estimativas de tamanho e quantidade das Sprints.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Planejar as aquisies [14]:
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 parti ci pao do gerente de proj etos opci onal 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 [15]:
Mai s uma vez a ati vi dade de entendi mento das estri as se mostra
fundamental , poi s com a l i mpeza do Backl og do Produto o Ti me Scrum
consegue identicar riscos, realizando o primeiro trabalho importante de
gerenciamento de riscos.
Responsvel por esta realizao: [TM] / [PO] / [GP]
Momento de realizao: [DC]
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 [16]:
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.
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]
Momento de realizao: [FC]
Determinar o oramento [17]:
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]
Momento de realizao: [FC]
Planejar o gerenciamento de riscos [18]:
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
Stakeholders do projeto que riscos j foram identicados e principalmente como eles
sero tratados ao longo do projeto.
Responsvel por esta realizao: [GP] / [PO]
Momento de realizao: [FC]
Neste caso o PO ser apenas um apoio para o GP, caso seja necessrio.
Planejamento da Sprint SP#0
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:
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]
Momento de realizao: [DC]
Identicar a velocidade do Time
Caso o time j tenha uma velocidade denida, esta pode ser simplesmente ocializada
neste momento. Por outro lado, se no houver uma velocidade conhecida, o Time
precisar denir uma velocidade estimada e trabalhar para atingi-la durante a Sprint.
Nesta segunda opo, o risco do Time errar na estimativa de sua velocidade alto
durante a primeira Sprint, e a qualquer momento durante a Sprint o Time poder
fazer ajustes para menos ou mais trabalho.
A partir da segunda Sprint em diante, esta etapa ser utilizada para revisar a velocidade
do Time de acordo com as Sprint anteriores e fazer ajustes mais precisos na velocidade.
Responsvel por esta realizao: [TM]
Momento de realizao: [DC]
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,
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
Limpar o Backlog
Limpar o Backlog um exerccio bem interessante e imprescindvel para que
o Time passe esta etapa, pois quando o Time, com o apoio do Product Owner,
entende todo o Backlog que ter que trabalhar.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Denindo o tamanho das estrias
Com o entendimento dos itens do Backlog do produto, o Time tem condies
de denir o tamanho de cada estria analisada. Com os tamanhos denidos
possvel comear a prever qual ser o esforo necessrio para realizar o trabalho
do Backlog e j pensar nas estimativas de tamanho e quantidade das Sprints.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Planejar as aquisies [14]:
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 parti ci pao do gerente de proj etos opci onal aqui , mas se torna
obrigatria caso haja a necessidade de realizar compras, pois ele que analisar
o oramento do projeto e dar a palavra nal sobre a compra ou no.
Responsvel por esta realizao: [TM] / [PO] / [GP]
Momento de realizao: [DC]
Velocidade do time
O exerccio de limpar o Backlog to importante que o seu resultado
utilizado em vrios outros processos. Aqui o Time verica se o prprio j tem
uma velocidade denida, ou seja, qual a quantidade de estrias, levando em
conta o item tamanho, o Time consegue realizar por Sprint.
Caso no haja esta denio, a partir da primeira Sprint completada, o Time
armazenar a velocidade e poder us-la para os prximos planejamentos e
comparaes com o resultado de futuras Sprints.
Responsvel por esta realizao: [TM]
Momento de realizao: [DC]
Identicar os Riscos:
Mai s uma vez a ati vi dade de entendi mento das estri as se mostra
fundamental , poi s com a l i mpeza do Backl og do Produto o Ti me 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]
Momento de realizao: [FC]
Determinar o oramento [17]:
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]
Momento de realizao: [FC]
Planejar o gerenciamento de riscos [18]:
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
Stakeholders do projeto que riscos j foram identicados e principalmente como eles
sero tratados ao longo do projeto.
Responsvel por esta realizao: [GP] / [PO]
Momento de realizao: [FC]
Neste caso o PO ser apenas um apoio para o GP, caso seja necessrio.
Planejamento da Sprint SP#0
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:
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]
Momento de realizao: [DC]
Identicar a velocidade do Time
Caso o time j tenha uma velocidade denida, esta pode ser simplesmente ocializada
neste momento. Por outro lado, se no houver uma velocidade conhecida, o Time
precisar denir uma velocidade estimada e trabalhar para atingi-la durante a Sprint.
Nesta segunda opo, o risco do Time errar na estimativa de sua velocidade alto
durante a primeira Sprint, e a qualquer momento durante a Sprint o Time poder
fazer ajustes para menos ou mais trabalho.
A partir da segunda Sprint em diante, esta etapa ser utilizada para revisar a velocidade
do Time de acordo com as Sprint anteriores e fazer ajustes mais precisos na velocidade.
Responsvel por esta realizao: [TM]
Momento de realizao: [DC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
Limpar o Backlog
Limpar o Backlog um exerccio bem interessante e imprescindvel para que
o Time passe esta etapa, pois quando o Time, com o apoio do Product Owner,
entende todo o Backlog que ter que trabalhar.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Denindo o tamanho das estrias
Com o entendimento dos itens do Backlog do produto, o Time tem condies
de denir o tamanho de cada estria analisada. Com os tamanhos denidos
possvel comear a prever qual ser o esforo necessrio para realizar o trabalho
do Backlog e j pensar nas estimativas de tamanho e quantidade das Sprints.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Planejar as aquisies [14]:
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 parti ci pao do gerente de proj etos opci onal aqui , mas se torna
obrigatria caso haja a necessidade de realizar compras, pois ele que analisar
o oramento do projeto e dar a palavra nal sobre a compra ou no.
Responsvel por esta realizao: [TM] / [PO] / [GP]
Momento de realizao: [DC]
Velocidade do time
O exerccio de limpar o Backlog to importante que o seu resultado
utilizado em vrios outros processos. Aqui o Time verica se o prprio j tem
uma velocidade denida, ou seja, qual a quantidade de estrias, levando em
conta o item tamanho, o Time consegue realizar por Sprint.
Caso no haja esta denio, a partir da primeira Sprint completada, o Time
armazenar a velocidade e poder us-la para os prximos planejamentos e
comparaes com o resultado de futuras Sprints.
Responsvel por esta realizao: [TM]
Momento de realizao: [DC]
Identicar os Riscos [15]:
Mai s uma vez a ati vi dade de entendi mento das estri as se mostra
fundamental , poi s com a l i mpeza do Backl og do Produto o Ti me Scrum
consegue identicar riscos, realizando o primeiro trabalho importante de
gerenciamento de riscos.
Responsvel por esta realizao: [TM] / [PO] / [GP]
Momento de realizao: [DC]
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 [16]:
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.
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]
Momento de realizao: [FC]
Neste caso o PO ser apenas um apoio para o GP, caso seja necessrio.
Planejamento da Sprint SP#0
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:
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]
Momento de realizao: [DC]
Identicar a velocidade do Time
Caso o time j tenha uma velocidade denida, esta pode ser simplesmente ocializada
neste momento. Por outro lado, se no houver uma velocidade conhecida, o Time
precisar denir uma velocidade estimada e trabalhar para atingi-la durante a Sprint.
Nesta segunda opo, o risco do Time errar na estimativa de sua velocidade alto
durante a primeira Sprint, e a qualquer momento durante a Sprint o Time poder
fazer ajustes para menos ou mais trabalho.
A partir da segunda Sprint em diante, esta etapa ser utilizada para revisar a velocidade
do Time de acordo com as Sprint anteriores e fazer ajustes mais precisos na velocidade.
Responsvel por esta realizao: [TM]
Momento de realizao: [DC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
Limpar o Backlog
Limpar o Backlog um exerccio bem interessante e imprescindvel para que
o Time passe esta etapa, pois quando o Time, com o apoio do Product Owner,
entende todo o Backlog que ter que trabalhar.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Denindo o tamanho das estrias
Com o entendimento dos itens do Backlog do produto, o Time tem condies
de denir o tamanho de cada estria analisada. Com os tamanhos denidos
possvel comear a prever qual ser o esforo necessrio para realizar o trabalho
do Backlog e j pensar nas estimativas de tamanho e quantidade das Sprints.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Planejar as aquisies [14]:
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 parti ci pao do gerente de proj etos opci onal aqui , mas se torna
obrigatria caso haja a necessidade de realizar compras, pois ele que analisar
o oramento do projeto e dar a palavra nal sobre a compra ou no.
Responsvel por esta realizao: [TM] / [PO] / [GP]
Momento de realizao: [DC]
Velocidade do time
O exerccio de limpar o Backlog to importante que o seu resultado
utilizado em vrios outros processos. Aqui o Time verica se o prprio j tem
uma velocidade denida, ou seja, qual a quantidade de estrias, levando em
conta o item tamanho, o Time consegue realizar por Sprint.
Caso no haja esta denio, a partir da primeira Sprint completada, o Time
armazenar a velocidade e poder us-la para os prximos planejamentos e
comparaes com o resultado de futuras Sprints.
Responsvel por esta realizao: [TM]
Momento de realizao: [DC]
Identicar os Riscos [15]:
Mai s uma vez a ati vi dade de entendi mento das estri as se mostra
fundamental , poi s com a l i mpeza do Backl og do Produto o Ti me Scrum
consegue identicar riscos, realizando o primeiro trabalho importante de
gerenciamento de riscos.
Responsvel por esta realizao: [TM] / [PO] / [GP]
Momento de realizao: [DC]
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 [16]:
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.
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]
Momento de realizao: [FC]
Determinar o oramento [17]:
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]
Momento de realizao: [FC]
Planejar o gerenciamento de riscos [18]:
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
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]
Momento de realizao: [DC]
Identicar a velocidade do Time
Caso o time j tenha uma velocidade denida, esta pode ser simplesmente ocializada
neste momento. Por outro lado, se no houver uma velocidade conhecida, o Time
precisar denir uma velocidade estimada e trabalhar para atingi-la durante a Sprint.
Nesta segunda opo, o risco do Time errar na estimativa de sua velocidade alto
durante a primeira Sprint, e a qualquer momento durante a Sprint o Time poder
fazer ajustes para menos ou mais trabalho.
A partir da segunda Sprint em diante, esta etapa ser utilizada para revisar a velocidade
do Time de acordo com as Sprint anteriores e fazer ajustes mais precisos na velocidade.
Responsvel por esta realizao: [TM]
Momento de realizao: [DC]
Termo de Abertura do Projeto [1]:
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]
Momento de realizao: [FC]
Identicao dos Stakeholders [2]:
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
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].
Momento de realizao: [FC]
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 [3]:
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;
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 [4];
2. Planejar o gerenciamento dos riscos [5];
3. Planejar a qualidade [6];
4. Planejar as aquisies [7].
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]
Momento de realizao: [FC]
Limpar o Backlog
Limpar o Backlog um exerccio bem interessante e imprescindvel para que
o Time passe esta etapa, pois quando o Time, com o apoio do Product Owner,
entende todo o Backlog que ter que trabalhar.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Denindo o tamanho das estrias
Com o entendimento dos itens do Backlog do produto, o Time tem condies
de denir o tamanho de cada estria analisada. Com os tamanhos denidos
possvel comear a prever qual ser o esforo necessrio para realizar o trabalho
do Backlog e j pensar nas estimativas de tamanho e quantidade das Sprints.
Responsvel por esta realizao: [TM] / [PO]
Momento de realizao: [DC]
Planejar as aquisies [14]:
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 parti ci pao do gerente de proj etos opci onal aqui , mas se torna
obrigatria caso haja a necessidade de realizar compras, pois ele que analisar
o oramento do projeto e dar a palavra nal sobre a compra ou no.
Responsvel por esta realizao: [TM] / [PO] / [GP]
Momento de realizao: [DC]
Velocidade do time
O exerccio de limpar o Backlog to importante que o seu resultado
utilizado em vrios outros processos. Aqui o Time verica se o prprio j tem
uma velocidade denida, ou seja, qual a quantidade de estrias, levando em
conta o item tamanho, o Time consegue realizar por Sprint.
Caso no haja esta denio, a partir da primeira Sprint completada, o Time
armazenar a velocidade e poder us-la para os prximos planejamentos e
comparaes com o resultado de futuras Sprints.
Responsvel por esta realizao: [TM]
Momento de realizao: [DC]
Identicar os Riscos [15]:
Mai s uma vez a ati vi dade de entendi mento das estri as se mostra
fundamental , poi s com a l i mpeza do Backl og do Produto o Ti me Scrum
consegue identicar riscos, realizando o primeiro trabalho importante de
gerenciamento de riscos.
Responsvel por esta realizao: [TM] / [PO] / [GP]
Momento de realizao: [DC]
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 [16]:
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.
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]
Momento de realizao: [FC]
Determinar o oramento [17]:
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]
Momento de realizao: [FC]
Planejar o gerenciamento de riscos [18]:
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
Stakeholders do projeto que riscos j foram identicados e principalmente como eles
sero tratados ao longo do projeto.
Responsvel por esta realizao: [GP] / [PO]
Momento de realizao: [FC]
Neste caso o PO ser apenas um apoio para o GP, caso seja necessrio.
Planejamento da Sprint SP#0
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:
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
Objetivo 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]
Momento de realizao: [DC]
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]
Momento de realizao: [DC]
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]
Momento de realizao: [DC]
Revisar os Riscos [15]:
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]
Momento de realizao: [DC]
Planejamento da Sprint SP#1
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:
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
6
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.
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
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
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
Concluso
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.
Sobre o Fbio Cruz
Graduado na rea de TI, PMP e ITIL-f certicado com mais de 19 anos de experincia
prossional, atuando sempre na rea de desenvolvimento de sistemas, sendo os lti-
mos 10 dedicados liderana de equipes e coordenao de projetos. Atualmente
gerente de projetos na empresa americana Ascendant Technology, Vice Presidente
de comunicaes no PMI Chapter de Santa Catarina e autor do blog
www.fabiocruz.com especializado em gerenciamento de projetos.
Fale com o Fbio: contato@fabiocruz.com
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.
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
Graduado na rea de TI, PMP e ITIL-f certicado com mais de 19 anos de experincia
prossional, atuando sempre na rea de desenvolvimento de sistemas, sendo os lti-
mos 10 dedicados liderana de equipes e coordenao de projetos. Atualmente
gerente de projetos na empresa americana Ascendant Technology, Vice Presidente
de comunicaes no PMI Chapter de Santa Catarina e autor do blog
www.fabiocruz.com especializado em gerenciamento de projetos.
Fale com o Fbio: contato@fabiocruz.com
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.
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.
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
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.
49
Sobre o Fbio Cruz
Graduado na rea de TI, PMP e ITIL-f certicado com mais de 19 anos de experincia
prossional, atuando sempre na rea de desenvolvimento de sistemas, sendo os lti-
mos 10 dedicados liderana de equipes e coordenao de projetos. Atualmente
gerente de projetos na empresa americana Ascendant Technology, Vice Presidente
de comunicaes no PMI Chapter de Santa Catarina e autor do blog
www.fabiocruz.com especializado em gerenciamento de projetos.
Fale com o Fbio: contato@fabiocruz.com
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!
Sobre a Project Builder
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!