Metodologia agil scrum x pmbok

METODOLOGIAS ÁGEIS
SCRUM
Marisa Wittmann
1

SCRUM
2
De onde vem o nome Scrum?
Takeuchi e Nonaka publicaram em 1986, na Harvard Business Review um estudo
denominado The New New Product Development Game, baseado no rugby.
Nesse estudo os autores comparam equipes de alta performance e
multifuncionais à formação scrum do jogo de rugby.
O rugby é um esporte coletivo de intenso contato físico.
Um tipo de jogada chamada scrum é utilizada para o reinício do jogo.
Quando na regra do jogo esta jogada é indicada, formam-se 3 linhas ordenadas
de 8 jogadores de cada time.
O momento desta jogada, é de auto-organização, velocidade e urgência sendo
características fundamentais que equipes de projetos devem ter quando
utilizam Scrum.
Devido à analogia apresentada por eles, Jeff Sutherland e Ken Schwaber,
idealizaram o framework Scrum e deram este nome.

SCRUM
3
Nos métodos tradicionais de Gerenciamento de Projetos, dá-se muita
importância para as áreas :
•Escopo
•Prazo
•Custo
Projetos entregues seguindo apenas este tripé, geralmente resultam em
entregas sem valor e com pouca qualidade, causando a insatisfação do cliente.
Pelas estatísticas, visualizamos o índice de fracasso nos projetos .
Agilidade é apresentar resultados com valor agregado.

SCRUM
4
Por ser uma metodologia ágil, diversos profissionais passaram a entender que
poderíamos desenvolver produtos e serviços sem documentação, sem padrão,
sem cuidado e sem qualidade.
Isto não é verdade, as metodologias ágeis podem trazer muito sucesso ao
projeto, e são utilizadas inclusive na indústria.
Apesar das metodologias existirem há muito tempo, foi em 2001 que um grupo
formado por Kent Beck e mais dezesseis renomados desenvolvedores 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,
Dave Thomas, Paulo Mourapode , assinaram o:
“MANIFESTO PARA O DESENVOLVIMENTO ÁGIL DE SOFTWARE” e o grupo foi
batizado de aliança dos ágeis.

SCRUM
5
Pode ser acessado em: http://manifestoagil.com.br/ e possui a seguinte base:
Melhorar o desenvolvimento considerando as prioridades:
•Os indivíduos e as interações são mais importantes do que os processos e as
ferramentas;
•O software funcionando é mais importante do que uma documentação completa;
•A colaboração com o cliente e dos clientes está acima de apenas negociações de
contratos;
•Respostas a mudanças acima de seguir planos.
•Isso não quer dizer que documentação não seja importante e que os processos e as
ferramentas sejam inúteis, significa que o item a esquerda é mais valorizado, apenas isto.

SCRUM
6
O Scrum superou a barreira de que servia apenas a área de TI para ser utilizado
em por outras áreas como:
Abril Digital
Agência Goiana de Habitação S/A – AGEHAB
Banco Fator
Globo.com
Gol
Instituto Nokia de Tecnologia
Petrobras
SulAmérica Seguros – Saúde / Autos
TRIP Linhas Aereas
UOL
Vivo

SCRUM
7
O Scrum pode e é usado em vários projetos fora do desenvolvimento de
softwares.
É recomendado:
Quando mudanças são constantes;
Quando a equipe aprende sobre o produto ou serviço ao longo do projeto;
Quando a complexidade e incerteza reduzem a visibilidade do produto, negócio;
Quando a colaboração é muito importante.

SCRUM
8
Apresentação da equipe Scrum
PO - Product Owner
SM - Scrum Master
Team Development

SCRUM
9
Papel: PO - Product Owner
O Product Owner, ou dono do produto, é o responsável
por maximizar o valor do produto e do trabalho da
equipe de Desenvolvimento.
O PO garante o ROI do projeto (Retorno sobre o
Investimento)
Valor é a soma do valor do conhecimento + o valor para o
cliente.
Equilibrar o trabalho reativo X o trabalho preventivo.
Gerencia as expectativas dos Stakeholders
Para que o Product Owner tenha sucesso,
toda a organização deve respeitar as suas decisões.

SCRUM
10
Papel: PO - Product Owner
Ele é a única pessoa responsável por gerenciar o Backlog do Produto
Expressando claramente os itens do Backlog do Produto;
Ordenando os itens do Backlog do Produto para alcançar melhor as
metas e missões;
Garantindo o valor do trabalho realizado pelo Time de
Desenvolvimento;
Garantindo que o Backlog do Produto seja visível, transparente, claro
para todos, mostrando em que o Time Scrum vai trabalhar a seguir;
Garantindo que a Equipe de Desenvolvimento entenda os itens do
Backlog do Produto no nível necessário.
O PO pode fazer este trabalho ou delegar, porém estas atividades são
de responsabilidade dele.

Scrum Master X Product Owner
11
Papel: SM - Scrum Master
O Scrum Master colabora com o Product Owner
de várias maneiras, incluindo:
 Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
 Comunicando claramente a visão, objetivo e itens do Backlog do Produto para a
Equipe de Desenvolvimento;
 Ensinando o Time Scrum a criar itens de Backlog do Produto de forma clara e
concisa;
 Compreendendo a longo prazo o planejamento do Produto no ambiente
empírico;
 Compreendendo e praticando a agilidade;
 Facilitando os eventos Scrum conforme exigidos ou necessários.

Scrum Master X Equipe de Desenvolvimento
12
O Scrum Master serve a Equipe de Desenvolvimento
de várias maneiras, incluindo:
Facilitador do trabalho.
Protege a equipe no sentido de não permitir que interfiram no trabalho da
equipe.
Remove qualquer impedimento para o trabalho da equipe.
Esses impedimentos são problemas que surgem no projeto e que geralmente
são externos a equipe. Ele está preocupado em perceber estes impedimentos e
removê-los para que a equipe possa trabalhar.
Ele não fica em cima da equipe perturbando e cobrando se o trabalho foi feito
ou não.

Scrum Master X Equipe de Desenvolvimento
 SM é o treinador, funcionando como o técnico de um time de futebol.
 Treinando a Equipe de Desenvolvimento em auto gerenciamento e
13
interdisciplinaridade;
 Treinando a Equipe de Desenvolvimento em ambientes organizacionais nos quais o
Scrum não é totalmente adotado e compreendido.
 Ensinando e liderando a Equipe de Desenvolvimento na criação de produtos de alto
valor;
 Facilitando os eventos Scrum conforme exigidos ou necessários;

Scrum Master X Organização
14
O Scrum Master serve a Organização de várias maneiras, incluindo:
 Liderando e treinando a organização na adoção do Scrum;
 Planejando implementações Scrum dentro da organização;
 Ajudando funcionários e partes interessadas a compreender e tornar
aplicável o Scrum e o desenvolvimento de produto empírico;
 Causando mudanças que aumentam a produtividade do Time Scrum;
 Trabalhando com outro Scrum Master para aumentar a eficácia da
aplicação do Scrum nas organizações.

Equipe de Desenvolvimento
 São auto organizadas.
 Ninguém (nem mesmo o Scrum Master) diz a Equipe de
Desenvolvimento como transformar o Backlog do Produto em
incrementos de funcionalidades potencialmente utilizáveis;
 São multifuncionais, possuindo todas as habilidades necessárias,
15
enquanto equipe, para criar o incremento do Produto.
 Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades
especializadas e área de especialização, mas a responsabilidade pertence à Equipe de
Desenvolvimento como um todo.
 Os integrantes da Equipe de Desenvolvimento recebem o título de Desenvolvedor,
independentemente do trabalho que está sendo realizado pela pessoa;
 O time de desenvolvimento deve conter vários especialistas, porém todos os
membros, inclusive os que não são especialistas, devem ser capazes de ajudar no
cumprimento de qualquer tarefa. E é justamente nesse ponto que ocorre a
disseminação do conhecimento entre os indivíduos da equipe, que com o tempo serão
capazes de realizar tarefas que antes não eram capazes.

TIME SCRUM – Tamanho da Equipe
16
O tamanho ideal da Equipe de Desenvolvimento:
deve ser pequeno o suficiente para se manter ágil
e grande o suficiente para completar uma parcela significativa do trabalho.
Menos de 3 integrantes na Equipe de Desenvolvimento:
diminuem a interação e resultam em um menor ganho de produtividade.
encontrar restrições de habilidades durante a Sprint, gerando uma equipe
incapaz de entregar um incremento potencialmente utilizável.
Havendo mais de 9 integrantes:
é exigida muita coordenação.
geram muita complexidade para um processo de gerenciamento empírico.
Os papéis de Product Owner e de Scrum Master:
não são incluídos nesta contagem,
a menos que eles também executem o trabalho do Backlog da Sprint.

Histórias contadas pelos Stakeholders
STAKEHOLDERS
Histórias descrevem as funcionalidades que devem
gerar valor;
São as necessidades ou requisitos informados
pelos cliente sobre o produto;
Algumas histórias no início do projeto são
chamadas de épicos porque elas são histórias
ainda muito amplas, complexas e pouco
detalhadas.
PO: MELHORA AS HISTÓRIAS CONTADAS
PO
PO
DECIDE
“lixo”
SIM
NÃO

Como funciona - SCRUM
ARTEFATOS DO SCRUM
Reunião de
Planejamento da Sprint
Produto
É definida
a META ou
Objetivo
EVENTOS DO SCRUM
Reunião de Planejamento Reunião Diária Reunião de Revisão Reunião de Retrospectiva

Eventos da Sprint - SCRUM
EVENTO TIME-BOX SPRINT TIME-BOX REUNIÃO
Reunião de Planejamento da Sprint
1ª. Parte: O que será PRONTO
2ª. Parte: como será PRONTO
1 mês 8hs
1ª.parte : 4hs
2ª. Parte: 4hs
2 semanas 4hs
1ª.parte : 2hs
2ª. Parte: 2hs
Reunião Diária 15 minutos
Reunião de Revisão da Sprint 1 mês 4hs
2 semanas 2hs
Reunião de Retrospectiva da Sprint 1 mês 3hs
2 semanas 1:30hs
1 2 3 4 5 6 7 8 9 1
0
1 2 3 4 5 6 7 8 9 3
0
1 2 3 4 5 6 7 8 9 2
0
P D D D D D D D D D D D D D D D D D D D D D D D D D D D D D
1 2
R
E
V
R
E
T
1 2
P D
3 4
D D
SPRINT de 1 mes SPRINT
19

Time Scrum trabalhando no Backlog da Sprint
Produto
Inspeção Inspeção
ok?
não
sim
Incremento
A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e
criar um plano para melhorias a serem aplicadas na próxima Sprint.
O propósito da Retrospectiva da Sprint é:
Inspecionar como a última Sprint foi em relação as pessoas, processos e ferramentas;
Identificar e ordenar os principais itens que foram bem e as potenciais melhorias;
Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;
20
É definida
a META ou
Objetivo
A Reunião Diária é mantida no mesmo horário e local
todo dia para reduzir a complexidade.
Durante a reunião cada integrante da Equipe de Desenvolvimento
esclarece:
O que foi completado desde a última reunião?
O que será feito até a próxima reunião?
Quais os obstáculos que estão no caminho?
Conceito de
“PRONTO”
Planejamento
Gestão do Escopo
Controle
Gestão da Qualidade
Execução
Gestão da
Qualidade
Gestão do Tempo
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão do Custo
Reunião de Planejamento
Reunião Diária
Reunião de Revisão
Reunião de Retrospectiva

Produto
ok?
não
sim
Incremento
22
É definida
a META ou
Objetivo
esclarece:
Conceito de
“PRONTO”
Planejamento
Gestão do
Escopo
Controle
Execução
Gestão da
Qualidade
Gestão do Tempo
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão do Custo
Reunião Diária

Produto
ok?
não
sim
Incremento
24
É definida
a META ou
Objetivo
esclarece:
Conceito de
“PRONTO”
Planejamento
Gestão do
Escopo
Controle
Execução
Gestão da
Qualidade
Gestão do Tempo
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão do Custo
Reunião Diária

Produto
ok?
não
sim
Incremento
26
É definida
a META ou
Objetivo
esclarece:
Conceito de
“PRONTO”
Planejamento
Gestão do
Escopo
Controle
Execução
Gestão da
Qualidade
Gestão do Tempo
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão do Custo
Reunião Diária

Produto
ok?
não
sim
Incremento
28
É definida
a META ou
Objetivo
esclarece:
Conceito de
“PRONTO”
Planejamento
Gestão do
Escopo
Controle
Execução
Gestão da
Qualidade
Gestão do Tempo
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão do Custo
Reunião Diária

Produto
ok?
não
sim
Incremento
30
É definida
a META ou
Objetivo
esclarece:
Conceito de
“PRONTO”
Planejamento
Gestão do
Escopo
Controle
Execução
Gestão da
Qualidade
Gestão do Tempo
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão da
Comunicação
Gestão do Custo
Reunião Diária

1ª. Sprint
2ª. Sprint
3ª. Sprint
4ª. Sprint
5ª. Sprint
Resultado dos Incrementos das Sprints
6ª. Sprint

Cancelamento da Sprint
Uma Sprint pode ser cancelada antes do time-box da Sprint terminar.
Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa fazer isso sob
influência das partes interessadas, da Equipe de Desenvolvimento ou do Scrum Master.
A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto.
Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das
tecnologias mudarem.
No entanto, devido a curta duração da Sprint, raramente isso faz sentido.
Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é
revisado.
Se uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita.
Todos os itens de Backlog do Produto incompletos são re-estimados e colocados de volta no
Backlog do Produto.
O cancelamentos de Sprints consomem recursos, já que todos tem que se reagrupar em outra
reunião de planejamento da Sprint para iniciar outra Sprint.
Cancelamentos de Sprints são frequentemente traumáticos para o Team Scrum, e são muito
incomuns.
33

 O papel do Product Owner contém muita Gestão da Comunicação com os stakeholders e Team Scrum,
 As Histórias fazem parte da Gestão de Escopo com o tratamento dos requisitos, negociação e mudanças.
 O Backlog da Sprint é um entregável da EAP ou WBS na Gestão do Escopo
 Cada backlog da sprint tem a Gestão do Tempo
 Cada backlog da sprint tem a Gestão de Custos
 Cada backlog da sprint tem a Gestão de Riscos
 A inspeção realizada no evento da Reunião de Revisão é a Gestão da Qualidade
 Inspecionar como a última Sprint foi em relação as pessoas, processos e ferramentas e identificar e
ordenar os principais itens que foram bem e as potenciais melhorias, realizada no evento da Reunião de
retrospectiva é a Gestão da Qualidade
 Os eventos/reuniões que ocorrem durante uma sprint é Gestão da Comunicação.
 Gerencia as expectativas dos Stakeholders é Gestão das Partes Interessadas.
 O papel do scrum master contém muita Gestão da Comunicação entre a Equipe de Desenvolvimento,
Product Owner e Stakeholders da organização.
Scrum X Pmbok
34

Compreender o framework Scrum é simples, mas para que o
projeto tenha sucesso é imprescindível que cada pessoa do time
execute o seu papel na essência.
O Product Owner tem um desafio muito grande ao decidir o que
entra e não entra no backlog do produto. As avaliações sobre
valor agregado ao produto, retorno do investimento são de
imensa responsabilidade e entendimento dos objetivos do
produto e estratégias da empresa.
Pense e avalie cada papel do Scrum.
Conclusões
35

CERTIFICAÇÕES
36
PO - Product Owner
SM - Scrum Master
https://www.scrum.org/Assessments/Professional-Scrum-Master-Assessments

Textos extraídos do Guia do Scrum (Ken Schwaber e Jeff Sutherland)
https://www.scrum.org/Scrum-Guides
12 Princípios do Manifesto Ágil
http://agilemanifesto.org/
Kanban
http://virtualkanban.net/
Pesquisa e Apresentação de Marisa Wittmann
Referências
37

Contato:
Marisa.wittmann@gmail.com
Gerente de Projetos PMP
Professora de Pós Graduação
38

Metodologia agil scrum x pmbok

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Metodologia agil scrum x pmbok

Similaire à Metodologia agil scrum x pmbok (20)

Dernier

Dernier (6)

Metodologia agil scrum x pmbok