Inserindo Gestão de Projetos como suporte a gestão em ... · 2.1.1 Grupo de processos Os grupos...

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

Dezembro/2018

ISSN 2179-5568 – Revista Especialize On-line IPOG - Goiânia - Ano 9, Edição nº 16 Vol. 01 Dezembro/2018

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

ágeis que utilizam Scrum

Ronann Gomes da Cruz - [email protected]

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.


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 Gestão de Projetos como suporte a gestão em ... · 2.1.1 Grupo de processos Os grupos...

Documents

Transcript of Inserindo Gestão de Projetos como suporte a gestão em ... · 2.1.1 Grupo de processos Os grupos...