Scrum trainning

Curso Preparatório para Certificação
Professional SCRUM Master
1

Curso Preparatório para Certificação SCRUM
Introdução
• Objetivos do Curso
• Detalhes sobre certificações Professional Scrum Master
• Manifesto Ágil
• Introdução ao Scrum
• Conceitos
• Papéis
• Artefatos
• Cerimônias
• Estimativas ágeis
• Release Planning
• Artefatos auxiliares
• Ferramentas para Scrum
• Scrum e PMBOK
2

Gestão Ágil de Projetos - Scrum
Introdução
Além da teoria:
• O dia-a-dia de projetos Scrum
• Dicas para implantação
• Troca de Experiências
• Nova forma de encarar projetos
• A questão cultural nas empresas
Scrum na
prática!
3

Certificação Professional Scrum Master
• A certificação Professional Scrum
Master está disponível no Scrum.org para
todos os que possuem um certo nível de
conhecimento - não apenas para aqueles
que fizeram o curso.
• A única exigência para aprovação é
realizar a avaliação online no Scrum.org.
A avaliação é feita somente em Inglês.
4

Níveis de Certificações Scrum
• Há dois níveis de certificação:
As certificações Professional Scrum
Master I (Fundamental) e II
(Intermediário) indicam o quão bem os
indivíduos compreendem os papéis,
regras, artefatos e limites de tempo que
compõem o Scrum framework.
5

• Professional Scrum Master I (Fundamental) mede
conhecimento básico de Scrum e seus papéis, regras,
artefatos e limites de tempo.
• Investimento: US$100
• Limite de Tempo: 60 minutos
• Pontuação Mínima: 85%
• Formato: Múltipla Escolha
• Material de Estudo: Guia do Scrum
• Simulação: Scrum Open Assessment
• Registre-se aqui para realizar a avaliação PSM I
6

• Professional Scrum Master II (Intermediate) mede
conhecimento intermediário de Scrum e seus papéis,
regras, artefatos e limites de tempo.
• Investimento: US$500
• Limite de Tempo: 120 minutos
• Pontuação Mínima: 85%
• Formato: Múltipla Escolha e dissertação
• Material de Estudo: Guia do Scrum
• Simulação: Scrum Open Assessment
• Registre-se aqui para realizar a avaliação PSM II
7

Instruções
• Para fazer a avaliação (exame), sugere-se seguir os
seguintes passos:
• 1) Revisar o Scrum Guide em Inglês ou seu
equivalente Guia do Scrum em Português.
• 2) Registrar-se para a avaliação desejada usando um
dos links acima e pagar a taxa indicada, usando seu
cartão de crédito. Você vai receber um e-mail com uma
senha, dentro de um ou dois dias.
• 3) Reserve 60 minutos de tempo.
• 4) Use a senha que lhe foi passada para a acessar o
site indicado no e-mail e começar a avaliação
8

9
Algumas empresas que utilizam Scrum:
Fonte: Scrum-Brasil

Apresentações
• Quem sou
• Da onde venho
• O que faço
• Se uso Scrum atualmente
10

Se conhecendo
• Nossos times de sucesso:
• Se organizarem em grupos de até
4 integrantes
• Definir um nome para o time
• Escrever 3 pontos que vocês tem
interesse sobre Scrum
10 MINS
11

Origem do Scrum
• 1989 - Takeuchi e Nonaka
• Equipes pequenas e multidisciplinares
• Fabricação de Autos e produtos de consumo
• The New Product Development Game
• 1991 – Jeff Sutherland
• Documentação e implementação na Eaton
• 1995 - Ken Schwaber
• Formalização e implantação no desenvolvimento
de SW
• 2001 – Manifesto Ágil 12

Manifesto Ágil
13
Indivíduos e interações
Software funcional
Colaboração com o cliente
Resposta à mudanças
Sobre
Sobre
Sobre
Sobre
Processos e ferramentas
Documentação
abrangente
Negociação de contratos
Seguir um plano

O que é ser Ágil para você?
14

Como você gerencia Riscos?
Situação 01:
• Você está desempregado há 10 meses…
• Mas possui uma entrevista marcada para o emprego perfeito em
uma cidade a 400 km de sua casa (+/- 5h de carro)
• A entrevista é as 17 horas de sexta-feira
Perguntas:
• O que você faz para chegar no horário na entrevista?
• No que você precisa pensar?
15

Como você gerencia Riscos?
Situação 02:
• Um grande amigo acabou de ser promovido e deseja comemorar!
• Para isso, marcou um happy hour a partir das 18:30, a 2 km de
onde você trabalha (+/- 15 minutos de carro)
• Você, como melhor amigo, não pode faltar!
Perguntas:
• O que você faz para chegar no horário do evento?
• No que você precisa pensar?
• O plano traçado foi diferente do anterior?
• Por que?
16

A certeza é maior em situações mais simples
People
Fonte: Ralph Stacey,
Universidade de Herfordshire
Scrum
Waterfall
Simples
Sem dúvidas nas regras
e na construção
Complicado
Quase todas as Regras e suas
construções são conhecidas
Complexo
Conhecimento médio das Regras
e de sua construção…
Caos
Conhecimento baixo das Regras
e de sua construção…
17

O que é Scrum?
• Framework para
desenvolvimento Ágil de projetos
• Leve
• Simples de entender
• Extremamente difícil de dominar, pois exige
equilíbrio entre flexibilidade e disciplina.
• Possui
• Papéis
• Eventos
• Artefatos
• Regras 18

O que é Scrum?
• Baseado em processo incremental e iterativo
• Processo empírico de gerenciamento e controle
• Muito mais atitude do que processos em si
• Escalável em projetos grandes e largos
19

O que não é visto, mas importa e muito:
• Papéis
• Eventos
• Artefatos
• Regras
• Cultura
• Time Multidisciplinar
• Auto-Organização
• Comprometimento
• Envolvimento do Cliente
• Colaboração
• Respeito
• Entregas iterativas 20

Pilares do Scrum
•Transparência
• Andamento do projeto visível
para todos
•Inspeção
• A cada evento existe uma oportunidade para
analisar e inspecionar o resultado
•Adaptação
• Realizar ajustes necessários o mais rápido
possível
21

Definição de Done
• Em seus times:
• Como seria a definição de Pronto da sua
equipe?
• Quais aspectos seriam levados em
consideração?
• Existiria algum documento associado a
ele?
15 MINS
22

Definição de Done
• Sua definição de Done considerou os itens abaixo?
Por que não?
• Teste de Performance
• Teste Unitário
• Teste de Regressão
• Teste de aceitação do usuário
• Revisão do código fonte
23

• Scrum é baseado no Desenvolvimento iterativo e
incremental:
Evolução
Contínua
Requisitos
Plan &
Design
Desenv
& Testes
Feedback
&
Integraçao
Nova Iteração
Incremento &
Versão
Iteração
Anterior
Próxima
Iteração…
24

• Baseado no Desenvolvimento iterativo e incremental
Lembram dos Pilares: Transparência, Inspeção e Adaptação?
A cada iteração, seu time deve ficar melhor, pior ou igual?
25

Incremental vs Seqüencial
Fonte: RUP
• Quais são as
principais diferenças
entre ambos?
• Qual dos dois entrega
resultado mais
rapidamente?
• Qual dos dois possui
maior risco? Por que?
26

Processos Preditivos vs Empíricos
Preditivo
Empírico
Empírico (adjetivo):
1) Derivado de ou guiado
pela experiência ou pelo
experimento.
O que isso significa em
projetos?
Será que o Pilar da
transparência é
importante aqui?
27
Plan Do!
P D P D P D P D P D

Isso acontece? Tem certeza?
• 35% dos requerimentos mudam ao longo do projeto
• 65% das funcionalidades não são ou são raramente
utilizadas
28
Fonte: Advanced Development Methods, Inc.

Isso acontece? Tem certeza?
29

Processo Scrum – Visão Macro
30

Processo Scrum – Visão Macro
31

O Time Scrum
• Product Owner
• Gerencia o backlog
• Garante entrega de Valor
• Equipe de Desenvolvimento
• Se auto-organiza
• Entrega produto “Done”
• Scrum Master
• Gerencia e estimula o
Processo do Scrum
• Remove impedimentos
32

O Scrum Master – Principais Objetivos
33
• Garantir que o processo Scrum seja praticado
na empresa de forma correta
• Remover impedimentos
• Garantir que o Scrum seja entendido
por todos os envolvidos no processo
• Treinar e dar Coaching p/ equipes

34
• Em relação ao PO
• Ajuda a encontrar técnicas no gerenciamento do Backlog
• Facilita os eventos Scrum
• Ensina a criação de itens de backlog concisos e claros
• Compreende o planejamento do produto
• Garante que o PO está preparado para cada Sprint

35
• Em relação a Equipe de Desenvolvimento
• Remove e se antecipa aos impedimentos
• Estimula a auto-organização da equipe
• Estimula a equipe a ser auto-suficiente
(interdisciplinar)
• Garante que a equipe tenha os skills
necessários para o projeto

36
• Em relação a Organização
• Propaga o Scrum
• Faz o time scrum ser entendido
• Mantêm o time motivado e feliz
• Trabalha pelo bom relacionamento do time
• Identifica formas de aumentar a produtividade de todos

O Scrum Master
37
• Para refletirmos:
• Um SM precisa ter perfil de
liderança?
• Ele precisa ter certos poderes e
autonomias?
• Vocês acreditam que o SM é um
papel Gerencial ou Operacional?
• O que um bom SM não deve
fazer?

O Scrum Master – Desafios nas Empresas
38
• Em relação a Organização
• Resistência a novos processos Scrum
• Garantir o comprometimento do time
• Disseminar a auto-organização
• Mudar a cultura da empresa e transformá-la em uma
comunidade
• Excesso de burocratização…

A Equipe de Desenvolvimento – Principais Objetivos
39
Transformar PBI’s em incremento de produto pronto!
•Auto-Organizados
•Multidisciplinares
•Comprometimento com a meta!
•Tamanho: 6 +/- 3 ou 7 +/- 2
•Comunicativos
•Resolvem seus conflitos

Equipe de Desenvolvimento
40
Em outras palavras:
Auto-organizados: capazes de dividir as tarefas entre si de forma que
no final da sprint todo o trabalho necessário esteja pronto.
Multidisciplinares: a equipe deve estar pronta para executar o que for
necessário para ter o trabalho pronto.
Resolvem conflitos: a equipe é transparente entre si, conversando
sobre pontos + ou – de cada ação.

41
Comprometimento de todos com a meta:

42
Acontece no dia-a-dia:
E se nem todos estiverem
comprometidos?
Baixa produtividade?
Time busca as Razões e coloca os
pingos nos “i”s internamente.

A Equipe de Desenvolvimento – Desafios
43
• Responder primeiramente para um time e não para uma
pessoa
• Se comunicarem e se entenderem
• Estar aberto a constante evolução técnica
• Conhecer sua velocidade
• Sempre focados na meta
• Ser o mais transparente e sincero possível
• Colaborarem entre si

O Product Owner – Principais Objetivos
1) Colher o backlog do produto (funcionalidades)
• Cliente / mercado
2) Ordenar o product backlog
• Priorização por ROI, Valor Agregado, Necessidade…
3) Planejar as releases
4) Detalhar e explicar o Product Backlog de maneira clara para o time
Fazer o que for preciso para que o time entregue o máximo de
valor por Sprint!
44

Um Product Owner é como um Gerente de Produtos
comum, só que mais:
• Colaborativo com o Time e com seu cliente
• Mudança de escopo que agregue valor ? Sem
problemas.
• Estimula e incentiva o time
• Faz entregas com freqüência
• Otimiza a produtividade do time
• Como?
• Somente entrega itens de alto valor agregado
• Dispensa itens de valor negativo
45

46
O Product Owner – Detalhe Importante:
• Possui a última palavra sobre o que será feito em relação ao
produto!

Product Owner – Desafios nas Empresas
47
• Falta de Poder sobre o produto
• O que será feito
• Quando será disponibilizado
• Questão hierárquica: PO & N clientes (diretores!)
• Ninguém tem permissão para mudar a prioridade acordada entre
o PO e a Equipe de Desenvolvimento.
• O que é ser Proxy PO?

Product Owner – Desafios nas Empresas
48
• O que acontece quando mais de uma pessoa é
responsável pelo futuro do mesmo produto?
• A tomada de decisão é fácil?
• Quais interesses são levados em
consideração?
• Existe um alinhamento estratégico
entre as direções mencionadas?

Product Backlog
50
É um inventário priorizado e ordenado de “desejos”
em relação ao produto
•Devem ser transparentes!
• Acesso e Entendimento
•O trabalho a ser feito é estimado
•Gerenciado somente pelo Product Owner
•Desenvolvido pelo Time!

O Product Backlog pode conter:
51
• Novas funcionalidades
• Casos de Uso
• User Stories
• Bugs
• Defeitos
• Desejos dos clientes
• Requerimentos não funcionais

Exemplo de Product Backlog
52

Gerando Product Backlog Items
53
Em seu time:
•Levante os PBIs (Product Backlog Items) necessários
para a construção de um produto de livre escolha.
•Escreva cada PBI em um Post-it
15 MINS

Fornecendo valor de Negócio ao PBI
54
Podem ser levados em consideração, por exemplo,
os itens abaixo:
•Valor percebido para o Consumidor
•Diferencial para uma prospecção
•Risco para a companhia
•Exigência de órgão regulatório
•Comprometimento com o mercado
•Redução de custos
•Aumento da Receita (ROI)
•Melhoria de processos internos
•E etc.
No mercado que atuam, quais poderiam ser aplicados?
Quais seriam os mais importantes? E por que?
5 MINS

Fornecendo valor de Negócio ao PBI:
55
Para praticarmos:
•Imaginem que vocês possuem 500 bolas de ping pong.
•Distribua as mesmas para cada PBI, de acordo com seu valor de
negócio
•A quantidade não pode se repetir
•Cole na parede os post-its em ordem decrescente de valor de
negócio (de cima para baixo)
•Escreva o valor de negócio no canto direito inferior de cada
cartão
15 MINS

Casos de Uso X User Stories
56
• Casos de uso:
• São formais
• Mais difíceis de entender
• Possuem maior rastreabilidade
• User Stories :
• Simples
• Fácil entendimento
• Incentivam conversa
E agora, qual dos dois usar?

Exemplos de User Stories
57
Como um usuário do site, eu
gostaria de pesquisar os
produtos por preço e
categoria, para encontrar
meu produto mais
rapidamente
Como um usuário, eu
gostaria de poder mudar o
parâmetro de ordenação,
bem como sua ordem:
crescente ou decrescente
Como um usuário, eu
gostaria de ver os produtos
ordenados por preço, por
padrão
• Verificar se o usuário está
logado antes de realizar a
pesquisa
• A pesquisa não deve
demorar mais do que 2s

Decompondo User Stories
58
Quando decompor ?

Como identificar boas User Stories ?
59
Independent : Histórias devem ser independentes uma das outras.
Negotiable : Histórias não são contratos, mas lembretes para
discussões.
Valuable : Histórias devem agregar valor para o cliente.
Estimatable : Os desenvolvedores devem ser capazes de estimar o
tamanhos das histórias.
Small : histórias grandes dificultam as estimativas. Bem como histórias
muito pequenas. Quebre ou agrupe dependendo do caso.
Testable : Histórias devem ser possíveis de serem testadas.

3Cs (Cards, Conversation, Confirmation)
60
Cards ( Requisito/User Story do Product Backlog )
"Um administrador pode cadastrar um jogo para que os apostadores
possam fazer seus palpites de resultado“.
Conversation ( Interação do Time Scrum no Sprint Planning )
“- O administrador pode cadastrar o jogo quando quiser ? E se ele
cadastrar muito em cima ?”
“- Ah, eu acho que ele tem que cadastrar com no mínimo 48h de
antecedência”
Confirmation (Regras de negócio / Critérios de Aceitação)
- Um administrador não poderá cadastrar um jogo com menos de 48h de
antecedência.
- Um administrador não poderá cadastrar dois jogos envolvendo os
mesmos times no mesmo horário.

61
15 MINS
Criando User Stories
Em seus times, detalhe os PBI’s em
requerimentos no formato de User Stories para o
produto criado no exercício anterior
Como <perfil>,
eu quero <o que>
para que <motivo>
• Lembrem-se da estrutura a ser
seguida
• Não se esqueçam dos critérios de
aceitação!
• Quais vocês começarão primeiro?

Qual deve ser o nível de Detalhamento do
Product Backlog?
62
Extremamente detalhado
Detalhado
Visão / Desejo

Qual deve ser o nível de Detalhamento do
Product Backlog?
63
Boa prática:
O PO deve estar 2 sprints à frente do time:
• Enquanto o Time trabalha na sprint atual (01), o PO está granularizando
os requerimentos da próxima sprint (02)
• E se sobrar tempo, detalhará a outra Sprint (03) em requerimentos mais
generalistas (menos granularizados)
Quais são os benefícios disso?

64
Estimando esforço com Planning Poker
Objetivo: Criar estimativas relativas (Story Points)
Pegue 8 cartões em branco e escreva os seguintes números em cada um:
2 3
8 13 40
1 5
05 MINS
100

65
Planning Poker
Na Prática!
Estime em Story Points:
1) Sua casa
2) Teatro Municipal
3) Cristo Redentor
4) Empire State Building
5) Torre Eiffel
15 MINS

66
Planning Poker
Durante o jogo, evitar:
1. “Cantar” a carta escolhida
2. Mostrar a carta antecipadamente
3. Tendenciar valores
Motivos
1. Desestimula a interação do grupo
2. Gera coerção nas estimativas

67
Planning Poker
Regras do Jogo
1. Cada membro de equipe de desenvolvimento deve possuir suas cartas
2. PO lê a user story da vez e a mesma é discutida brevemente
3. Cada membro da equipe escolhe sua carta de estimativa
4. Assim que escolher, todos mostram sua escolhas simultaneamente
5. As variações de estimativa são discutidas (principalmente as mais divergentes)
6. Uma nova rodada de estimativa deve ser realizada até as estimativas obterem
um consenso
Mas e se algum integrante persistir em uma estimativa mais alta em relação ao
restante do time???

68
Planning Poker
Benefícios:
1.Amadurecimento dos integrantes
2.Divisão de conhecimento
3.Estimula a troca de informações entre o
time
4.Obtenção de detalhes ocultos
5.Força a participação de todos os
membros da equipe de desenvolvimento

69
Estimando prazo com Story Points
PBI
Id PBI
Story
Points
1 User Story 1 5
2 User Story 2 1
3 User Story 3 3
4 User Story 4 8
.
.
.
N User Story N 13
TOTAL 500
1. Estimar os PBIs com Planning Poker
2. Somar as estimativas
3. Obter a velocidade do time
4. Dividir a soma das estimativas pela
velocidade do time para obter a
quantidade de Sprints estimadas para
conclusão do Product Backlog.
Ex: Se o time possui uma média de
conclusão de 50 story points por Sprint,
a estimativa de conclusão das PBIs ao
lado é de 10 Sprints (500/50)
E se o time for iniciante e não souber qual sua velocidade ? Como estimar ?

70
Fazendo ajustes nas estimativas
Entrosamento x
Conhecimento Técnico x
Conhecimento do Negócio
Estimativa * ( 1 + Fator )

71
Eventos Scrum
1. Release
2. Sprint
3. Planejamento da Sprint
4. Reuniões Diárias
5. Revisão da Sprint
6. Retrospectiva da Sprint

72
Release – Visão Geral
• É como você entrega valor para o seu cliente
• Formada por um conjunto de Sprints
• Sempre deve possuir um Objetivo ou Propósito:
1. Mais valor ao Cliente
2. Oportunidade no Mercado
3. Atender Regulamentações
4. Novas Funcionalidades
5. Manutenção / Correção
Quais são os melhores?

73
Release - Estratégias
1. Date-Driven
• “Precisamos entregar funcionalidades de valor até dia
31/12 sem falta, para competirmos com a concorrência”.
• Tempo é a restrição.
• Escopo/funcionalidade de valor são flexíveis.
2. Feature-Driven
• “Nosso novo modelo só pode ser lançado quando estiver
pronta a funcionalidade de fazer download de jogos”.
• Escopo/funcionalidade de valor são as restrições.
• Tempo é flexível.

74
Release - Estratégias

75
Release Planning

76
Releases – Recapitulando:
1. Identifique o objetivo da release (release goal)
2. Priorize os Requerimentos (PBI)
3. Estime os PBIs
4. Faça os ajustes nas estimativas
5. Monte um Baseline por Sprint
6. Avalie a viabilidade do plano
7. Comece a Release

77
Sprints
• É dentro das sprints que o time transforma PBI`s em partes
de produto “Done” (Potencial incremento de produto).
• Geralmente com duração de 1 a 4 semanas.
• Duração estabelecida levando em consideração:
• Tempo adequado para entrega de valor.
• Tempo adequado para obtenção de feedback.
• Tempo adequado para atingir a definição de “Done”.
• Prazo de tolerância a riscos.
• Que o time deve procurar trabalhar em ritmos
sustentáveis.
• Devem sempre entregar valor ao produto.

78
Sprints
Encarar cada sprint como a grande final do
campeonato!
Se a meta de cada sprint for batida, o projeto será entregue com
sucesso e no prazo!

79
Importante: Durante a Sprint:
• A equipe permanece com a mesma quantidade de integrantes
• As metas de qualidade não diminuem
• O Escopo pode ser detalhado e renegociado entre o PO e a Equipe
de desenvolvimento, porém:
O Objetivo da Sprint não pode ser alterado!
Para pensarmos:
Podemos adicionar / remover PBI ‘s em uma sprint em
Execução? Se sim, quando e por que?

80
Cancelamento de Sprints
Pode? Sim…
Quem pode? Apenas o PO*
Ocorre com freqüência? Não
Recomendado? NÃO!
Pontos Positivos:
•Evita que a equipe trabalhe
em algo que não terá valor
Pontos Negativos:
•Desmotiva a equipe
•Sensação de fracasso…
O que pode fazer a sprint ser cancelada?

81
Sprints – Eventos Encapsulados
1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective

82
Sprint Planning
Time decide quais PBI’s
conseguirão ser transformados em
produto “Done” dentro da Sprint
•Transformação de Product Backlog em Sprint Backlog
•Seu Timebox varia de acordo com o tamanho da Sprint:

83
Sprint Planning
Parte 1:
1. PO apresenta cada funcionalidade (PBI)
segundo sua priorização, de forma clara
e detalhada
2. Equipe de Desenvolvimento entende cada
Item e verifica quantos itens conseguirão
ser trabalhados na Sprint
3. Time Scrum define a meta da sprint
(sprint goal!)
PO explica o por que!
Obrigatórios na Parte 1: PO e Equipe de Desenvolvimento

84
Sprint Planning
Parte 2:
1.Time verifica como irá transformar os PBIs selecionados em parte
de produto “Done”.
2.Criação do Sprint Backlog, documento gerado e gerenciado
somente pelo time de desenvolvimento.
Obrigatórios na Parte 2:
Equipe de Desenvolvimento, porém PO também é
importante!

85
Quadro Kanban
1.Coloque as tarefas de cima
para baixo na ordem de
importância
2.Em cada tarefa, coloque o
número do PBI para manter a
rastreabilidade
3.Adicione aos cartões seus
executores a medida que as
tarefas forem sendo
realizadas
4.Movimente por entre as
colunas sempre que possível!

86
Sprint Planning - Quadro Resumo
Capacidade
Projetada do
Time
Product
Backlog
Analisar, avaliar e selecionar os PBI
para a Sprint
Criar o Sprint Goal e se comprometer
com o trabalho
Decompor para tarefas e estimá-las
Trabalho provisionado em tarefas
Comprometimento com o mesmo
Último
desempenho
do time
Último
Incremento
PO
TEAM

87
Perguntas:
1.Um membro da equipe de desenvolvimento pode se comprometer
sozinho com um item durante o planning?
2.O Scrum Master deve participar ?
3.O PO pode tendenciar dimensionamentos?
Sprint Planning

88
Sprint Planning
Dicas:
1.Implementar um intervalo de descanso (almoço) entre cada parte da
reunião
2.Realizar Planning sempre no começo da semana (segunda / terça)
3.Cobrar a participação ativa de todo o time durante a reunião.
Afinal, o comprometimento com a meta é do time!
4.Faça a equipe detalhar em conjunto cada PBI, discutindo o esforço de
cada tarefa
5.As tarefas devem ser escritas com as palavras do próprio time
6.Aproveite e já armazene cada estimativa dada! (TS, Excel…)

89
Durante a Sprint
• O PO não pode interferir na ordem de execução das tarefas da equipe
de desenvolvimento
• Equipe de desenvolvimento deve ter e manter atualizado um plano de
como alcançar a meta da sprint
• Status das tarefas devem ser atualizados diariamente (Kanban ou TS)
• Caso a equipe perceba que estimou errado os PBIs da sprint, o PO
deve ser avisado o quanto antes

90
Daily Scrum / Reuniões Diárias
Objetivo: sincronizar as tarefas e montar plano para as próximas 24h
• Timebox de 15 minutos
• Todos de pé!
• Mesma data e horário (Por que?)
Devem responder a 3 perguntas:
1. O que eu fiz desde a última daily?
2. O que será feito até a próxima?
3. Existem impedimentos?

91
Daily Scrum
• Mais uma oportunidade de inspeção do progresso
• Bom momento para mover as tarefas no Kanban
• Estimula a comunicação
• Identifica e prevê impedimentos
• Elimina outras reuniões

92
Daily Scrum
• Integrantes: apenas a equipe de desenvolvimento
• PO pode participar como ouvinte ?
• Pontos positivos e negativos disso
• E o SM ?
TEAM
O Replanejamento do trabalho restante para o cumprimento da
meta geralmente é realizado após a Daily
A qualquer momento este plano
deve estar claro para o PO ou SM

93
Daily Scrum
• Fazer diante do quadro Kanban
• O time deve reportar para ele mesmo
• Todos do time de desenvolvimento devem participar
• Todos devem ficar até o final e ajudando!
• Sem celular, por favor.
• Para estimular o planejamento do trabalho restante, pergunte
sobre o sentimento para o alcance da meta.
Dicas

94
Objetivo: Apresentação e Inspeção do incremento gerado
Revisão da Sprint
Time
• Apresenta o que foi feito e como
• Responde a pergunta sobre o
incremento
• Quais problemas ocorreram e como
foram corrigidos
PO
• Avalia e identifica o que está
realmente Done
• Analisa se a meta foi alcançada

95
Participam:
Revisão da Sprint
• PO
• Equipe de desenvolvimento
• Interessados sobre o produto (SM, stakeholders e etc.)
• Executado no final da sprint, antes da retrospectiva
• Time Box:
• 4 h -> Sprint de 4 semanas
• 2 h -> Sprint de 2 semanas

96
Importante:
Revisão da Sprint
• É uma reunião de ação e não uma mera
apresentação
• PO deve analisar cada PBI entregue
• Saída: backlog do projeto revisado
Benefícios:
•Permite a comunicação do time
•Equipe de desenvolvimento obtém skills de apresentação
e;
•Estimula a execução das tarefas da melhor forma
possível, caso contrário…

97
Oportunidade para:
Revisão da Sprint
• Adicionar ao Backlog itens não terminados ou não aceitos
(Undone work)
• Atualizar Backlog com itens finalizados
• Reordenar o Backlog caso necessário
• Avaliar com o SM uma nova configuração do time
• Parar o projeto! Não permitir outra sprint
• Solicitar mais uma equipe no projeto

98
Dicas:
Revisão da Sprint
• Incentive cada desenvolvedor a apresentar o que ele mesmo
desenvolveu
• Arquitetura também importa!
Ninguém quer produto descartável.
• Estimule o PO a dar a opinião a cada item apresentado
• Envolva o cliente na reunião. Ele deve se sentir parte do time
• Permita o PO trabalhar algumas horas entre a Revisão e a
próxima Planning.

99
Débito Técnico:
• Defeitos
• Falta de testes de aceitação
• Código Duplicado
• Regra de negócio em lugares errados
• Falta de testes unitários
• Impossibilidade de voltar para a versão anterior
• Algoritmos de difícil manutenção
Originados de trabalhos que
impedem entrega de produto
“DONE”
Podem ser:

100
Evitando Undone Work usando Extremme Programming (XP)

101
Garantindo qualidade com Test-Driven Development

102
Envolvendo PO com Acceptance Test-Driven Development

103
Retrospectiva da Sprint
O que fizemos de bom?
O que fizemos de ruim?
O que iremos manter?
O que iremos mudar e como?
Montar lista desses itens!
Quando aplicar esse plano de melhorias?
Inspeção do time pelo próprio time

104
• Importante saber ouvir
• Maturidade
• Todos devem ter o mesmo propósito
• Manter o respeito e o profissionalismo
• Scrum Master incentiva a equipe a melhorar
• Todo o time scrum participa!
Inspeção do time pelo próprio time
Sala de reunião, iglu - Google Suíça

105
Dicas:
1. Solicite que cada membro individualmente coloque os itens de discussão em
post-its
2. Discuta em conjunto cada um desses itens
3. Estimular alternativas provenientes da própria equipe
4. Estabelecer votações para as alternativas de ação
5. Começar e finalizar um assunto por vez!
6. Deixar os próprios membros da equipe tirarem as conclusões
7. Discutir formas de evitar reincidências já mencionadas em retrospectivas
anteriores
8. Sair da reunião com uma lista desses pontos e de suas estratégias

106
Artefatos auxiliares
Fornecem transparência, oportunidade de inspeção e adaptação
Trafegam e/ou são atualizados pelos eventos

107
Release Burn Down Chart
Objetivo: Demonstram a quantidade de trabalho restante dentro
da Release

108
Sprint Burn Down Chart
Objetivo: Demonstram a quantidade de trabalho restante dentro
da Sprint

Ferramentas para Scrum
Microsoft Visual Studio (ALM)
http://www.microsoft.com/visualstudio/pt-br/solutions/management
Kanbanize (kanban online)
http://kanbanize.com
Sketchflow (prototipação)
http://www.microsoft.com/expression/products/SketchFlow_Overview.aspx
Axure (prototipação)
http://www.axure.com/features
Resharper (qualidade de código)
http://www.jetbrains.com/resharper/
Qual mais?

110
Scrum e PMBOK
Planning Execution
Status Report / Release Burndown
Lessons Learned
/ Retrospective
High Level
product
Backlog
Release
Planning
( Planning
Poker – High
Level)
Sprint 1 Sprint 2 Sprint 3
DeployWBS
Project
Management
Product
Lifecycle
(developed by
SCRUM
Methodology)
WBS / Product Backlog
Project Charter

111
Scrum e PMBOK
Quais áreas de conhecimento são comuns entre o PMBOK e o SCRUM?
• Scrum: Framework. PMBOK: Guia de boas práticas
• Escopo (através do Product Backlog)
• Atividades (através do Sprint Backlog)
• Tempo (através da Sprint e Release Planning)
• Comunicação (através do Kanban e relatórios burndown)
• Gerenciamento dos Stakeholders
• Riscos (através do Daily Scrum, Sprint Review e priorização e
refinamento do Product Backlog)

112
Scrum e PMBOK
Como o PMBOK pode complementar o SCRUM?
• Gerenciamento dos custos
• Gerenciamento de contratos/aquisições
• Gerenciamento de recursos humanos
(principalmente em estruturas matriciais)
• Gerenciamento da integração

114
Times que batem metas:
Devem Comemorar!

115
Obrigado!
Boa Sorte no Exame Scrum!

Scrum trainning

Mais conteúdo relacionado

Mais procurados (20)

Semelhante a Scrum trainning (20)

Mais de Miguel Vilaca (8)

Último (11)

Scrum trainning