Gerenciamento de

Projetos
Ferramentas de
Qualidade
Ferramentas de qualidade

• Diagrama de Causa e Efeito

(Ishikawa): Suponha que uma
empresa esteja investigando
as causas de atrasos na
entrega de um projeto. Um
diagrama de causa e efeito
poderia ser criado, mostrando
as possíveis causas desses
atrasos, como problemas de
comunicação, falta de
recursos, falhas no
planejamento, etc.
Ferramentas de qualidade

• Fluxograma: Um fluxograma poderia

ser criado para representar o
processo de fabricação de um
produto, mostrando todas as etapas
desde a entrada dos materiais até a
saída do produto acabado,
incluindo decisões, inspeções e
fluxos de informação entre as
etapas.
Ferramentas de qualidade

• Folha de Verificação: Para monitorar

a qualidade de um processo de
embalagem, uma folha de
verificação simples poderia ser
usada para registrar o número de
embalagens defeituosas
encontradas em cada lote,
permitindo uma análise sistemática
da frequência e tipo de defeitos.
Ferramentas de qualidade

• Diagrama de Pareto: Suponha que uma

empresa esteja analisando os tipos de
reclamações dos clientes. Um diagrama
de Pareto poderia ser usado para
classificar e priorizar os tipos de
reclamações com base na frequência,
destacando os problemas mais comuns
que precisam ser abordados primeiro.
Ferramentas de qualidade

• Histograma: Um histograma poderia

ser usado para mostrar a distribuição
dos tempos de espera dos clientes
em uma fila de atendimento. Ele
ajudaria a visualizar a frequência
com que diferentes tempos de
espera ocorrem e identificar
qualquer padrão ou tendência.
Ferramentas de qualidade

• Gráfico de Controle: Um gráfico de

controle poderia ser usado para
monitorar o número de defeitos
encontrados em produtos
fabricados ao longo do tempo. Ele
ajudaria a identificar se o processo
está sob controle ou se há variações
significativas que requerem
investigação.
Ferramentas de qualidade

• Diagrama de Dispersão: Um
diagrama de dispersão poderia ser
usado para mostrar a relação entre
a quantidade de publicidade de
um produto e suas vendas mensais.
Ele ajudaria a determinar se há uma
correlação entre essas variáveis e
avaliar o impacto da publicidade
nas vendas.

Dica de vídeo:
https://www.youtube.com/watch?v=ch0MZlLUZL0
Estilos de liderânça
 Estilos de Liderança

1. Exigente (Demanding): Este estilo envolve

estabelecer trocas claras entre o líder e os
membros da equipe, como recompensas por
desempenho ou sanções por não cumprimento
de prazos.

2. Autocrático (Autocratic): Neste estilo, o líder toma

decisões unilateralmente e direciona as
atividades da equipe. É mais apropriado em
situações onde a equipe carece de experiência
ou quando as decisões precisam ser tomadas
rapidamente.
 Estilos de Liderança

3. Liberal (Laissez-faire): O líder delega

responsabilidades e autoridade para a
equipe. É eficaz quando a equipe é
altamente qualificada e auto-suficiente.

4. Visionário (Visionary): Este estilo envolve

inspirar e motivar a equipe a alcançar
objetivos desafiadores. O líder
transformacional busca criar um impacto
positivo na cultura e no desempenho da
equipe.
 Estilos de Liderança

5. Democrático (Democratic): Este estilo envolve

a tomada de decisões de forma colaborativa,
com o líder incentivando a participação da
equipe. É útil quando se deseja promover a
criatividade e o comprometimento da
equipe.

6. Leader Coach (Coaching): Neste estilo, o líder

foca em atender às necessidades da equipe,
facilitando seu crescimento e
desenvolvimento. O líder servidor coloca as
necessidades da equipe em primeiro lugar.
Gerenciamento de
Projetos
Quarta Unidade
Professor Adilson da Silva
 Objetivos

• Gerenciamento de Comunicação
• Gerenciamento de Riscos
• Gerenciamento de Aquisições
• Gerenciamento de Partes interessadas
• Atividade Contextualizada
• Gestão ágil de projetos
Gerenciamento de
Comunicações
Gestão das comunicações

• Gestão das comunicações visa

garantia que as necessidades de
informações das partes
interessadas sejam atendidas.

• O gerente de projeto gasta 90%

do tempo em comunicação
Gestão das comunicações

• 5 Cs da comunicação
• Correta
• Concisa
• Clara
• Coerente
• Controlada
 Gestão das comunicações

• 5 Cs devem ser apoiados de habilidades:

• Escuta ativa
• Consciência de diferenças culturais e
pessoais
• Identificação, definição e
gerenciamento das partes interessadas
• Aprimorar habilidades como:
• Persuasão
• Motivar pessoas
• Orientar para melhorar desempenho
• Negociar para alcançar objetivos
• Solucionar conflitos
Processos de gerenciamento da
comunicações
Planejar o
Gerenciamento das
comunicações P

I Iniciação
P Planejamento
Monitorar as Gerenciar as
E Execução
comunicações Comunicações
C E
C Controle
F Finalização
Processos de gerenciamento da
comunicações
• É o processo de desenvolver uma
abordagem e um plano adequado
para atividades de comunicação
do projeto com base nas
necessidades de informações de
cada parte interessada, nos ativos e
nas necessidades do projeto
 Processos de gerenciamento da
comunicações
• Documentos que precisam ser divulgados.
• Termo de abertura
• Plano de projeto e documentos do projeto
• EAP
• Cronograma de reuniões
• Riscos
• Problemas
• Sucessos
• Trabalho futuro
• Data da próxima festa de conclusão do
marco
• Lições aprendidas
• Registro de questões
• Resultado das solicitações de mudanças
• etc
Monitorar as comunicações

• É o processo de garantir que as

necessidades de informações do
projeto e de suas partes sejam
atendidas
Gerenciamento de
Riscos
Gestão de Risco

• Gestão de Riscos consiste em

identificar, analisar e responder a
riscos, de forma a maximizar a
probabilidade de ocorrência de
eventos positivos e minimizar a
probabilidade de eventos adversos ao
projeto.
Componentes de Risco

• Fato ou Evento
• Desencadeia um ou mais riscos;

• Probabilidade
• Chance de ocorrência;

• Impacto
• Extensão da perda ou ganho
 Graus de Riscos em projetos

• Risco Individual do Projeto

• É um evento ou condição incerta que, se
ocorrer, provocara um efeito positivo ou
negativo em um ou mais objetivos do
projeto.
• Risco Geral do Projeto
• É o efeito da incerteza do projeto no seu
todo, decorrente de todas as fontes de
incerteza, incluindo riscos individuais,
representando a exposição das partes
interessadas às implicações de variação
no resultado do projeto, seja positivas ou
negativa.
Planejar gerenciamento de
riscos Planejar o
Gerenciamento de
Riscos P

Monitorar os riscos
C Identificar os riscos
P

Implementar E
Realizar a Análise
respostas aos riscos
Qualitativa dos
Riscos P

I Iniciação
P Planejamento
Planejar as Realizar a Análise
E Execução Respostas aos Quantitativa dos
C Controle Riscos P Riscos P
F Finalização
Planejar gerenciamento de
riscos
• Decidir como abordar as atividades e
processos de gerência de riscos do
projeto e criar um plano para sua
execução.

• Para que serve?

Serve para identificar a área de
conhecimento à qual o risco é aplicável
no projeto. Esse atributo é importante
para que o gerenciamento dos riscos
possa ser realizado de forma unificada
para cada categoria.
Planejar gerenciamento de
riscos
• Plano de gerenciamento de Riscos
• A saída deste processo é o Plano de
Gerência de Riscos , que descreve
como o processo de gerência de riscos
será executado no projeto
(endereçando identificação de riscos,
quantificação de riscos, respostas a
risco e a monitoração e controle de
riscos).
Identificar os riscos

• Identificar os riscos individuas do

projeto, bem como as fontes de riscos
do projeto, e de documentar suas
características

• Identificar riscos é um processo iterativo

• Podem surgir no decorrer do projeto,
através do ciclo de vida e o nível de
risco geral do projeto também pode
mudar.
Realizar análise qualitativa dos riscos

• Priorizar os riscos individuais do projeto para

análise ou ação posterior, através de
avaliação de probabilidade de ocorrência e
impacto.
• Parâmetros dos riscos
• Urgência.
• Proximidade.
• Dormência (O período de tempo após o
risco ocorrer antes que o seu impacto)
• Gerenciabilidade.
• Capacidade de controle.
• Capacidade de detecção.
• Conectividade (Até que ponto o risco está
relacionado a outros riscos individuais)
• Impacto estratégico.
Realizar análise qualitativa dos riscos
• Analisar numericamente o efeito
combinado dos riscos individuais no projeto
e outras fontes de incerteza nos objetivos
gerais do projeto.
• Descreve a chance que uma variável pode
assumir ao longo de um espaço de valores
• A distribuições podem ser:
• contínuas, amplamente usadas em
modelagem e simulação, representam
incerteza em valores tais como durações
de atividades e custos
• discretas para representar eventos
incertos, como o resultado de um teste ou
cenário possível em uma árvore de
decisão.
Planejar as respostas aos riscos

• Desenvolver alternativas, selecionar

estratégias e acordar ações para lidar com a
exposição geral de riscos e também tratar os
riscos individuais do projeto.
 Planejar as respostas aos riscos

• Estratégias para Ameaça

• Escalar - Quando a ação é escalada para
estruturas com mais autonomias que o
gerente do projeto.
• Prevenir - Atuar para eliminar o risco ou
proteger o projeto de seu impacto
• Transferir - Transferir a responsabilidade pela
consequência do Risco
• Exemplos: Seguros e Garantias
• Mitigar -Ação tomada para reduzir a
probabilidade ou impacto
• Aceitar - Reconhece o risco, mas nenhuma
ação é tomada
Planejar as respostas aos riscos
• Estratégias para Oportunidades
• Escalar - Quando a ação é escalada para
estruturas com mais autonomias que o
gerente do projeto.
• Explorar - Eliminar a incerteza associada a
um risco positivo, fazendo que a
oportunidade ocorra
• Compartilhar - Atribuição da
responsabilidade a terceiros que possam
capturar melhor a oportunidade
• Aceitar -Aceitar o risco sem mudar o plano.
• Melhorar
• Aumento da probabilidade e/ou
impactos positivos
Planejar as respostas aos riscos

• Estratégias para riscos gerais do projeto

• Prevenir - No caso de riscos
significativamente negativos e fora dos
limites acordados para o projeto.
• Explorar - No caso de riscos
significativamente positivo e fora dos limites
acordados para o projeto.
• Transferir/compartilhar - Se o nível do risco
geral do projeto for alto, mas a
organização é incapaz de soluciona-lo
efetivamente, um terceiro poderá ser
envolvido.
Implementar as respostas aos riscos

• Implementar os planos acordados de

respostas aos riscos
 Monitorar Riscos

• Monitorar a implementação dos planos

acordados de respostas aos riscos;
• Acompanhar riscos identificados;
• Identificar e analisar novos riscos; e
• Avaliar a eficácia do processo de riscos
Gerenciamento de
Aquisições
Gerenciamento de Aquisições

• Gerenciamento das aquisições do

projeto inclui os processos necessários
para comprar ou adquirir produtos,
serviços ou resultados externos a
equipe do projeto
• Gerenciamento e controle necessários
para desenvolver e administrar acordos
como:
• Contratos,
• Pedidos de compra,
• Memorandos de entendimento
(MOAs) ou
Acordos de nível de serviço (ANS ou
SLA)
Processos de gerenciamento das
aquisições

Planejar o
Gerenciamento das
Aquisições P

I Iniciação
P Planejamento
Controlar as aquisições Conduzir as Aquisições
E Execução
C E
C Controle
F Finalização
Planejar o Gerenciamento de
Aquisições

• Decidir o processo de compras do

projeto, especificando a
abordagem e identificando
fornecedores em potencial.
Conduzir Aquisições

• Obter respostas de fornecedores, seleção

de um fornecedor e adjudicação de um
contrato.
Controlar Aquisições

• Gerenciar as relações de aquisições,

monitoramento do desempenho do
contrato e realizações de mudanças e
correções nos contratos, conforme
necessário
Gerenciamento de
Partes Interessadas
Gestão de partes interessadas

• Identificar todas as pessoas, grupos ou

organizações que podem impactar ou
serem impactados pelo projeto, analisar as
expectativas e seu impacto no projeto, e
desenvolver estratégias de gerenciamento
apropriadas para o engajamento eficaz
nas decisões e execução do projeto
Gestão de partes interessadas

• Englobam pessoas e organizações, tais

como clientes, patrocinadores, a
organização executora e o público que
estão ativamente envolvidos no projeto, ou
cujos interesses podem ser positiva ou
negativamente afetados pela execução ou
pela conclusão do projeto
Gestão de partes interessadas

• Projetos são bem-sucedidos

quando alcançam seus
objetivos e atendem ou
excedem as expectativas das
partes interessadas
(stakeholders), porém, tais
interesses são muitas vezes
contraditórios!
Gestão de partes interessadas

• O que fazer
1. Identificar todos os envolvidos
2. Determinar seus requisitos,
expectativas e interesses
3. Determinar seus nível de influência
4. Planejar como você deve gerenciar
e como irá se comunicar
5. Gerenciar suas expectativas,
influência e engajamento
6. Executar o plano: Comunicar-se
7. Controlar as comunicações e o
engajamento
Processos de gerenciamento das
partes interessadas
Identificar as partes
interessadas
I

Controlar o Planejar o
engajamento das gerenciamento das
partes interessadas partes interessadas
C P

I Iniciação
P Planejamento Gerenciar o
E Execução
engajamento das
C
partes interessadas
Controle E
F Finalização
 Identificar as partes
interessadas
• Identificar pessoas, grupos ou organizações
que podem impactar ou serem
impactados por uma decisão, atividade ou
resultado do projeto e analisar e
documentar informações relevantes
relativas aos seus interesses, nível de
engajamento, interdependências,
influência, e seu impacto potencial no êxito
do projeto.
 Planejar o engajamento das partes
interessadas

• Desenvolver estratégias para envolver as

partes interessadas do projeto, com base
em suas necessidades, expectativas,
interesses e potencial impacto no projeto.
Gerenciar o engajamento das partes
interessadas

• Comunicar e trabalhar com as partes

interessadas para atender às suas
necessidades/expectativas deles, abordar
as questões à medida que elas ocorrem, e
incentivar o engajamento apropriado das
partes interessadas nas atividades do
projeto, no decorrer de todo o ciclo de
vida do projeto.
 Gerenciar o engajamento das partes
interessadas

• Monitorar os relacionamentos das partes

interessadas do projeto em geral, e ajustar
as estratégias e planos para o
engajamento das partes interessadas.
Metodologias Ágeis
 Manifesto Ágil e Suas Bases

• Indivíduos e interações => mais importantes que processos e ferramentas.

• Software funcionando => mais importante do que documentação
completa e detalhada.
• Colaboração com o => mais importante do que negociação de
Cliente contratos.
• Adaptação a mudanças => mais importante do que seguir o plano inicial.

http://www.agilemanifesto.org
Manifésto Ágil

• Nossa maior prioridade é satisfazer o

cliente, através da entrega adiantada
e continua de software de valor;
• Aceitar mudanças de requisitos,
mesmo no fim do desenvolvimento.
Processos ágeis se adéquam a
mudanças, para que o cliente possa
tirar vantagens competitivas;
• Entregar software funcionando com
frequência, na escala de semanas até
meses, com preferência aos períodos
mais curtos;
Manifésto Ágil

• Pessoas relacionadas à negócios e

desenvolvedores devem trabalhar em
conjunto e diariamente, durante todo o
curso do projeto;
• Contínua atenção à excelência técnica
e bom design, aumenta a agilidade;
• Simplicidade: a arte de maximizar a
quantidade de trabalho que não
precisou ser feito;
• As melhores arquiteturas, requisitos e
designs emergem de times auto-
organizáveis.
Manifésto Ágil

• As melhores arquiteturas, requisitos e

designs emergem de times auto-
organizáveis.
• Em intervalos regulares, o time reflete
em como ficar mais efetivo, então, se
ajustam e otimizam seu
comportamento de acordo
 Manifésto Ágil

• São características marcantes dos

métodos ágeis a flexibilidade e a
simplicidade.
• Vejamos seus benefícios:
• aumento da satisfação dos clientes
(diminuição das reclamações);
• melhoria na comunicação e aumento
na colaboração dos envolvidos;
• aumento do retorno do investimento
nos projetos;
• aumento da motivação da equipe;
Manifésto Ágil

• Vejamos seus benefícios (cont.):

• melhoria na qualidade do software
produzido;
• diminuição de custos;
• aumento da produtividade dos
desenvolvedores.
Métodos Tradicional X Ágil

• Vejamos a seguinte situação: sua

empresa, um banco da cidade,
vai implementar um aplicativo
móvel para que os clientes possam
visualizar seus extratos. Há rumores
de que seu principal
concorrente,um outro banco da
cidade, vai lançar seu próprio
aplicativo móvel também.
Tempo é uma
Questão
Essencial
 Métodos Tradicional X Ágil

Neste esboço ágil, A

• TRADICIONAL: Escreveria o termo de
abertura do projeto, definindo o SOBRECARGA É MUITO
aplicativo móvel, enviaria para MENOR, economizando
aprovação, definiria o cronograma tempo desde a ideia até
precisamente, enviaria para aprovação a execução.
de novo, criaria a equipe do projeto,
para ai sim, iniciar o desenvolvimento.
• Ágil: Seria parecido, porém, bem mais
simples e objetivo! Seria definido a visão
do produto para o aplicativo móvel,
montaria uma equipe, iniciaria o
desenvolvimento.
Métodos Tradicional X Ágil

• As mudanças que uma adoção ágil traz

Planejar para
impacto na forma como os membros da eliminar
equipe desempenham seus trabalhos, indo riscos
contra ao que foi aprendido com
treinamentos anteriores.
• A principal diferença entre um modelo
Tradicional e um ágil é o tipo de controle
nos processos de cada um.
Tradicional X Ágil
Valor para o
Cliente é o
que nos
move!
Processo SCRUM

https://knowledge21.com.br/blog/o-que-e-scrum/
Framwork SCRUM

• SCRUM é um framework para

organizar e gerenciar trabalhos
complexos, tal como projetos de
desenvolvimento de software.
Projeto SCRUM

• Em projetos Scrum a equipe tem a

responsabilidade, ou seja, não há
centralização de autoridade.
Equipes dos Projetos
SCRUM

• O SCRUM atua de forma AUTO-

ORGANIZADO, eliminando papéis,
dando as pessoas uma visão que
vá além de suas especialidades e
ajuda a equipe de todas as
maneiras possíveis. Além disso,
equipes Scrum são pequenas.
 Gerente funcional
ou de Projetos

• A equipe é auto-organizada, ou
seja, os processos são definidos pela
própria equipe, sendo um dos
princípios, o manifesto ágil. Além
disso, o manifesto ágil prioriza
pessoas e interações mais do que
processos e ferramentas.
Resiliência

• Equipes Scrum tem a capacidade

de superar o distúrbio imposto por
fenômenos externos, pois o
desenvolvimento deve ser
adaptável e dinâmico.
Escalabilidade em
SCRUM
Scrum pode ser
• Equipe de 7 + ou - 2 Pessoas
• Escalabilidade através de usado em
equipes
• Fatores de Escala
• Tipo de aplicação
projetos
• Tamanho da equipe
• Dispersão da equipe
envolvendo
• Duração do projeto
mais de 500
pessoas
Princípios do SCRUM

• Mostrar a eficácia das suas práticas Fundamentado nas

de desenvolvimento para que você teorias empíricas de
possa melhorá-las, enquanto provê
um framework dentro dos quais controle de processo e
produtos complexos podem ser
desenvolvidos.
tem como base para
• Emprega uma abordagem iterativa sua implementação
e incremental para otimizar a
previsibilidade e controlar riscos. três pilares:
transparência,
inspeção e adaptação.
 Valores que sustentam os
pilares do SCRUM

• Respeito: Os membros do Time do Scrum

respeitam uns aos outros como pessoas
capazes e independentes.
• Abertura: O Time do Scrum e
Stakeholders concordam em estarem
abertos a respeito do trabalho a ser feito
e dos desafios com a sua execução.
Transparência
• Os aspectos do processo
que afetam o resultado
devem ser visíveis para
aqueles que gerenciam os
resultados. Esses aspectos
não apenas devem ser
transparentes, mas também
o que está sendo visto deve
ser conhecido.

DAT A 22/ 0 3/ 20 23
Inspeção
• Os diversos aspectos do
processo devem ser
inspecionados com uma
frequência suficiente para
que variações inaceitáveis no
processo possam ser
detectadas. A frequência da
inspeção deve levar em
consideração que qualquer
processo é modificado pelo
próprio ato da inspeção.

DAT A 22/ 0 3/ 20 23
Adaptação
• Se o inspetor determinar,a partir da
inspeção, que um ou mais
aspectos do processo estão fora
dos limites aceitáveis e que o
produto resultante será inaceitável,
ele deverá ajustar o processo ou o
material sendo processado

DAT A 22/ 0 3/ 20 23
Valores que sustentam os
pilares do SCRUM
• Comprometimento: No Scrum cada
pessoa deve estar comprometida
com os objetivos do time e com a
meta da sprint.
• Foco: No Scrum o time mantém o
foco constante na meta da sprint e
nos objetivos do time.
• Coragem: Um Time de Scrum
trabalha com coragem para fazer a
coisa certa e encarar os difíceis
problemas, dentro dos limites do
framework.
SCRUM - Fundamentos
Papéis

Atitude SCRUM Artefatos

Cerimônias
Atitudes
• Compromisso - Compromisso implica o
engajamento e envolvimento. A
equipe de scrum se compromete a
atingir metas específicas. Confiante de
que o scrum team vai entregar o que
promete, a organização mobiliza sobre
o compromisso de atender cada
objetivo.
• O Processo Ágil, possui a ideia de auto-
organização, proporciona às pessoas
toda a autoridade de que necessitam
para cumprir os compromissos. No
entanto compromisso exige um esforço
consciente.
SCRUM - Fundamentos

Papéis

Atitude SCRUM Artefatos

Cerimônias
SCRUM – Papéis

Papeis Centrais
• Dono do Produto (PO)
• Scrum Master
• Time de Desenvolvimento
Papéis não essenciais
• Stakehoder(s)
• Fornecedores
• Scrum Guidance Body
SCRUM - Fundamentos

Papéis

Atitude SCRUM Artefatos

Cerimônias
SCRUM – Papéis

Papeis Centrais
• Dono do Produto (PO)
• Scrum Master
• Time de Desenvolvimento

Papéis não essenciais

• Stakehoder(s)
• Fornecedores
• Scrum Guidance Body
O time de Desenvolvimento -
Objetivos

•O Time Scrum tem um papel

fundamental no desenvolvimento do
projeto, pois é o time quem transforma
requisitos em funcionalidades, ou seja,
ele desenvolve e entrega todo o
produto.
O time de Desenvolvimento -
Objetivos
• Ser Multifuncional, com sete (mais ou
menos) membros;
• Seleciona o objetivo da Sprint (Sprint
Goal) e especifica os produtos e trabalho
o necessários;
• Tem a liberdade de fazer qualquer coisa
dentro das diretrizes do projeto para
alcançar o objetivo da Sprint;
• É auto organizável e planeja suas
atividades;
• Apresenta os produtos de trabalho ao
Product Owner
O time de Desenvolvimento -
Responsabilidades
•Realizar execução Sprint –
Concepção, construção, integração e
testes de itens do Product Backlog.

•Inspeção e Adaptação – com

participação na reunião diária é
esperado que cada membro da
equipe inspecionem coletivamente o
progresso do trabalho;
O time de Desenvolvimento -
Responsabilidades
•Grooming do Product Backlog – o time
deve alocar 10% do seu tempo para
ajudar PO com as atividades de
refinamento do Product Backlog;

•Planejar a Sprint – No inicio de cada

sprint, a equipe de desenvolvimento
deve participar do planejamento.
Ajudando a estabelecer, junto com o
Scrum master e o PO, as metas da
Sprint.
O time de Desenvolvimento -
Características

•Auto Organização - Os membros da

equipe Scrum são indivíduos motivados
que não esperam seus superiores para
entender quais tarefas eles precisam fazer.
•Fortalecida - A equipe é formada com os
recursos necessários para entregar os
produtos ou serviços desejados,
juntamente com autoridade para tomar
as decisões. A equipe interage entre si
com responsabilidade individuais e
conjuntas.
O time de Desenvolvimento -
Características
•Colaboração - A equipe compartilha
conhecimentos, ideias, riscos e
responsabilidades , além de garantir um
trabalho em harmonia com os membros da
equipe para entregar os resultados
desejados.
•Objetivo Comum - Dentro da equipe, os
indivíduos devem trabalhar em conjunto
para um objetivo comum.
•Cultura - Aconselha-se a formar uma
equipe Scrum com os membros instalados
presencialmente na organização.
O time de Desenvolvimento -
Características
•Tamanho perfeito - O tamanho ideal da
equipe de Scrum deve ser de seis a dez
pessoas, pois isso irá garantir que a equipe
Scrum seja grande o suficiente para possuir
todas as habilidades necessárias para o
projeto.
•Múltiplas Habilidades -A equipe deve
possuir coletivamente as habilidades
necessárias para garantir todas as entregas
do projeto.
O time de Desenvolvimento -
Características

•Um projeto envolve pessoas e

mudanças, principalmente
quando falamos de entregas
constantes. Dessa form, as
metodologias ágeis trabalham
com equipes altamente
motivadas e com suporte a
mudanças durante o processo
de desenvolvimento.
Product Owner

• Representa o cliente e é responsável por

garantir que a equipe agregue valor ao
negócio.
• É o ponto central do projeto ágil e é quem
exerce a liderança sobre o produto que
está sendo desenvolvido.
• Este é claramente um papel para uma
pessoa em tempo integral com
Responsabilidades significativas.
Product Owner Responsabilidades

•Planejamento – é participante-chave nas

atividades de planejamento de Produtos,
Release e Sprints.
•Grooming do Product Backlog – É quem
supervisiona toda a preparação e
refinamento do product Backlog, o que
inclui: criar, atualizar, estimar e priorizar os
itens.
•Critérios de Aceitação – O PO é
responsável por definir os critérios de
aceitação para cada item do Prouct
Backlog.
Product Owner Responsabilidades

•Colabora com equipe de desenvolvimento

– Ele deve colaborar frequentemente com
a equipe de desenvolvimento de uma
forma muito direta e estreita.

•Colabora com o resto da equipe – Ele é o

porta-voz de toda a comunidade de
partes interessadas, internas e externas da
empresa.
Product Owner
Scrum Master – Lider Servidor

• Ouvir – Espera-se que os líderes servidores

ouçam atenta e receptivamente ao que
está sendo dito ou não dito.

• Empatia – Bons líderes servidores aceitam e

reconhecem indivíduos por suas
competências e habilidades especiais e
únicas.
Scrum Master – Lider Servidor

•Cura – Os lideres servidores reconhecem

e aproveitam oportunidades de ajudar
os seus colegas, que estão passando
por fases emocionais.
•Consciência – A conscientização e
particularmente, a autoconsciência, é
um traço em lideres servidores. Isto lhes
permite compreender melhor e integrar
os problemas relacionados a, ética,
poder e valores.
 Scrum Master – Lider Servidor

• Persuasão – Ao invés de forçar o

cumprimento através da coerção, os
lideres servidores praticam a
persuasão.
• Conceituação – Capacidade de
visualizar e analisar os problemas, a
partir de uma perspectiva conceitual
e visionária mais ampla, ao invés de
focar apenas nos objetivos imediatos
de curto prazo, é uma habilidade
única de bons lideres servidores.
Scrum Master – Lider Servidor

• Previsão – Suas mentes intuitivas

permitem que os líderes servidores
usem e apliquem lições passadas em
realidades presentes para prever o
resultado de situações, e decisões
atuais.

• Stewardship – exige um compromisso

de servir aos outros.
Scrum Master – Outras características

• Autoridade do processo – como o

próprio nome diz, ele é o mestre do
SCRUM, a pessoa que mais conhece
do framework.

• Estudo contra interferências – Ele deve

proteger a equipe contra a
interferência externa.
Scrum Master – Liderança Servidora

• Removedor de impedimentos – Ele é

responsável por remover os
impedimento que possam aparecer.

• Agente de mudança - Responsável

por implantar e manter o SCRUM na
empresa.
Scrum Master – Liderança Servidora

• Compromisso com o crescimento de

outros – tem o profundo compromisso
com o crescimento das pessoas que
trabalham dentro de sua organização.
• Construindo a comunidade – Os líderes
servidores estão interessados na
construção de comunidade dentro de
um ambiente de trabalho, levando em
consideração as mudanças nas
sociedades, longe de comunidades
menores, para grande instituições que
moldam e controlam vidas humanas.
Responsabilidade do Scrum Master
com a Organização
• Treinar a organização na adoção do
Scrum.
• Planejar implementações Scrum
dentro da organização.
• Ajuda partes interessadas a
compreender e tornar aplicável o
Scrum e o desenvolvimento e produto
empírico.
• Influenciar mudanças que aumentam
a produtividade do Time Scrum.
• Trabalhar com outro Scrum Master
para aumentar a eficácia da
aplicação do Scrum nas
organizações.
Perfil Scrum Master

• Conhecimento – para ser um bom

coach, o Scrum Master deve
combinar os processos do Scrum.
• Questionador – Scrum Master têm
que saber fazer as perguntas certas;
• Paciente – como Scrum Masters
preferem não dar respostas, eles
precisam tem paciência até que a
própria equipe consiga chegar às
respostas;
Perfil Scrum Master

• Colaborativo – o Scrum Master deve ter

excelentes habilidades de colaboração
para trabalhar com o Product Owner, a
equipe de desenvolvimento e todos os
outros envolvidos.
• Protetor – o Scrum Master deve proteger
a equipe.
• Transparente – finalmente, o Scrum
Master é transparente em todas as
formas de comunicação;
Relação
dos Papéis
Papeis não essenciais –
Fornecedores
• Fornecedores:
• Indivíduos ou organizações
que fornecem produtos e
serviços, que não estão
dentro das competências
essenciais da organização
do projeto;
Papéis não essenciais – Scrum
Guidance body
• Scrum Guidance Body:
• Consiste de um conjunto de documentos e/ou um grupo de
especialistas que estão geralmente envolvidos na definição
de objetivos relacionados com:
• Qualidade
• Regulamentações governamentais
• Segurança e outros;
• Orientam o trabalho realizado pelo Dono do produto, Scrum
Master e Time Scrum
 Quem É
Responsável por?
• Criar Itens no Backlog do Produto
• Garantir a Qualidade
• Priorizar o Backlog do Produto
• Participar do Sprint Planning
• Participar do Sprint Review
• Participar da Reunião Diária
• Participar da Reunião de
Retrospectiva
• Testar
• Desenvolver
• Melhorar o Processo
• Melhorar Práticas Técnicas
• Falar com os Stakeholders
• Acompanhar o Progresso do Sprint
• Participar do Grooming do Backlog
• Garantir que o Backlog do Produto está
Visível para Todos
• Resolver Impedimentos Técnicos
• Facilitar os Eventos Scrum
• Garantir que as Regras Scrum são
Seguidas
• Coach do Time
• Acompanhar o Progresso do Release
 Quem É
Responsável por?
• Garantir a Qualidade - Time
• Participar do Sprint Planning - Todos
• Participar do Sprint Review - Todos
• Participar da Reunião Diária – Time, Scrum
Master
• Participar da Reunião de Retrospectiva –
Time, Scrum Master
• Participar do Grooming do Backlog - Todos
• Testar - Time
• Desenvolver - Time
• Integrar o Software - Time
• Melhorar o Processo - Time
• Melhorar Práticas Técnicas - Time
• Priorizar o Backlog do Produto - PO
• Falar com os Stakeholders - PO
• Acompanhar o Progresso do Sprint – PO e Time
• Garantir que o Backlog do Produto está Visível
para Todos - PO
• Criar Itens no Backlog do Produto - PO
• Resolver Impedimentos Técnicos – Scrum Master
• Facilitar os Eventos Scrum – Scrum Master
• Garantir que as Regras Scrum são Seguidas –
Scrum Master
• Coach do Time – Scrum Master
• Acompanhar o Progresso do Release – PO
SCRUM - Fundamentos

Papéis

Atitude SCRUM Artefatos

Cerimônias
Cerimônias
Cerimônias
•O Objetivo dos eventos no
Scrum é proporcionar um maior Sprint
controle sobre o processo,
adquirindo uma rotina de SPRINT
SPRINT
trabalho e aumentando a PLANNING II
PLANNING I
transparência no decorrer do
desenvolvimento.
DAILY REVISÃO
SCRUM SPRINT

RETROSPECTIVA
SPRINT
Cerimônias
•Eventos prescritos são usados no
Scrum para criar uma rotina e Sprint
minimizar a necessidade de
reuniões não definidas no Scrum;
•Eventos time boxed com uma SPRINT SPRINT
duração máxima; PLANNING I PLANNING II
•Todos os eventos Scrum são
oportunidades para inspecionar
e adaptar. DAILY REVISÃO
SCRUM SPRINT

RETROSPECTIVA
SPRINT
 Sprint
• A Sprint é o principal evento do
Scrum, esse evento trata-se de um Sprint
ciclo de desenvolvimento (iteração),
que tem um tempo determinado
com dia para começar e dia para SPRINT SPRINT
acabar. PLANNING I PLANNING II
• Esse tempo pode variar de 2 a 4
semanas, mas nunca exceder 30 DAILY REVISÃO
dias. Uma Sprint começa ao final da SCRUM SPRINT
Sprint anterior, sem intervalos.

RETROSPECTIVA
SPRINT
Sprint
• O objetivo deste evento é
transformar os itens do Backlog do Sprint
Produto (funcionalidades
descritas) em um software ou
parte dele, totalmente funcional SPRINT SPRINT
e pronto para uso, dentro do PLANNING I PLANNING II
período definido para a Sprint.
DAILY REVISÃO
SCRUM SPRINT

RETROSPECTIVA
SPRINT
 Sprint
• O tempo da Sprint sempre será
definido em dias corridos, sem Sprint
descontar finais de semana e
feriados. Deve ter uma duração de
2 semanas (14 dias corridos) a 4 SPRINT SPRINT
semanas (30 dias corridos). PLANNING I PLANNING II
• Duração menor do que 14 dias
pode ser insuficiente para construir DAILY REVISÃO
um software ou parte dele, SCRUM SPRINT
totalmente funcional e pronto para
uso, por isso não é recomendável,
porém é possível.
RETROSPECTIVA
SPRINT
 Sprint
• Duração maior do que 30 dias, pode
aumentar consideravelmente o risco, Sprint
pois mais do que 30 dias alguns
requisitos e prioridades poderão ser
alteradas e o tempo para se obter SPRINT SPRINT
um feedback do cliente é muito PLANNING I PLANNING II
longo e a chance de descobrir o que
estava errado é grande. DAILY REVISÃO
SCRUM SPRINT

RETROSPECTIVA
SPRINT
Eventos Scrum – Time Box
 Sprint - Recomendações
• A duração seja constante do início
ao fim do projeto, ou seja, uma vez Sprint
definida a duração da Sprint, que
esse seja o mesmo até que todo o
backlog do produto seja finalizado. SPRINT SPRINT
• Outra recomendação é que times
PLANNING I PLANNING II
mais novos no Scrum façam Sprints
maiores, de 30 dias no início, pois DAILY REVISÃO
terão mais tempo para se adequar SCRUM SPRINT
as regras do Scrum e um tempo
maior para entregar o que foi
selecionado para a Sprint.
RETROSPECTIVA
SPRINT
 Sprint - Recomendações
• Um produto completo poderá ter
inúmeras Sprints, quantas forem Sprint
necessárias até que o backlog do
produto seja finalizado (se é que ele
for finalizado algum dia). Ao final de SPRINT SPRINT
cada Sprint, é liberado um software PLANNING I PLANNING II
ou parte dele, pronto para o uso,
porém isso não quer dizer que será DAILY REVISÃO
liberada uma versão final, que vai
SCRUM SPRINT
para produção.

RETROSPECTIVA
SPRINT
 Eventos Scrum - Sprint
•Durante a Sprint:
• Não são feitas mudanças que Sprint
podem afetar o objetivo da Sprint;
• As metas de qualidade não
diminuem; SPRINT SPRINT
• O escopo pode ser esclarecido e PLANNING I PLANNING II
renegociado entre o Product
Owner e o Time de
Desenvolvimento quanto mais for DAILY REVISÃO
aprendido. SCRUM SPRINT
• Cada Sprint tem a definição do que
é para ser construído, um plano
projetado e flexível que irá guiar a
construção, o trabalho e o RETROSPECTIVA
resultado do produto; SPRINT
Eventos Scrum – Sprint Cancelamento
• Uma Sprint pode ser cancelada antes
do time-box, se o objetivo da Sprint se
tornar obsoleto;
Sprint
• Somente o Product Owner tem a
autoridade para cancelar a Sprint mas SPRINT SPRINT
ele pode fazer isso influenciado pelas
outras partes interessadas;
PLANNING I PLANNING II
• Qualquer item de Product Backlog
completado e “Pronto” é revisado; DAILY REVISÃO
• Se uma parte do trbalho estiver
potencialmente utilizável, o PO o SCRUM SPRINT
aceita;
• Todos os itens do Product Backlog
incompletos são reestimados e RETROSPECTIVA
colocados de volta no Product SPRINT
Backlog.
Eventos Scrum - Reunião de planejamento
• O Sprint Planning Meeting é a
reunião de planejamento que ocorre Sprint
antes do início de uma Sprint, como
resultado de um trabalho
colaborativo do Scrum Team. SPRINT SPRINT
• Ao fim de uma Sprint Planning PLANNING I PLANNING II
Meeting o Development Team deve
saber responder ao Scrum Master e
ao Product Owner o que será DAILY REVISÃO
entregue como resultado do SCRUM SPRINT
próximo incremento e como o
trabalho será desenvolvido para
chegar ao resultado.
RETROSPECTIVA
SPRINT
Eventos Scrum - Reunião de planejamento
• O PO apresenta para o Scrum Team o
Product Backlog, que consiste em Sprint
uma lista ordenada de tudo que é
necessário para o produto final, para
que o Development Team escolha SPRINT SPRINT
quantos itens será capaz de PLANNING I PLANNING II
desenvolver na próxima Sprint.
• Essa é uma decisão que deve ser
tomada apenas pelo o Development DAILY REVISÃO
Team, pois é este quem vai SCRUM SPRINT
desenvolver o produto que
representará o resultado da Sprint.

RETROSPECTIVA
SPRINT
Eventos Scrum - Reunião de planejamento
• O PO tem a responsabilidade de
definir a prioridade dos itens do Sprint
Product Backlog, mas quem sabe
quantos itens serão desenvolvidos é
o DT. SPRINT SPRINT
• Após a criação do Sprint Backlog, PLANNING I PLANNING II
que representa a seleção dos itens
do Product Backlog, que serão
desenvolvidos na Sprint, define-se o DAILY REVISÃO
objetivo da Sprint que será a meta SCRUM SPRINT
com a qual todos devem trabalhar
até o término da Sprint.

RETROSPECTIVA
SPRINT
Eventos Scrum - Reunião de planejamento
• O trabalho a ser realizado na Sprint é
planejado na reunião de
planejamento da Sprint.
• Planejamento é feito de forma
colaborativa, não apenas feito pelo
ScrumMaster.
• O Scrum Master garante que o
evento ocorra e que os participantes
entendam seu propósito;
• O Scrum Master ensina o Time Scrum
a manter-se dentro dos limites do
time-box;
Fonte: http://uni4.com.br/blog/tag/sprint-planning-meeting/
Eventos Scrum - Reunião de planejamento
• Tem como objetivo responder:
• O que pode ser entregue como
resultado do incremento da
próxima Sprint?

• Como o trabalho necessário para

entregar o incremento será
realizado?
Eventos Scrum - Reunião de planejamento
• Planning – Parte 1: O que fazer
• Durante a primeira parte do Sprint
Planning, product Owner apresenta
com uma visão de negocio os itens
do Product Backlog com maior
prioridade.
• O Time faz perguntas para entender
e já rascunhar algumas possíveis
soluções técnicas.
• Esses itens apresentados irão formar
o Sprint Backlog.
Eventos Scrum - Reunião de planejamento
Planning – Parte 2: Como fazer
• Logo após a Sprint Planning parte 01,
o Time deve se reunir para realizar o
planejamento técnico dos itens
do Sprint Backlog.
• Nessa etapa é onde vai acontecer a
quebra técnica dos itens em tarefas.
• Também é nesse momento
que o Time estima os itens e tarefas
do Sprint Backlog.

Importante ressaltar que é o Time que

define a quantidade de trabalho que
vai ser desenvolvido durante o SPRINT.
Eventos Scrum - Reunião de planejamento
• Time de Desenvolvimento também
pode convidar outras pessoas para
participar desta reunião para
fornecer opinião técnica ou de
domínios específicos;
• O Product Owner pode estar
presente para esclarecer questões
sobre os itens do Product Backlog e
para ajudar nas decisões
conflituosas de troca;
Eventos Scrum - Reunião de planejamento
• No final da reunião de
planejamento da Sprint, o Time
de Desenvolvimento deve ser
capaz de explicar ao Product
Owner e ao Scrum Master como
pretende trabalhar para
completar o objetivo da Sprint e
criar um incremento previsto;
Eventos Scrum - Reunião de planejamento

• Estimativas:
• Planning Poker;
• Ideal Time;
• Relative Sizing / Story Points;
• Estimativa por Afinidade (T-shirt
size, Sequencia de números de
Fibonacci);
Eventos Scrum - Reunião de planejamento

Fonte: http://www.emilianosoldipmp.info/2013/05/agile-raw-affinity-estimation/
Eventos Scrum - Reunião Diária
•A Daily Scrum Meeting é uma reunião
diária time-box de 15 minutos para que
o time sincronize as atividades e crie um
Sprint
plano para as próximas 24 horas.
•Deve ser realizada no mesmo horário e SPRINT SPRINT
local;
•Três perguntas:
PLANNING I PLANNING II
•O que eu fiz ontem que ajudou o Time
de Desenvolvimento a atender a meta DAILY REVISÃO
da Sprint?
•O que eu farei hoje para ajudar o Time SCRUM SPRINT
de Desenvolvimento atender a meta
da Sprint?
•Eu vejo algum obstáculo que impeça RETROSPECTIVA
a mim ou o Time de Desenvolvimento SPRINT
no atendimento da meta da Sprint?
Eventos Scrum - Reunião Diária

• Normalmente, após a reunião diária, o

time de desenvolvimento ou alguns
integrantes se encontram para
discussões mais detalhadas;
• O Scrum Master assegura que o Time
tenha a reunião, mas o Time de
Desenvolvimento é responsável por
conduzir a Reunião Diária;
• Somente os integrantes do Time de
Desenvolvimento participem da
Reunião Diária;
Eventos Scrum - Reunião Diária

• Essa reunião assegura que o DT está

seguindo a direção correta em
relação ao objetivo da Sprint. Como
regra do Scrum somente os
integrantes do Development Team
devem participar da Daily Scrum
Meeting
Eventos Scrum - Reunião Diária

• Melhoram as comunicações,
eliminam outras reuniões,
identificam e removem
impedimentos para o
desenvolvimento.
• Destacam e promovem rapidez na
tomada de decisões, e ainda
melhoram o nível de conhecimento
do Time de Desenvolvimento.
Eventos Scrum - Reunião Diária

• São muitas as vantagens de se

realizar as Daily Scrum’s todos os
dias.
• Além de melhorar a comunicação
e o engajamento da equipe,
corrige os rumos, mitiga os riscos e
ainda proporciona o uso dos 3
pilares do Scrum, que é a inspeção
(do progresso) e adaptação
(ajustes e impedimentos)
diariamente e transparência (todos
sabem o que está acontecendo).
 GIFTS Sprint
•Good Start – Ajudam a começar bem o dia
•Improvement – Promove a melhoria
contínua SPRINT SPRINT
•Focus – Reforça o foco no que realmente PLANNING I PLANNING II
importa
•Team – Para reforçar o senso de equipe
DAILY REVISÃO
•Status – Para comunicar o que está
acontecendo SCRUM SPRINT
• O Daily Scrum funciona como um mini
PDCA diário promovido pela equipe do
projeto. RETROSPECTIVA
SPRINT
Eventos Scrum - Review
• A Sprint Review acontece ao final de
cada Sprint e tem como objetivo Sprint
avaliar o que foi produzido pelo
development Team.
• É uma reunião time-box com SPRINT SPRINT
duração de 4 horas para Sprints de PLANNING I PLANNING II
um mês.
• O Time Scrum e as partes
interessadas colaboram sobre o que DAILY REVISÃO
foi feito na Sprint e nas próximas SCRUM SPRINT
coisas que precisam ser finalizadas;
• Não é uma reunião de status;

RETROSPECTIVA
SPRINT
Eventos Scrum - Review
• Os participantes incluem o Time
Scrum e os Stakeholders chaves
convidados pelo Product Owner;
• O Product Owner esclarece quais
itens do Backlog do Produto que
ficaram “Prontos” e quais não
ficaram “Prontos”;
• O Time de Desenvolvimento
demonstra o trabalho que está
“Pronto” e responde as questões
sobre o incremento;
Eventos Scrum - Review
• O grupo todo colabora sobre o
que fazer a seguir;
• Fornece valiosas entradas para a
Reunião de Planejamento da
próxima Sprint;
Eventos Scrum - Retrospectiva

• A retrospectiva da Sprint ocorre Sprint

após a revisão da Sprint e antes do
próximo Planejamento da Sprint.
• Isso é no máximo uma reunião de SPRINT SPRINT
três horas para Sprints de um mês. PLANNING I PLANNING II
• Oportunidade para o Time Scrum
inspecionar a si próprio e criar um
plano para melhorias a serem DAILY REVISÃO
aplicadas na próxima Sprint. SCRUM SPRINT

RETROSPECTIVA
SPRINT
Eventos Scrum - Retrospectiva
•Propósito da Retrospectiva da Sprint:
•Inspecionar como a última Sprint foi Sprint
em relação as pessoas, relações,
processos e ferramentas;
•Identificar e ordenar os principais SPRINT SPRINT
itens que foram bem e as potenciais PLANNING I PLANNING II
melhorias;
•Criar um plano para implementar
melhorias no modo que o Time DAILY REVISÃO
Scrum faz seu trabalho.
SCRUM SPRINT
• Perguntas características
• O que ocorreu bem na Sprint?
• O que poderia ser melhorado?
• O que nos comprometemos a
RETROSPECTIVA
melhorar no próximo Sprint? SPRINT
Eventos Scrum - Retrospectiva

• O Scrum Master encoraja o Time Scrum a

melhorar o processo de desenvolvimento e
as práticas para fazê-lo mais efetivo e
agradável para a próxima Sprint.
• O Time Scrum planeja formas de aumentar
a qualidade do produto.
• Ao final da Retrospectiva, o Time Scrum
deverá ter identificado melhorias que
serão implementadas na próxima Sprint.
• A Retrospectiva da Sprint fornece um
evento dedicado e focado na inspeção e
adaptação, onde as melhorias podem ser
adotadas a qualquer momento.
 Eventos Scrum - SCRUM of SCRUM

• Tem o objetivo de alinhar tecnicamente

as equipes que estão participando do
mesmo projeto.
• Tratam assuntos que possam causar
atrasos na entrega do produto como
um todo.
• Essa reunião ocorre uma vez por
semana e para participar é ecolhido um
membro da equipe que possa
responder a dúvidas.
Eventos Scrum - SCRUM of SCRUM

• Podem existir dois tipos de Scrum de

Scrums um que busca alinhar aspectos
técnicos e outro que trata de aspectos
táticos e gerenciais.
• No primeiro recomendasse que seja
inidicado um membro do time de
desenvolvimento, pois ele precisa de
conhecimento dos problemas técnicos.
• No segundo tipo, o melhor indicado é o
Scrum Master.
Eventos Scrum SCRUM of SCRUM
• Normalmente são feitas quatro
perguntas na execução do Scrum de
Scrums com o objetivo de tornar a
reunião mais dinâmica e objetiva, e
preencher as informações necessárias
para o andamento do produto.
• O que sua equipe fez desde a última
reunião?
• O que seu time irá fazer depois desta
reunião?
• Há algum impedimento para
realização das atividades?
• Seu time está deixando de fazer algo
que de alguma forma irá impactar os
outros times?
Eventos Scrum
SCRUM of SCRUM
• Tem o objetivo de alinhar
tecnicamente as equipes que
estão participando do mesmo
projeto.
• Tratam assuntos que possam
causar atrasos na entrega do
produto como um todo.
• Essa reunião ocorre uma vez por
semana e para participar é
ecolhido um membro da equipe
que possa responder a dúvidas.
Eventos Scrum
SCRUM of SCRUM
• Podem existir dois tipos de Scrum
de Scrums um que busca alinhar
aspectos técnicos e outro que trata
de aspectos táticos e gerenciais.
• No primeiro recomendasse que seja
inidicado um membro do time de
desenvolvimento, pois ele precisa
de conhecimento dos problemas
técnicos.
• No segundo tipo, o melhor
indicado é o Scrum Master.
 Eventos Scrum
SCRUM of SCRUM
• Normalmente são feitas quatro perguntas na
execução do Scrum de Scrums com o objetivo
de tornar a reunião mais dinâmica e objetiva, e
preencher as informações necessárias para o
andamento do produto.
• O que sua equipe fez desde a última reunião?
• O que seu time irá fazer depois desta reunião?
• Há algum impedimento para realização das
atividades?
• Seu time está deixando de fazer algo que de
alguma forma irá impactar os outros times?
SCRUM - Fundamentos

Papéis

Atitude SCRUM Artefatos

Cerimônias
Artefatos SCRUM
SCRUM - Fundamentos

Papéis

Atitude SCRUM Artefatos

Cerimônias
Artefatos SCRUM

• Os artefatos definidos para o Scrum

são especificamente projetados
para maximizar a transparência
das informações chave de modo
que todos tenham o mesmo
entendimento dos artefatos.
 Artefatos SCRUM

• O Backlog do Produto (Product

Backlog) é uma lista de
funcionalidades desejadas de um
produto, ou seja os requisitos que um
cliente espera receber ao final do
projeto, descrito com sua própria
linguagem.
Características Chave
• Para o planejamento da nossa primeira entrega, precisamos
desdobrar as caracteristicas-chave do produto, programadas
para o primeiro release, em requisitos ou histórias.
Backlog do Produto
ID História
1 O cliente deve conseguir pesquisar livros por autor (Valor 8)
2 O cliente deve conseguir pesquisar livros por título (Valor 10)
3 O cliente deve conseguir pesquisar livros por editora (Valor 6)
4 O cliente deve conseguir comprar um livro escolhido (compra 1 item por vez) (Valor 10)
5 O cliente deve conseguir incluir o item em um carrinho de compras (Valor 7)
6 O cliente deve conseguir pagar sua compra via boleto bancário (Valor 9)
7 O cliente deve conseguir pagar sua compra via cartão de crédito (Valor 8)
8 O cliente deve conseguir rastrear sua encomenda (Valor 4)
9 O cliente deve ser notificado por e-mail das etapas de sua compra (pagamento, aprovação, correio) (Valor 6)
10 O cliente deve oseguir enviar o feedback de seu atendimento após o recebimento do produto (Valor 5)
Priorização do Backlog

• De forma mais ampla, a equipe Scrum e

o Product Owner precisam considerar
todo o backlog ao ordenar seus itens, a
fim de otimizar o valor ou o retorno sobre
o investimento (ROI).
 Priorização do Backlog
• O primeiro passo a fazer o
planejamento e a divisão das tarefas
da Sprint. Isso é realizado na reunião de
planejamento do Sprint e utiliza uma
técnica chamada de planning poker.
Cada tarefa deve ter horas associadas.
• O tempo de uma tarefa é sempre
analisado usando uma sequencia
Fibonaci,ou seja uma tarefa deve ter
entre 3 horas (no mínimo) e 6 horas (no
máximo), de forma que possa ser
realizada em um dia.
Levantamento de Requisitos
• Diferente do modelo tradicional de
gestão de projetos, onde precisamos
fechar o escopo para poder começar a
executar, no Scrum acredita-se que o
início do projeto não é o melhor
momento para isso. Nesse ponto ainda
não conhecemos suficiente o projeto.
Requisitos Funcionais
Requisitos Funcionais são conhecidos no mundo ágil como User Stories
(Estórias do Usuário).
Quem? O que? Por que?
(Precisa) (Precisa) (Precisa)
Como cliente Eu posso reservar Para poder retirá-los no
filmes pela internet drive-thru da loja
Como atendente Eu posso obter a Para informar o cliente
posição atualizada de sobre sua
um filme disponibilidade
Como gestor da loja Eu posso consultar Para criar e oferecer
informações sobre o promoções mais
histórico dos clientes atraentes
Requisitos Não Funcionais
• Os Requisitos não funcionais, são
aspectos subjetivos relacionados às
User Stories.
• Adaptabilidade
• Confiabilidade
• Eficiência
• Flexibilidade
• Performance
• Portabilidade
• Usabilidade
Requisitos do Produto
• Tanto os requisitos funcionais quanto
os não-funcionais podem ser
representados pelas User Stories.

• Os funcionais diretamente e os não-

funcionais como parte dessas
mesmas User Stories.
 User Story

• Para estruturar
adequadamente o
Backlog do Produto,
utiliza-se o conceito de
User Stories, que
contém a descrição
detalhada dos requisitos
de cada solicitação a
ser implementada.
Requisitos do Produto
•SER INDEPENDENTE: Isso garante a
flexibilidade durante o ciclo de
desenvolvimento do produto.
•SER NEGOCIÁVEL: O requisito deve permitir
alterações.
•SER PRIORIZADO: O requisito deve,
obrigatoriamente, assegurar a entrega de
valor para o cliente.
•SER ESTIMADO: O requisito deve
apresentar condições para que seu prazo
de desenvolvimento/entrega possa ser
estimado.
Requisitos do Produto
•SER PEQUENO: O requisito deve estar
descrito de forma que permita uma
estimativa com certo nível de certeza
(quanto menor, melhor).
•SER INSPECIONADO: O requesito deve
prover as informações necessárias para
que possa ser inspecionado/testado
pelo cliente final.
Requisitos do Produto
• Mantenha o Product Backlog
atualizado.
• Dê importância à definição de pronto.
• Conhecimento, incerteza e risco de
histórias.
• Qual é a influência da história no
próximo release.
• Atenção ao tamanho das histórias.
• Atenção à dependência entre as
histórias.
• Ouça todos os interessados no projeto.
• Utilize técnicas de priorização.
• Considerar a priorização por temas.
 Requisitos do Produto
• O propósito das reuniões de Backlog
Grooming (Refinamento do Backlog) é
aprimorar o Product Backlog.
• Aliás, a palavra Grooming em inglês
significa cuidar da aparência, manter
limpo e arrumado.
• Uma reunião de Backlog Grooming deve
ser realizada próximo ao final da iteração,
garantindo assim, que o Product Backlog
esteja sempre pronto para a próxima.
 Atividades do Backlog Grooming
• Organizar o backlog é uma processo
contínuo que envolve:
• A descoberta de novos itens, assim
como alteração e remoção de itens
antigos.
• Quebrar Estórias muito grandes
(épicos).
• A priorização dos itens do backlog
(trazendo os mais importantes para o
topo).
Atividades do Backlog Grooming
• Organizar o backlog é uma processo
contínuo que envolve:
• Preparar e refinar os itens mais
importantes para a próxima reunião
de planejamento.
• Estimar e corrigir estimativas dos itens
do backlog (em caso de novas
descobertas).
• Incluir Critérios de Aceitação.
Quem participa da Reunião de Grooming
• Embora a manutenção do Backlog seja
de responsabilidade do Product Owner,
outros membros do time podem
colaborar na reunião de Organização
do Backlog,
• Ken Schwaber sugere a participação de
10% da equipe durante de 5 a 10% do
tempo da Sprint, de forma a incentivar
a comunicação face a face entre as
pessoas ao invés de outros meios como
comunicação por e-mail ou
documentos.
Backlog da Sprint
• O SPRINT BACKLOG é um artefato vivo
durante o Sprint.
• Na reunião de planejamento, ele não
precisa estar completo, apenas com as
atividades necessárias para os primeiros
dias do Sprint.
Backlog da Sprint
• O Sprint Backlog é uma lista ordenada
de User Stories, que a equipe acredita
que possa ser completada durante o
próximo Sprint.
• Essa lista é um subconjunto do Product
Backlog no qual estão priorizadas todas
as User Stories do projeto.
Backlog da Sprint
• O BACKLOG do Sprint é dinâmico por
natureza;
• O Backlog do Sprint é um subconjunto
do Backlog do Produto.
• O Backlog do Sprint é uma saída de
uma reunião de planejamento do
Sprint.
• No Backlog do Sprint, a equipe Scrum
trabalha em como as histórias do
usuário seriam implementadas em um
Sprint.
 Característica de um Backlog do Sprint

• O Backlog do Sprint é de propriedade da

equipe de desenvolvimento e contém o
que, e como ele é entregue.
• Por último, a equipe implementanda
(converte) os itens de Backlog do produto
mais priorizados em software de trabalho.
• Para cada iteração (Sprint), a equipe cria
um plano com base no que está no topo
do Backlog do Produto ao iniciar o Sprint.
Por que o Backlog do Sprint é Importante

• Quaisquer atividades de mitigação

para tratar os riscos identificados
também serão incluídas como
tarefas no Backlog do Sprint.
Dicas para Planejar o Sprint Backlog
• Envolva todos os membros da equipe
do processo.
• Discuta como cada item deve ser
implementado.
• Tenha uma definição de Feito.
• Identifique todos os tipos de tarefas.
• Não calcule tarefas em tudo.
• Não atribua tarefas antecipadamente.
• Revise o compromisso do Sprint.
• Não use muito tempo.
• Evolua o Sprint Backlog durante o
Sprint.
Dicas para Planejar o Sprint Backlog
• Assim que o time prevê o número de
histórias que podem ser realizadas no
Sprint Backlog, o escopo deve ser
blindado até o final do Sprint.
• No entanto, se durante o Sprint o
Product Owner decidir que há uma
característica de maior valor de
negócio que precisa entrar no Sprint,
deve ocorrer uma interrupção da
mesma.
 Incremento

• O Incremento do Produto é composto

por novas funcionalidades e por
melhorias no que foi produzido
anteriormente, oriundas de itens do
Product Backlog.
 Incremento

• Em cada Sprint, é gerado pelo time de

desenvolvimento um Incremento do
Produto pronto, de acordo com a
Definição de Pronto.
• Idealmente, esse Incremento está
sempre apto a ser entregue para os
clientes, ou seja, é entregável (ou
potencialmente entregável”).
O que é a definição de preparado?
•Um artefato utilizado para garantir
que os itens a serem considerados na
reunião de Sprint Planning estejam Preparado?
preparados segundo um critério bem Sprint Planning
definido.
•É um acordo formal entre Product
Owner e time de desenvolvimento SPRINT
sobre o estado em que um item do
Product Backlog deve estar para ser
Sprint Review
considerado preparado para entrar
no Sprint Backlog. Pronto?
O que é a definição de preparado?

• É criada antes do início do

desenvolvimento do produto,
geralmente antes mesmo do primeiro
Sprint.
• Entretanto ela pode ser modificada e
evoluir de forma a acomodar novas
necessidades identificadas ao longo
do projeto. A Definição de Preparado
geralmente tem o formato de uma
lista de critérios, condições ou, ainda,
passos de um processo.
Definição de Pronto
• Quando o item do Backlog do
produto ou um incremento é
descrito como “pronto”, todos
devem entender o que isso
significa. Embora isso varie
significativamente para cada time
Scrum, os integrantes devem tem
um entendimento compartilhado
do que significa o trabalho estar
completo, assegurando a
transparência.
Definição de Pronto
• A Definição de Pronto é um
acordo formal entre Product
Owner e time de desenvolvimento
sobre o que é necessário para se
considerar que um trabalho
realizado no Sprint está “Pronto”.
• Essa é a “Definição de Pronto”
para o time Scrum e é usada para
assegurar quando o trabalho está
completado no incremento do
Produto.
Radiadores de Informação
• São diferentes ferramentas visuais, que
mostram os dados de andamento do
projeto rapidamente através de
gráficos, tabelas ou resumos:
• Não é exclusivo do Scrum, também
encontramos isso na XP, na Lean e na
FDD.
• No SCRUM são?
• Graficos Burndonw e Burnup;
• Kanban ou Quadro de tarefas;
• Roadmap de produtos;
• Mapas de Histórias;
Atualizando o Burndown Chart no Daily Meeting

• O gráfico Burndown é atualizado

diariamente após a reunião diária
da equipe.
• Ele serve para indicar o tanto de
trabalho que ainda resta fazer na
Sprint.
 Roadmap do
produto
• O roadmap de produto é uma
importante ferramenta
estratégica para Product
Managers, auxiliando no
planejamento e execução de
todo o projeto de lançamento
de um novo produto ou
funcionalidade.
 Roadmap do produto

• A importância do Roadmap
• Ajuda a alcançar na visão do
produto;
• Garante a entrega;
• Alinha Stakeholders;
• Evita ruídos de comunicação;
• A aproxima as equipes da
estratégia da empresa.
Mapas de Histórias

• “User Story Mapping é um mapa

que organiza as histórias de
usuário em um modelo que
ajuda a compreender a
funcionalidade do sistema, a
identificar falhas no seu
backlog, e a, efetivamente,
planejar releases holísticas que
oferecem valor aos usuários e
ao negócio a cada versão”
Processo SCRUM

https://knowledge21.com.br/blog/o-que-e-scrum/
Outras Metodologias
Ágeis
KANBAN
Kanban e desenvolvimento
de Software
• O Kanban ajuda a assimilar e controlar o
progresso de suas tarefas de forma visual.
• É, normalmente, utilizado um quadro
branco com alguns pequenos papéis
(Post-it) colados, esses papéis representam
as suas tarefas, ao termino de cada tarefa
o papel é puxado para a etapa seguinte
até que a mesma seja finalizada.
• Ao olhar para um quadro Kanban é fácil
enxergar como o trabalho seu e de sua
equipe fluem, permitindo não só
comunicar o status, mas também dar e
receber feedbacks.
Kanban e desenvolvimento
de Software
• O Kanban é um dos métodos de
desenvolvimento de software menos
prescritivo, se tornando adaptável a
quase qualquer tipo de cultura. Ao
contrário de outros métodos que forçam
uma mudança desde o início, o Kanban
busca a evolução, não a revolução.
Kanban - Práticas fundamentais
• Visualizar o fluxo de trabalho (workflow)
• Limitar a quantidade de trabalho em
andamento (WIP)
• Gerenciar e medir o fluxo
• Tornar as políticas do processo explicitas
• Implementar loops de feedback
• Usar modelos para reconhecer
oportunidades de melhoria.
 Kanban - Classificação de itens e hierarquia

Buffer

WIP

Priorização de Itens
Kanban - Cartões de
parede (Cards Wall)
• É importante que os cartões
possuam informações simples e
descritivas.
Kanban - Bons motivos
para o uso
• A redução de desperdício e de custo são
os benefícios mais importantes para uma
empresa/equipe que deseja ampliar seus
objetivos.
• Tempo de ciclo curtos, oferecendo
recursos mais rapidamente;
• Melhor gestão nas mudanças de
prioridade;
• Requer menos organização;
• O processo é simplificado;
• Maior visibilidade dos projetos;
Kanban - Bons motivos
para o uso
• A redução de desperdício e de custo
são os benefícios mais importantes para
uma empresa/equipe que deseja
ampliar seus objetivos.
• Redução de desperdício;
• Redução de custo;
• Elimina atividades que não agregam
valor para a equipe;
• Melhora a motivação e desempenho
da equipe.
LEAN
 Metodologia LEAN

• O objetivo de um sistema de
produção Lean é “ter as coisas certas
no lugar certo na hora certa, desde a
primeira vez, enquanto elimina-se o
desperdício estando sempre aberto a
mudanças”.
• O termo Lean Software Development
teve sua origem em 2003 na
publicação de um livro de mesmo
nome escrito por Tom e Mary
Poppendieck. Neste trabalho os
autores apresentam como aplicar
princípios de Lean ao
desenvolvimento de software.
 Metodologia LEAN

• Lean oferece um conjunto de

princípios que podem ser utilizados
por organizações para adaptar
ferramentas, técnicas e métodos a
seus contextos e capacidades
específicas.
• Lean Software Development trás os
conceitos de Lean para o universo do
desenvolvimento de software, para
que através da aplicação dos
mesmos princípios seja possível
eliminar desperdícios e alcançar
melhores resultados.
Metodologia LEAN -
Princípios

• Eliminar Desperdícios;
• Amplificar o aprendizado;
• Adiar comprometimentos e manter
flexibilidades;
• Entregar rápido;
• Tornar a equipe responsável;
• Construir com qualidade e integridade;
• Visualizar e Otimizar o todo;
Metodologia LEAN -
Princípios
• Heijunka: Nivelamento da produção
• Hansei: Reflexões profundas em busca da
melhoria contínua;
• Andon: Ferramenta visual e sonora para
sinalização de problemas na linha de
produção.
• Poka-Yoke: Dispositivo para controle da
qualidade. Acionado automaticamente
quando há algum erro ou defeito no
processo de produção.
• Kaizen: Melhoria Contínua.
• KanBan: instrumento de sinalização que
permite a criação de fluxo.
XP
XP

• O XP é um método de
desenvolvimento de software, leve,
não é prescritivo, e procura
fundamentar as suas práticas por um
conjunto de valores.

• O objetivo principal do XP é levar ao

extremo um conjunto de práticas
que são ditas como boas na
engenharia de software.
XP - Valores
• Comunicação – Dentro do time,
entre o cliente e a equipe.
• Coragem – Para fazer refactoring,
para jogar fora o código e refazer
tudo no dia seguinte.
• Feedback – Testes de aceitação,
presença do cliente.
• Simplicidade – Faça sempre da
maneira mais simples e que vá
funcionar.
• Respeito – Trabalho em equipe
XP - Princípios

• Envolvimento do Cliente
• Entrega Incremental
• Foco nas pessoas
• Aceitar Mudanças
• Manter a simplicidade
XP - Boas Práticas
A criação de testes leva em conta não o
• Test First tempo ganho com a criação dos mesmos

Design antes da codificação, mas conhecer

previamente as possíveis falhas do seu
sistema.

• Refactoring A reconstrução baseia-se na remoção de

redundância, eliminação de funcionalidades
inúteis, e reconstrução de projetos obsoletos.

• Stand-up
Meeting Reuniões rápidas e diárias com a equipe

• Continuous Os diversos módulos do software são

Integration
integrados diversas vezes por dia e todos os
testes unitários são executados. O código não
passa até obter sucesso em 100% dos testes
unitários.
XP - Boas Práticas

• Pair Todo código de produção é

desenvolvido por duas pessoas

Programming trabalhando com o mesmo teclado,

o mesmo mouse e o mesmo monitor.

• Move People As duplas de programação são

revezadas em média a cada 2h.
Around
E equipe como um todo é
• Collective Code responsável por cada arquivo de
código. Não é preciso pedir
Ownership autorização para alterar qualquer
arquivo.

• Coding Todo código é desenvolvido

Standards seguindo um padrão.
XP - Boas Práticas

• The Customer is O cliente está sempre disponível para

resolver dúvidas, alterar o escopo de
Always Available uma iteração e definir prioridades.

O software é entregue em pequenas

• Small Release versões para que o cliente possa

obter o seu ganho o mais cedo
possível e para minimizar riscos.

O código está, a qualquer momento,

• Simple Design na forma mais simples que passe
todos os testes.

213/31
XP - Boas Práticas
Cada programador trabalha 40 horas por
semana. Se o horário for flexível, deve-se
• 40-Hour Week respeitar o horário do par naquele período,
senão enquanto um trabalha o outro vai
pra casa.

• On-Site Ter um papel de cliente na

equipe XP em tempo integral
Customer para responder as perguntas

• Acceptance São definidos pelo usuário e são os

critérios de aceitação do software.
Tests
• System Ajuda a manter todos os desenvolvedores
em sintonia com o projeto quando dando
Metaphor nomes a objetos ou classes.
XP - Papéis do XP
• Desenvolvedor: são os
desenvolvedores que fazem as tarefas
mais vitais em um projeto XP.
• Cliente: Ele faz a priorização do que
será desenvolvido e a verificação se o
software corresponde aos seus
anseios.
• Coach: Deve manter o time engajado
no projeto.
• Testador: Ele chefia as operações de
teste do sistema de diversas formas.
• Cleaner: promove refatorações, reduz
a complexidade do sistema, aumentar
a coesão do código.
XP - Papéis do XP
• Tracker: Ele coleta as métricas do time
de desenvolvimento durante a
iteração, gerando dados que podem
ser usados para o aperfeiçoamento
da equipe durante o projeto.
• Gerente: Desempenha diversas
tarefas no projeto, como a facilitação
da comunicação entre
desenvolvedores e clientes, auxilia o
cliente na priorização de histórias,
agenda reuniões com o cliente,
auxilia no planejamento do projeto
gera relatórios e acompanhamento
do projeto etc.
XP - SCRUM
FDD
 FDD
• Feature Driven Development
(Desenvolvimento Guiado por
Funcionalidades) é uma
metodologia ágil para
gerenciamento e desenvolvimento
de software. Ela combina as
melhores práticas do
gerenciamento ágil de projetos com
uma abordagem completa para
Engenharia de Software orientada
por objetos.
 Conceitos
• O Desenvolvimento Guiado Por Funcionalidades (FDD) é uma
metodologia ágil para o processo de engenharia de software,
elaborado com foco na entrega frequente de “software funcionando”
para os clientes e na utilização de boas práticas durante o ciclo de
seu desenvolvimento.
• Um fato marcante é o forte favorecimento ao envolvimento de
clientes (interno ou externo) ao processo de planejamento e
desenvolvimento do software.
• Diferentemente de outras metodologias, o FDD não é extremamente
focado na programação ou no modelo, mas sim utiliza o bom senso
para abstrair o melhor dos dois mundos.
• Não é uma metodologia de gerenciamento de projetos de software.
Apesar de, em suas práticas, existirem atividades relacionadas a esse
fim. Apresenta como foco principal cobrir o processo de engenharia
de software, e não do gerenciamento.
Práticas do FDD
• Modelagem de objetos do domínio.
• Desenvolvimento por feature
(funcionalidade).
• Posse individual de classe (código).
• Equipes de features (papéis por
áreas de negócio).
• Inspeções (especificações, código,
teste de unidades).
• Builds regulares (geração de versões
com novos features).
• Gerenciamento de configuração.
• Relatório/Visibilidade de resultados.
 Práticas do FDD
• Exemplo
• Área de Features Principal (Subject
Domain Area)
• Gerenciamento de venda de
produtos
• Conjunto de Features (Business
Activity)
• Vender para um cliente
• Features
• Calcular o total de vendas
• Calcular o total de compras de
um cliente
• Estimar o tempo de entrega de
uma venda
• Calcular a taxa de uma venda
Estrutura

223
Papéis do FDD
•Gerente de projeto - Função
administrativa – Prepara relatório de
progresso, contratação e alocação de
pessoas. Providencia ambiente de
trabalho.
•Arquiteto chefe - Responsável elo
projeto técnico.
•Especialistas no domínio – Representa os
usuários.
•Gerentes de desenvolvimento –
administra atividades do dia a dia.
•Programadores chefes – responsável por
administrar os demais programadores,
•Proprietários de classes – membros das
equipes de desenvolvimento.
 Papéis do FDD suporte

• Gerente de liberação – acompanha

os relatórios de progresso.
• Engenheiro de build – Controla as
versões do sistema.
• Ferramenteiro – cria ferramentas do
suporte ao projeto.
• Administrador de sistemas –
configura, avalia e gerencia
problemas nos servidores, nas
estações de trabalho e na rede
utilizada pela equipe.
Conclusão
• FDD
• Fornece clareza
• Eleva o controle
• Facilita a comunicação – reporta
resultados
• Status do projeto completo é
determinado pelas características
entregues
• Características quebram o
trabalho em entregas menores e
mais gerenciáveis
• Builds regulares
XP - SCRUM
PMO
PMO
• Segundo o PMI, um escritório de
gerenciamento de projetos é uma
estrutura de gerenciamento que
padroniza os processos de
governança relacionados ao
projeto e facilita o
compartilhamento de recursos,
metodologias, ferramentas e
técnicas.
PMO
• Nas organizações em que a área de
projetos é bem definida e o
desenvolvimento de novos projetos
tem estratégias de inovação, a
estrutura de um escritório de
gerenciamento de projetos (PMO) é
fundamental para o planejamento e
controle.
• As lições aprendidas em cada projeto
não devem ser negligenciadas, e os
escritórios são responsáveis por
gerenciarem esse conhecimento na
empresa, evitando que erros
cometidos em outros projetos possam
ocorrer novamente.
PMO

• Além disso, os escritórios otimizam o

uso de recursos, já que concentram as
informações de todos os projetos em
andamento e possuem a visão dos
novos que ainda estão sendo
planejados, equilibrando suas
necessidades e demandas.
PMO
• Tipos de PMO
• Pools de administração;
• Política de processo;
• Suporte especializado;
• Controle de portfólio e programação
de projetos (consolidação de
informações)
• Tarefas do PMO
• Definição de formatos de relatórios e
cronogramas.
• Coleta e cobrança de relatórios .
• Avaliações de qualidade dos
relatórios (cronogramas, formatos
etc).
PMO
• Os escritórios ágeis propõem a
administração dos projetos de forma
transparente e adaptável, enquanto
inspecionam as entregas de seus múltiplos
projetos.
• Foco em pessoas;
• Direcionado ao monitoramento e
controle sutil;
• Leve por definição;
• Simples de ser entendido;
• Promotor de novos hábitos que
provocam mudanças culturais;
• Executor da governança ágil;
• Focado na melhoria contínua do
próprio PMO;
PMO
• Vários projetos são monitorados,
selecionados, priorizados através de
um único backlog.
• O PMO Ágil visa a acelerar a cultura
ágil, respeitando e contribuindo para
que a organização e todos os
envolvidos nos projetos entendam e
sejam ágeis.
• O PMO Ágil se concentra em trabalhar
sempre nos pilares ágeis
de transparência, inspeção e adaptaç
ão.
PMO
• Para controle e governança, são
propostos cinco eventos formais:
• Revisão de estrutura;
• Planejamento da Sprint multiprojetos
• Reunião Semanal;
• Revisão Multiprojetos;
• Retrospectiva Multiprojetos
Vamos jogar (Revisar)?

https://kahoot.it/challenge/09799707?challen
ge-id=59884278-d99d-42cb-90da-
7465316b78b7_1709664199403
 Atividades
Contextualizada
Atividade
Contextualizada
PROJETOS X OPERAÇÕES
• As operações são esforços contínuos que
geram saídas repetitivas, com recursos
designados para realizar basicamente o
mesmo conjunto de tarefas.
• O gerenciamento de operações é
responsável pela supervisão, orientação e
controle das operações de negócios.
• Os projetos por sua vez, exigem atividades
de gerenciamento de projetos e um
conjunto de habilidades
específicas, enquanto as operações
exigem gerenciamento de processos
contínuos de negócios.
 Atividade
Contextualizada

• Diferentemente da natureza contínua das

operações, os projetos são esforços
temporários. Um projeto é diferente de uma
operação, embora tenham alguns aspectos
em comum, tais como:
• Realizados por pessoas.
• Restringidos por recursos limitados.
• Planejados, Executados e Controlados.
 Atividade
Contextualizada
• Entretanto existem algumas
especificidades relativas a cada um.

• Descreva 3 características específicas

de PROJETOS e 3 características
específicas de Operações.

• Após realizar suas reflexões, elabore um

pequeno texto, contendo o máximo de
30 a 40 linhas, expondo sua
argumentação, acerca do solicitado.
 Próximos Passos

• Responder os questionários
• Realizara atividade contextualizada
 Próximos Passos

• Vamos jogar um
pouco?
 Adilson da Silva

Obrigado

adilson.silva@sereducacional.com