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
http://bit.ly/2ZyUVqf
The Scrum Guide
http://bit.ly/2ZyVikD
What is Extreme Programming (XP)? | Agile Alliance
http://bit.ly/2ZAfdzt
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.
http://bit.ly/2ZwMpYJ
Kanban
http://bit.ly/2ZAgzdH
The PMI Talent Triangle
http://bit.ly/2Ltcv4V
Business Analysis Practice Guide | PMI
http://bit.ly/2LuOeeK
PRINCE2 Agile | PRINCE2 | AXELOS
http://bit.ly/2Lr7tpv

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