Gerenciamento

Inserir Título Aqui

Inserir
de Projetos
TítuloÁgeis
Aqui
Introdução a Modelos Tradicionais de Gestão em Projetos

Responsável pelo Conteúdo:

Prof. Me. Luiz Lima

Revisão Textual:
Prof.ª Dr.ª Luciene Oliveira da Costa Granadeiro
 Introdução a Modelos Tradicionais
de Gestão em Projetos

Fonte: Getty Images

Nesta unidade, trabalharemos os seguintes tópicos:
• Modelos Genéricos na Fábrica de Software;
• Modelos Tradicionais para Gestão;
• Conceitos.

Objetivo
• Introduzir o profissional ao conhecimento e à diferenciação dos modelos de genéricos
da fábrica de software e modelos tradicionais de Gerenciamento de Projeto utilizando
PMBOK, PRINCE2 e outros.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o úl-
timo momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Introdução a Modelos Tradicionais de Gestão em Projetos

Contextualização
Nossa situação-problema central é baseada em um Projeto de Desenvolvimento de
um App (aplicativo – SEJ) Mobile para uma empresa de Seguros que pretende atingir o
nicho de mercado do público jovem.

Nesta Unidade 1, existem 3 abordagens que devem ser verificadas pelos alunos:
• Decidir qual deve ser o melhor modelo de processo genérico de desenvolvimento
de software a ser utilizado.
• Decidir qual deve ser o melhor modelo tradicional de gerenciamento de projetos a
ser utilizado.
• Decidir qual dos frameworks (PMBOK, RINCE2, RUP, MSF, SCRUM, outros)
apresenta melhor adaptação quanto às mudanças de fases do projeto.

6
Modelos Genéricos na Fábrica de Software
Quando falamos sobre o desenvolvimento de um modelo genérico na área de software,
como isso impacta no processo de gerenciamento de um projeto?

Um modelo de processo de software é uma representação simplifica-

da de um processo de software. Cada modelo representa uma pers-
pectiva particular de um processo e, portanto, fornece informações
parciais sobre ele. Por exemplo, um modelo de atividade do processo
pode mostrar as atividades e sua sequência, mas não mostrar os pa-
péis das pessoas envolvidas. (SOMMERVILLE, 2011, p. 19)

Abordando de forma genérica, os modelos de processo de software são uma repre-

sentação simplificada de um processo de software, e pode ser entendido como uma
metodologia para as atividades, ações e tarefas necessárias para se desenvolver um
software com qualidade.

O processo de software pode ser considerado um roteiro para o desenvolvimento de

um produto ou sistema, dentro do prazo acordado entre as partes.

Cada modelo apresenta diferenças específicas, pois foram idealizados em momentos

diversos, em que as atividades, os processos e a forma de organização apresentam ca-
racterísticas próprias.

Cada uma dessas atividades pode estar ligada a um ou mais processos. Esses proces-
sos podem ser organizados de forma sequencial, iterativa ou até em espiral.

Cada membro da equipe deve receber as suas atribuições de papéis e responsabilida-

des dentro das fases do projeto.

Outra visão que se deve ter a respeito desses modelos é que não são absolutos, ou
seja, precisam ser seguidos em todos os pontos em que foram elaborados, pois são
formatos de orientação para equipes de desenvolvimento, podendo ser alteradas e até
utilizadas somente parcialmente.
Esses modelos genéricos não são descrições definitivas dos processos
de software. Pelo contrário, são abstrações que podem ser usadas
para explicar diferentes abordagens de desenvolvimento de software.
(SOMMERVILLE, 2011, p. 19)

Quando falamos sobre o desenvolvimento de um modelo genérico na área de software, como

isso impacta no processo de gerenciamento de um projeto? Todo projeto sofre impactos quan-
to às escolhas dos modelos de gestão, pois deve ser: compatível com as habilidades da equipe,
adequado ao cronograma de entrega e de acordo com o custo/benefício do projeto.

Os modelos genéricos de processos de software que serão abordados neste curso serão:
• Modelo cascata;

7
7
UNIDADE
Introdução a Modelos Tradicionais de Gestão em Projetos

• Desenvolvimento em espiral;
• Desenvolvimento ágil;
• RUP – Rational Unified Process; e
• MSF – MSF – Microsoft Solutions Framework.

Modelo Cascata
O Modelo Cascata tem origem do inglês Waterfall Model, criado na década de 1970,
com a publicação de um artigo por Winston Walker Royce, cientista americano da com-
putação, que foi diretor da Lockheed Software Technology Center em Austin, Texas
nos Estados Unidos, considerado um pioneiro na área de desenvolvimento de software.
Modelo em cascata. Esse modelo considera as atividades fundamen-
tais do processo de especificação, desenvolvimento, validação e evolu-
ção, e representa cada uma delas como fases distintas, como: especifi-
cação de requisitos, projeto de software, implementação, teste e assim
por diante. (SOMMERVILLE, 2011, p. 19)

Definição de
requisitos

Projeto de sistema
e software

Implementação e
teste unitário

Integração e teste
de sistema
Operação e
manutenção
Figura 1
Fonte: Adaptado de SOMMERVILLE, I. Engenharia de software, 2011

O Modelo Cascata está divido nas seguintes:

• Análise e definição de requisitos;
• Projeto de sistemas e de software;
• Implementação e testes de unidades;
• Integração e teste de sistemas;
• Operação e manutenção.

Entretanto, o Modelo Cascata apresentava alguns problemas, como:

• Sua inflexível divisão do projeto nos estágios distintos;
• Os acordos devem ser feitos em um estágio inicial do processo, e isso significa que
é difícil responder aos requisitos do cliente, que sempre se modificam;

8
 • Esse modelo deve ser utilizado somente quando os requisitos forem bem com-
preendidos.

Nesse tipo de Modelo, os testes eram somente na final, o que prejudicava a implan-
tação do Sistema, caso existisse a necessidade de alteração de algum requisito, ou se
algum requisito tivesse sido mudado devido a alguma necessidade do cliente.

Essas situações causavam a quebra do cronograma de implantação com necessidade

de aumento do prazo ou, às vezes, a decisão por implantações que precisavam de ge-
renciamento de mudanças em sequência.

Desenvolvimento em Espiral
O Desenvolvimento em Espiral foi criado por Barry Boehm, em 1988, por meio do
artigo A Spiral Model of Software Development and Enhancement. Nesse modelo, ele
discutia sobre o desenvolvimento iterativo e incremental do software.

Apresentava uma iteração de 6 meses a dois anos, em que seu modelo possuía 04 prin-
cipais atividades – definição de objetivos, planejamento, desenvolvimento e validação, ava-
liação e redução de riscos –, sendo utilizado com maior frequência em projetos grandes.

Possui algumas vantagens que podem ser consideradas, como:

• Estimativas mais realísticas;
• Versátil para lidar com mudanças;
• Otimização do tempo de implementação do sistema;
• Facilidade de decisão e de teste;

Algumas desvantagens podem ser também elencadas:

• Maior ênfase na fase funcional;
• Exigência quanto avaliação de riscos;
• Aplicado a sistemas grandes;
• Sem muita utilização.

Figura 2
Fonte: Adaptado de SOMMERVILLE, I. Engenharia de software. 9, 2011

9
9
UNIDADE
Introdução a Modelos Tradicionais de Gestão em Projetos

RUP – Rational Unified Process

O Modelo RUP – Rational Unified Process foi criado na década de 1980 pela empre-
sa Rational Software Corporation, fundada por Paul Levy e Mike Devlin.

O RUP foi criado como uma metodologia para controlar grandes projetos de software,
sendo aprimorado durante o passar dos anos.
O Rational Unified Process – RUP é um exemplo de modelo de
processo moderno, derivado de trabalhos sobre a UML e o Unified
Software Development Process associado [...]. Ele reúne elementos
de todos os modelos de processo genéricos, ilustra boas práticas na
especificação e no projeto e apoia a prototipação e a entrega incre-
mental. (SOMMERVILLE, 2011, p. 34)

Foi adquirido pela IBM, e teve seu nome alterado para IRUP – IBM Rational
Unified Process.

Fornece técnicas de boas práticas focando no aumento da produtividade e utiliza a

abordagem de Orientação a Objetos, sendo projetado para que fosse documentado uti-
lizando a notação UML – Unified Modeling Language.

É considerado um tipo de gerenciamento pesado que depende de grandes equipes em

grandes projetos, entretanto, apresenta fácil adaptação aos projetos de pequena escala.

Apresenta uma solução disciplinada de atribuição de tarefas e responsabilidades e se

baseia nos 4P, ou seja: Pessoas, Projeto, Produto e Processo.

Iteração de fase

Concepção Elaboração Construção Transição

Figura 3
Fonte: adaptado de SOMMERVILLE, I. Engenharia de software, 2011

MSF – Microsoft Solutions Framework

O MSF – Microsoft Solutions Framework, criado em 1994, é um conjunto de boas
práticas selecionadas pela Microsoft com base em suas experiências em desenvolvimento
de software.

Apresenta-se como um modelo evolutivo, sendo um framework flexível utilizado

como guia no desenvolvimento de projetos de software. Suas principais características

10
estão focadas em papéis bem definidos, com a definição e implantação das melhores
práticas em fluxos de trabalho e atividades do projeto.

O MSF possui duas variações: uma abordando processos tradicionais ou clássicos e

outra versão abordando a metodologia ágil, onde é chamado de MSF for Agile Software
Development, em que apresenta práticas de forma mais simplificada.

antar
m p l
I

Vis
u
ali
zação
Estabilizar

MSF

jar
Con a n e
stru
ir Pl
Figura 4

O MSF apresenta flexibilidade para entregar soluções de tecnologia com rapidez,

com equipe menor e menor nível de riscos, com maior qualidade.

Auxilia as equipes a focar diretamente as causas mais comuns de falhas de projetos

de tecnologia, otimizando índices de sucesso, melhorando a qualidade da solução e no
impacto nos negócios.

No MSF, existe o objetivo principal em:

• Alinhar metas de negócios com os de tecnologia;
• Estabelecer de forma clara e objetiva as metas, as funções e as responsabilidades
dentro do projeto;
• Implementar um processo iterativo, com marcações controladas por pontos
de verificação;
• Gerenciar o risco de forma proativa;
• Alterar a forma efetiva de mudança.

Desenvolvimento Ágil
O desenvolvimento de software ágil surgiu na metade da década de 1990, em reação
aos modelos de desenvolvimentos tradicionais, principalmente o Cascata.

Os métodos ágeis procuram diminuir o risco pelo desenvolvimento do software, visto

fazer isso em curtos períodos, denominados de iteração, sendo de uma semana até quatro.

11
11
UNIDADE
Introdução a Modelos Tradicionais de Gestão em Projetos

Cada iteração é um miniprojeto, ou seja, possui um objetivo que se inicia e tem seu
devido fim, onde se incluem as tarefas de implantação e também o incremento de uma
nova funcionalidade, com as seguintes fases internas: planejamento, análise de requisi-
tos, projeto, codificação, teste e documentação.

A diferença entre esses métodos e um processo tradicional é que cada iteração não
precisa estar focada em adicionar o seu conjunto de funcionalidades ao projeto como
um todo.

O projeto de software ágil tem como finalidade implantar uma nova versão ao fim de
cada iteração, sendo que nessa etapa a equipe reavalia as prioridades do projeto.

Nos métodos ágeis, existe uma ênfase muito grande nas comunicações que precisam
ser geralmente presenciais, ao invés de meios digitais.

Na maior parte das vezes, o time do projeto ágil deve estar agrupado em um mesmo
local ou sala, incluindo toda a equipe necessária para a elaboração do software, como:
desenvolvedores, gerentes, analistas de negócio, clientes, testadores e técnicos ou auxi-
liares.

Um dos pontos negativos dessa metodologia é a produção de pouca documentação.

Figura 5
Fonte: Adaptado de SOMMERVILLE, I. Engenharia de software, 2011

Modelos Tradicionais para Gestão

• PDCA (Plan, Do, Check, Action – Planejar, Fazer, Verificar e Agir)
• PMBoK (Project Management Body of Knowledge – Guide to the Project Mana-
gement Body of Knowledge)
• PRINCE2 (PRojects IN Controlled Environments – Projetos em ambientes controlados)

12
 Um projeto pode ser definido como:
• Um processo único, que tem atividades e operações coordenadas e controladas
e datas de início e término, com um único objetivo, que deve seguir os requisitos
especificados pelo cliente, com limitações e restrições de tempo, custo e recursos.

Observe as fases de um projeto tomando por base a Figura:

Figura 6 – Evolução do projeto de construção de estádio para a Copa do Mundo

Fonte: CARVALHO, F. C. A. Gestão de Projetos, Pearson, 2014

Existem modelos tradicionais de Gerenciamento de Projetos, dentre eles, o PDCA, o

PMBOK e o PRINCE2.

Podemos falar que PDCA é:

• Plan, Do, Check, Action (Planejar, Fazer, Verificar e Agir), e está entre as princi-
pais ferramentas que deram origem às demais conhecidas nas melhores práticas de
gestão feitas pelas empresas.

O PDCA foi criado em meados da década de 1920:

• Seu mentor Walter A. Shewart teve ajuda de outros profissionais, que logo foi apli-
cada na área da qualidade por William Edward Deming e, assim, tornou-se o mais
popular framework de gestão.

Componentes Plan, Do, Check, Action (Planejar, Fazer, Verificar e Agir):

• O planejamento com seu artefato conhecido como plano ajuda na previsibilidade
e visão das atividades a serem cumpridas de acordo com o dimensionamento da
equipe e permite uma garantia de melhor gestão.
• No tocante à execução do que foi planejado e formalizado no documento “plano”,
devem-se efetuar as atividades conforme o que foi estabelecido em cronograma jun-
tamente com seus recursos. Na execução, podem aparecer restrições durante todo
o ciclo de vida do projeto, e esse framework permite a possibilidade de adaptar-se
conforme a necessidade para, assim, garantir o sucesso.

13
13
UNIDADE
Introdução a Modelos Tradicionais de Gestão em Projetos

• A forma encontrada para manter o projeto nos trilhos pode ser utilizada na etapa da
verificação, que ajuda no monitoramento e controle do projeto com possibilidades de
reavaliação e previsão de ações pertinentes à correção quando houver necessidade.
• O cerne das atividades está contemplado nessa etapa, pois se permite que, ao se
deparar com situações diárias de problemas, deve-se interagir com ações assertivas
pontuais e com qualidade para alcançar a excelência do projeto.

Podemos falar que PMBoK é:

• Project Management Body of Knowledge ou Universo de Conhecimento em Ge-
rência de Projetos, desenvolvido pelo PMI – Project Management Institute;
• Representa o conjunto de melhores práticas sobre gerenciamento de projetos, ou
seja, framework ou identificado como guia para os profissionais da área.

O PMBOK foi desenvolvido pelo PMI – Project Management Institute que:

• É uma instituição sem fins lucrativos, dedicada à promoção do gerenciamento
de projetos.
• Fundada em 1969, na Pensilvânia (Estados Unidos), está presente em 185 países e
possui mais de 500 mil associados.
• É uma referência mundial na gestão de projetos.

O PMBOK auxilia a criação do PMO – Project Management Office, ou seja, o Escri-

tório de Projeto que determina:
• Treinamentos;
• Softwares;
• Padronização de políticas;
• Procedimentos para cada fase.

O PMBOK também auxilia o gerente de projeto a analisar os custos, a utilização dos

recursos dos projetos e sua viabilidade, que pode ser representada de forma gráfica, como:

Figura 7 – Gráfico do nível de consumo de recursos humanos ao longo do ciclo de vida do projeto
Fonte: Adaptado de CARVALHO, F. C. A. Gestão de Projetos, Pearson, 2014

14
 O PMBOK apresenta o inter-relacionamento de seus componentes representados por
meio da imagem:

Ciclo de vida do projeto

Início do Organização Execução Terminar

projeto e preparação do trabalho o projeto

Grupo de processos

Processos Processos de Processos de Processos de Processos de

planejamento execução monitoramento encerramento
de iniciação controle

10 Áreas de Conhecimento

Revisão Fase de Uso Linha de

Chave: projeto Potencial tempo
de fase

Figura 8
Fonte: Adaptado de Project Management Institute. 6. ed.
Um Guia do Conhecimento em Gerenciamento de Projetos, 2017

Sendo que os conceitos do PMBOK serão abordados no Tópico 3, item: Fundamen-

tos do PMBOK.

PRINCE2 (Projects IN Controlled Environments – Projetos em ambientes controlados).

O PRINCE2 é:
• Um método de gerenciamento de projetos mais amplamente adotado no mundo,
usado por pessoas e organizações de setores e setores de grande porte;
• Um método flexível que orienta o essencial para gerenciar projetos bem sucedidos,
independentemente do tipo ou escala.

O método PRINCE2 possui: 07 princípios, 07 temas e 08 processos.

Sobre os Princípios do PRINCE2:

São os requisitos orientadores e as boas práticas que determinam se o projeto está

sendo gerenciado genuinamente usando o PRINCE2.

Existem 07 princípios e, a menos que todos sejam aplicados, não é um projeto

do PRINCE2.

15
15
UNIDADE
Introdução a Modelos Tradicionais de Gestão em Projetos

Quanto aos temas do PRINCE2:

Descrevem aspectos do gerenciamento de projetos que devem ser abordados em

paralelo ao longo do projeto.

Os 07 temas explicam o tratamento específico para várias disciplinas de gerencia-

mento de projetos e por que eles são necessários.

Ajuda a aplicarem os temas, indicando o requisito mínimo necessário para cada tema,
e fornece orientações específicas sobre como adaptá-los a determinados ambientes.

A respeito dos processos do PRINCE2:

Descrevem as etapas do ciclo de vida do projeto, desde a ideia inicial até o fechamento
do projeto (e a medição dos benefícios).

Cada processo fornece listas de verificação de atividades recomendadas, responsabi-

lidades relacionadas e orientação sobre como adaptar a um ambiente específico.

Que são: criando um projeto, dirigindo um projeto, iniciando um projeto, geren-

ciando as fronteiras de um estágio, controlando um estágio, gerenciando a entrega do
produto, fechando um projeto e planejamento.

O PRINCE2 apresenta a seguinte estrutura:

Ambiente do Projeto
Caso comercial
Progresso Organização

Processos PRINCE2
Mudança Qualidade

Risco Planos

Temas PRINCE2

Princípios PRINCE2

Figura 9
Fonte: Adaptado de AXELOS. (2017) Managing successful
projects with PRINCE2. Norwich: TSO (The Stationery Office)

Esses detalhes serão abordados no Tópico 3, item: PRINCE2 (PRojects IN Controlled

Environments – Projetos em ambientes controlados).

Aqui um exemplo de processo a ser descrito pelo PRINCE2 em seu ciclo de vida:

16
 Estado(s)
Pré-projeto Estágio Inicial subsequente Estágio Final Pós-projeto

Fornecer o Corporativo, gerenciamento de programas ou cliente Revisão dos resultados

mandato do e benefícios
projeto Garantir o alinhamento transição do projeto
Direção

Dirigindo um projeto

Iniciando
um

Ambiente do projeto
projeto Gerenciando Gerenciando
um limite um limite Fechando
Gerenciando

de estágio de estágio um projeto

Iniciando Controlando Controlando

um projeto um estágio um estágio
Entregando

Gerenciando a Gerenciando a
entrega do produto entrega do produto

Ciclo de Vida
do projeto

Figura 10
Fonte: Adaptado de AXELOS. (2017) Managing successful
projects with PRINCE2. Norwich: TSO (The Stationery Office)

Conceitos
• Fundamentos do framework PMBoK;
• Fundamentos do framework PRINCE2;
• Diferenças entre as versões PMBoK e PRINCE2.

Fundamentos do framework PMBoK

A estrutura do PMBOK é divida em 03 partes:
• Guia do conhecimento em gerenciamento de Projetos (Guia PMBOK);
• Padrão de Gerenciamento de Projetos;
• Apêndices, glossário e índice remissivo.

As fases do Gerenciamento do Projeto pelo PMBOK são 04, que são:

• Início do projeto;

17
17
UNIDADE
Introdução a Modelos Tradicionais de Gestão em Projetos

• Organização e preparação;
• Execução do trabalho;
• Terminar o projeto.

Os processos no PMBOK estão agregados em 05 grandes grupos:

• Iniciação;
• Planejamento;
• Execução;
• Monitoramento e Controle;
• Encerramento.

Sendo 10 as áreas de conhecimento do PMBOK:

• Gerenciamento da integração do projeto;
• Gerenciamento do escopo do projeto;
• Gerenciamento do cronograma do projeto;
• Gerenciamento dos custos do projeto;
• Gerenciamento da qualidade do projeto;
• Gerenciamento dos recursos do projeto;
• Gerenciamento das comunicações do projeto;
• Gerenciamento dos riscos dos projetos;
• Gerenciamento das aquisições do projeto;
• Gerenciamento das partes interessadas do projeto.

Fundamentos do framework PRINCE2

O PRINCE2 aborda o gerenciamento de projetos com 04 elementos integrados:
• Princípios;
• Temas;
• Processos;
• Ambientes do Projeto.

Os princípios do PRINCE2 são:

• Justificativa contínua do negócio;
• Aprender com a experiência;
• Definir papéis e responsabilidades;
• Gerenciar por estágios;
• Gerenciar por exceção;

18
 • Foco no produto;
• Customização ou adaptação (tailor).

Pelo PRINCE2 são 07 os temas:

• Business Case;
• Organização;
• Qualidade;
• Planos;
• Risco;
• Mudança;
• Progresso.

Os processos do PRINCE2 são 08, que são:

• Criando um projeto;
• Direcionando um projeto;
• Iniciando um projeto;
• Gerenciando as fronteiras de um estágio;
• Controlando um estágio;
• Gerenciando a entrega do produto;
• Fechando um projeto e;
• Planejamento.

Diferenças entre as versões PMBoK 5ª edição e 6ª edição

• Tem uma novidade quanto à agilidade na execução de projetos. As práticas ágeis
estão diretamente ligadas às áreas de conhecimento em diversos ambientes.
• A organização da entrada, ferramentas, técnicas e saídas, que ficam agrupadas.
• Mais ênfase ao conhecimento estratégico e de negócios, incluindo discussões de
documentos empresariais e gestão de projetos.
• O novo modelo traz 04 seções introdutórias em cada área de conhecimento, que são:
» Conceitos-chave;
» Tendências e práticas emergentes;
» Considerações de adaptação;
» Abordagens para ambientes ágeis, interativos e adaptativos.

Foram incluídos 03 processos na 6ª edição do PMBOK:

• Gerenciar o Conhecimento do Projeto;

19
19
UNIDADE
Introdução a Modelos Tradicionais de Gestão em Projetos

• Implementação de Respostas aos Riscos;

• Controlar Recursos.

Algumas áreas mudaram de nome, como:

• De: Gerenciamento de Tempo para Gerenciamento de Cronograma;
• De: Planejar o Gerenciamento Recursos Humanos para Planejar o Gerenciamento
de Recursos;
• De: Realizar a Garantia da Qualidade para Gerenciar a Qualidade;
• De: Controlar as Comunicações para Monitorar as Comunicações;
• De: Controlar Riscos para Monitorar Riscos;
• De: Planejar o Gerenciamento das Partes Interessadas para Planejar o Engajamen-
to das Partes Interessadas;
• De: Controlar o Gerenciamento das Partes Interessadas para Monitorar o Engaja-
mento das Partes Interessadas.

Diferenças entre as versões PRINCE2 e PRINCE2 Agile:

Quanto à versão PRINCE2 Agile, podemos citar que:

• É a solução de gerenciamento ágil de projetos mais completa do mundo, combinan-
do a flexibilidade e capacidade de resposta ágil com a governança do PRINCE2.

E podemos citar que as vantagens do PRINCE2 Agile são:

• Permitir que você se concentre no gerenciamento e na entrega;
• Funcionar com qualquer abordagem ágil estabelecida;
• Permitir que você seja pontual e atinja os prazos de forma mais consistente;
• Ser um projeto de colaboração que é corporativo;
• Dimensionar para seus requisitos e pragmatismo precisos;
• Aumentar a confiança das partes interessadas;
• Apresentar ferramentas adicionais para gerenciar e reagir aos requisitos em cons-
tante mudança.

20
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
PMBOK
[Link]

Leitura
Modelo Cascata
[Link]
MSF – Microsoft Solutions Framework
[Link]
PRINCE2
[Link]
Diferença entre as versões do PMBOK 6ª edição
[Link]

21
21
UNIDADE
Introdução a Modelos Tradicionais de Gestão em Projetos

Referências
AMARAL, D. C. et al. Gerenciamento ágil de projetos: aplicação em produtos inova-
dores. São Paulo, 2011.[U1]

AXELOS. (2017). Managing successful projects with PRINCE2 (2017 ed.). Norwich:
TSO (The Stationery Office).

CRUZ, F. Scrum e Agile em Projetos: guia completo. 2. ed. Brasport, São Paulo,
2018.[U2]

FOGGETTI, C. Gestão ágil de projetos/Cristiano Foggetti. São Paulo: Education do

Brasil, 2014. (Coleção Bibliografia Universtitária Pearson).

JUGEND, D. Gestão de projetos: teoria, prática e tendências. Elsevier Brasil[U3],

São Paulo, 2016.

MASSARI, V. Agile Scrum Master no Gerenciamento Avançado de Projetos. Brasport,

São Paulo, 2016.

PMI. Project Management Institute. Um Guia do Conhecimento em Gerenciamento

de Projetos (Guia PMBOK). 6. ed. Newtown Square, PA, 2017.

ROZENFELD, H.; AMARAL, D. C. Gestão de Projetos em Desenvolvimento de

Produtos. São Paulo: Saraiva, 2006.

SABBAGH, R. Scrum: Gestão ágil para projetos de sucesso. Casa do Código, São
Paulo, 2014.

22
Gerenciamento
Inserir Título Aqui
de
Inserir Título
Projetos ÁgeisAqui
Introdução em Modelos Gerenciamento Ágeis

Responsável pelo Conteúdo:

Prof. Me. Luiz Lima

Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
 Introdução em Modelos Gerenciamento Ágeis

Fonte: Getty Images

Nesta unidade, trabalharemos os seguintes tópicos:
• O Manifesto Ágil;
• Scrum;
• Extreme Programming;
• Lean Manufacturing – Sistema Toyota de Produção;
• Sistema Kanban;
• Fundamentos do PMBOK enfoque Ágil;
• Fundamentos do PRINCE2 Enfoque Ágil ou PRINCE2 Agile.

Objetivo
• Desenvolver o conhecimento da metodologia ágil, seus tipos e suas características, bem
como enfoque sob ótica do PMBOK e PRINCE2.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o úl-
timo momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

Contextualização
Nossa situação-problema central proposta para a unidade é baseada em um Projeto
de Desenvolvimento de um App (aplicativo) SEJ para uma empresa de Seguros que quer
atingir o nicho de mercado do público jovem.

Nesta Unidade existem 3 abordagens que devem ser verificadas pelo aluno:
• Decidir quais dos tipos de modelos ágeis melhor se adequaria neste projeto.
• Decidir como os fundamentos do PMBOK podem auxiliar este projeto com enfo-
que ágil.
• Decidir como os fundamentos do PRINCE2 Agile podem auxiliar este projeto.

6
O Manifesto Ágil
Por que os fundamentos do Manifesto Ágil surgiram como mudanças para a forma de
Gestão de Projetos?

O Manifesto Ágil é a declaração de princípios fundamentais referente ao desenvol-

vimento ágil. Foi criado em fevereiro de 2001 por 17 profissionais que já praticavam
vários métodos ágeis.

Apresenta os seguintes valores:

• indivíduos e interações mais que processos e ferramentas;
• software em funcionamento mais que documentação abrangente;
• colaboração com o cliente mais que negociação de contratos;
• responder a mudanças mais que seguir um plano.

Os 17 profissionais são: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor,
Ken Schwaber, Jeff Sutherland e Dave Thomas.

Ken Schwaber e Jeff Sutherland criaram o Scrum; Kent Beck é o criador do

Extreme Programming; Kent Beck e Martin Fowler escreveram vários livros sobre o
Extreme Programming.

Além dos valores, o Manifesto Ágil possui 12 princípios:

• A maior prioridade é satisfazer o cliente por meio da entrega adiantada e contínua
de software com valor;
• Aceitação de mudanças de requisitos, até mesmo no fim do desenvolvimento,
pois os processos ágeis se adequam a mudanças para que o cliente possa ter
vantagem competitiva;
• O software deve ser entregue funcional, no tempo de semanas até meses, ou no
menor período;
• Durante todo o curso do projeto, as pessoas relacionadas aos negócios e desenvol-
vedores devem trabalhar em conjunto diariamente;
• Os indivíduos participantes do projeto devem se manter motivados. Para que isso
aconteça, devem ter o ambiente e suporte necessário, bem como confiar que farão
seu trabalho de forma adequada;
• As comunicações devem ser feitas pessoalmente, através de uma conversa cara a cara;
• O Software funcional é a medida primária de progresso do projeto;

7
7
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

• Os processos ágeis devem promovem um ambiente sustentável, no qual os patro-

cinadores, desenvolvedores e usuários sejam capazes de manter, indefinidamente,
passos constantes em suas atividades;
• Uma contínua atenção à excelência técnica e melhoria do design aumenta a agili-
dade do projeto;
• A simplicidade deve maximizar a quantidade de trabalho que não precisou ser realizado;
• As melhores arquiteturas, requisitos e designs ajudam a criar times auto-organizáveis;
• Em períodos regulares, o time deve reavaliar as suas atividades, ajustando-se e oti-
mizando seu comportamento acordado.

Por que os fundamentos do Manifesto Ágil surgiram como mudanças para a forma de Ges-
tão de Projetos? Principalmente porque os tipos tradicionais não apresentavam flexibili-
dade em questão de alterações de requisitos, bem como não apresentavam questões de
unidade com o cliente no desenvolvimento dos produtos e nem valorizavam as pessoas
participantes do projeto.

Scrum
A palavra Scrum tem origem no inglês, significa reinicio de jogada no rugby (é
um esporte coletivo de intenso contato físico originário da Inglaterra). O Scrum é um
framework criado para desenvolver e manter produtos complexos. Ele apresenta pi-
lares, eventos e artefatos com regras que os unem. Ken Schwaber e Jeff Sutherland
desenvolveram o Scrum e criaram o Guia do Scrum.

São os pilares do Scrum:

• transparência;
• inspeção; e
• adaptação.

Os pilares são os princípios sobre os quais o Scrum foi desenvolvido, criando um

ambiente propício para a metodologia ágil.

A transparência é considerada o primeiro pilar, pois define que o projeto deve ser
conhecido por todas as partes envolvidas.

Alguns exemplos:
• quando o Product Owner descreve por meio das User Stories as funcionalidades
para o produto;
• quando o cliente determina as prioridades dos sprints;
• quando o Scrum Master apresenta o planejamento dos sprints e o andamento dos
sprints backlogs;

8
 • quando o time comunica diariamente o andamento do trabalho na reunião diária;
• quando a equipe utiliza um kanban para atualizar e deixar explícito o andamento e
progresso do projeto;
• quando o incremento do produto é feito e o cliente pode dar um feedback antes da
entrega final do projeto.

A Inspeção é o segundo pilar, ela determina que o projeto deve ser sempre inspe-
cionado para que se tenha uma garantia de qualidade. Por ser um princípio decisivo,
pode ser utilizado dentro dos testes e também de cada sprint.

Por exemplo:
• no conceito de feito;
• na reunião de Revisão do Sprint com o product owner;
• nas estimativas play poker de Users stories;
• no final de cada reunião diária para verificar a adequação do grupo a User story;
• ao se verificar bugs e sua correção.

A adaptação é o terceiro pilar, pois o projeto precisa se adaptar à necessidade de negócio.

Por exemplo:
• no planejamento dos sprints, quando o Product Owner faz a priorização das
Users Stories;
• na reunião de Revisão da sprint, quando o Product Owner reprioriza as Users
Stories (itens do backlog).

O Scrum é o processo de desenvolvimento com uma abordagem bem compreendida

que pode ser planejada, estimada e completada com sucesso. Ele assume a imprevisibili-
dade do processo de desenvolvimento de sistemas, definindo-o como um conjunto flexí-
vel de atividades em conjunto com ferramentas e técnicas estabelecidas e viáveis com um
time de desenvolvimento para conceber e construir sistemas. Como essas atividades são
flexíveis, são usados pontos de controles para gerenciar o processo e riscos inerentes ao
processo. No Scrum existe um aprimoramento do ciclo de desenvolvimento orientado a
objetos iterativo/incremental utilizado de forma geral.

Os eventos que ocorrem no Scrum são utilizados para proporcionar regularidade e

para diminuir a necessidade de reuniões não definidas na metodologia. Todos os eventos
apresentam um horário predefinido e uma duração máxima.

Observando-se que ao iniciar um Sprint, a sua duração é fixa e não pode ser dimi-
nuída ou aumentada. Os outros eventos podem ser finalizados sempre que o objetivo do
evento é conseguido de modo a assegurar a utilização de uma quantidade adequada de
tempo, não existindo assim perdas no processo.

Deve-se entender que o Sprint é um componente para todos os outros eventos,

pois cada evento apresenta uma oportunidade formal para inspecionar e adaptar os

9
9
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

itens priorizados que estão sendo elaborados. Estes eventos são elaborados para con-
ceber ações de transparência e inspeção. A omissão de quaisquer um desses eventos
acarretará numa diminuição da transparência e também existirá perda para se inspe-
cionar e adaptar.

Os eventos do Scrum são:

• Sprint;
• planejamento da Sprint;
• reunião diária;
• revisão do sprint; e
• retrospectiva do sprint.
O Sprint é considerado o coração da metodologia Scrum, pois indica um período de
um mês ou menos durante o qual se desenvolve um item priorizado, ou seja, um incre-
mento. Cada Sprint deve apresentar durações consistentes no momento da execução.
Ao se finalizar um Sprint, por exemplo: o Sprint 0, vem imediatamente o Sprint 1,
depois o Sprint 2 e assim por diante.
Já o Planejamento do Sprint é uma reunião de cerca de 8 horas para um Sprint de 1
mês, em que o plano para execução do trabalho é criado e deve apresentar a colabora-
ção do time Scrum. O Scrum Master possui papel decisivo neste evento, pois ele deve
fazer com que todos os participantes entendam os objetivos do evento e que cumpram
corretamente a sua duração.
A reunião diária é um evento de 15 minutos e deve ser para o time de desenvolvi-
mento, e como o nome diz, deve ser realizada todos os dias durante a duração do Sprint.
Nesta reunião, ocorre o planejamento/alinhamento das atividades do time indicando o
que deve ser realizado nas próximas 24 horas. Isso aumenta a colaboração do time que
analisa a performance do dia anterior com uma inspeção do progresso para atingir o
objetivo do Sprint e fazer a avaliação para a conclusão do Sprint Backlog.
A Revisão do Sprint é uma reunião de 4 horas para um Sprint de 1 mês que ocor-
re ao se finalizar um Sprint utilizado para a inspeção do incremento e adaptação do
Product Backlog, caso haja necessidade. É uma reunião informal onde cada colaborador
informa como contribuiu para as alterações e resultados do Product Backlog durante o
Sprint. Isso serve para dar um feedback e aumentar a colaboração.
Quando se fala em Retrospectiva do Sprint, refere-se a uma reunião de 3 horas para
um Sprint de 1 mês onde ocorre a inspeção do time Scrum e também para a criação
de planos de melhoria que podem ocorrer durante o próximo sprint. O Scrum Master
deve garantir o entendimento dos objetivos da reunião pelos participantes para criar
uma situação positiva e produtiva. Ele também deve conseguir manter o tempo adequa-
do da reunião.

Os artefatos produzidos no projeto Scrum são:

• Product backlog;
• Sprint backlog; e
• Incremento.

10
 O Product Backlog é uma lista organizada dos itens necessários para o produto.

O Product Backlog deve ser uma lista única para consulta dos requisitos, sendo o
Product Owner o responsável por este artefato, bem como: seu conteúdo, a sua dispo-
nibilidade e seu formato ordenado.

Já o Sprint Backlog deve ser considerado como os itens internos do Product Backlog.

O Sprint Backlog deve ser elencado para o Sprint (que deve durar de 2 a 4 semanas).

Juntamente com o Sprint Backlog, o plano de entrega para concretização do Obje-

tivo do Sprint também deve acompanhá-lo.

Sendo uma previsão dada pela equipe de desenvolvimento para as funcionalidades

integrantes do próximo incremento.

Pode-se concluir que um incremento, que é um bloco de trabalho concluído ao fim de

cada Sprint e que pode ser inspecionado.

O incremento adiciona todos os itens que compõem o Product Backlog, os já con-

cluídos durante o Sprint atual em conjunto com os incrementos dos Sprints anteriores,
sendo que este conjunto deve estar utilizável.
“O Scrum tem sido usado para desenvolver software, hardware,
software embutido, redes de funções interativas, veículos autónomos,
escolas, governos, marketing, gerir a operação de organizações e qua-
se tudo que usamos no nosso dia a dia, como indivíduos e socieda-
des.” (SUTHERLAND; SCHWABER, 2017)

Extreme Programming
O Extreme Programming é também chamado de XP, foi criado em 1997 por Kent
Beck, sua metodologia apresenta foco em agilidade de equipes e qualidade de projetos,
sendo uma metodologia baseada em comportamentos e atitudes.

Baseado nos seguintes princípios:

• feedback rápido;
• presumir simplicidade;
• mudanças incrementais;
• abraçar mudanças; e
• trabalho de alta qualidade.

Baseado nos seguintes valores:

• comunicação;
• simplicidade;
• feedback;

11
11
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

• coragem; e
• coach.

Seus processos são:

• planejamento;
• projeto (“designing”);
• codificação; e
• testes.

As práticas do Extreme Programming são:

• pair programming;
• projeto simples;
• teste;
• refatoração;
• propriedade coletiva;
• interação contínua;
• cliente presente;
• semana de 40 horas;
• padrões de código;
• metáfora; e
• reunião diária.

No Pair Programming, todo o desenvolvimento do código do sistema deve ser escrito por
dois programadores conjuntamente, ocorrendo maior produtividade e menos erros. Com o
rodízio de pares, pode-se melhorar a comunicação e o relacionamento entre o time.

É mais adequado a pequenas e médias empresas e, quando usado, deve-se manter a

disciplina para que ele auxilie os negócios da empresa eficazmente. O time é formado
por até 10 colaboradores e estes devem manter-se atualizados de todas as fases do tra-
balho que está sendo realizado, bem como efetuar testes de forma produtiva, visando
o aprimoramento da qualidade do projeto para que se atinja os objetivos selecionados.

O Extreme Programming é recomendado a:

• Grupos de 2 a 10 pessoas;
• O Projeto deve ser de até 3 anos;
• O programa deve ser de 1000 a 250.000 linhas de código;
• Alguns papéis do método XP;
• Programadores;
• Treinadores (coach);

12
 • Acompanhador (tracker);
• Cliente.

Na fase de Exploração do XP:

• Dura 2 a 6 meses;
• Termina ao se entregar a primeira versão do software ao cliente;
• Os clientes escrevem Story Cards;
• Os programadores interagem com os clientes discutindo sobre as tecnologias;
• Experimentam diferentes tecnologias e arquiteturas;
• Planejamento de 1 a 2 dias.

Lembra-se que conversamos sobre o MSF na unidade anterior? O que significa MSF? Quan-
do foi criada? E para que serve?

MSF – Microsoft Solutions Framework

O MSF – Microsoft Solutions Framework é considerado um guia para o desenvolvi-
mento de softwares que foi criado pela empresa Microsoft em 1994. É um concorrente
do RUP – Rational Unified Process e do XP – Extreme Programming, mas em um
projeto MSF existe a regência por iterações.

O MSF versão 3.0 apresentava 04 elementos básicos:

• Princípios Fundamentais;
• Modelo de Processo;
• Modelo de Equipe; e
• Mindsets ou disciplinas.

Princípios:
• Parceria com clientes;
• Comunicação aberta;
• Visão compartilhada;
• Qualidade é muito importante para o trabalho;
• Metodologia ágil com adaptação a mudança;
• Fluxo de valor.

Apresenta os seguintes processos:

• Integrar planejamento e condução da mudança de controle;
• Definir e gerenciar o escopo do projeto;

13
13
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

• Preparar um orçamento e gerenciar os custos;

• Preparar e acompanhar os horários;
• Garantir que os recursos são atribuídos à direita do projeto;
• Gerir contratos e vendedores de projeto e adquirir recursos;
• Facilitar a equipe e comunicações externas;
• Facilitar o processo de gestão do risco; e
• Documentar e monitorar a qualidade da equipe do processo de gestão.

Com o objetivo de se definir os papéis e as responsabilidades da equipe, o MSF

desenvolveu o Modelo de Equipe.

Gerenciamento
de Programa –
Gerente do Projeto
Gerenciamento
do produto – Arquitetura
Analista – Arquiteto
de Negócio

MSF
Experiência do
Desenvolvimento
usuário – Analista
– Desenvolvedor
do Negócio

Operações de
atualização –
Teste – Teste
Gerente de
atualização

Figura 1 – Papéis e Responsabilidades da Equipe

No MSF foram elencados 08 mindsets ou disciplinas:

• Qualidade é definida pelo cliente;
• Orgulho do trabalho individual;
• Equipe de pares;
• Entregas frequentes de versões;
• Desejo de aprender;
• Tornar-se específico rapidamente;
• Qualidade de serviço;
• Cidadania.

14
 O MSF na versão 4.0 foi publicado em duas metodologias:
• Uma tradicional, o MSF for CMMI Process Improvement;
• Uma ágil, o MSF for Agile Software Development.

Lean Manufacturing – Sistema

Toyota de Produção
A Lean Manufacturing, também chamada de manufatura enxuta ou manufatura es-
belta, é também chamada de Sistema Toyota de Produção.

O Lean Manufacturing foi criado por Taiichi Ohno, engenheiro da empresa Toyota,
no Japão, no pós-segunda guerra mundial, sendo seus precursores: Sakichi Toyoda,
fundador do Grupo Toyoda em 1902; Kiichiro Toyoda, filho de Sakichi Toyoda, que en-
cabeçaram as operações de manufatura de automóveis entre 1936 e 1950; em conjunto
também com Eiji Toyoda.

O Sistema de Lean Manufacturing é um conjunto de atividades com o objetivo

principal na otimização da capacidade de respostas às mudanças e diminuição de
perdas na Produção.

Sua concepção é de uma filosofia de gestão baseada na diminuição em 07 tipos

de desperdícios:
• Superprodução;
• tempo de espera;
• transporte;
• excesso de processamento;
• inventário;
• movimento; e
• defeitos.

Apresenta os seguintes princípios:

• melhoria contínua; e
• respeito a pessoas.

Sistema Kanban
O Sistema Kanban foi criado por Taiichi Ohno, em 1953, e possui o significado de
“cartão visual”. Muitas vezes é confundido com o Sistema Toyota de Produção devido
ter sido criado pelo mesmo autor.

15
15
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

O Sistema Kanban apresenta os princípios de:

• visualização da cadeia de valor;
• desenvolvimento evolucionário (adaptativo);
• restrição do trabalho; e
• seu progresso em torno de seus estágios.

No Kanban existe a identificação de seus estágios de trabalho conforme:

• TO DO (a fazer);
• DONE (feito);
• WIP – Working in progress (trabalho em andamento).

No Kanban pode-se definir limites de tempo que os cartões podem ficar em determi-
nados estágios, ou seja, delimitar o tempo para cada atividade.

Identifica suas classes de trabalho:

• User stories (histórico dos usuários);
• Bug (erro);
• Defeito;
• Melhoria;
• Teste;
• Requisito.

O Kanban apresenta 5 regras básicas para sua efetiva utilização:

• 1ª regra: o processo subsequente deve ser retirado; no processo precedente, os
produtos necessários devem apresentar as quantidades necessárias e no ponto ne-
cessário de tempo;
• 2ª regra: o processo precedente deve ser capaz de produzir os seus produtos nas
quantidades requisitadas pelo processo subsequente;
• 3ª regra: os produtos com defeitos não devem passar para o processo subsequente;
• 4ª regra: o número de “cartões visuais” deve ser minimizado;
• 5ª regra: deve ser utilizado para adaptar pequenas flutuações na demanda, ou seja,
quando existe alto sincronismo da produção.

Fundamentos do PMBOK enfoque Ágil

O PMBOK continua tendo as 10 áreas de conhecimento e os 5 grupos de processos
atuais foram mantidos (com ênfase na gestão do conhecimento), entretanto agora exis-
tem 49 processos.

16
 A estrutura do livro PMBOK continua dividida em 03 partes igual no enfoque
ágil, apresentando:
• Guia do conhecimento em gerenciamento de Projetos (Guia PMBOK);
• Padrão de Gerenciamento de Projetos;
• Apêndices, glossário e índice remissivo.

As fases do Gerenciamento do Projeto pelo PMBOK com enfoque ágil são 04:
• Início do projeto;
• Organização e preparação;
• Execução do trabalho;
• Terminar o projeto.

Os processos no PMBOK com enfoque ágil estão agregados em 05 grandes grupos:

• Iniciação;
• Planejamento;
• Execução;
• Monitoramento e Controle;
• Encerramento.

Ocorreu um aprofundamento referente ao enfoque ágil em cada uma das 10 áreas de

conhecimento do PMBOK:
• Gerenciamento da integração do projeto;
• Gerenciamento do escopo do projeto;
• Gerenciamento do cronograma do projeto;
• Gerenciamento dos custos do projeto;
• Gerenciamento da qualidade do projeto;
• Gerenciamento dos recursos dos do projeto;
• Gerenciamento das comunicações do projeto;
• Gerenciamento dos riscos dos projetos;
• Gerenciamento das aquisições do projeto;
• Gerenciamento das partes interessadas do projeto.

A novidade é que em cada área do conhecimento foram inseridas 04 seções introdutórias:

• Conceitos-chave;
• Tendências e práticas emergentes;
• Considerações de adaptação;
• Abordagem para ambientes Ágeis, iterativos e adaptativos.

17
17
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

Na nova versão, os três primeiros capítulos do PMBOK foram reescritos:

• No capítulo 1, todas as informações das versões anteriores foram mantidas, mas
existe uma evolução quanto à profissão focada na mudança organizacional e como
meio de fornecer valor ao negócio.
• O capítulo 2 explica a influência do ambiente de trabalho, pois para o sucesso do pro-
jeto deve-se alinhar a abordagem da gestão do projeto com a realidade da empresa.
• No capítulo 3, dedicado ao papel e as competências do gerente de projeto, são
detalhadas as habilidades técnicas, estratégicas e de liderança.

Nesta versão ocorreu a expansão das estruturas organizacionais, além do PMO –

Project Management Office, sendo que agora as estruturas são:
• Funcional;
• Matricial;
• Projetizada;
• Orgânica;
• Multidivisional;
• Virtual; e
• Híbrida.

Ocorreu a ampliação da utilização de métodos e conceitos ágeis:

• Nas práticas ágeis existem mais ênfase no conhecimento de negócios e requisitos;
• Detalhe em cada área de conhecimento das práticas ágeis amplamente utilizadas
em ambientes adaptativos;
• Criou-se um Apêndice Agile para cada área de conhecimento, com detalhes de
como cada área está associada, integrada e beneficiada com a utilização da abor-
dagem Agile;
• Inclusão de um ciclo de vida híbrido.

Nesta versão do PMBOK foram aprimorados os conceitos em documentos e para a

avaliação da excelência/sucesso do projeto detalhando-se, itens como:
• Caso de Negócio;
• Plano de gerenciamento de benefícios;
• Termo de Abertura;
• Plano de Gerenciamento;
• Medidas de excelência/sucesso do projeto.

18
 Ocorreram uma melhor organização das entradas, ferramentas e técnicas e saídas:

• Componentes do Plano;

• Exemplos de documentos;

• Atualizações de documentos;

• Entradas e saídas simplificadas: com tabela para cada processo;

• O Plano do Projeto deve ser a entrada para: o Plano de Gerenciamento de Es-

copo, o Plano de Gerenciamento de Requisitos e o Plano de Gerenciamento das
Partes Interessadas;

• Plano do Projeto atualizou a saída para: o Plano de Gerenciamento de Escopo

Atualizado, o Plano de Gerenciamento de Requisitos Atualizado, o Plano de Geren-
ciamento das Partes Interessadas Atualizado.

Existe a adaptação dos Processos:

• As necessidades do projeto determinarão os documentos reais do projeto;

• Significa analisar o projeto para determinar quanta ênfase colocar em casa proces-
so (com base no escopo e tamanho do projeto).

Ocorre também a diferenciação entre monitorar e controlar:

• Visto que o Monitorar atende ao Check do ciclo PDCA, enquanto o Controlar aten-
de ao Act do ciclo PDCA;

• Em alguns processos foi alterada a nomenclatura “Controlar” ou “Monitorar” para

“Controlar e Monitorar”;

• No conceito de Monitorar existe a análise contínua do progresso do projeto nos

níveis de atividades e resultados/produtos;

• Enquanto que no conceito de controlar, este utiliza informações de monitoramento

para a tomada de decisão (no redirecionamento do projeto, no ajuste das atividades,
dos resultados, ou até mesmo para criar um redesenho do projeto).

Maior ênfase no Gerenciamento de Requisitos:

• Foi reforçado o processo de coletar requisitos com as informações do Practice

Guide for Business Analysis;

A Figura a seguir apresenta a diferenciação do PMBOK tradicional com o PMBOK

com ênfase ágil:

19
19
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

Modelo Tradicional Modelo Ágil

Fixo Fixo Fixo
Escopo Tempo Custo

Foco no
aumento de
valor
Foco no
Planejamento

Tempo Custo Escopo

Flexível Flexível Flexível
Figura 2 – Gerenciamento de Projetos Tradicional × Gerenciamento Ágil
Fonte: Adaptado de BILSEL

Fundamentos do PRINCE2
Enfoque Ágil ou PRINCE2 Agile
Lembra-se que conversamos sobre o PRINCE2 na unidade anterior? O PRINCE2 é igual ao
PRINCE2 Agile?

O PRINCE2 Agile foi publicado pela AXELOS em junho de 2015. Ele é um fra-
mework de gerenciamento ágil de projetos que combina a flexibilidade e capacidade de
resposta ágil com a governança do PRINCE2. E fornece estrutura, controle e controle
ao trabalhar com conceitos, métodos e técnicas ágeis. Ele foi projetado para auxiliar os
profissionais a se adaptar aos controles de gerenciamento para trabalhar em um ambien-
te ágil, ajudando a compreender os requisitos de governança do PRINCE2, bem como a
interface do PRINCE2 com as formas de trabalho ágeis.

Lembra-se que conversamos sobre o PRINCE2 na unidade anterior? O PRINCE2 é igual ao

PRINCE2 Agile? O PRINCE2 é uma metodologia flexível para gerenciar projetos a serem bem
sucedidos, independentemente do tipo ou escala. Já o PRINCE2 Agile é uma metodologia
baseada no desenvolvimento ágil.

PRINCE2 Agile considera o ágil como uma família de comportamentos, conceitos,

frameworks e técnicas.

A importância do PRINCE2 Agile é ressaltada devido à:

• Permissão que se concentre no gerenciamento e na entrega;

20
• Funciona com qualquer abordagem ágil estabelecida;
• A pontualidade e que atinja os prazos de forma mais consistente;
• Ser um projeto de colaboração que é corporativo;
• Permissão de dimensionar para seus requisitos e pragmatismo precisos;
• Aumentar a confiança das partes interessadas;
• Às ferramentas adicionais para gerenciar e reagir aos requisitos em constante mudança.

As fases técnicas também chamados de estágios técnicos são:

• Análise;
• Projeto;
• Construção;
• Teste; e
• Implementação.

Os critérios de aceitação são:

• Um termo geralmente usado no agile para avaliar se uma história do usuário (user
stories) foi concluída.
• É o equivalente a critérios de qualidade em PRINCE2 e Definição de Feito em Scrum.

As linhas de base dele são:

• Plano de Revisão de Benefícios;
• Caso de Negócio;
• Estratégia de Gestão de Comunicação;
• Estratégia de Gerenciamento de Configuração;
• Plano (incluindo Plano de Projeto, Plano de Estágio e Plano de Equipe);
• Descrição do Produto;
• Resumo do projeto;
• Documentação de iniciação de projeto ou PID;
• Descrição do Produto do Projeto;
• Estratégia de Gestão da Qualidade;
• Estratégia de Gerenciamento de Risco;
• Pacote de trabalho.

A forma dos registros são:

• Registro de Item de Configuração;

21
21
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

• Log diário;
• Registro de Emissão;
• Registro de lições;
• Registo de Qualidade; e
• Registro de riscos.

Os relatórios podem ser identificados como:

• Relatório de ponto de verificação;
• Relatório final do projeto;
• Relatório do estágio final;
• Relatório de exceção;
• Relatório de destaque;
• Relatório de Assunto;
• Relatório de lições; e
• Conta de Status do Produto.

No PRINCE 2 Agile, as retrospectivas são semelhantes à melhoria contínua, ou

Kaizen, para que se possam inspecionar e adaptar.

Nele usa-se o termo ‘revisão’ para uma finalidade específica ao utilizar a técnica de
revisão de qualidade, enquanto é usado frequentemente ao utilizar o desenvolvimento ágil.

Quanto ao painel do projeto ou Sistema Kanban, este deve determinar quanto tempo
de duração de um estágio antes de decidir o que o compõe. Deve priorizar um requisito
(ou user stories) que precisa ser satisfeito para atingir uma saída que deve cumprir um
“timebox”, senão a entrega não se torna efetiva.

Ao se liberar os recursos, as partes interessadas corretas devem estar envolvidas,

devendo ser apropriado preencher e criar uma lista de “perguntas mais frequentes ou
FAQs” para quando o produto estiver operacional.

Lembre-se que muitas vezes o sprint zero ou iteração zero ou descoberta (também
chamados de sprints iniciais) pode ser usado para a entrega inicial.

22
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Leitura
Agile Manifesto for Software Development | Agile Alliance
[Link]
The Scrum Guide
[Link]
What is Extreme Programming (XP)? | Agile Alliance
[Link]
Implementação Do Sistema De Manufatura Enxuta (Lean Manufacturing) Na Embraer
LINDGREN, P. C. C. Implementação Do Sistema De Manufatura Enxuta (Lean
Manufacturing) Na Embraer. Monografia (MBA em Gerência de Produção e Tecno-
logia) – Departamento de Economia, Contabilidade, Administração e Secretário
Executivo, Universidade de Taubaté, Taubaté, 2001.
[Link]
Kanban
[Link]
The PMI Talent Triangle
[Link]
Business Analysis Practice Guide | PMI
[Link]
PRINCE2 Agile | PRINCE2 | AXELOS
[Link]

23
23
UNIDADE
Introdução em Modelos Gerenciamento Ágeis

Referências
AMARAL, D. C. et al. Gerenciamento ágil de projetos: aplicação em produtos
inovadores. São Paulo: Ed. Saraiva, 2011.

AXELOS. Managing successful projects with PRINCE2. Norwich: TSO, 2017. (The
Stationery Office).

BECK, K; GAMMA, E. Extreme programming explained: embrace change.

Addison-Wesley professional, 2000.

CRUZ, F. Scrum e Agile em Projetos: guia completo. 2. ed. São Paulo: Brasport, 2018.

FOGGETTI, C. Gestão ágil de projetos. São Paulo: Education do Brasil, 2014. (Coleção
Bibliografia Universitária Pearson).

JUGEND, D. Gestão de projetos: teoria, prática e tendências. São Paulo: Elsevier

Brasil, 2016.

MASSARI, V. Agile Scrum Master no Gerenciamento Avançado de Projetos. São

Paulo: Brasport, 2016.

PMI – Project Management Institute, 6. ed. Um Guia do Conhecimento em

Gerenciamento de Projetos (Guia PMBOK), Newtown Square, PA, 2017.

ROZENFELD, H.; AMARAL, D. C. Gestão de Projetos em Desenvolvimento de

Produtos. São Paulo: Saraiva, 2006.

SABBAGH, R. Scrum: Gestão ágil para projetos de sucesso. São Paulo: Editora
Casa do Código, 2014.

SUTHERLAND, J.; SCHWABER, K. The scrum guide. The definitive guide to scrum:
The rules of the game. Scrum. org, v. 268, 2017.

24
Gerenciamento
Inserir Título Aqui
de
Inserir Título
Projetos ÁgeisAqui
Iteração de Modelos Tradicionais e Ágeis

Responsável pelo Conteúdo:

Prof. Me. Luiz Lima

Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
 Iteração de Modelos Tradicionais e Ágeis

Fonte: Getty Images

Nesta unidade, trabalharemos os seguintes tópicos:
• Papéis e Responsabilidades – PMBOK;
• Capacitação e Certificações;
• Iteração de Modelos Tradicionais e Ágeis.

Objetivo
• Desenvolver os papéis e responsabilidades para equipes que utilizam PMBOK, PRINCE2 e
Scrum, bem como suas capacitações e certificações, além da iteração de modelos tradi-
cionais e ágeis.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o úl-
timo momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

Contextualização
Nossa situação-problema central proposta para o Cursos é baseada em um Projeto
de Desenvolvimento de um App (aplicativo) SEJ para uma empresa de Seguros que quer
atingir o nicho de mercado do público jovem.

Nesta Unidade existem 3 abordagens que devem ser verificadas pelos alunos:
• Indicar como a definições de papéis e responsabilidades impactam na gestão desse projeto.
• Definir como um profissional certificado faz a diferença dentro da equipe do projeto.
• Definir como a iteração entre modelos tradicionais e ágeis pode impactar no projeto.

6
Papéis e Responsabilidades – PMBOK
No contexto de Iniciação do Projeto
Existem quatro categorias fundamentais dos fatores organizacionais que ilustram o
contexto de um projeto:
• Cumprir requisitos regulatórios, legais ou sociais;
• Atender a pedidos ou necessidades dos stakeholders ou partes interessadas;
• Implementar ou alterar estratégias de negócio ou tecnológicas; e
• Criar, melhorar ou corrigir produtos, processos ou serviços.

Estes fatores podem ser analisados por meio dessa Figura:

Revisão e Ajustes no Portfólio

Programas e
Operações:
Portfólio: Projetos:
Estratégia Realização do
Decisões de Valor Entrega de
Valor de Negócio
Resultados

Análise do Impacto nos Negócios

Análise do Desempenho do Valor

Figura 1 – Ambiente Organizacional do Projeto

Fonte: Adaptado de PMI – Project Management Institute, 2017

O ambiente organizacional sempre estará sujeito a revisão e ajustes em seu portfólio,

inicialmente a estratégia geralmente é a primeira a ser analisada, pois seu objetivo é
impulsionar toda a estrutura.

O portfólio concentrará as decisões de valor para que estas, seguindo a estratégia

proposta, possam criar os programas e os projetos com intuito de entrega de resultados,
bem como realizam a análise do impacto nos negócios detectados dentro dos programas
e projetos da organização.

Em contrapartida, os programas e projetos orientam as operações para que estas ela-

borem a realização do valor de negócio. Além disso, a análise do desempenho do valor
gerado ao negócio será realizada continuamente e as correções e melhorias detectadas
nesta análise são incluídas no ciclo posterior.

7
7
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

Dados e informações de gerenciamento de projetos

Durante o ciclo de vida do projeto, muitos dados são coletados, analisados e trans-
formados em informações úteis ao projeto. Estas informações serão os resultados dos
vários processos e compartilhados pela equipe do projeto. Eles são analisados no
contexto, agregados e transformados, tornando-se informações do projeto durante
vários processos. As informações devem ser comunicadas verbalmente ou armazenadas
e distribuídas como relatórios em vários formatos.

Os relatórios podem ser observados na Figura 2:

Dados do Projeto, Informações e Relatórios de Fluxos

Processos
de Execução
Dados do desempenho do trabalho
Processos
de Execução
Plano de gerenciamento
do projeto e documentos Informações sobre o desempenho do trabalho
do projeto
Processos
de Execução
Relatórios do desempenho do trabalho

Processos Processos Processos

de Execução de Execução de Execução

Soluções de Mudança
Membros da equipe do projeto
Partes interessadas no projeto
Figura 2 – Relatórios de Fluxo
Fonte: Adaptado de PMI – Project Management Institute, 2017

A análise e coleta de informações do projeto pode ser apresentada em forma de:

• dados de desempenho do trabalho;
• informações sobre o desempenho do trabalho;
• relatórios de desempenho do trabalho.

Tailoring ou Adaptação
• O tailoring ou adaptação indica que a metodologia de gerenciamento de projetos
pode ser:
• desenvolvida por especialistas da própria organização;
• obtida de fornecedores;
• adquirida de associações profissionais; ou
• obtida de agências governamentais.

8
 Pois o PMBOK é um guia de melhores práticas e não uma metodologia, por isso
pode ser utilizada totalmente, em parte e adaptada.

Influências das Estruturas Organizacionais nos Projetos

Para escolha de uma estrutura organizacional, pode-se incluir alguns fatores, como:
• Nível de alinhamento com os objetivos da organização;
• Apresentar capacidade de especialização;
• Grau de extensão de controle, eficiência e eficácia,
• Objetividade quanto o escalonamento das decisões;
• Baseline e escopo de autoridade claros;
• Apresentar capacidades de delegação;
• Apresentar prestação de contas;
• Correta atribuição de responsabilidades;
• Apresentar capacidade de adaptação de projeto;
• Simplicidade no projeto;
• Eficiência de performance;
• Análise de custo;
• Localização física; e
• Comunicações formais.

Os tipos de estruturas organizacionais podem ser: orgânicas, funcionais, multidivi-

sionais, matriciais (forte, fraca e equilibrada), orientada a projetos (composta ou hibrida),
virtuais, híbridas ou EGP (Escritório de Gerenciamento de Projeto).

Este quadro resume as características dos tipos de estrutura organizacional:

Quadro 1 – Tipos de estrutura organizacional

Características do projeto
Tipos de Pessoal
Grupos de Quem
estrutura Autoridade administrativo
trabalho Papel do gerente do Disponibilidade gerencia o
organizacional do gerente de
organizados projeto de recursos orçamento
do projeto gerenciamento
por do projeto?
de projetos
Flexível; Em tempo parcial;
Orgânico ou pessoas Pouca ou pode ou não ser Pouca ou Proprietátio Pouco ou
simples trabalhando nenhuma um papel designado, nenhuma ou operador nenhum
lado a lado como coordenador
Trabalho Em tempo parcial;
Funcional realizado (ex.: Pouca ou pode ou não ser Pouca ou Gerente Em tempo
(centralizado) engenharia, nenhuma um papel designado, nenhuma funcional parcial
fabricação) como coordenador

9
9
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

Características do projeto
Tipos de Pessoal
Grupos de Quem
estrutura Autoridade administrativo
trabalho Papel do gerente do Disponibilidade gerencia o
organizacional do gerente de
organizados projeto de recursos orçamento
do projeto gerenciamento
por do projeto?
de projetos
Um de:
produto;
Multidivisional processos de
(pode replicar produção; Em tempo parcial;
funções para portifólio; Pouca ou pode ou não ser um Pouca ou Gerente Em tempo
cada divisão programa; nenhuma papel designado, como nenhuma funcional parcial
com pouca região coordenador
centralização) geográfica;
tipo de
cliente
Por função,
com gerente
Moderada Função designada em Moderada a Gerente do
Matriz – forte do projeto Full-time
a alta tempo integral alta projeto
como uma
função
Em tempo parcial; feito
como parte de outro
Gerente Em tempo
Matrix – fraca Função Baixa trabalho e não uma Baixa
funcional parcial
função designada,
como coordenador
Em tempo parcial;
incorporado nas
funções como
Matriz – Baixa a Baixa a Em tempo
Função uma habilidade e Misto
equilibrada moderada moderada parcial
pode não ser um
papel designado,
como coordenador
Orientado
a projetos Alta a Função designada em Alta a quase Gerente do Em tempo
Projeto
(composto, quase total tempo integral total projeto integral
híbrido)
Estrutura
de rede
como nós Poderia ser em
Baixa a Em tempo integral ou Baixa a
Virtual nos pontos Misto tempo integral
moderada parcial moderada
de contato ou parcial
com outras
pessoas
Mix de outros
Híbrido Mista Misto Mista Misto Misto
tipos
Mix de outros Alta a Função designada em Alta a quase Gerente do Em tempo
EGP
tipos quase total tempo integral toral projeto integral
Fonte: Adaptado de PMI – Project Management Institute, 2017

O Gerente de Projetos desempenha um papel crítico na liderança da equipe de pro-

jetos para que esta consiga atingir os objetivos, principalmente durante o ciclo de vida
do projeto.

Muitos se envolvem em todo o projeto do início ao fim, outros apenas nas fases de
avaliação e análise antes da inicialização do projeto.

10
 Lembra-se que na unidade anterior comentamos sobre PMI Talent Triangle, também cha-
mado de Triângulo de Talentos do PMI. Para que serve o PMI Talent Triangle?

O Gerente de Projeto deve apresentar as seguintes habilidades-chave:

• ser capaz do gerenciamento de Projetos Técnicos, ou seja, possuir capacidade técnica;
• apresentar capacidade de liderança;
• ter capacidade do gerenciamento estratégico e de negócios, onde deve conhecer
com aprofundamento o ramo do negócio em que o projeto será desenvolvido.

O Gerente de Projeto necessita desenvolver com equilíbrio estas habilidades conforme

o Triângulo de Talentos do PMI:
• Gerenciamento de Projetos Técnicos;
• Gerenciamento estratégico e de negócios;
• Liderança.
tos o
roje estã
de Ps em G
nica

Lide
Téc

ran
a ç

Gestão Estratégica
de Negócios

Figura 3 – Triangulo de Talentos do PMI

Fonte: [Link]

O mercado global está cada vez mais complexo e competitivo e somente as habilida-
des técnicas não são suficientes. As empresas buscam habilidades adicionais em lideran-
ça e inteligência no negócio para suportar os objetivos estratégicos de longo prazo que
contribuam ao sucesso do projeto.

As habilidades apresentadas no Triangulo do PMI são um conjunto considerado ideal,

ou seja, uma combinação de conhecimento técnico, de liderança e de gestão estratégica
e negócios.

Agora, para se manter atrativo e competitivo, você deve na medida do possível de-
senvolver essas habilidades que são hoje demandas de muitos empregadores, nossos
Patrocinadores ou Owners.

Para a habilidade de gestão de projetos técnicos, o gerente de projeto deve ter a ca-
pacidade de:
• Concentrar-se nos elementos críticos de gerenciamento de projetos técnicos;

11
11
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

• A adaptação de ferramentas, técnicas e métodos tradicionais e ágeis;

• Estabelecer determinado tempo para as prioridades;
• Gerenciar os elementos do projeto, não somente: o cronograma, custos, recursos
e riscos.

Para a habilidade de gerenciamento estratégico e de negócios, os gerentes de projeto

devem conhecer o negócio para poder:
• Explicar os aspectos do negócio;
• Trabalhar em conjunto com o patrocinador, a equipe e o pessoal com conhecimen-
to especializado para desenvolver uma estratégia;
• Implementar a estratégia para otimizar o valor do negócio do projeto.

Para a habilidade de liderança, o Gerente de Projeto deve desenvolver a capacidade

de orientar, motivar e dirigir uma equipe.

A equipe deve desenvolver capacidade de negociação, resiliência, comunicação, reso-

lução de problemas, pensamento crítico e habilidades interpessoais.

Lembra-se que na unidade anterior comentamos sobre PMI Talent Triangle, também cha-
mado de Triângulo de Talentos do PMI. Para que serve o PMI Talent Triangle? É um novo do-
cumento elaborado pelo PMI que apresenta as 03 habilidades que devem ser desenvolvidas
pelo gerente de projeto: gerenciamento técnico, gerenciamento estratégico e de negócios
e liderança.

No PMBOK, alguns papéis são:

• Gerente de portfólio;
• Gerente de programa;
• Gerente de projeto;
• Patrocinador ou Owner; e
• Equipe do projeto.

Um projeto pode ser gerenciado em três cenários:

• como projeto autônomo, ou seja, um projeto que não está vinculado a um portfólio
ou programa;
• um projeto dentro de um programa;
• um projeto dentro de um portfólio.

Por exemplo, vários projetos podem ser necessários para que uma organização possa
atingir suas metas e seus objetivos estratégicos.

Pode-se definir um Programa como um grupo de projetos, com programas subsidiá-

rios e atividades de programa que estão relacionados e são gerenciados de modo coor-
denado pelo Gerente de Programa. Nesta situação, estes benefícios da gestão conjunta

12
não estariam disponíveis se cada projeto fosse gerenciado individualmente, observando
que um programa não é um grande programa, pois este seria chamado de megaprojeto.

Certas organizações utilizam um portfólio de projetos para gerenciar vários progra-

mas e projetos em andamento em um determinado momento. Esta gestão principal é
feita pelo Gerente de Portfólio.

Um portfólio pode ser definido como projetos, programas, portfólios subsidiários e

operações gerenciadas em grupo para alcançar os objetivos estratégicos de uma organi-
zação, ou seja, cada uma dessas subpartes pode apresentar gerentes auxiliares.

E para situações de organizações complexas é indicada a utilização do gerenciamento

de portfólios, programas e projetos para se atingir um equilíbrio e sucesso para os
objetivos estratégicos.

Exemplo de Portfólio

Programa Programa Porfólio

A B A

Programa Programa
B1 C

Projeto Projeto Projeto Projeto Projeto Projeto Projeto Projeto Projeto

Operações
1 2 3 4 5 6 7 8 9

Recursos Compartilhados e Partes Interessadas

Figura 4 – Portfólio, Projetos e Operações

Fonte: Adaptado de PMI – Project Management Institute, 2017

No PRINCE 2, alguns papéis são:

• Gerente do projeto;
• Equipe;
• Patrocinadores do negócio;
• Usuários; e
• Fornecedores.

O gerente de projeto é responsável em planejar a sequência de atividades para cons-

truir o projeto, descobrir quantos recursos serão necessários e assim por diante.

Para construir um projeto, o gerente deve delegar parte ou todo o trabalho a outros
membros da equipe. A capacidade de delegar é importante em qualquer formato de
gerenciamento, mas existem particularidades no gerenciamento de projetos, devido as
funcionalidades cruzadas e aos riscos existentes.

13
13
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

Nesta fase, o objetivo do projeto é “seguir de acordo com o que foi planejado”, porém
não se pode confiar que sempre aconteça isso. É responsabilidade do gerente de projeto
monitorar se o trabalho que está em andamento corresponde ao que foi planejado.

Caso o trabalho não estiver de acordo com o planejado, o gerente de projeto deve
fazer algo a respeito, ou seja, exercer o controle do projeto. Mesmo que o projeto esteja
caminhando bem, o gerente de projeto deve sempre identificar uma oportunidade para
acelerar o cronograma ou reduzir custos.

Planejar

Controlar Delegar

Monitorar

Figura 5 – Atividades do Gerente de Projeto

Fonte: Adaptado de AXELOS, 2017

No PRINCE2 existe a responsabilidade relevante dentro do desenvolvimento do

Business Case do projeto para os seguintes participantes:
• Gerente corporativo, gerente de programa ou o cliente;
• Executivo;
• Usuário(s) sênior(es);
• Fornecedor(s) sênior(es);
• Gestor de projeto;
• Área de Qualidade do projeto; e
• Área de Suporte do projeto.

Segue um quadro resumo dessas responsabilidades:

Quadro 2 – Responsabilidades no PRINCE2

Participantes do
Responsabilidades
Business Case
Fornecer o mandato do projeto e definir quaisquer padrões para os quais o business case precise
Gerente corporativo, ser desenvolvido.
gerente de programa Responsabilizar o(s) usuário(s) sênior(es) pela realização dos benefícios pós-projeto permitidos
ou o cliente. pelos produtos do projeto.
Responsável pela abordagem de gerenciamento de benefícios (pós-projeto).

14
 Participantes do
Responsabilidades
Business Case
Responsável pelo business case e pela duração do projeto.
Responsável pela abordagem de gerenciamento de benefícios (para a duração do projeto), a
menos que seja gerenciado por um gerente corporativo, gerente de programa ou o cliente.
Executivo
Supervisiona o desenvolvimento de um caso de negócios viável, garantindo que o projeto esteja
alinhado com as estratégias corporativas, de gerenciamento de programas ou de clientes, e
garanta o financiamento para o projeto.
Responsável por especificar os benefícios sobre os quais o caso de uso serão aprovados.
Assegura-se de que o resultado desejado do projeto seja especificado.
Certifica-se de que o projeto produza produtos que forneçam os resultados desejados e que esses
Usuário(s) sênior(es)
resultados gerem os benefícios desejados.
Garante que os benefícios esperados (obtidos a partir dos resultados do projeto) serão realizados.
Fornece declarações de realizações reais de benefícios versus suas previsões e suas revisões.
Responsável por ser o fornecer do business case (se existirem).
Fornecedor(s)
Confirma quais os produtos necessários podem ser entregues dentro dos custos esperados
sênior (es)
e sua viabilidade.
Responsável pelo desenvolvimento do business case e abordagem de gestão de benefícios
conforme delegado pelo executivo.
Analisa o impacto de problemas e riscos na viabilidade contínua do business case.
Gestor de projeto
Avalia e atualiza o business case e a abordagem de gerenciamento de benefícios ao final de cada
estágio do gerenciamento.
Avalia e relata o desempenho do projeto no encerramento do projeto.
Verifica e monitora o business case em relação a eventos externos e ao progresso do projeto.
Assegura-se de que o projeto se encaixa com as estratégias gerais corporativas, de gerenciamento
de programas ou de clientes.
Monitora o financiamento do projeto em nome da empresa, do gerente do programa ou do cliente.
Área de qualidade Assegura-se de que a solução de valor para dinheiro seja constantemente reavaliada.
do projeto Monitora as alterações no plano do projeto para identificar qualquer impacto nas necessidades do
negócio ou do business case.
Revisa a avaliação de impacto de possíveis mudanças no caso de negócios e no plano do projeto.
Verifica e monitora a abordagem de gerenciamento de benefícios para alinhamento com
corporativo, gerenciamento de programa ou cliente.
A abordagem de gerenciamento do business case e seus benefícios deve ter uma baseline e,
Área de Suporte
portanto, estar sob controle de mudanças. A área de suporte do projeto deve aconselhar o gerente
do projeto
do projeto sobre quaisquer mudanças propícias ou reais dos produtos que afetam o business case.
Fonte: adaptado de AXELOS. (2017).

Time e papéis Scrum:

• Scrum Master;
• Product Owner; e
• Equipe(Time).

A Equipe Scrum é constituída:

• pelo Product Owner;
• a Equipe de Desenvolvimento; e
• o Scrum Master.

O modelo de equipe do Scrum é projetado para otimizar a flexibilidade, criatividade e

produtividade, demonstrando ser cada vez mais efetiva nas atividades e processos e em
qualquer trabalho complexo. Existem equipes Scrum que são: auto‐organizadas e outras
multifuncionais. Ser auto‐organizadas refletem que podem escolher a melhor forma de

15
15
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

realizar o seu trabalho, em vez de serem dirigidas por outros fora da equipe; enquanto
que as equipes multifuncionais possuem todas as competências necessárias para realizar
o trabalho sem depender de outros que não fazem parte dessa equipe.

As equipes Scrum fazem a entrega dos produtos de forma iterativa e incremental,

ocorrendo a maximização de feedback do projeto. As entregas incrementais de produ-
tos prontos asseguram uma versão utilizável do produto sempre disponível ao cliente.

O Product Owner, traduzido do inglês como dono do produto, é o responsável quanto

a maximizar o valor do produto e influenciar no trabalho da equipe de desenvolvimento.

A equipe de desenvolvimento está formada pelos profissionais necessários para en-

tregar o incremento pronto que já pode ser utilizado como um produto ou versão no
final de cada Sprint, sendo que apenas os membros dessa equipe criam o incremen-
to. Estas equipes são compostas por profissionais capacitados a organizar e gerir seu
próprio trabalho, exigindo a existência de sinergia para otimizar a sua eficiência e sua
eficácia. Elas também devem apresentar as características de serem auto-organizadas e
multifuncionais. No Scrum não existem subequipes de desenvolvimento, mas estas de-
vem ser ágeis e com componentes suficientes para concluir o trabalho do Sprint.

O Scrum Master é o responsável a promover e suportar o Scrum como determina o

Guia Scrum. Na teoria, este conhece as práticas, as regras e os valores Scrum de forma
a ajudar a todos a entender e aplicá-las, sendo o líder da equipe em suas interações, com
indicações úteis, com intuito de maximizar o valor criado pelo produto.

O papel do Scrum Master é:

• garantir que os objetivos, o âmbito e o domínio possam ser compreendidos pela
Equipe Scrum;
• encontrar técnicas na gestão do Product Backlog;
• auxiliar a Equipe Scrum a entender a necessidade dos itens claros e precisos do
Product Backlog;
• entender o planejamento do Produto em ambientes empíricos;
• assegurar que o Product Owner auxilie na organização do Product Backlog de
forma a maximizar o valor do projeto;
• Compreender e praticar o método ágil;
• Facilitar os eventos Scrum conforme a necessidade e a exigência do projeto.

O Scrum Master deve atuar junto a Equipe de Desenvolvimento da seguinte forma:

• formar uma equipe auto-organizável e multifuncional;
• auxiliar a equipe a criar produtos de alto valor agregado;
• remover restrições e impedimentos do progresso da equipe;
• facilitar os eventos Scrum que forem necessários e exigidos;

16
 • formar equipes em ambientes organizacionais, mesmo naqueles em que ainda não
seja totalmente adotado ou compreendido.

A atuação do Scrum Master junto à organização deve ser:

• liderar e treinar a organização na adoção do Scrum;
• planejar as implementações do Scrum dentro das organizações;
• auxiliar os colaboradores e os Stakeholders a compreender a aplicação do Scrum
e o desenvolvimento empírico dos produtos;
• atuar nas mudanças de formas a aumentar a produtividade da equipe Scrum; e
• trabalhar em conjunto com outros Scrum Masters para aumentar a eficácia da
aplicação do Scrum em uma organização.

Capacitação e Certificações
As Certificações do PMBOK são:
• Certificação CAPM – Técnico Certificado em Gerenciamento de Projetos®;
• Certificação PMP – Profissional de Gerenciamento de Projetos (PMP)®;
• Certificação PfMP® - Profissional de Gerenciamento de Portfolio fazer PMI;
• Certificação PMI-PBA® - Profissional em Análise de Negócios do PMI;
• Certificação PMI-SP – Profissional em Gerenciamento de Cronograma do PMI®;
• Certificação PMI-RMP – Profissional em Gerenciamento de Riscos do PMI®;
• Certificação PgMP – Profissional de Gerenciamento de Programas®;
• Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis do PMI®.

Sobre a certificação de Profissional Técnico Certificado em Gerenciamento de Proje-

tos (CAPM)®, que significa Certified Associate in Project Management, foi criada pelo
PMI – Project Management Institute em 2003.

A Certificação CAPM é para profissionais que trabalham com projetos, sendo proje-
tada para aqueles com menos experiência em gerenciamento de projetos, esta certifica-
ção atesta a compreensão do conhecimento, terminologia e processos fundamentais de
um gerenciamento de projetos eficiente segundo o Guia PMBOK®.

Os pré-requisitos para obter esta certificação são:

• Possuir ensino superior completo e treinamento formal de 23h em gerenciamento
de projetos; ou
• Ensino médio e ter experiência mínima de 1500 horas como membro de equipe
de projeto.

17
17
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

A certificação PMP é a mais importante para gerentes de projeto, significa Profissio-

nal de Gerenciamento de Projetos e foi criada pelo PMI – Project Management Institute.

Esta certificação é reconhecida e exigida mundialmente, ela atesta que o profissional

possui formação, experiência e competência para conduzir e dirigir projetos.

Os profissionais certificados PMP possuem um diferencial no seu salário, ficando

acima dos pares não certificados.

Os pré-requisitos para se candidatar à certificação PMP são:

• formação superior de quatro anos (de bacharel ou equivalente);
• possuir no mínimo três anos de experiência em gerenciamento de projetos;
• possuir no mínimo 4.500 horas de liderança e direção de projetos; e
• Ter 35 horas em formação em gerenciamento de projetos.

OU
• possuir diploma de ensino médio (ou equivalente);
• possuir no mínimo cinco anos de experiência no gerenciamento de projetos;
• possuir no mínimo 7.500 horas de liderança e direção de projetos; e
• ter 35 horas em formação em gerenciamento de projetos.

A certificação PfMP, que significa Profissional de Gerenciamento de Portfolio, foi

criada pelo PMI – Project Management Institute e reconhece o nível avançado de expe-
riência e as habilidades para um gerente de portfólio.

A Certificação PfMP® demonstra que o profissional apresente comprovada capaci-

dade no gerenciamento coordenado de um ou mais portfolios que visam a atingir os
objetivos organizacionais.

Aqueles que possuem a certificação PfMP são responsáveis pela execução do proces-
so de gerenciamento de portfólio, pela comunicação em torno do progresso do portfólio
e recomendações para a ação.

Os pré-requisitos da Certificação de Gerenciamento de Portfolio são:

• possuir diploma de ensino médio (ou equivalente) e com no mínimo 7 anos (10.500
horas) de experiência em gerenciamento de portfólio dentro do período dos últimos
15 anos;

OU
• possuir formação de nível superior de 4 anos (bacharel ou equivalente) com no
mínimo 4 anos (6.000 horas) de experiência em gerenciamento de portfólio dentro
do período dos últimos 15 anos;
• Os candidatos devem possuir um mínimo de 8 anos (96 meses) de experiência
profissional em negócios.

18
 E para manter a Certificação PfMP, os detentores da certificação necessitam obter 60
PDUs a cada ciclo de 3 anos.

A Certificação PMI-PBA®, que significa Profissional em Análise de Negócios, foi cria-

do pelo PMI® – Project Management Institute.

Os pré-requisitos para a Certificação PMI-PBA® são:

• possuir diploma do Ensino Médio e 7.500 horas de experiência em análise de negó-
cio no período de oito anos, com 2000 horas trabalhando em equipe de projetos,
e 25 a 35 horas em formação de análise de negócios.
• possuir formação superior de bacharelado com quatro anos e experiência de 4.500
horas em análise de negócio, com 2000 horas trabalhando em equipe de projetos,
e 25 a 35 horas de formação em análise de negócios.

A certificação PMI-SP – Profissional em Gerenciamento de Cronograma é a res-

posta para o aumento da complexidade e diversidade do gerenciamento de projetos no
mundo. Foi reconhecida e exigida mundialmente, pois preenche a necessidade de um
especialista em gerenciamento de cronograma no projeto.

Para se candidatar à certificação PMI-SP®, você precisa:

• possuir curso superior de quatro anos (bacharelado ou o equivalente);
• possuir no mínimo de 3.500 horas de experiência de gerenciamento de cronogra-
ma de projetos;
• ter 30 horas de educação em gerenciamento de cronograma do projeto.

OU
• possuir diploma de ensino médio (ou equivalente);
• possuir no mínimo 5.000 horas de experiência de gerenciamento de cronograma
de projetos;
• ter 40 horas de educação em gerenciamento de cronograma do projeto.

A certificação PMI-RMP - Profissional de Profissional em Gerenciamento de Riscos

foi criada pelo PMI e preenche a necessidade de um especialista em gerenciamento de
risco no projeto, pois reconhece a expertise e a competência para avaliar e identificar
riscos, mitigar ameaças e aproveitar as oportunidades dos projetos, e também se possui
habilidades e conhecimento em todas as áreas de gerenciamento de projetos.

Pré-requisitos para se candidatar à certificação PMI-RMP®:

• possuir curso superior de quatro anos (bacharelado ou o equivalente);
• possuir no mínimo 3.000 horas de experiência de gerenciamento de riscos
de projetos;
• ter 30 horas de educação em gerenciamento de riscos do projeto.

OU

19
19
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

• possuir o diploma de ensino médio (ou equivalente);

• possuir no mínimo 4.500 horas de experiência de gerenciamento de riscos
de projetos;
• ter 40 horas de educação em gerenciamento de riscos do projeto.

A certificação PgMP – Profissional de Gerenciamento de Programas foi criada pelo

PMI – Project Management Institute para reconhecer as habilidades e experiências de
gerentes de programa experientes, onde se comprova a competência para supervisionar
vários projetos inter-relacionados e seus respectivos recursos para atingir objetivos estraté-
gicos de negócios. Os profissionais certificados supervisionam o sucesso de um programa,
ou seja, para a coordenação de um grupo de projetos para obter maiores benefícios, sendo
que os controles não estariam disponíveis se fossem gerenciados individualmente.

Os pré-requisitos para se candidatar à certificação PgMP® são:

• possuir formação superior de quatro anos (de bacharel ou equivalente);
• possuir no mínimo de quatro anos de experiência no gerenciamento de projetos;
• possuir no mínimo de quatro anos de experiência no gerenciamento de programas.

OU
• possuir diploma de ensino médio (ou equivalente);
• possuir no mínimo de quatro anos de experiência no gerenciamento de projetos;
• possuir no mínimo de sete anos de experiência no gerenciamento de programas.

A Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis, criado pelo

PMI – Project Management Institute, reconhece o conhecimento dos princípios ágeis,
práticas e ferramentas e técnicas através de metodologias ágeis.

Para se candidatar à certificação PMI-ACP®, você precisa ter:

• experiência Geral de Projetos de no mínimo 2.000 horas de trabalho em equipes
de projeto, sendo que essas horas devem ter sido obtidas nos últimos 5 anos. Entre-
tanto, aqueles que já possuírem a certificação PMP®, o requisito já está cumprido.
• experiência de Projetos com Métodos Ágeis: 1.500 horas de trabalho em equipes
de projetos utilizando métodos ágeis, sendo que estas horas devem ser adicio-
nadas às 2.000 horas necessárias na experiência geral de projetos obtidas nos
últimos 3 anos.
• treinamento em Práticas ou Métodos Ágeis na quantidade de 21 horas de contato.
Estas horas devem compreender tópicos de métodos ou práticas ágeis para projetos.

As Certificações do Time Scrum são:

• Professional Scrum Master;
• Professional Scrum Product Owner;
• Professional Scrum Developer;

20
 • Scaled Profissional Scrum;
• Professional Scrum with Kanban;
• Professional Agile Leadership.

Existem variações das certificações Scrum, como:

• Professional Scrum Master (PSM I) do [Link];
• Certified Scrum Master (CSM) da Scrum Alliance;
• Agile Scrum Foundation (ASF) do EXIN; e
• Scrum Foundation Certified (SFC) da ScrumStudy.

Estas certificações acima são consideradas as fundamentais para quem deseja co-
nhecer o Scrum e abordagens ágeis. Além destas, existem outras focadas em papéis
específicos no Scrum, como Product owner e Developer. Porém, essas certificações
mais especializadas não serão abordadas neste tópico.

As Certificações do [Link]:
• Professional Scrum Master I (PSM I) é uma certificação para comprovar conheci-
mento sobre o Scrum, pois o objetivo é avaliar o conhecimento do Scrum Guide,
o preço é de 150 dólares.
• Professional Scrum Master II é recomendada para aqueles que já tem experiência
prática no Scrum;
• Professional Scrum Master III é o nível máximo de conhecimento para o Scrum
Master.
• Professional Product Owner I (PSPO I) é voltada para quem irá atuar no papel de
Product Owner se relacionando com as áreas de negócio/usuários.
• Professional Scaled Scrum é para os profissionais que querem testar conhecimen-
to no uso do framework NEXUS™ e se aplica quando o projeto envolve várias
equipes. Framework NEXUS foi criado em 2015 para complementar as práticas
do Scrum quando há várias equipes trabalhando em um mesmo produto.
• Professional Scrum Developer (PSD) é para o profissional que quer demonstrar co-
nhecimento no desenvolvimento de software usando práticas de engenharia, testes,
integração e arquitetura.

O Nexus é um framework criado para desenvolver e sustentar iniciativas de desenvol-

vimento de produtos e software em escala. O Nexus usa o Scrum como base para sua
construção. Este guia apresenta os papéis, eventos, artefatos e regras. O Nexus é uma
unidade de desenvolvimento (no Scrum Profissional Escalado).

A Certificação - Certified Scrum Master (CSM) da Scrum Alliance é uma das certi-
ficações mais famosas de Scrum. O custo é cerca de R$ 2.000 e equivale a uma Certi-
ficação PSM I.

21
21
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

A Certificação Scrum Fundamental Certified (SFC) da ScrumStudy é uma certifica-

ção fundamental, eles desenvolveram várias outras certificações para profissionais que
trabalham com o Scrum.

A Certificação Agile Scrum Foundation (ASF) do EXIN tem como vantagem o fato de
prestar o exame em português e em casa com sistema de monitoramento com webcam,
sendo uma certificação ideal para iniciantes em gerenciamento ágil de projetos, pois é
comparada a Certificação PSM I.

A certificações Agile Scrum Master (ASM) e Agile Product Owner são oferecidas
pelo EXIN como continuidade no programa de formação da Certificação ASF.

As Certificações PRINCE2 são:

• PRINCE2® Foundation;
• PRINCE2® Practitioner;
• PRINCE2® Agile Foundation; e
• PRINCE2® Agile Practitioner.

A Certificação PRINCE2® Foundation é uma certificação do nível básico para intro-

dução do método PRINCE2, para que o profissional ateste seu conhecimento sobre o
método, no intuito de trabalhar efetivamente como membro de uma equipe de gerencia-
mento de projetos em um ambiente que suporte o framework, sendo um pré-requisito
para a certificação PRINCE2 Practioner.

Sobre a Certificação PRINCE2® Practitioner, é para confirmar se o profissional pos-

sui conhecimento suficiente sobre como aplicar e adaptar o método em vários ambientes
e cenários de projetos diferentes, tendo como pré-requisito possuir a Certificação PRIN-
CE2 Foundation.

A Certificação PRINCE2® Agile Foundation é para gerentes de projeto do PRINCE2

que exigem orientação específica sobre como se adaptar ao PRINCE2 em um contexto
ou ambiente ágil. Esta certificação permite que os profissionais apliquem os princípios
de gerenciamento de projetos do PRINCE2 combinando com conceitos ágeis, como
Scrum e Kanban, sendo destinada a todos os profissionais e organizações envolvidos
com a entrega e suporte a projetos, produtos e programas.

A Certificação do PRINCE2® Agile Practitioner foi desenvolvido para ajudá-lo a apli-

car o método PRINCE2 Agile na prática, por meio de exemplos reais de gerenciamento
de projetos., sendo pré-requisito possuir a Certificação PRINCE2 Agile Foundation. O
seu certificado é válido por três anos e no final você pode voltar a fazer o exame ou
manter seu certificado através do My PRINCE2.

22
Iteração de Modelos Tradicionais e Ágeis
• Implementação PMBOK em conjunto com o Scrum:

O Guia PMBOK aborda todas as áreas do gerenciamento de projetos e apresenta boas

práticas para todas as etapas de um projeto, entretanto não é considerada uma metodologia.

Já o Scrum é um framework para ser utilizado em gerenciamento de Projetos.

A união do PMBOK com o Scrum pode ser analisada por meio da Figura:

Figura 6 – Gerenciamento de Projetos – Scrum × PMBOK

Fonte: Adaptada de CRUZ, 2013

Algumas considerações podem ser observadas na implementação do PMBOK em

conjunto com o Scrum:
• Na implementação conjunta, os 05 grandes grupos de processos do PMBOK ainda
continuam constantes dentro dessa união.
• Dentro do Planejamento foi incluído o passo do Scrum de Planejamento da Sprint.
• As Reuniões do Scrum: Diária, de Revisão e de Retrospectiva fazem parte do Mo-
nitoramento e Controle do PMBOK nesta versão.
• Ocorreu a adaptação do Monitoramento e Controle para verificações paralelas das
reuniões diárias do Scrum.
• Foram inseridas também de entregas incrementais até a finalização do produto.
• Na execução ênfase na construção do produto.
• No encerramento os incrementos do produto pronto são entregues

23
23
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

Para facilitar o entendimento da implementação conjunta do Scrum com o PMBOK,

apresento uma visão simplificada do mesmo quadro anterior, assim:

Figura 7 – Visão simplificada – Scrum × PMBOK

Fonte: Adaptada de CRUZ, 2013

Ciclo de vida do projeto tradicional versus visão Scrum:

Existem diferenças entre vários ciclos de vida:

• Preditivo;
• Iterativo ou incremental; e
• Ágil.

Quadro resumo:

Quadro 3 – Ciclo de Vida de Projetos Tradicional × Iterativo × Ágil

Preditivo Interativo ou Incremental Ágil
Requisitos elaborados
Os requisitos são
Requisitos coletados Entregas do todo com frequência
definitos previamente
em intervalos periódicos dividas em subprodutos durante a entrega
Entregas frequentes
Entrega um
de acordo com
único produto
os subconjuntos
Mudanças realizadas Stakeholders envolvidos Mudanças
Restrição as periodocamente regularmente incorporadas
mudanças
em tempo real
Fonte: PMI – Project Management Institute, 2017

24
No ciclo de vida preditivo, pode-se verificar que:
• os requisitos são definidos previamente, antes do início do ciclo;
• entrega os planos no final, entregando um único produto;
• restrição às mudanças, sendo menos possíveis;
• há stakeholders envolvidos nos milestones;
• os riscos e custos são controlados pelo planejamento detalhado.

No ciclo de vida Iterativo ou incremental pode-se verificar que:

• os requisitos podem ser coletados em intervalos periódicos durante o período de
entrega;
• as entregas do todo do produto podem ser dividas em subprodutos;
• as mudanças devem ser realizadas periodicamente;
• os stakeholders são envolvidos regularmente;
• os riscos e os custos são controlados pelo avanço progressivo dos planos;

No ciclo de vida ágil pode-se verificar que:

• Requisitos elaborados com frequência durante a entrega.
• Entregas frequentes de acordo com os subconjuntos.
• Mudanças incorporadas em tempo real.

Pode-se verificar o detalhe do Ciclo de Vida do Scrum de forma pura:

Figura 8 – Metodologia Scrum

Fonte: Adaptado de SUTHERLAND; SCHWABER, 2017

25
25
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

A representação do PRINCE2 simplificado para um projeto pode ser assim:

Figura 9 – Representação de um projeto com uso do PRINCE2

Fonte: Adaptado de AXELOS, 2017

Figura 10 – Gerenciamento de projetos de uma organização usando PRINCE2

Fonte: Adaptado de AXELOS, 2017

26
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
Transforming the World of Work®
[Link]
EXIN – EXIN Brasil
[Link]

Vídeos
Scrum Fundamentals Certified
[Link]

Leitura
Certificações – PMI
[Link]
PMI Agile Certified Practitioner (PMI-ACP)®
[Link]
Manual PMI-ACP – Português
[Link]
PRINCE2® 2017 Project Management Certifications
[Link]
Guia do Nexus™
[Link]

27
27
UNIDADE
Iteração de Modelos Tradicionais e Ágeis

Referências
AMARAL, D. C. et al. Gerenciamento ágil de projetos: aplicação em produtos
inovadores. São Paulo: Ed. Saraiva, 2011.

AXELOS. Managing successful projects with PRINCE2. Norwich: TSO, 2017. (The
Stationery Office).

CRUZ, F. Scrum e Agile em Projetos: guia completo. São Paulo: Brasport, 2018.

FOGGETTI, C. Gestão ágil de projetos. São Paulo: Education do Brasil, 2014.-

(Coleção Bibliografia Universitária Pearson).

JUGEND, D. Gestão de projetos: teoria, prática e tendências. São Paulo: Elsevier

Brasil, 2016.

MASSARI, V. Agile Scrum Master no Gerenciamento Avançado de Projetos. São

Paulo: Brasport, 2016.

PMI – Project Management Institute, 6. ed. Um Guia do Conhecimento em

Gerenciamento de Projetos (Guia PMBOK), Newtown Square, PA, 2017.

ROZENFELD, H.; AMARAL, D. C. Gestão de Projetos em Desenvolvimento de

Produtos. São Paulo: Saraiva, 2006.

SABBAGH, R. Scrum: Gestão ágil para projetos de sucesso. São Paulo: Editora Casa
do Código, 2014.

SUTHERLAND, J.; SCHWABER, K. The scrum guide. The definitive guide to scrum:
The rules of the game. [Link], v. 268, 2017.

28
Gerenciamento
Inserir Título Aqui
de
Inserir Título
Projetos ÁgeisAqui
Aplicabilidade da Técnica Gerenciamento
de Projetos Ágeis com Scrum

Responsável pelo Conteúdo:

Prof. Me. Luiz Lima

Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
 Aplicabilidade da Técnica Gerenciamento
de Projetos Ágeis com Scrum

Fonte: Getty Images

Nesta unidade, trabalharemos os seguintes tópicos:
• Aplicação do Scrum em Projetos Ágeis;
• Aplicação do Gerenciamento de Projetos Ágeis;
• Desenvolver Habilidades e Competências
no Gerenciamento de Projetos Ágeis.

Objetivos
• Desenvolver a aplicabilidade do método de gerenciamento de Projetos Ágeis com: Scrum,
PMBOK 6ª. Edição, PRINCE2 Agile;
• Desenvolver das habilidades e competências no gerenciamento de projetos ágeis.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o úl-
timo momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Aplicabilidade da Técnica Gerenciamento de Projetos Ágeis com Scrum

Contextualização
Nossa situação-problema central que está sendo proposta para o Cursos é baseada
em um Projeto de Desenvolvimento de um App (aplicativo) SEJ para uma empresa de
Seguros que quer atingir o nicho de mercado do público jovem.

Nesta Unidade, existem 3 abordagens que devem ser verificadas pelos alunos:
• Definir como seria o impacto em nosso projeto da aplicação do SCRUM em Pro-
jetos Ágeis;
• Definir como seria o impacto em nosso projeto para aplicação do Gerenciamento
de Projetos Ágeis;
• Definir como se poderia desenvolver as habilidades e competências do Gerente de
Projeto Ágeis.

6
Aplicação do Scrum em Projetos Ágeis
Estudo de Caso
É um Projeto de Desenvolvimento de Software Aplicativo Mobile para uma empre-
sa de Seguros com foco a atingir o mercado do público jovem para dois ramos: seguro
de automóvel e seguro de acidente pessoais.

Usando o Scrum
Nesta etapa, utilizamos a metodologia Scrum para o Gerenciamento do Projeto do
Caso de Uso.

Deve-se elaborar o Backlog do projeto, ou seja, pode-se detalhar sobre o assunto:

• É o principal artefato do projeto Scrum;
• Reuni todos os requisitos do produto que deve ser entregue;
• Nele deve-se ter todo o entendimento necessário para atender aos requisitos;
• Deve produzir as funcionalidades com intuito de ser capaz de entregar o produto final;
• Ele lista todas as características, funções, tecnologias, melhorias e correções que
constituem o produto pronto que deve ser entregue.

Os eventos do Scrum visam criar uma rotina para diminuir a necessidade de muitas
reuniões. Em cada evento existe uma oportunidade de inspecionar e adaptar parte do
projeto. Quando não se utilizam de forma adequada todos tipos de eventos, pode não
ocorrer a otimização dos ganhos proporcionados pelo método.

Pode-se detalhar outros tipos que são considerados conjuntos menores de artefatos:
• Product backlog:
» É todo o backlog que será construído/trabalhado ao longo do projeto;
» No nosso caso o Aplicativo para Seguros Pronto.
• Sprint backlog:
» É somente a parte do backlog considerada “pronta” e selecionada para ser traba-
lhada na versão da Sprint;
» O primeiro Sprint é chamado Sprint 0 e geralmente contém algum item princi-
pal elencado pelo Product Owner.
• Incrementos:
» São os acréscimos advindos das versões posteriores, ou seja, sprint 1, sprint 2,
assim por diante;
» Cada um desses sprints apresenta algumas funcionalidades secundárias em or-
dem de priorização.

7
7
UNIDADE
Aplicabilidade da Técnica Gerenciamento de Projetos Ágeis com Scrum

Para que o time do nosso projeto, a recomendação é que efetuem todos os even-
tos Scrum.

O Scrum pode ser aplicado em qualquer tipo de projeto, não importando o tama-
nho ou ramo de negócio, mesmo em projetos complexos, sendo preferido em casos
de projetos de ambiente de tecnologia, geralmente com equipes menores de 03 a 07
pessoas. Este tipo de método é geralmente utilizado em consultorias que usam o mo-
delo de precificação homem/hora.

O ciclo de vida permite a execução do projeto com iterações de menor tamanho,

este seria um modelo sequencial e repetitivo que gera incrementos (do produto) até
chegar ao final do projeto ou entrega do produto final. Os eventos apresentam a situ-
ação denominada: cerimônias, de forma estruturada e em sequência.

O ciclo de vida do projeto utilizando o Scrum apresenta a estrutura de Sprints,

conforme a figura:

Figura 1 – Modelo Ágil - Scrum

Fonte: Adaptado de CRUZ, 2018

Lembra-se quando anteriormente citamos o conceito de times auto-organizáveis e mul-

tidisciplinares. O que significa um time auto-organizável? Qual a diferença entre auto-
-organizável e multidisciplinares?

O Scrum possui várias regras, entre elas que o time ou equipe possua característica
auto-organizável e multidisciplinar.

O time deve sempre ser formado por profissionais com experiência e com seniori-
dade, pois times experientes possuem melhor desempenho.

8
 O planejamento do Sprint, ou seja, da versão de entrega, deve ser realizado apenas
uma vez quando se iniciam os Sprints que deverão ser entregues sucessivamente para
se completar o produto final.

Agora vamos observar o ciclo de vida do Scrum aplicado ao projeto App SEJ:

Figura 2 – Ciclo Scrum no Projeto SEJ

Fonte: Adaptado de CRUZ, 2018

Lembra-se quando anteriormente citamos o conceito de times auto-organizáveis e mul-

tidisciplinares. O que significa um time auto-organizável? Qual a diferença entre auto-
-organizável e multidisciplinares? Um time auto-organizável é aquele que pode escolher a
melhor forma de realizar o seu trabalho, em vez de ser dirigida por outras pessoas fora da
equipe; enquanto que as equipes multifuncionais possuem todas as competências neces-
sárias para realizar o trabalho sem depender de outros que não fazem parte dessa equipe.

Visão do Produto faz a descrição objetiva da meta da fase e suas realizações, onde
cada fase pode ter uma meta e um produto descrito.

Elicitar requisitos é uma das fases do projeto na qual são extraídas as informa-
ções do cliente sobre o projeto, onde são percebidas as necessidades do sistema e as
suas características.

Existem várias técnicas para elicitar requisitos, como:

• Entrevistas, dinâmicas de grupo e oficinas;
• Técnicas de brainstorming, Delphi e mapas mentais;
• Técnica de tomada de decisão em grupo;
• Questionários, pesquisas, observação e protótipos.

9
9
UNIDADE
Aplicabilidade da Técnica Gerenciamento de Projetos Ágeis com Scrum

O Product Owner é quem define as histórias do produto que devem ser comple-
mentadas com documentos necessários e preparado o backlog do produto para com-
pletar o entendimento.

Conforme o tamanho do projeto, o Product Owner não consegue definir todas

as histórias do projeto e durante a execução as histórias são incrementadas de forma
iterativa sobre o escopo inicial.

A técnica MoSCoW auxilia na priorização das histórias, ou seja, dá graduação e

evita conflitos ou conflitos na definição da importância para o cliente do conjunto de
histórias. O MoSCoW deve ser exercitada pelo Product Owner em conjunto com o
cliente, pois facilita o entendimento do que é importante no projeto.

O significado do MoSCoW é o seguinte:

• Mo Must have - Deve ter; Mais importante

• S Should have - Deveria ter;

• Co Could have - Poderia ter; e
• W Won´t have - Não terá. Menos importante

Se utilizarmos o nosso projeto como exemplo, segue uma utilização prática

do MoSCoW:

Tabela 1 – MoSCoW aplicado no Projeto SEJ

Importância Requisito
M – Deve ter Existência de controles de entrada e saída.
M – Deve ter Alertas de não finalização de cadastro do cliente.
M – Deve ter Integração com ERP da empresa Seguradora.
S – Deveria ter Integração com CRM na gestão de clientes.
S – Deveria ter Alertas de não finalização do cadastro do prêmio (para seguro auto ou pessoal).
S – Deveria ter Segurança para gestão dos usuários.
C – Poderia ter Versão para dispositivos desktop.
W – Não terá Apresentação em múltiplos idiomas.
Fonte: Acervo do Conteudista

Outra técnica que ajuda na estimativa das histórias e tarefas com base no consenso
do time Scrum é o “Playing Poker Card”.

Este conjunto de 12 cartas é utilizado com valores específicos que representam o

“story points”(pontos por história) ou mesmo o tempo em horas.

As 12 cartas são estas:

• 0 (zero), esta carta representa uma tarefa ou história que já foi concluída ou pronta,
bem como um tempo bem escasso para conclusão que não pode ser mensurado;
• 1/2 ou 0,5 (meio);
• 1;

10
 • 2;
• 3;
• 4;
• 5;
• 8;
• 13;
• 20;
• 40;
• 100, representa uma história bem grande, para seu sucesso deve ser particionado
em tarefas menores, existindo o risco de uma estimativa errônea neste caso;
• “?”, representa uma história indefinida;
• “figura de uma xícara de café”, representa pausa para um break ou café, um des-
canso, pois a reunião pode ter sido longa.

Tomando por exemplo o nosso projeto e a aplicação do “Playing Poker Cards”,

segue um exemplo:

Tabela 2 – Poker Cards aplicação no Projeto SEJ

Importância Prioridade Requisito
M – Deve ter 180 Existência de controles de entrada e saída.
M – Deve ter 150 Alertas de não finalização de cadastro do cliente.
M – Deve ter 130 Integração com ERP da empresa Seguradora.
S – Deveria ter 90 Integração com CRM na gestão de clientes.
S – Deveria ter 70 Alertas de não finalização do cadastro do prêmio (para seguro auto ou pessoal).
S – Deveria ter 60 Segurança para gestão dos usuários.
C – Poderia ter 30 Versão para dispositivos desktop.
W – Não terá 20 Apresentação em múltiplos idiomas.
Fonte: Acervo do Conteudista

Aplicação do Gerenciamento
de Projetos Ágeis
O PMBOK lançou na sua 6ª. Edição o Anexo 3 detalhes para uso do Gerenciamento
de Projetos Ágeis. O ciclo de vida é diferenciado, onde se caracteriza pela elaboração
progressiva dos requisitos com base em planejamento iterativo curto e execução de ci-
clos. No nosso projeto poder-se-ia utilizar uma sequência para cada tipo de seguro: um
para seguro auto e outro para pessoal.

11
11
UNIDADE
Aplicabilidade da Técnica Gerenciamento de Projetos Ágeis com Scrum

Figura 3 – Ciclos de Iteração Sequencial

Fonte: Adaptado de PMI, 2017

Nesta nova edição existem alterações quanto aos Grupos de Processos. No Grupo
de Inicialização os projetos adaptativos utilizam e validam a utilização do termo de
abertura do projeto frequentemente.

Conforme o projeto tem andamento, as prioridades que são concorrentes e as suas

alterações podem fazer com que as restrições e os critérios fiquem ultrapassados. Por
isso, os processos de iniciação são executados nos projetos adaptativos, garantindo
o andamento do projeto dentro dos limites acordados e de acordo com as metas que
possam refletir as informações mais recentes.

O processo de iniciação é realizado a cada ciclo iterativo de um projeto de ciclo

de vida adaptativo. No Grupo de Planejamento estão os processos necessários para
definir o escopo do projeto, bem como refinar os objetivos e desenvolver as ações
necessárias para atingir os objetivos do projeto.

Nos ciclos de vida de projetos preditivos existem poucas mudanças de escopo do

projeto e de haver alta sincronia entre as partes interessadas. Nesses projetos só exis-
tem benefício se as escolhas forem bem-feitas de forma predefinida, sem alterações.
Já nos ciclos de vida adaptativos, estes desenvolvem um conjunto de planos de alto
nível para os requisitos iniciais e enquanto são elaborados os requisitos apropriados
durante o ciclo de planejamento. Portanto, os ciclos de vida preditivos e adaptativos
apresentam diferenças quanto ao nível de planejamento e quando este é feito.

Nos projetos que exigem um maior grau de complexidade e apresentam incer-

teza, devem envolver muitos membros de equipe e stakeholders nos processos de
planejamento, visando superar a incerteza e incorporar detalhes na faixa de entradas
no planejamento.

No Grupo de Execução, os processos de execução devem concluir o trabalho defi-

nido no plano de gerenciamento do projeto para atender os requisitos do projeto.

Este trabalho em ciclos de vida de projetos ágeis, iterativos e adaptativos deve

ser apresentado e gerenciado por meio de iterações, conforme a figura anterior.
Cada iteração é de um tempo curto, fixo, para realizar o trabalho, e deve apresentar
uma demonstração da funcionalidade ou do design. Com base nesta demonstração,

12
os stakeholders mais importantes e a equipe realizam uma revisão retrospectiva.
A demonstração e a revisão auxiliam a verificação do andamento em relação ao plano
e mostra se é necessária alguma mudança no escopo, no cronograma do projeto ou
nos processos de execução.

Essas reuniões também auxiliam na gestão e interação com os stakeholders apre-

sentando os incrementos do trabalho pronto e de acordo com o produto pronto.
A retrospectiva ajuda que as questões referentes a execução devem ser identificadas
e discutidas em tempo hábil, em conjunto com as ideias de melhorias. As reuniões de
retrospectivas são importantes para a gestão do conhecimento no projeto, envolver
a equipe através de discussões sobre o que está funcional e melhorar problemas da
equipe. No momento em que o trabalho é feito por meio de iterações curtas, também
é monitorado e gerenciado de acordo com os prazos de entrega do projeto a longo
prazo. A velocidade do desenvolvimento do projeto, as despesas, as taxas de defeito
e a capacidade da equipe devem ser monitorados em forma de iteração para avaliar o
desempenho até a conclusão.

No Grupo de Monitoramento e Controle estão os processos necessários para acom-

panhar, analisar e alterar o progresso e o desempenho do projeto; e para identificar
quaisquer áreas nas quais seriam necessárias as mudanças no plano e iniciá-las, man-
tendo uma lista de pendências (backlog) com as abordagens iterativas, ágeis e adapta-
tivas que acompanham, analisam e ajustam o progresso e o desempenho do projeto.

As prioridades da lista de pendências são definidas e organizadas por um repre-

sentante de negócios com o auxílio da equipe do projeto que estima e indica as de-
pendências técnicas. O trabalho sai do topo da lista de pendências para a próxima
iteração baseado na prioridade do negócio e na capacidade da equipe. As solicitações
de mudanças e defeitos são analisadas pelo representante de negócios após a equipe
ser consultada sobre as questões técnicas e devem ser priorizadas conforme a lista de
pendências do trabalho.

A abordagem de se utilizar uma lista única de trabalho e de mudanças foi criada

em ambientes de projeto com taxas de mudança muito alta. Ao se alinhar em con-
junto esses fluxos de trabalho em uma única lista de pendências, ocorre uma nova
sequência que apresenta em um único local para que os stakeholders façam a gestão
e controle do trabalho do projeto para realizar o controle de alterações e que devem
validar o escopo.

Cada mudança, ao ser realizada, é transferida da lista de pendências, sendo con-

cluídas por meio de iterações, tendências e métricas sobre o trabalho realizado, e o
esforço de mudança e as taxas de defeito devem ser calculados. O progresso deve ser
analisado com amostragens, realizado por iterações curtas.

A capacidade da equipe deve ser medida diante do progresso em relação ao escopo

original, ou seja, o que foi realizado versus o que foi planejado, bem como também
deve ser avaliado o impacto das mudanças que levam a esforços que devem minimizar
os defeitos, permitindo que as estimativas de custo, cronograma e escopo sejam reali-
zadas baseadas nas taxas reais de progresso e impactos da mudança.

13
13
UNIDADE
Aplicabilidade da Técnica Gerenciamento de Projetos Ágeis com Scrum

As métricas e projeções devem ser informadas em conjunto com os stakeholders

sobre o projeto através de gráficos de tendências para informar o progresso, compar-
tilhar questões, otimizar as atividades de melhoria contínua, gerenciando as expecta-
tivas dos stakeholders.

No Grupo de encerramento, os processos são aqueles realizados para concluir ou

finalizar ou encerrar formalmente um projeto, fase ou contrato. Feito por meio do
trabalho em projetos iterativos, adaptativos e ágeis, deve ser priorizado para realizar
primeiro os itens de maior valor para o negócio. Caso o grupo de processos de en-
cerramento conclua um projeto prematuramente, o valor ao negócio gerado deve ser
avaliado. No encerramento prematuro, as falhas com custos irrecuperáveis devem ser
minimizadas e os benefícios antecipados com um resultado rápido ou apresentando
uma prova de conceito para o negócio.

No Planejamento Contínuo e Adaptativo, este é baseado em Lean Manufacturing,

tem como objetivo refinar e melhorar agressivamente todos os elementos do plano de
gerenciamento do projeto, além dos pontos de verificação pré-agendados, associados
às iterações, conforme figura a seguir:

Figura 4 – Grupo de Processos em fases contínuas

Fonte: Adaptado de PMI, 2017

Aplicação do Caso de Estudo ao PRINCE2 Agile

O PRINCE2 e sua versão Agile são adequados apenas para uso em projetos, onde
a metodologia ágil pode ser utilizada.

O trabalho contínuo de rotina aplicando o conceito de “negócios como usual”

(BAU) abrangendo áreas como o desenvolvimento contínuo de produtos, manutenção
de produtos e melhoria.
A distinção entre trabalho de projeto e trabalho BAU é importante porque algumas
formas de trabalho ágeis devem ser aplicadas de maneira diferente em cada situação.
O trabalho de BAU deve ser utilizado em tarefas repetitivas de rotina que podem ser rea-
lizadas por pessoas com as habilidades técnicas sem necessidade de acompanhamento

14
por um gerente de projeto. Por exemplo, as modificações ou melhorias que necessitam
ser feitas em um produto já existente e os prazos são baixas.
Geralmente, deve haver uma lista grande dessas tarefas que aparecem durante toda
a vida útil do produto, podendo existir uma equipe dedicada a esse trabalho. A visão
diferenciada no PRINCE2 é que o Projeto pode até ser uma coleção de itens da BAU
manuseado coletivamente.
Na prática, ao ser utilizado em um projeto quando um novo produto ou serviço é
criado ocorre a necessidade de um comprometimento dos stakeholders para que haja
no escopo menor requisitos que contenham incerteza.
A equipe do projeto pode estar localizada em locais diferentes. Mesmo que o pes-
soal da equipe mude, o projeto pode ter longa duração e fazer parte de um programa
maior de trabalho, precisando que seja gerenciado por um gerente de projeto.
A equipe que desenvolverá o nosso projeto com a metodologia PRINCE2 Agile
precisará se adaptar a estas características.

Tabela 3 – Detalhe do PRINCE2 Agile no projeto e na manutenção

Características durante o projeto Características BAU – Manutenção que
no desenvolvimento do App SEJ acontecerá após a implantação do App SEJ
Equipe é criada em progresso
Temporário Equipe estável
Difícil Rotina
Um grau Um grau de certeza
Fonte: Acervo do Conteudista

Como um projeto possui etapas definidas para o trabalho inicial até que a atividade
de entrega se inicie, no final de um projeto. Neste ponto a equipe do projeto pode
ser desfeita e seus componentes podem atuar em outros projetos. E o produto criado
estará pronto para o uso operacional e, a partir daí, deve ser mantido e melhorado em
um ambiente BAU. Neste momento, a mesma equipe ou outra pode assumir a manu-
tenção do sistema entregue, ou seja, do produto pronto, mas em produção.

Figura 5 – PRINCE2 Agile - Negócios como Usual

Fonte: Adaptada de AXELOS, 2017

15
15
UNIDADE
Aplicabilidade da Técnica Gerenciamento de Projetos Ágeis com Scrum

O PRINCE2 Agile pode ser usado apenas no lado esquerdo da linha pontilhada
(ou seja, para projetos). Ágil pode ser usado em ambos os lados (ou seja, usado em
projetos e para BAU).

No PRINCE2 em sua versão Agile se ressalta o gerenciamento ágil de um projeto, na

qual se deve evitar visões inconsistentes, sendo isso a base fundamental da metodologia.

Uma visão básica do ágil pode geralmente ser vista como:

• Usar uma abordagem de tempo limitado e iterativa para desenvolver um software;
• Usar um conjunto de técnicas, eventos como: reuniões diárias de stand-up, sprints,
bem como histórias de usuários na elicitação dos requisitos;
• Usar o frameworks ágeis.

Uma comparação entre o PRINCE2 versus o PRINCE2 Agile pode apresentar os

seguintes detalhes:
• Organizações e indivíduos fora da comunidade PRINCE2 também podem se bene-
ficiar com PRINCE2 Agile;
• Para os profissionais que possuem experiência em desenvolvimento ágil, estes po-
dem querer adotar o padrão PRINCE2 em conjunto o ágil;
• Para os profissionais com pouca experiência no desenvolvimento ágil, estes podem
se familiarizar e, talvez, adotar o padrão PRINCE2 à medida que evoluem em sua
capacidade ágil;
• O PRINCE2 Agile não é um substituto do PRINCE2;
• O PRINCE2 Agile pode fornecer orientações adicionais para ajudar a adotar o
PRINCE2 nos projetos, independentemente se o desenvolvimento é ágil ou não.

Em nosso projeto pode ser utilizado o PRINCE2 e, também, o PRINCE2 Agile.

Desenvolver Habilidades e Competências

no Gerenciamento de Projetos Ágeis
As habilidades que devem ser desenvolvidas pelo Gerente de Projetos Ágeis pelo
PMBOK são:
• Ser capaz do gerenciamento de Projetos Técnicos;
• Apresentar liderança;
• Ter capacidade do gerenciamento estratégico e de negócios.

Entretanto, existe uma diferenciação quanto as capacidades que o Gerente de Pro-

jetos precisa possuir no PRINCE2:
• Planejar;
• Delegar;

16
 • Monitorar; e
• Controlar.
Mas, de forma geral, a recomendação para os gestores é de que estes sempre de-
vem desenvolver as habilidades de:
• Liderança;
• Comunicação; e
• Motivação da equipe.
Quando se observa sobre o aspecto de liderança, muitos estudiosos se aprofunda-
ram no assunto:

“O estilo de comportamento do líder refere-se ao que ele faz e como o faz” (WHITE;
LIPPITT, 1939).

Existem três tipos de líderes bem diferenciados e definidos, que são:

• Autoritário;
• Democrático; e
• Liberal.
O líder Autoritário, geralmente, fixa todas as diretrizes sem qualquer participação
do grupo, sendo geralmente dominador.

Na influência do líder Autoritário na gestão da equipe ocorre que:

• O trabalho de grupo só ocorre com a presença física do líder;
• Quando a chefia não está, o trabalho não se desenvolve;
• Existe tendência a indisciplina e insatisfação da equipe; e
• Somente trabalham sob pressão.
O líder Democrático é um líder onde as diretrizes são decididas em grupo e debati-
das conjuntamente. Este líder tenta estimular a equipe e não se impor.

Na influência do líder Democrático na gestão da equipe ocorre que:

• O líder e o grupo desenvolvem comunicações espontâneas e mais cordiais;
• Existe harmonia e amizade no ambiente de trabalho; e
• O ritmo de trabalho é progressivo e seguro.
Para o líder Liberal, sua participação do líder é limitada, sendo que ele não regula
nem avalia o que se passa no grupo.

Na influência do líder Liberal na gestão da equipe ocorre que:

• É o grupo que decide sobre a divisão das tarefas e escolhe os companheiros sem a
participação do líder;
• O líder somente faz alguns comentários irregulares sobre as atividades da equipe,
quando questionado; e

17
17
UNIDADE
Aplicabilidade da Técnica Gerenciamento de Projetos Ágeis com Scrum

• O líder somente esclarece quem pode fornecer informações ao grupo.

Quando se aborda o tema da Motivação com foco na gestão de projetos, deve-se

pensar em um foco de motivação organizacional, onde:
• Motivar as pessoas é um dos maiores desafios;
• Motivação é resultado da interação entre indivíduo e a situação que o envolve;
• Questões como:
» O que nos motiva e o que nos desmotiva?
• Outras questões como:
» A Motivação vem de dentro do indivíduo ou do ambiente que o motiva?
» Como criar o coaching da equipe de forma equilibrada e progressiva?

Outro ponto muito importante na Gestão da Equipe e que impacta na clareza e na

fluidez da equipe é o alinhamento na Comunicação Organizacional.

O fator de Comunicação Organizacional é:

• O tipo ou processo de comunicação que acontece no contexto de uma organização,
seja esta pública ou privada;
• Devendo ser subentendida nas entrelinhas, ou seja, tanto nas frases ditas, nas ações
e na linguagem corpórea.

Existem também duas denominações que devem ser observadas, pois causam con-
fusão com o conceito de liderança, que são: coaching e mentoring.

Coaching é o processo de otimização de resultados para desenvolver as competên-

cias e habilidades com resultados planejados e para seu êxito necessitam de: empenho,
foco e ações efetivas.

O responsável por conduzir o processo de coaching é chamado de Coach ou “treinador”.

Mentoring é uma forma de tutoria onde um profissional mais sênior e mais expe-
riente orienta e compartilha com profissionais mais jovens, que estão iniciando no
mercado de trabalho ou numa empresa, experiências e conhecimentos no sentido de
dar-lhes orientações e conselhos para o desenvolvimento de suas carreiras.

Um Gerente de Projetos pode utilizar o método de checklist: 5W2H.

18
 Figura 6 – 5W2H
Fonte: Acervo do Conteudista

O Método de checklist é utilizado para algumas atividades específicas no intuito

de apresentar maior clareza. Esta metodologia baseia-se em seguir as etapas de um
determinado processo. Assim, deve-se fazer uma explicação minuciosa, detalhada-
mente, com o objetivo de apresentar e analisar características para avaliar todas: as
capacidades, potencialidades, limitações e implicações do projeto. Basicamente é um
mapeamento das ocorrências estabelecidas no planejamento.

Quando se está em um projeto ágil, o ambiente corporativo é muito competitivo

exigindo a ausência de dúvidas, por isso, um método como 5W2H é muito assertivo
para todos os colaboradores do projeto.

Enfim, o aprimoramento do Gerente de Projetos que utiliza a metodologia ágil para

desenvolver suas habilidades e sua capacitação, pode antecipar sua adequação e des-
taque no mercado profissional.

19
19
UNIDADE
Aplicabilidade da Técnica Gerenciamento de Projetos Ágeis com Scrum

Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Livros
PMBOK com Foco Ágil – Anexo 3
PMI - Project Management Institute. Um Guia do Conhecimento em Gerenciamento
de Projetos (Guia PMBOK). 6. ed. Newtown Square, PA, 2017.

Leitura
Scrum
[Link]
PRINCE2 Agile
[Link]
Motivação
[Link]
Liderança
[Link]

20
Referências
AMARAL, D. C. et al. Gerenciamento ágil de projetos: aplicação em produtos ino-
vadores. São Paulo: Editora Saraiva, 2011.

AXELOS. Managing successful projects with PRINCE2. Norwich: TSO, 2017. (The
Stationery Office).

CRUZ, F. Scrum e Agile em Projetos: guia completo. São Paulo: Brasport, 2018.

CARVALHO, G. R. et al. Sistemas de recompensa e suas influências na motiva-

ção dos funcionários: estudo em uma cooperativa capixaba. Simpósio de excelência
em gestão e tecnologia, 2012.

FOGGETTI, C. Gestão ágil de projetos. São Paulo: Education do Brasil, 2014. (Co-
leção Bibliografia Universitária Pearson).

JUGEND, D. Gestão de projetos: teoria, prática e tendências. São Paulo: Elsevier

Brasil, 2016.

LEWIN, K.; LIPPITT, R.; WHITE, R. K. Patterns of aggressive behavior in

experimentally created “social climates”. The Journal of social psychology, v.
10, n. 2, p. 269-299, 1939.

MASSARI, V. Agile Scrum Master no Gerenciamento Avançado de Projetos. São

Paulo: Brasport, 2016.

PMI - Project Management Institute, 6. ed. Um Guia do Conhecimento em Geren-

ciamento de Projetos (Guia PMBOK), Newtown Square, PA, 2017.

ROZENFELD, H.; AMARAL, D. C. Gestão de Projetos em Desenvolvimento de

Produtos. São Paulo: Saraiva, 2006.

SABBAGH, R. Scrum: Gestão ágil para projetos de sucesso. São Paulo: Editora Casa
do Código, 2014.

21
21