II_Teorico (1)

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Gerenciamento de 
Projetos Ágeis
Introdução em Modelos Gerenciamento Ágeis
Responsável pelo Conteúdo:
Prof. Me. Luiz Lima
Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
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.
Fonte: Getty Im
ages
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!
Introdução em Modelos Gerenciamento Ágeis
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
7
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
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
9
• 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 desenvolvimentopara 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
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
11
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
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
13
• 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
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
Desenvolvimento
– Desenvolvedor
Arquitetura
– Arquiteto
Teste – Teste
MSF
Operações de
atualização – 
Gerente de
atualização
Experiência do
usuário – Analista
do Negócio
Gerenciamento
do produto –
Analista
de Negócio
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
15
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
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
17
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
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
19
Ocorreram uma melhor organização das entradas, ferramentas e técnicas e saídas: 
• Componentes do Plano; 
• Exemplosde 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
UNIDADE 
Introdução em Modelos Gerenciamento Ágeis
Modelo Tradicional
Fixo
Escopo
Escopo
Foco no
Planejamento
Foco no
aumento de
valor
Modelo Ágil
Fixo Fixo
FlexívelFlexívelFlexível
Tempo Custo
Tempo Custo
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
21
• 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
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.
Ne le 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
23
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
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