Inserindo Gesto de Projetos Como Suporte A Gesto em Ambientes Geis Que Utilizam Scrum Ronann Gomes D 1675257053220

Inserindo Gestão de Projetos como suporte a gestão em ambientes ágeis que utilizam Scrum
Dezembro/2018
Inserindo Gestão de Projetos como suporte a gestão em ambientes

ágeis que utilizam Scrum
Ronann Gomes da Cruz - ronann.gomes@gmail.com
MBA Gestão de Projetos em Engenharias e Arquitetura
Instituto de Pós-Graduação - IPOG
Campo Grande, MS, 25 de abril de 2016
Resumo
Atualmente sabe-se que a velocidade como o mundo evolui é de extrema rapidez e dinamismo
quando comparada com anos anteriores, isso ocorre devido a progressos significativos na área
de Tecnologia da Informação e Comunicação (TIC), que suporta e é base para todo esse
desenvolvimento. Empresas focadas ao Desenvolvimento de Software necessitam lançar cada
vez mais rápidas soluções que agreguem valor a essa tendência de dinamismo exigida pelo
mercado. E para isso utilizam diversas ferramentas e técnicas para o gerenciamento desse
perfil de projetos sendo a mais difundida e aplicada até o momento é o framework Scrum.
Todavia, o framework aplicado sozinho possui pontos fracos logo, como forma de
complementar esses pontos negativos a fim de aproveitar melhor os pontos positivos, uma
abordagem mista unindo o Guia de boas práticas PMBOK v5 é uma sugestão plausível para
fortalecer o modelo de gerenciamento do Scrum e será proposto por esse artigo que pretende
descrever como a gestão de projetos sugerida pelo PMBOK pode ser aplicada dentro do
Scrum.
Palavras-chave: Scrum. Pmbok. Gestão.
1. Introdução
É notório como atualmente, o ser humano vive inserido em um mundo onde a tecnologia e o
acesso a informação está ao alcance de muito mais pessoas do que em gerações passadas, até
mesmo as crianças desta geração possuem contato com dispositivos móveis como tablets,
notebooks e smartphones manipulando-os de maneira tão intuitiva e fácil quanto adultos.
O avanço da tecnologia proporciona dinamismo e globalização de muitos setores da
economia, e naturalmente gera nas empresas oportunidades de mudanças para que estas por
sua vez se adequem a esse ritmo de produtividade e demanda cada vez maior e mais exigente.
Aproveitando-se de ferramentas, técnicas e metodologias que auxiliem na gestão dos projetos
e negócios para ocuparem o mercado atual.
Um setor da economia que nesse momento muito se ouve falar é o da Tecnologia da
Informação e Comunicação (TIC) que de acordo com a publicação MERCADO
BRASILEIRO DE SOFTWARE da ABES Software de 2015 o mercado mundial de Software
e Serviços atingiu em 2014 o valor de US$ 1,067 bilhão, e o Brasil manteve o 8º lugar no
ranking mundial, com um mercado interno de US$ 25,2 bilhões. De acordo com a mesma
publicação de 2013 a 2014 houve uma evolução de 9,7% nos indicadores de mercado.
ISSN 2179-5568 – Revista Especialize On-line IPOG - Goiânia - Ano 9, Edição nº 16 Vol. 01 Dezembro/2018
Dezembro/2018
Para manter-se em crescimento a gestão de projetos torna-se fundamental para empresas deste
setor. Conforme Shane Hastie e Stéphane Wojewoda (2015) que publicaram um artigo sobre
o CHAOS Report de 2015 que se centra na apresentação das informações e dados sobre o
sucesso e o fracasso de projetos, ainda há trabalho a ser feito em torno de alcançar resultados
bem-sucedidos de projetos de desenvolvimento de software. Nos últimos cinco anos projetos
considerados muito grandes obtiveram apenas 2% de sucesso, além disso, em 2015 19% das
empresas fracassaram em seus projetos.
Devido a uma gama vasta de suporte a gestão, tomar a decisão de qual ou quais utilizar torna-
se por diversas vezes um trabalho tanto quanto complexo, pois, exige experiência, capacitação
profissional e estudos de casos semelhantes além de investimentos que podem não estar ao
alcance de quem pretende aplicar.
Durante um longo período uma das formas de apoio a Gestão de Projetos que mais se
consolidou no mercado e tem sido utilizada até o momento como um guia no gerenciamento é
o Project Management Body of Knowledge (PMBOK), um conjunto de boas práticas na
gestão de projetos organizada pelo Project Management Institute (PMI), esse guia que
conforme Fábio Cruz (2013) possui boas práticas que comprovadamente funciona na maioria
dos projetos na maioria do tempo, ou seja, não significa que seja o mais correto ou que
somente estas práticas funcionam no gerenciamento eficaz e eficiente de projetos, mas pode
ajudar e muito na diminuição dos problemas do dia a dia de projetos, e aumentar e muito as
chances de sucesso dos projetos.
De acordo com um levantamento do PMSURVEY (2013), 34% das empresas possuem o
papel do Gerente de Projetos e em relação ao perfil das organizações por tipo de projeto, mais
de 50% os projetos são externos com os clientes externos tendo participação efetiva no
desenvolvimento. Logo, essa relação com o cliente precisa ser gerenciada de modo a tornar o
projeto um sucesso.
Todavia, o PMBOK é considerado por muitos como uma modelo de gestão clássica e que
num mundo atual, principalmente quando tratando de empresas de TI focadas no
desenvolvimento de softwares, vantagens citadas por Vargas (2006) como evitar surpresas
durante a execução do trabalho, antecipação de situações desfavoráveis estimando as ações
corretivas e preventivas, além de otimizar a alocação de recursos e documentar e facilitar a
estimativa para projetos futuros são deixadas de lado alegando que sua aplicação causa
burocracias desnecessárias, necessidade de conhecimento de todo o escopo do produto ou
serviço previamente e baixa flexibilidade em relação aos processos necessários que suportam
cada área de conhecimento.
Portanto, no que diz respeito a TIC, empresas que possuem projetos na área de
desenvolvimento de software optam por algo que provê agilidade ao projeto sem abrir mão de
um mínimo de gerenciamento, essa visão, que tem se tornado cada vez mais usual e aplicada
no mundo conforme a pesquisa 9TH ANNUAL State of Agile™ Survey apresenta que dos
seus entrevistados cerca de 24% dos entrevistados trabalhou em organizações que têm prática
ágil durante mais de cinco anos, acima dos 19% em 2013. Isso representa um crescimento
dessa forma de gerenciamento e as maiores razões para a adoção desse gerenciamento são de
acordo com a publicação:
Dezembro/2018
• Acelerar a entrega do produto 59%

• Melhorar a capacidade de gerir mudanças de prioridades 56%
• Aumentar a produtividade 53%
• Melhorar a qualidade do software 46%
• Melhorar a prestação de previsibilidade 44%
• Melhorar os negócios / alinhamento de TI 40%
• Melhorar a visibilidade do projeto 40%
• Reduzir o risco do projeto 38%
• Melhorar o moral da equipe 26%
• Melhorar a engenharia de disciplina 25%
• Reduzir o projeto custou 23%
• Aumentar a capacidade de manutenção de software 22%
• Melhor gerir equipes distribuídas 20%
Entretanto, assim como a gama de meios para o gerenciamento de projetos de forma clássica é
grande, para o gerenciamento ágil não é diferente e mais utilizada no momento é o Scrum,
que conforme a pesquisa citada ocupa 56% dos métodos utilizados.
Mas, visto que, uns defendem o uso de metodologias clássicas, outros defendem métodos
ágeis, e sabendo que ambos possuem pontos negativos e positivos, a ideia de uni-los é vista
com bons olhos por alguns, e a inserção de boas práticas consideradas clássicas em um
ambiente que já utiliza Scrum, comprova que ambas podem se complementar fortalecendo o
que individualmente possuem de melhor formando assim uma abordagem mista que garanta o
sucesso do projeto.
2. PMBOK e Scrum unidos
Primeiramente conhecer as boas práticas sugeridas tanto pelo Guia PMBOK quanto as do
framework Scrum é fundamental para que a união alcance maior eficiência e eficácia na
aplicação em um projeto. Por isso, a seguir serão apresentadas de forma sucinta tais práticas.
2.1 O Guia PMBOK 5a edição
O guia PMBOK contém o padrão e guia globalmente reconhecidos para a profissão de
gerenciamento de projetos PMBOK(2013). Isso não quer dizer que seja o mais correto ou que
só as práticas descritas nele funcionam no gerenciamento de projetos. Em resumo o PMBOK
possui cinco grupos de processos que contemplam as dez áreas de conhecimentos que possui,
combinando essas áreas de conhecimento com os grupos de processos têm-se os quarenta e
sete processos que são sugeridos como necessários e aplicáveis no gerenciamento de um
projeto.
Dezembro/2018
2.1.1 Grupo de processos

Os grupos de processos de maneira breve como descrito por CRUZ(2013) é muito importante
conhece-los e compreendê-los, para que a união com o Scrum seja visível, possível e
aplicável de maneira simples e positiva. Os cinco processos conforme o PMBOK(2013) são:
• Grupo de processos de iniciação. Os processos executados para definir um novo projeto
ou uma nova fase de um projeto existente através da obtenção de autorização para iniciar
o projeto ou fase.
• Grupo de processos de planejamento. Os processos necessários para definir o escopo do
projeto, refinar os objetivos e definir a linha de ação necessária para alcançar os objetivos
para os quais o projeto foi criado.
• Grupo de processos de execução. Os processos realizados para executar o trabalho
definido no plano de gerenciamento do projeto para satisfazer as especificações do
projeto.
• Grupo de processos de monitoramento e controle. Os processos exigidos para
acompanhar, analisar e controlar o progresso e desempenho do projeto, identificar
quaisquer áreas nas quais serão necessárias mudanças no plano, e iniciar as mudanças
correspondentes.
• Grupo de processos de encerramento. Os processos executados para finalizar todas as
atividades de todos os grupos de processos, visando encerrar formalmente o projeto ou
fase.
É importante dizer que estes grupos de processos cobrem todos os 47 processos divididos nas
10 áreas de conhecimento do guia.
2.1.2 Áreas de conhecimento
Conforme o PMBOK(2013) uma área de conhecimento representa um conjunto completo de
conceitos, termos e atividades que compõem um campo profissional, campo de
gerenciamento de projetos, ou uma área de especialização. As áreas de conhecimento são:
• Gerenciamento da integração do projeto. O gerenciamento da integração do projeto inclui
os processos e atividades para identificar, definir, combinar, unificar e coordenar os vários
processos e atividades dentro dos grupos de processos de gerenciamento do projeto.
• Gerenciamento do escopo do projeto. O gerenciamento do escopo do projeto inclui os
processos necessários para assegurar que o projeto inclui todo o trabalho necessário, e
apenas o necessário, para terminar o projeto com sucesso.
• Gerenciamento do tempo do projeto. O Gerenciamento do tempo do projeto inclui os
processos necessários para gerenciar o término pontual do projeto.
• Gerenciamento dos custos do projeto. O gerenciamento dos custos do projeto inclui os
processos envolvidos em planejamento, estimativas, orçamentos, financiamentos,
gerenciamento e controle dos custos, de modo que o projeto possa ser terminado dentro do
orçamento aprovado.
Dezembro/2018
• Gerenciamento da qualidade do projeto. O gerenciamento da qualidade do projeto inclui

os processos e as atividades da organização executora que determinam as políticas de
qualidade, os objetivos e as responsabilidades, de modo que o projeto satisfaça às
necessidades para as quais foi empreendido.
• Gerenciamento dos recursos humanos do projeto. O gerenciamento dos recursos humanos
do projeto inclui os processos que organizam, gerenciam e guiam a equipe do projeto. A
equipe do projeto consiste das pessoas com papéis e responsabilidades designadas para
completar o projeto.
• Gerenciamento das comunicações do projeto. O gerenciamento das comunicações do
projeto inclui os processos necessários para assegurar que as informações do projeto
sejam planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas, gerenciadas,
controladas, monitoradas e finalmente dispostas de maneira oportuna e apropriada.
• Gerenciamento dos riscos do projeto. O Gerenciamento dos riscos do projeto inclui os
processos de planejamento, identificação, análise, planejamento de respostas e controle de
riscos de um projeto.
• Gerenciamento das aquisições do projeto. O gerenciamento das aquisições do projeto
inclui os processos necessários para comprar ou adquirir produtos, serviços ou resultados
externos à equipe do projeto.
• Gerenciamento das partes interessadas do projeto. O gerenciamento das partes
interessadas do projeto inclui os processos exigidos para identificar todas as pessoas,
grupos ou organizações que podem impactar ou serem impactados pelo projeto, analisar
as expectativas das partes interessadas e seu impacto no projeto, e desenvolver estratégias
de gerenciamento apropriadas para o engajamento eficaz das partes interessadas nas
decisões e execução do projeto.
De acordo com CRUZ (2013) todos os processos contidos nas dez áreas de conhecimento são
os mesmos distribuídos entre os grupos de processo, formando um conjunto de 47 processos.
O que ocorre é uma combinação entre as áreas de conhecimento e os grupos de processos,
resultando uma matriz de relacionamento entre ambas. Este foi um breve resumo introdutório
sobre o guia PMBOK.
2.2 O guia do Scrum
Apesar da premissa de que a união é proposta para empresas que já possuem o Scrum como
guia implantado para gerenciamento dos projetos. Um breve resumo será apresentado a
respeito do guia.
Este guia é amplamente utilizado em projetos de metodologias ágeis e conforme o guia possui
a seguinte definição “[...]Scrum(subs): Um framework dentro do qual pessoas podem tratar e
resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam
produtos com o mais alto valor possível.[...]” Guia do Scrum, de Ken Schwaber (2013). O
framework consiste nos times do Scrum associados a papéis, eventos, regras e artefatos.
Dezembro/2018
2.2.1 Time do Scrum e papéis

De acordo com o Guia do Scrum (2013) O Time Scrum é composto pelo Product Owner, o
Time de Desenvolvimento e o Scrum Master. Times Scrum são auto-organizáveis e
multifuncionais. Isso quer dizer que o próprio time escolhe qual a melhor forma de
completarem o trabalho e no quesito multifuncionais quer dizer que possuem todas as
competências para completar o trabalho sem necessitar de fatores externos ao time. De forma
resumida os papéis de cada um time pode ser observado a seguir:
• Product Owner (Dono do produto) é o responsável por maximizar o valor do produto e do
trabalho do Time de Desenvolvimento. É uma pessoa e não um comitê, todavia pode
representar o desejo de um comitê e como seu trabalho é feito pode variar de organização
e indivíduo.
• Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar
uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada
Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.
• Scrum Master (Mestre Scrum) é responsável por garantir que o Scrum seja entendido e
aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas
e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master
ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o
Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas
interações para maximizar o valor criado pelo Time Scrum.
A existencia destes papéis é fundamental e obrigatória quanto ao uso do Scrum, em relação ao
time de desenvolvimento a quantidade de pessoas não é fixa, mas sugere-se que seja de 5 a 9
pessoas, podendo haver mais pessoas.
2.2.2 Eventos e regras do Scrum
Os eventos do Scrum são prescritos de forma a minimizar as reuniões não definidas ou que
possuem longa duração com pouca objetividade, além de gerar rotinas em todos os envolvidos
devido as durações de tempo fixo para cada evento. Os principais eventos são: Sprint,
Planejamento da Sprint, Reuniões Diárias, Revisão da Sprint e Retrospectiva da Sprint.
• Sprint é um evento de um mês ou menos, durante o qual ao fim, uma versão incremental
potencialmente utilizável do produto, é criada. Uma nova Sprint sempre inicia
imediatamente após o término da anterior.
• Planejamento da Sprint possui um time-box com no máximo oito horas para uma Sprint
de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum
Master garante que o evento ocorra e que os participantes entendam seu propósito. O
Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box.
• Reuniões diárias do Scrum é um evento time-boxed de 15 minutos, para que o Time de
Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24
horas. Esta reunião é feita para inspecionar o trabalho desde a última Reunião Diária, e
Dezembro/2018
prever o trabalho que deverá ser feito antes da próxima Reunião Diária. A Reunião Diária
é mantida no mesmo horário e local todo dia para reduzir a complexidade.
• Revisão da Sprint A Revisão da Sprint é executada no final da Sprint para inspecionar o
incremento e adaptar o Backlog do Produto se necessário. Durante a reunião de Revisão
da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint.
Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os
participantes colaboram nas próximas coisas que podem ser feitas para otimizar valor.
Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento
destina-se a motivar e obter comentários e promover a colaboração. Esta é uma reunião
time-boxed de 4 horas de duração para uma Sprint de um mês. Para Sprints menores, este
evento é usualmente menor.
• Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e
criar um plano para melhorias a serem aplicadas na próxima Sprint. A Retrospectiva da
Sprint ocorre depois da Revisão da Sprint e antes da reunião de planejamento da próxima
Sprint. Esta é uma reunião time-boxed de três horas para uma Sprint de um mês. Para
Sprint menores, este evento é usualmente menor.
Esses são os principais eventos do Scrum, como eles são realizados pode variar de acordo
com a organização e indivíduos envolvidos.
2.2.3 Artefatos do Scrum
Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência
e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são
especificamente projetados para maximizar a transparência das informações chave de modo
que todos tenham o mesmo entendimento dos artefatos. Os principais são os Backlogs do
Produto e da Sprint que em reumo é uma lista ordenada de tudo que deve ser necessário no
produto e no decorrer da Sprint.
2.3 Unindo PMBOK e Scrum
Como pôde ser observado anteriormente, o Scrum tem um modelo mais simplificado que o
Guia PMBOK, dessa forma, a abordagem mista que será apresentada é a aplicação das boas
práticas sugeridas pelo Guia a partir do ciclo Scrum. Ou seja, alguns dos processos que o Guia
PMBOK sugere como boas práticas serão inseridos em projetos onde a base é o Scrum
formando uma metodologia unificada. O resultado será apresentado dividido em três partes:
Dentro do Ciclo Scrum, Fora do Ciclo Scrum e em Paralelo ao Ciclo Scrum.
Além disso, o papel do Gerente de Projetos será incorporado ao que chamaremos de Time do
Projeto (TP), resultando numa equipe com o envolvimento do Product Owner (PO), Scrum
Master (SM), Scrum Team (ST) e então o Gerente de Projetos (GP).
A Figura 1 apresenta o ciclo de vida resultante da abordagem mista Scrum e PMBOK.
Dezembro/2018
Figura 1 - Ciclo de vida Scrum + Guia PMBOK

Fonte: http://www.projectbuilder.com.br/Downloads/ebook-gratuito-scrum-pmbok-ciclo-de-vida-A0.pdf
Conforme Fábio Cruz descreve em seu artigo na Revista Engenharia de Software Magazine
47, mesmo em um ambiente ágil é preciso realizar algumas atividades formais,
principalmente para registrar certas passagens importantes do projeto, como a oficialização do
seu início.
Ainda conforme a publicação a maioria dos médios e grandes clientes aceita bem a
implantação de metodologias ágeis, mas não abre mão de processos contidos no
gerenciamento tradicional, principalmente no que diz respeito a formalizações, controles de
alto nível para visão da gerência sênior, incluindo alternativas para garantir legalmente que
certas ações são realizadas e outras não.
Sendo assim é possível observar que já antes mesmo do projeto iniciar o ciclo Scrum, boas
práticas sugeridas pelo PMBOK podem ser utilizadas como apoio aos artefatos o que
fortalece a abordagem mista.
3. Desenvolver o Termo de Abertura
Portanto, o Guia PMBOK 5ª edição sugere como primeiro processo denominado
“Desenvolver o Termo de Abertura do Projeto”, a criação de um artefato que consiste em
como está escrito no PMBOK (2013) um documento que formalmente autoriza a existência
de um projeto. O principal benefício deste processo é um início de projeto e limites de
Dezembro/2018
projetos bem definidos, a criação de um documento formal do projeto, e uma maneira direta
da direção executiva aceitar e se comprometer formalmente com o projeto.
Neste documento então será registrado os requisitos iniciais que de acordo com CRUZ (2013)
satisfaçam as necessidades e expectativas das partes interessadas na execução do projeto. É
importante ressaltar que na abordagem mista é possível que ainda não se tenha o escopo ou
todos os requisitos no momento da criação deste termo, por isso, ele pode ser usado para dar
abertura a uma fase do projeto, e fases é exatamente como o Scrum trabalha, o que fortalece
ainda mais essa união.
É um documento simples que conforme CRUZ (2013) diz “o que” e “como” será concluído o
projeto ou a fase, já respeitando datas importante, orçamentos definidos, recursos e riscos.
Esse processo então deve ser executado pelo GP e fora do ciclo Scrum.
Já com o termo então definido e encaminhado as pessoas identificadas como chaves do
projeto para inicia-lo é necessário então relacionar todos os envolvidos e interessados no
projeto. Esses interessados também são conhecidos como stakeholders.
E mais uma vez utilizando as boas práticas do PMBOK 5º edição, um processo denominado
“Identificar as Partes Interessadas” nos auxiliará no momento de relacionar os envolvidos e
interessados.
4. Identificar as Partes Interessadas
Identificar as partes interessadas de acordo com o PMBOK (2013) é o processo de identificar
pessoas, grupos ou organizações que podem ter impacto ou serem impactados por uma
decisão, atividade ou resultado do projeto. Além disso, conforme CRUZ (2013) as partes
interessadas podem influenciar o projeto de forma positiva e/ou negativa e/ou serem afetadas
pelo projeto, também de forma positiva e/ou negativa. Portanto, dar atenção a este processo é
fundamental para a saúde de um projeto em qualquer ambiente, seja ágil ou tradicional.
No Scrum este termo Stakeholder não existe de forma oficial mas o papel existe e com muita
força de acordo com CRUZ (2013). O registro das partes pode ser realizado por meio de um
documento simples com informações básicas como: nome, dados de contato, posição na
organização, local de atuação, requisitos, expectativas e influência. Tendo como principal
benefício deste processo para o GP, a identificação e o direcionamento apropriado para cada
parte interessada.
Ainda que o papel de Stakeholder não exista no Scrum identificar o cliente e analisar os
requisitos é uma tarefa executada pelo PO, sendo assim para a execução deste processo ainda
que esteja Fora do Ciclo Scrum pode ser realizado em conjunto pelo PO e o GP. Isso porque
essa é uma atividade de igual importância para ambos. Note que já é possível observar a união
se tornando mais clara com atuações em conjunto.
5. Desenvolver o plano de gerenciamento do projeto
Este é um importante documento que de acordo com CRUZ (2013) tem a função de nortear
todos os trabalhos de gerenciamento de projeto e também para formalizar como o projeto será
conduzidos em todas as suas etapas. Além disso ele continua dizendo que este é o momento
Dezembro/2018
ideal, e o documento perfeito, para deixar bem claro para todos os stakeholders do projeto que
serão utilizadas ferramentas e técnicar tradicionais combinadas com as ágeis.
É importante informar em que momento cada uma delas será aplicada, deixar claro quais os
propósitos e quais serão os benefícios, além de que conforme CRUZ (2013) é altamente
recomendável publicar o plano de projeto para todas as partes interessadas contendo pelo
menos o seguinte:
• Ciclo de vida do projeto e os processos que serão aplicados em cada fase;
• Como o trabalho será executado para completar os objetivos do projeto. A sugestão é
que neste item seja descrito como o Scrum será utilizado e quais as conexões entre ele e as
técnicas tradicionais;
• Como serão gerenciadas as mudanças no projeto;
• Como serão gerenciadas as configurações no projeto;
• Como serão gerenciados os requisitos no projeto;
• O que será feito para manter a integridade das linhas de base do projeto;
• Quais as necessidades para as comunicações entre as partes interessadas.
Note que este documento contém informações técnicas, logo, sugere-se que seja criado de
forma que se tenha uma fácil leitura e entendimento. Para a criação deste documento o GP
pode ter auxilio de alguns papéis do Scrum para criação das definições, são eles o PO e o SM
devido ao conhecimento específico sobre o framework. Este processo também é executado
Fora do Ciclo Scrum.
Pela definição do PMBOK (2013) desenvolver o plano de gerenciamento do projeto é o
processo de definir, preparar e coordenar todos os planos auxiliares e integra-los a um plano
de gerenciamento de projetos abrangente. E os então chamados de planos auxiliares seriam:
• Plano de gerenciamento das comunicações;
• Plano de gerenciamento de riscos;
• Plano de gerenciamento da qualidade;
• Plano de gerenciamento das aquisições;
• Plano de gerenciamento das partes interessadas.
De acordo com Cruz (2013) não há um obrigatoriedade em cumprir esses processos neste
ponto e nem em nenhum outro. São tarefas opcionais que podem acontecer para um projeto, e
para outro não. A exemplo do planejamento de aquisições, que só acontecerá em projeto onde
houver a necessidade de comprar produtos ou adquirir serviços.
Todavia, ainda de acordo com Cruz (2013) o trabalho de discussão, definição e registro desses
planejamentos pode ser realizado no mesmo momento em que o Time estiver trabalhando no
plano de gerenciamento do projeto. Assim o tempo será otimizado, não havendo burocracias
ou dezenas de etapas a cumprir.
Dezembro/2018
6. Planejar o gerenciamento das comunicações

Se pegarmos a maioria dos valores do manifesto ágil, temos:
• “Indivíduos e interação entre eles mais que processos e ferramentas”.
• “Colaboração com o cliente mais que negociação de contratos”.
• “Responder a mudanças mais que seguir um plano”.
É possível notar que estão explicitamente deixando claro o valor e importância da
comunicação ativa, objetiva, direta e eficaz. Pois, para haver interação entre indivíduos é
necessário que haja comunicação, para colaborar com o cliente também é necessário
comunicação e por fim responder as mudanças é fundamental manter uma comunicação
próxima, clara e objetiva com os envolvidos do projeto.
Uma vez que é notório que ambas as abordagens dão importância e valor altíssimo às
comunicações nos projetos. Inserir esse processo tradicional utilizando ferramentas e técnicas
ágeis para elaboração deste plano é uma sugestão de valor.
Conforme o PMOBOK (2013) é o processo de desenvolver uma abordagem apropriada e um
plano de comunicação do projeto com base nas necessidades de informação e requisitos das
partes interessadas e nos ativos organizacionais disponíveis. Ainda conforme ele, embora
todos os projetos compartilhem a necessidade de comunicar as informações do projeto, as
necessidades de informação e os métodos de distribuição podem variar muito.
Pontos importante que podem precisar ser considerados incluem, mas não estão limitados, a:
• Quem precisa de quais informações;
• Onde as informações devem ser armazenadas;
• O formato em que as informações devem ser distribuídas e armazenadas;
• Quais informações sobre o projeto serão distribuídas.
Quando se trata do formato como as informações devem ser distribuídas, é possível fazer uma
associação com o Scrum. Pois, conforme Cruz (2013) O Quadro de Tarefas, e o Gráfico de
Burndown são ótimos exemplos de ferramentas de comunicação para um projeto que se
propõe a ser ágil – e neste caso deve ser parte integrante do plano de comunicações do
projeto.
Outra técnica mais simples e fácil são as reuniões, estas, desde que mantenham-se voltadas
para a objetividade e clareza da sua agenda e o Scrum também contribui muito para reuniões
efetivas e objetivas com a técnica de Reuniões Diárias de 15 minutos e Standup Meeting.
O formato do plano de gerenciamento de comunicações pode ser em texto ou em forma de
planilha e/ou tabela listando o tipo de informações e quem deve receber além da frequência de
envio. Neste processo todo o TP deve participar.
7. Planejar o gerenciamento de riscos
Por definição, o PMBOK (2013) diz que o risco do projeto é um evento ou condição incerta
que, se ocorrer, provocará um efeito positivo ou negativo em um ou mais objetivos do projeto.
Dezembro/2018
Portanto conforme Cruz (2013) antecipar é uma das palavras mais importantes, porque para o
gerente de projeto se preparar para o risco é necessário antecipá-lo e mantê-lo sob controle.
É importante que o TP esteja envolvido e compartilhe a responsabilidade de ficar atentos aos
riscos seja ele uma ameaça ou uma oportunidade que possa surgir no projeto. Para isso
existem técnicas para realizar esta análise, mas uma técnica que permite conhecer, monitorar e
controlar além de prover um tempo de resposta para o risco são as reuniões diárias propostas
pelo Scrum pois, nela os obstáculos para conclusão de uma atividade são todos relacionados,
sendo assim, importante a presença do GP ainda que este participe apenas como ouvite para
extrair tais informações e trata-las posteriormente.
O plano deve ser um documento de fácil leitura e entendimento, pode ser um documento texto
que inclui mas não se limita a:
• Metodologia do gerenciamento de risco, incluindo as cerimônias do Scrum por
exemplo como já citado;
• Papéis e responsabilidades;
• Categorias de riscos;
• Definições de probabilidade e impacto;
• Tolerância aos riscos;
• Modelo de relatórios de riscos.
Mais uma vez é importante ressaltar que este processo deve ser realizados por todos e Fora do
Ciclo Scrum.
8. Planejar o gerenciamento da qualidade
De acordo com o PMBOK (2013) a definição de qualidade é o grau com que um conjunto de
características inerentes atende aos requisitos, já numa linguagem de mais fácil entendimento
Cruz (2013) define que um projeto que atenda à qualidade necessariamente precisa atender às
necessidades e expectativas do cliente, nada a mais e nada a menos.
No tocante ao processo de planejar o gerenciamento da qualidade o PMBOK (2013) define
que este é o processo de identificação dos requisitos e/ou padrões de qualidade do projeto e
suas entregas, e de documentação de como o projeto demonstrará conformidade com os
relevantes requisitos e/ou padrões de qualidade.
Alguns artefatos já gerados em etapas anteriores podem ser utilizados como entradas para
execução deste processo, como por exemplo o registro das partes interessadas, registro dos
riscos, custos e cronogramas, documentação dos requisitos além de técnicas como análise de
custo-benefício, custo da qualidade, diagramas de causa e efeito, fluxogramas e etc.
Uma dica que Cruz (2013) oferece é que quando o TP discute requisitos e/ou padrões de
qualidade e como atendê-los e demonstrar que o projeto está em conformidade com a
qualidade esperada, pode ser necessário realizar mudanças no planejamento de custos,
cronograma ou riscos.
Dezembro/2018
Logo, como saída deste processo o plano de gerenciamento da qualidade pode ser um
documento texto que contenha informações tais como:
• Quais são os requisitos de qualidade macro do projeto;
• Como os requisitos de qualidade serão gerenciados, incluindo as cerimônias do Scrum
e suas regras;
• Quem será responsável pelo monitoramento do plano;
• Métricas para medição e controle da qualidade;
• Lista de verificação.
Conforme Cruz (2013) ressalta, este processo deve ser realizado por todos, pois é preciso que
todos tenham o mesmo entendimento do que é qualidade para o cliente. Este processo é
executado Fora do Ciclo Scrum.
9. Planejar o gerenciamento das aquisições
O PMBOK (2013) define que o gerenciamento das aquisições do projeto inclui os processos
necessários para comprar ou adquirir produtos, serviços ou resultados externos à equipe do
projeto. Atualmente as aquisições são parte de vários projetos, especialmente os grandes, com
alta complexidade e/ou de longa duração.
Portanto, Cruz (2013) sugere que este é o primeiro processo que realmente evidencia a
necessidade de participação de um gerente de projetos em uma equipe ágil que utiliza o
framework do Scrum como abordagem de gestão.
Isto porque o framework não sugere que o ST gerencie aquisições de produtos e/ou serviços,
e/ou contratos com terceiros. Porém na prática em muitos projetos essa necessidade é
fundamental para o sucesso do projeto.
Sendo assim, todos podem participar da realização do processo, porém cabe ao GP preparar o
documento pois é ele o dono das decisões de custos, orçamentos e cronogramas. Este
documento texto pode conter informações como: tipo de contrato, questões associadas a
riscos, documentos de aquisições, restrições e premissas para efetuar as aquisições, lista de
fornecedores e etc. Este processo é realizado Fora do Ciclo Scrum.
10. Planejar o gerenciamento das partes interessadas
Este processo de acordo com o PMBOK (2013) visa desenvolver estratégias apropriadas para
envolver as partes interessadas de maneira eficaz no decorrer de todo o ciclo de vida do
projeto, com base na análise das suas necessidades, interesses, e impacto potencial no êxito do
projeto.
É um plano que precisa ter atenção, pois, de acordo com Cruz (2013) o gerenciamento dos
Stakeholders é mais do que melhorar a comunicação e requer mais que gerenciamento do
Time do Projeto. Gerenciar os Stakeholders é criar e manter um relacionamento entre o Time
do Projeto e os Stakeholders com o propósito de satisfazer suas respectivas necessidades e
requisitos dentro dos limites do projeto.
Dezembro/2018
Isso vai de encontro com um dos valores descritos no manifesto ágil que seria a colaboração
com o cliente mais que negociação de contratos, reforçando ainda mais o valor da união
destas abordagens como proposta do artigo.
Haja vista que para ambas abordagens esse gerenciamento é importante, é interessante que
este documento texto seja criado em um trabalho conjunto do GP e do PO, Fora do Ciclo
Scrum e tenha como base o seguinte conjunto de informações sugeridos por Cruz (2013):
• Nível atual e desejado de envolvimento para os stakeholder-chave.
• Escopo e impacto de mudanças de stakeholders.
• Relações identificadas e possíveis sobreposições de stakeholders.
• Requisitos de comunicação dos stakeholders por fase do projeto.
• Dados sobre a distribuição de informações para os stakeholders.
• Razões para a distribuição das informações e do impacto esperado com o
envolvimento dos stakeholders.
• Momentos e frequências para a distribuição das informações aos stakeholder.
• Método de atualização e refinamento do plano de gerenciamento das partes
interessadas de acordo com o progresso e desenvolvimento do projeto.
Após realizar esses processos e atividades formais que são externas ao Scrum, ou seja, Fora
do Ciclo Scrum, Cruz (2013) sugere que agora tanto o GP e a equipe formada podem iniciar a
execução do projeto pela ótica do Scrum. Sendo assim o primeiro dos 5 principais grupos de
processos sugeridos pelo PMBOK que é Iniciação se encerra dando início a Planejamento.
11. Planejar e Executar o Scrum
Em acordo com Cruz (2013) ao colocarmos o Scrum pra rodar, estamos ao mesmo tempo
trabalhando na execução do projeto, dando continuidade às atividades de planejamento,
realizando teste, entregas e outras etapas e tarefas.
Esses conceitos combinam com a definição do PMBOK (2013) chamado “Ciclo de vida
iterativo e incremental”. De acordo com Cruz (2013) isso significa que o projeto será divido
em várias fases de acordo com a entrega de valor acordada com o cliente. Partindo da
premissa que a abordagem do artigo é sobre a inserção de conceitos de Gestão de Projetos
utilizando o PMBOK em um ambiente ágil que utiliza Scrum isso quer dizer que o projeto
será divido no que no mundo ágil é conhecido por Sprints.
Planejar por ciclos de vida iterativos e incrementais já é um conceito antigo no Guia PMBOK,
todavia, na quarta edição do guia esse planejamento era conhecido por “Planejamento por
ondas sucessivas”. Mais uma vez é possível perceber uma união simples que pode ser
realizada entre PMBOK e Scrum.
Em seu livro Cruz (2013) menciona que para reforçar ainda mais esta união natural, além do
ciclo de vida iterativo e incremental, o Guia PMBOK (2013) trouxe o ciclo de vida
adaptativo, que também sugere que o tamanho do ciclo seja de duas a quatro semanas, tendo o
Dezembro/2018
seu conteúdo delimitado em requisitos selecionados (inclusive mencionando o termo

Backlog).
Mais uma vez pode-se visualizar esta união ocorrendo naturalmente, e por se tratar de um
planejamento por fases é necessário que o PO e GP unam forças para que se tenha a visão
inicial do produto da fase, assim ajustando o cronograma de marcos, algum outro documento
de planejamento já realizado, etc. Este processo então envolvendo o PO e o GP deve ser
realizando Dentro do Ciclo Scrum.
Uma vez que a tarefa do PO em preparar o Backlog do Produto é realizada e têm-se já uma
noção do que precisa ser realizado o Guia PMBOK (2013) sugere que seja realizado o Plano
de gerenciamento do escopo, que tem como um dos principais objetivos evitar alterações não
controladas e não assistidas.
É sugerido por Cruz (2013) que o GP seja o responsável por este documento, porém a
participação do PO é fundamental, pois este será o responsável pelo escopo e precisa
contribuir e conhecer muito bem como o escopo do projeto será gerenciado. Este documento é
gerado Fora do Ciclo Scrum pois, é uma sugestão do Guia PMBOK.
Feito isso, dentro do ciclo Scrum o PO como responsável pelo escopo deve realizar a coleta
de requisitos, por meio de um documento de fácil leitura e entendimento. Automaticamente
ao fim da coleta é necessário que o escopo seja definido, essa definição cabe ao PO realizar e
partindo da premissa que o Scrum já é adotado para o artigo, a definição de escopo acaba se
tornando o que no Scrum é conhecido como “Histórias de Usuários”.
De acordo com Schwaber e Sutherland (2013) cabe ao PO, ao ST e ao SM a realização dos
eventos envolvendo a criação dos artefatos Backlog da Sprint e do Produto, além da
realização de um evento denominado no guia do Scrum como “Reunião de Planejamento da
Sprint”. O GP pode participar porém apenas como ouvinte para que não altere os processos
definidos no framework.
A participação apesar de ser como ouvinte pode servir como uma orientação para a criação de
um artefato sugerido pelo PMBOK (2013) conhecido por Estrutura Analítica do Projeto
(EAP).
Uma boa EAP de acordo com Cruz (2013) deve conseguir determinar os pacotes de trabalho
de um projeto, e somente os trabalhos necessários para a conclusão do projeto ou fase. Se
organizada e acompanhada pelo GP, torna-se uma arma eficiente contra alterações não
controladas.
Ainda é sugerido por Cruz (2013) que para desenvolver uma ótima EAP nesta metodologia
mista usar o conceito de pacotes de trabalho da EAP quando estiver definindo as Histórias,
principalmente no que tange à granularidade. A ideia é que cada História seja um item da
EAP de menor nível.
Portanto, o GP não deve interferir nos eventos e artefatos sugeridos pelo framework Scrum,
todavia, deve tirar proveito das informações neles gerado para que realize a criação dos
artefatos e planejamentos sugeridos pelo Guia PMBOK. Sendo assim, este processo pode
envolver o GP e o PO, dentro do Ciclo Scrum otimizando recurso e tempo para criação.
Dezembro/2018
12. Estimando os recursos das atividades

Este processo demonstra a necessidade da união do Guia PMBOK com o Scrum e, apesar de
simples, tem suas particularidades.
O GP de acordo com Cruz (2013) tem aqui a responsabilidade de analisar as alternativas e
tomar decisões a respeito de contratações para formar o ST, bem como a respeito da compra
de materiais e equipamentos para permitir que o time produza.
E devido a isso que este processo fortalece a união, pois conforme Cruz (2013) determinar o
orçamento, analisar e gerenciar os custos do projeto não são de responsabilidade explícita de
nenhum dos papéis do Scrum, por isso se torna evidente a necessidade da abordagem de união
para tratar tais questões.
13. Planejar o gerenciamento dos recursos humanos
Em conjunto com a estimativa de recursos, o GP pode produzir um plano de gerenciamento
dos recursos humanos que vai ao encontro do objetivo de forma o ST. O autor Cruz (2013)
sugere que uma das realizações deste plano seja a de determinar as necessidades e identificar
os recursos humanos com habilidades necessárias para o êxito do projeto.
O PO deve fornecer auxilio para o GP estimar os recursos e definir o plano de recursos
humanos e este processo pode ser executado Dentro do Ciclo Scrum.
É importante ressaltar que alguns processo sugeridos pelo Guia PMBOK são exclusivamente
complementares e breves, não atrapalhando nem complica a rotina dos times ágeis, mas sim
complementando com o intuito de somar aos trabalhos já realizados pelo ST.
14. Linhas de base do projeto
Uma linha de base marca a situação de um projeto num determinado momento. É um conceito
fundamental que deve ser entendido e utilizado para o proveito do time do projeto como todo.
Neste momento quando se está definindo o escopo, custo, prazos, etc. Não há mudanças, pois
as linhas de base não foram aceitas e marcadas ainda.
Agora, conforme Cruz (2013) apenas quando uma versão finalizada, oficial e aprovada pelas
partes interessadas é obtida e alinha de base é formada, qualquer alteração passa a ser
considerada uma mudança e deve ser tratada como tal.
15. Processo de planejamento iterativo
No Scrum, o produto final é construído iterativamente, começando pelo de maior valor e
maior risco. Logo, Cruz (2013) orienta que o objetivo principal deste processo é realizar um
planejamento inicial mais breve e, no momento de execução de cada reunião de revisão e
planejamento de Sprint, assim como durante as reuniões diárias, serem realizados
planejamento complementares.
É verdade que esta é uma diferença entre o Scrum e o modelo tradicional mais conhecido,
pois geralmente este último realiza todo o planejamento da versão no início do trabalho e este
não é modificado ao longo do tempo. Neste caso como o Scrum é utilizado como base o
conceito tradicional não se aplica.
Dezembro/2018
Durante o planejamento que é realizado por todos os integrantes do time, dúvidas em relação
a determinados requisitos podem surgir, logo, o claro entendimento de todo o trabalho que
deverá ser realizado durante o projeto e/ou fase é de suma importância para que riscos possam
ser identificados, mitigados ou explorados.
Em paralelo a esse trabalho o planejamento do gerenciamento de custo pode ser realizando, o
GP tem condições de trabalhar no gerenciamento dos custos e focar nos processos que o
envolvem.
Esta é uma área considerada por Cruz (2013) como uma das mais importantes do
gerenciamento de projetos, também como uma das mais difíceis. E mais uma vez a união é
fortalecida neste processo pois, em momento nenhum é mencionado no Scrum o
gerenciamento de custos.
Sendo assim, o GP pode tratar dessas questões paralelamente à execução de um projeto
Scrum, sem interferir nos trabalho do ST. De acordo com Cruz (2013) este é um dos grupos
de processos que mais justificam a união proposta em uma única proposta aplicável a um
mesmo projeto.
16. Planejar o gerenciamento dos custos
Por definição PMBOK (2013) planejar o gerenciamento dos custos é o processo de
estabelecer as políticas, os procedimentos e a documentação necessários para o planejamento,
gerenciamento, despesas, e controle dos custos do projeto. Portanto, como gerente de projetos
Cruz (2013) orienta que se tente evitar a aprovação do orçamento antes da estimativa dos
custos ser completada.
Para realização de tal processo o GP, fora do Ciclo Scrum pode se munir de ferramentas e
técnicas para apoiá-lo, dentre as possíveis encontradas no mercado Cruz (2013) sugere:
• Paramétrica: utiliza uma relação estatística para calcular uma estimativa para
parâmetros de atividas.
• Bottom-up: é indicada todas as vezes em que uma atividade não puder ter seu custo
estimado devido a seu tamanho ou sua complexidade.
• Estimativa de três pontos: também conhecida como PERT, sigla em inglês que
significa “Program Evaluation and Review Technique” ou, em português, “Técnica de
Revisão e Avaliação de Programa”. Esta estimativa considera as incertezas das estimativas e
os riscos.
Por fim, com as primeiras análises e identificações é necessário atualizar os planos já
realizados até o momento, o GP deve realizar as revisões e pode ter o apoio do PO caso seja
necessário. Este processo deve ser realizado fora do Ciclo Scrum.
A seguir a cerimônia de planejamento da Sprint deve ser iniciada e os processos nela contidos
terão a participação do GP apenas copo ouvinte, para que este possa extrair informações
necessárias para atualização e revisão dos planos criados.
17. Planejar a Sprint
Dezembro/2018
Tendo por base que a aplicação desta abordagem tomou como premissa que o Scrum já é
adotado e aplicado, cabe ressaltar que o GP não realizado o processo sugerido pelo PMBOK
conhecido como “Sequenciar as atividades”, pois este processo caberá ao PO juntamente com
o ST.
Todavia como ouvinte o GP pode ter informações suficientes para identificar o que o
PMBOK denomina “caminho crítico”, este por sua vez pode não existir explicitamente, ou
não ser nominado declaradamente no Scrum conforme Cruz (2013), mas quando o Time
define a priorização do seu Backlog e determina que alguns itens devem ser feitos antes de
outros, ele está relatando a existência de um caminho crítico dentro da Sprint.
Ainda dentro desta cerimônia, outra informação que o GP poderá extrair é o registro de novos
riscos, pois Cruz (2013) defende que durante o entendimento e a priorização do Backlog da
Sprint, o Time terá a oportunidade de discutir sobre riscos que podem afetar os trabalhos na
próxima Sprint. Sendo assim ninguém deve ignorar os riscos.
Caso novos riscos sejam registrados, eles devem ser acompanhados e monitorados, para isso
ferramentas e técnicas podem ser um apoio fundamental para priorização deles. Entre
algumas sugeridas por Cruz (2013) e o Guia PMBOK, tem-se:
• Matriz de probabilidade e impacto que tem como objetivo priorizar os riscos para um
posterior controle mais efetivo.
• Técnicas de coleta e apresentação de dados que podem ser entrevistas e distribuições
de probabilidade.
• Técnicas de modelagem e análise quantitativa dos riscos que podem ser simulações a
exemplo da técnica de Monte Carlo.
• Opinião especializada que normalmente é utilizada para identificar impactos
potenciais.
Estes processos devem ser realizado pelo GP fora do Ciclo Scrum, porém não basta
identificá-los e registrá-los é necessário que o GP tenha o que o PMBOK (2013) sugere como
Plano de respostas aos riscos.
18. Plano de respostas aos riscos
Conforme Cruz (2013) é importante que nenhum risco fique sem dono e sem estratégia de
resposta. É fundamental que os riscos sejam levados sempre às reuniões de projeto para
acompanhamento e monitoramento de sua situação, probabilidade e gatilho.
Dentre as estratégias, incluem para riscos negativos ou ameaças: eliminar, transferir, mitigar e
aceitar. Já riscos considerados positivos ou oportunidades podem adotar estratégias tais como:
explorar, compartilhar, melhorar e aceitar. Todas essas estratégias devem ser observadas e
discutidas por todos o time do projeto dentro do ciclo Scrum.
19. Desenvolver o cronograma
Dezembro/2018
Com todo o planejamento de riscos, recursos humanos, custos, além das definições e
priorizações realizadas pelo ST o GP possui informações suficientes para então desenvolver o
cronograma da fase.
De acordo com Cruz (2013) neste ponto o objetivo principal é detalhar o cronograma com
datas, tarefas e recursos apenas para esta fase. Isso faz com que o cronograma seja mais
simples, cresça e ganhe mais detalhes gradativamente seguindo o conceito de iteração e
incremento.
Este processo deve ser executado em paralelo a Ciclo do Scrum que conforme é realizado o
trabalho de planejamento da Sprint pelo ST, o GP monta um cronograma com as atividades
que o time irá trabalhar ao longo da Sprint.
Por fim ao final da reunião de planejamento da Sprint e dos trabalhos realizados com o
entendimento e decomposição do que deve ser feito o time tem a oportunidade de rever todo o
trabalho feito, realizar as revisões necessárias finalizando esta cerimônia e o segundo grande
processo do PMBOK Planejamento partindo para a Execução.
20. Execução da Sprint
No tocante a execução é fundamente não quebrar as cerimônias e eventos que o Scrum adota,
pois o ST não deve ser interrompido para que possa ter todo o tempo necessário para o
desenvolvimento das suas atividades.
Dessa forma, não será abordado nenhum processo do PMBOK para esta fase apenas a
participação do GP nas cerimônias como ouvinte para obtenção de informações que o
auxiliem no monitoramento e controle da execução do projeto.
21. Monitoramento e Controle da Sprint
De acordo com Cruz (2013) a partir deste momento o ciclo de desenvolvimento começa a
tomar uma forma mais conhecida pelas equipes de desenvolvimento tradicional, porém
seguindo o fluxo e as regras do Scrum.
Um dos primeiro processos que pode ser observado durante o monitoramento e controle da
Sprint é o que o PMBOK (2013) sugere como “Desenvolver a equipe do projeto”, este
processo deixa claro a importância desta abordagem de união, pois como visa a melhoria de
competências para que o desempenho do projeto seja aprimorado no momento em que as
reuniões diárias são executadas o GP tem a oportunidade de observar o ST a fim de coletar
informar informações para aplicar a melhoria contínua no próprio time.
Outra oportunidade gerada pelas reuniões diárias é o processo que o PMBOK (2013)
denomina “Realizar a garantia da qualidade”, já que durante a cerimônia é mencionado o que
foi realizando, o que será e quais os obstáculos encontrados é possível neste momento
verificar a qualidade das entregas parciais.
Além disso novos riscos podem ser observados e os já encontrados podem ser acompanhados
de perto pelo GP, desde que este não interfira no objetivo da reunião aos moldes do Scrum.
Por fim estes processos podem todos serem realizados dentro do ciclo Scrum pelo GP que por
sua vez pode contar com o apoio do PO para realização.
Dezembro/2018
22. Revisão e retrospectiva da Sprint

Estas são cerimônias que Scrum possui que são de extremamente importantes para o GP obter
informações e armazenar o conhecimento, pois a partir delas é onde é possível controlar a
qualidade, inspecionar o que foi produzido e principalmente registrar a lições aprendidas
durante a fase. O resultado disso é a observação do crescimento de maturidade organizacional
que deve permanecer na empresa mesmo ao fim e entrega do projeto.
Por fim, se deve encerrar a fase também chamada Sprint, no Scrum não há intervalo entre o
encerramento de uma fase e o início de outra, isso é realizado automaticamente pelo time.
Não contendo assim nenhuma atividade de encerramento dentro do ciclo Scrum, o que pode
ocorrer é a orientação e o acompanhamento da homologação e entrega da fase, além do
controle de qualidade, bem como atualização dos artefatos do Scrum porém, lembrando que
tudo isso se dá fora do ciclo Scrum e não possui um papel responsável, portanto, sendo
possível ser realizado por todos do time.
Encerrando-se a fase, o escopo é validado, as aquisições são novamente revistas e uma vez
que o Scrum trabalha em ciclos todos os processos já citados anteriormente são repetidos até
que o produto final seja realmente entregue, deixando assim o processo do PMBOK
Monitoramento e Controle para trás e caminhando para o Encerramento do Projeto.
23. Encerramento do projeto
Este processo segundo Cruz (2013) é caracterizado por sua formalidade, mas não deixa de ser
menos importante que os demais. Ele garante que o trabalho foi realizado e aceito pelo
cliente.
Algumas dicas sugeridas por Cruz (2013) para realização deste processo podem ser seguidas a
fim de evitar maiores problemas futuras, são elas:
• O encerramento do projeto sem a devida documentação necessária, registrada e
assinada pelo cliente pode acarretar em problemas sérios, incluindo processos judiciais,
multas e outras penas legais.
• Em alguns casos o processo de encerramento das aquisições poderá servir de apoio
para o GP verificar se todo o trabalho foi completado.
• Encerre as aquisições e cancele os contratos que não sejam necessários.
Por fim este é a sugestão de abordagem mista unindo, o Guia PMBOK 5ª edição e o
framework ágil Scrum. Note que nem todos os processos do PMBOK foram sugeridos, mas
nada impede a complementação inserindo-os ou caso necessário retirando-os.
24. Conclusão
Ao seguir a sugestão de abordagem mista unindo, o Guia PMBOK e o framework Scrum é
possível concluir que há ganhos gerais em vários sentidos, a nível estratégico organizacional
por exemplo o grande ganho é que não há necessidade das empresas abrirem mão dos seus
ambientes para experimentarem essa combinação. Isso pôde ser observado na própria criação
do artigo que tomou como premissa uma empresa onde já havia implantando nela o Scrum.
Dezembro/2018
Inúmeros clientes podem se recusar a utilizar somente o Scrum em projetos de sua

contratação, seja por desconhecer às técnicas ágeis, quer seja por não confiar nas práticas por
ter ouvido depoimentos sobre falta de gerência. Logo, como ganhos têm a abordagem mista
que com uso das boas práticas do Guia PMBOK oferece a segurança que o cliente necessita.
Outro grande ganho é o suporte a áreas que o Scrum não menciona ou sugere como gerir, um
exemplo disso seria o controle de aquisições e contratos, controle de custos e recursos, este é
um ganho, pois um time que conta com o papel do Gerente de Projetos pode tirar proveito do
que já conhece sem interferir no processo de execução em ambientes ágeis.
Além de ganhos como transparência com o cliente além de credibilidade devido a forma
como o Scrum trabalha com as entregas, além de gerar valor uma vez que há entregas
contínuas a previsibilidade da entrega também se torna um destaque desta abordagem.
Enfim, outros ganhos podem ser citados como trabalhos focados na execução, o
fortalecimento do autogerenciamento e valorização da entrega de valor. Esses são alguns
resultados da aplicação desta abordagem.
Todavia, é importante dizer que não há aqui a afirmação de que uma ou outra está mais
correta ou que há apenas este modo de uni-las. A dosagem correta para o complemento de
metodologias com boas práticas cabe ao Gerente de Projetos de acordo com cada projeto que
por definição de acordo com o Guia PMBOK entre outras coisas é único.
Sendo assim cabe a pesquisa e prática por quem deseja aplicar a união para ver o que mais se
adequa ao próprio projeto. Por isso, nem todos os processos do Guia PMBOK foram citados,
mas nada impede que possam ser utilizados ou que alguns dos que foram citados sejam
retirados.
Referências
ABES -Associação Brasileira das Empresas de Software. Mercado Brasileiro de Software:
panorama e tendências, 2015. 1a. ed. - São Paulo: ABES -Associação Brasileira das
Empresas de Software, 2015.
CRUZ, Fábio. Revista Engenharia de Software Magazine 47 - PMBOK e Scrum, como

uní-los.
CRUZ, Fábio. Scrum e Guia PMBOK® unidos no gerenciamento de projetos. – Rio de

Janeiro: Brasport, 2013.
HASTIE, Shane. WOJEWODA, Stéphane. Standish Group 2015 Chaos Report - Q&A
with Jennifer Lynch. 2015. < http://www.infoq.com/articles/standish-chaos-2015 >
Acessado em: 25/04/2016.
BECK, Kent. BEEDLE, Mike. BENNEKUM, Arie van. COCKBURN, Alistair.

CUNNINGHAM, Ward. FOWLER, Martin. GRENNING, James. HIGHSMITH, Jim. HUNT,
Andrew. JEFFRIES, Ron. KERN Jon. MARICK, Brian. MARTIN, Robert C. MELLOR,
Dezembro/2018
Steve. SCHWABER, Ken. SUTHERLAND, Jeff. THOMAS, Dave. Manifesto para

Desenvolvimento Ágil de Software. 2001. < http://www.manifestoagil.com.br/ > Acessado
em 25/04/2016.
Project Management Institute - PMI®. Um Guia do Conhecimento em Gerenciamento de

Projetos (Guia PMBOK®). Quinta edição. 2013.
SCHWABER, Ken. SUTHERLAND Jeff. Guia do Scrum. 2013.
VARGAS, Ricardo Viana. Gerenciamento de projetos: estabelecendo diferenciais

competitivos. – Rio de Janeiro: Brasport, 2006.
©2015 VersionOne, Inc. State of Agile Survey. Nona edição. 2014.

Inserindo Gesto de Projetos Como Suporte A Gesto em Ambientes Geis Que Utilizam Scrum Ronann Gomes D 1675257053220

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Inserindo Gesto de Projetos Como Suporte A Gesto em Ambientes Geis Que Utilizam Scrum Ronann Gomes D 1675257053220

Enviado por

Direitos autorais:

Formatos disponíveis

Inserindo Gestão de Projetos como suporte a gestão em ambientes ágeis que utilizam Scrum

Inserindo Gestão de Projetos como suporte a gestão em ambientes

Palavras-chave: Scrum. Pmbok. Gestão.

• Acelerar a entrega do produto 59%

2.1.1 Grupo de processos

• Gerenciamento da qualidade do projeto. O gerenciamento da qualidade do projeto inclui

2.2.1 Time do Scrum e papéis

Figura 1 - Ciclo de vida Scrum + Guia PMBOK

6. Planejar o gerenciamento das comunicações

seu conteúdo delimitado em requisitos selecionados (inclusive mencionando o termo

12. Estimando os recursos das atividades

22. Revisão e retrospectiva da Sprint

Inúmeros clientes podem se recusar a utilizar somente o Scrum em projetos de sua

CRUZ, Fábio. Revista Engenharia de Software Magazine 47 - PMBOK e Scrum, como

CRUZ, Fábio. Scrum e Guia PMBOK® unidos no gerenciamento de projetos. – Rio de

BECK, Kent. BEEDLE, Mike. BENNEKUM, Arie van. COCKBURN, Alistair.

Steve. SCHWABER, Ken. SUTHERLAND, Jeff. THOMAS, Dave. Manifesto para

Project Management Institute - PMI®. Um Guia do Conhecimento em Gerenciamento de

SCHWABER, Ken. SUTHERLAND Jeff. Guia do Scrum. 2013.

VARGAS, Ricardo Viana. Gerenciamento de projetos: estabelecendo diferenciais

©2015 VersionOne, Inc. State of Agile Survey. Nona edição. 2014.

Você também pode gostar