PDS
SCRUM
Prof. Pedrina Brasil
pedrina.brasil@ifrn.edu.br

●
●
O nome SCRUM é derivado do Rugby
– É um método de reinício de jogada;
– Os jogadores se empurram para pegar a bola;
Envolve o trabalho de equipe
Introdução
2

●
●
●
Na Engenharia de Software, SCRUM é um
framework de processo
– Técnicas e métodos variados são aplicados;
Não é uma metodologia que fará você
desenvolver produtos melhores;
Não é uma bala de prata:
não te dá respostas rápidas
ao desenvolvimento de
software;
Introdução
3

●
4
●
Ajudar a construir com qualidade e com melhor
retorno de investimento
– É um processo gerencial;
– Define papéis, artefatos e “cerimônias” (eventos);
– Esses elementos podem ser adicionados de acordo
com sua necessidade;
Pode ser aplicado em qualquer contexto no qual
pessoas trabalhem para atingir um objetivo.
Introdução

●
5
●
●
As equipes se auto-organizam para maximizar
a comunicação e diminuir a supervisão;
O produto evolui em uma série de “sprints”;
Os requisitos (funcionalidades) são listados em
um “product backlog”;
Principais Características

●
6
●
●
●
Criadores
–Jeff Suttherland - jeffsutherland.com
–Ken Schwaber - controlchaos.com
Um dos primeiros a adotar
–Mike Beedle - mikebeedle.com
Conferências: OOPSLA 96, PLoP 98
Inspiração
– Desenvolvimento Iterativo e Incremental em
empresas (DuPont) nos anos 80.
Origem do Scrum

Visão Geral
7

Visão Geral
8

●
9
●
●
É um ciclo: lembre-se do modelo iterativo;
Uma Sprint pode durar de duas a quatro
semanas
– O tempo da Sprint deve ser definido previamente;
Durante uma sprint, são realizadas as tarefas
priorizadas
– Tarefas podem ser quebradas em duas ou mais;
– Cada tarefa é atribuída a um membro da equipe
● O colaborador é quem escolhe a tarefa.
– Não há mudanças nas tarefas durante o Sprint.
Sprint

●
10
●
●
●
Estórias;
Product Backlog;
Sprint Backlog;
Gráfico Burndown;
Artefatos

●
11
●
●
●
Estórias;
Product Backlog;
Sprint Backlog;
Gráfico Burndown;
Artefatos

●
●
●
São pequenas descrições que detalham itens a
serem considerados;
Ajuda na compreensão do problema;
Ajuda a levantar e organizar os requisitos.
Estórias (User Stories)
12

●
●
●
É composta por uma ou mais sentenças;
As sentenças são construídas na linguagem de
negócio ou cotidiana do usuário final;
Captura “o que”, “quem” e “por quê” um requisito
precisa ser implementado de forma concisa;
Estórias (User Stories)
13

●
14
●
É um artefato que está presente em outras
metodologias ágeis;
Toda estória é composta:
– Ator: é o proprietário (usuário) da estória
● É recomendado descrever de forma específica quem é o ator
– Isso ajuda a identificar o contexto da história dentro do sistema
– Ação: é o que o ator quer fazer;
● Utilizando a ação, o autor espera alcançar seu objetivo no sistema;
– Funcionalidade: é o que o ator espera que aconteça ao
realizar a ação
●
●
É o resultado de executar a ação segundo a ótica do ator;
Também pode ser visto como justificativa.
Estórias (User Stories)

●
15
●
●
●
Uma lista ordenada de tudo o que é necessário
no produto (lista de funcionalidades);
Cada item deve ter seu peso (prioridade) de
acordo com a vontade do cliente;
É replanejado no início de cada Sprint;
É gerada incrementalmente
– Começa-se pelo básico;
– O extra aparece com o tempo.
Product Backlog

● Backlog inicial
– Deve conter características que agreguem algum
valor de negócio ao produto;
– Novos requisitos aparecem quando o cliente vê o
produto;
Product Backlog
Este é o
Product
Backlog
16

● Exemplo de um Product Backlog:
Product Backlog
IMPORTÂNCIA
17
Funcionalidades
Funcionalidade 8
Funcionalidade 3
Funcionalidade 4
Funcionalidade 1
Funcionalidade 2
Funcionalidade 10
Funcionalidade 7
Funcionalidade 9
Funcionalidade 6
Funcionalidade 5
IMPRESCINDÍVEL
IMPORTANTE
SERIA BOM TER

●
18
Exemplo de um Product Backlog:
Product Backlog
Item Estimativa
Permitir que o usuário edite seu perfil no sistema. 3
Permitir que o usuário envie documento para o cliente por
meio do sistema.
5
Permitir que o usuário cancele uma transação corrente. 3
Permitir que o gerente gere um relatório financeiro. 8
Permitir que um usuário aloque tarefas para outro usuário. 8
Como estimar o esforço para determinada
atividade?

●
●
É uma prática que ajuda na estimativa de uma
história ou de uma tarefa;
Uma boa métrica deve levar em consideração a
opinião de todo o time;
Planning poker
19

●
20
●
●
Planning poker, do português “Poker do
planejamento”;
Ajuda a chegar em um consenso na estimativa
do esforço demandado para uma tarefa;
Assim como User Stories, não é uma técnica
exclusiva do Scrum
– Outras metodologias ágeis utilizam o planning
poker;
Planning poker

●
21
●
●
●
●
Cada membro recebe um conjunto de cartas com
sequenciais;
Para cada estória de usuário analisada, cada membro
joga uma carta com a face para baixo sobre a mesa;
Em cada carta estará contido o valor numérico de
pontos que o mesmo considera justo para que a
estória seja concluída;
Para as grandes diferenças entre valores, os membros
que jogaram esses valores devem expor suas razões;
Com base nas explicações, as cartas são jogadas
novamente até que um consenso seja encontrado.
Planning poker

●
●
●
As cartas possuem uma sequência de valores;
Essa sequencia pode ser simples:
– 0, 1, 2, 3, 4, 5, 6, 7, 8…
Considerando a inerente possibilidade de
valores distantes serem escolhidos, pode-se
utilizar outras sequencias
– Sequencia de Fibonacci;
Planning poker
22

● Exemplo de conjunto de cartas:
Planning poker
23

● Exemplo de conjunto de cartas:
Planning poker
●
24
Significa que o membro
não se sente confiante
para atribuir um valor a
tarefa;

● Exemplo de conjunto de cartas:
Planning poker
●
25
Significa que a tarefa é
absolutamente desnecessária e
deveria ser descartada;

● Exemplo de conjunto de cartas:
Planning poker
●
26
Significa que a tarefa necessita de
uma pequeno esforço para ser
concluída;

● Exemplo de conjunto de cartas:
Planning poker
27
significaca que a tarefa é
extremamente importante;

● Exemplo de conjunto de cartas:
Planning poker
● Significa uma pausa para refletir
antes de tomar a decisão;
● Esta pausa é importante e deve
ser respeitada quando solicitada;
● É muito provável que os membros
não abusem dela.
28

● Exemplo de conjunto de cartas:
Planning poker
– Os outros números representam o
sentimento dos membros quanto ao
esforço necessário para a realização da
tarefa.
29

● Cenário:
– Reunião de planejamento da sprint com toda a
equipe (4 pessoas);
– É hora da estimativa dos esforços das tarefas
● Todos (menos o ScrumMaster e o P.O.) recebem suas
cartas:
Planning poker em ação
30

●
31
●
●
O Scrum Master pede então que o PO leia a
primeira estória de usuário
“Como usuário, quero acessar o site através do
celular e usar todos os recursos, assim como no
navegador do desktop”;
O Scrum Master pede que todos os membros
pensem sobre o esforço para aquela estória;
Em seguida, pede que todos mostrem suas
cartas.
Planning poker em ação

●
32
1a Rodada
– Alan e Carlos fazem jogadas extremas;
– Nesta situação o Scrum Master pergunta a ambos o
motivo de suas escolhas;
– Após suas justificativas, é realizada a 2a Rodada.
Planning poker em ação
Membro Carta
Lucas 8
Ana 5
Alan 21
Carlos 3
Maria 5

●
33
2a Rodada
– Os valores estão mais uniformes;
– Com esse cenário, pode-se assumir algumas opções:
1) Incentivar a discussão até um consenso geral;
2) Fazer uma média dos valores;
3) Como os valores estão próximos, assumir o maior valor..
Planning poker em ação
Membro Carta
Lucas 8
Ana 5
Alan 8
Carlos 5
Maria 5

●
34
●
●
Uma lista de tarefas a ser completadas dentro
de uma Sprint;
Os itens são derivados a partir do Product
Backlog;
São considerados
– A prioridade que o cliente deu aos itens;
– O tempo e esforço estimados pela equipe para
completar os vários itens;
Sprint Backlog

●
35
●
●
●
●
●
Cada indivíduo escolhe o trabalho que fará
– Trabalhos nunca são atribuídos;
Atualização diária da estimativa do trabalho restante
Qualquer membro da equipe pode adicionar, apagar
ou mudar tarefas;
O trabalho aparece a partir do Sprint;
Se uma tarefa não é clara, defina-a como um item com
uma quantidade maior de tempo e subdivida-a depois;
Atualize as coisas a serem feitas na medida em que
se tornam mais conhecidas;
Sprint Backlog

●
●
Mostra a linha de esforço frente aos trabalhos
que precisam ser realizados;
O eixo y analisa a quantidade de trabalho a ser
completado e o eixo x o tempo de execução;
Gráfico Burndown
36

●
37
●
●
Também é divido em duas partes: um gráfico
para o Produto e outro para o Sprint.
– Mede o progresso do desenvolvimento do produto e
da Sprint;
Representa diariamente o processo do trabalho
desenvolvido;
Em resumo: um gráfico que mostra “quanto
falta”;
Gráfico Burndown

● O gráfico burndown ajuda a medir o projeto:
Gráfico Burndown
38

● O gráfico burndown ajuda a medir o projeto:
Gráfico Burndown
39

●
4
●
●
Product Owner;
Scrum Master;
Team;
Papéis

●
4
●
●
Product Owner;
Scrum Master;
Team;
Papéis

●
42
●
●
●
Maximiza o produto
– Define as funcionalidades e restrições;
– Prioriza as funcionalidades de acordo com o valor;
– Define visão, objetivos e datas de lançamento;
Maximiza o time
– Aceita ou rejeita os resultados dos trabalhos;
Representa usuários e clientes
– Deve ser apenas uma pessoa, e não um comitê
Responsável por gerenciar o backlog do
produto.
Product Owner

●
43
●
●
●
●
Não define tarefas;
Não distribui tarefas;
Tira dúvidas (sobre “o que”);
Não invade “o como”;
Valida o produto.
Product Owner

●
44
Gerenciamento do Product Backlog
– Expressa os itens do backlog de forma clara;
– Ordena os itens do backlog para alcançar metas;
– Garante visibilidade, transparência e clareza
– Garante o entendimento dos itens para que a equipe
de desenvolvimento entenda o que deverá ser feito.
Product Owner

● É o Product Owner quem faz a ponte entre a
área de negócios e a equipe Scrum
Product Owner
45

● É o Product Owner quem faz a ponte entre a
área de negócios e a equipe Scrum
Product Owner
– O PO deve
entender as
necessidades e
prioridades de
cada indivíduo da
equipe Scrum;
– Deve ser seu
porta-voz;
46

● É o Product Owner quem faz a ponte entre a
área de negócios e a equipe Scrum
Product Owner
– Mas ele também
deve se
comunicar com o
time Scrum para
ajudar na ordem
em que o produto
será construído;
47

●
48
●
●
É uma pessoa em tempo integral com
responsabilidades significativas;
Uma única pessoa pode não ser capaz de lidar
com a quantidade de coisas que o PO tem que
fazer e se preocupar;
Sob certas circunstâncias, pode se fazer
necessário um time de Product Owners.
Product Owner

Product Owner
49

●
50
Caracterísrticas do PO
– Conhecimento de Negócio;
– Habilidade com Pessoas;
– Autoridade;
– Responsabilidade.
Product Owner

● Caracterísrticas do PO
Product Owner
51

● O dia-a-dia do PO
Product Owner
52

●
53
●
●
Product Owner;
Scrum Master;
Team;
Papéis

●
54
●
●
Aplicar valores e práticas Scrum
– Garante que o Scrum seja bem compreendido e
aplicado;
– Mantenedor, guardião do processo e das boas
práticas;
Remover barreiras entre o desenvolvimento e
o cliente;
Garantir a produtividade do time
– Garantir que o time não assuma mais coisas do
que consegue em uma sprint;
Scrum Master

●
55
●
●
Blindar o time contra interferências externas
– Servidor, removedor de riscos;
– Ajuda o time a entender as interações úteis e
inúteis;
– Protege a equipe de excesso de otimismo;
Melhorar o dia a dia dos membros do time;
Pode ser considerado um professor, mentor,
coach;
Scrum Master

●
56
●
●
●
Compreender e praticar a agilidade;
Facilitar os eventos do Scrum.
Trabalhando para o PO:
– Auxiliar em técnicas para gerenciamento do backlog;
– Comunicar a visão e o objetivo dos itens do backlog;
Trabalhando para o time:
– Treinar auto-gerenciamento e interdisciplinaridade;
– Facilitar os eventos de scrum sempre que necessário;
– Garantir que o scrum está sendo seguido.
Scrum Master

●
57
Exemplos de obstáculos a serem removidos:
– “O meu quebrou e eu preciso de um novo”;
– “Eu preciso de tempo para debugar um problema no
”;
– “Eu preciso de ajuda para entender ”;
– “O cliente não teve tempo de se reunir conosco
no planejamento e por isto estou parado”;
– “O presidente da empresa pediu para eu resolver
um problema para ele em outro projeto, por um dia
ou dois...”
Scrum Master

●
58
●
●
Product Owner;
Scrum Master;
Team;
Papéis

●
●
●
Team = Equipe
– Responsáveis por entregar o produto;
Estão todos no mesmo barco;
Os papéis dos stakeholders caem em duas
categorias: porcos e galinhas
Team
59

●
●
Os porcos:
– Scrum Master;
– Team;
As galinhas:
– Representantes do Cliente
● Pessoas que criam o ambiente para implantação do
produto;
– Outros stakeholders
●
●
Representam as várias pessoas envolvidas com o projeto;
Clientes ou fornecedores;
Team
60

Team
● Os porcos:
– Scrum Master;
– Team;
● As galinhas:
– Representantes do Cliente
● Pessoas que criam o ambiente para implantação do
produto;
– Outros stakeholders
● Representam as várias pessoas envolvidas com o projeto;
● Clientes ou fornecedores;
29

● Tamanho: sacia a fome com duas pizzas;
– Originalmente: 7± 2;
– Hoje, são aceitos times 6 ± 3
● Resultados demonstraram que times com 3 ou 4
membros foram bem sucedidos!
Team
62

● Em 7± 2 ou 6 ± 3, o valor
máximo é 9:
– A ideia original vem do artigo
“The Magical Number
Seven, Plus or Minus Two:
Some Limits on Our
Capacity for Processing
Information”
– Em ambientes complexos, o
número 9 pode ser útil para
comunicação,
relacionamentos e
produtividade
Team
63

32

●
65
●
●
Multi-funcional e multi-disciplinar;
Dedicação integral;
Auto-organizável
– Não devem possuir títulos distintos de
desenvolvedor
●
●
Desenvolvedor Junior, Pleno e Sênior;
Não existe nível hierárquico;
– Individualmente, cada membro pode ter habilidades
específicas, mas a responsabilidade é do time;
Team

●
66
●
●
●
Planejamento da Sprint;
Reuniões Diárias;
Revisão da Sprint;
Retrospectiva da Sprint;
Eventos

●
67
●
●
●
Planejamento da Sprint;
Reuniões Diárias;
Revisão da Sprint;
Retrospectiva da Sprint;
Eventos

●
68
Selecionam-se itens do Product Backlog e as tarefas são
identificadas e estimadas
– Ou seja, prepara-se o Sprint Backlog
● Detalha cronograma e responsabilidades na Sprint;
– Esse procedimento é feito de forma colaborativa e não apenas pelo
Scrum Master;
– Duas etapas:
●
●
O que será feito?
Como será feito?
●
●
É realizada no início de cada Sprint;
É limitada a um período de 8 horas
– 4 horas para priorização: Product Owner;
– 4 horas para planejamento.
Planejamento da Sprint

●
●
Reuniões Diárias = Daily Scrums;
Comunicação é essencial;
Reuniões Diárias
69

●
●
●
Apenas os membros da equipe;
No início de cada dia de um Sprint;
Diariamente, em pé, durante exatos 15 minutos;
Reuniões Diárias
70

●
71
●
●
Sempre começa na hora;
Sempre no mesmo local e horário
– Geralmente pela manhã;
Todos são bem vindos, mas somente os porcos
falam;
Reuniões Diárias

●
72
●
●
Cada membro da equipe deve responder as
seguintes perguntas:
– O que eu fiz desde ontem?
– O que eu planejo fazer hoje?
– Algo me impediu de atingir meu objetivo?
O Scrum Master é o responsável por resolver os
possíveis impedimentos levantados;
Ajuda a manter os objetivos e não perder o foco
– Evita atrasos de projeto;
– Qualquer deslize pode ser corrigido de imediato.
Reuniões Diárias

●
73
Kanban Board
– É uma tabela que serve para determinar tarefas
exemplo: para executar, em andamento ou
finalizada;
– Permite um controle detalhado de produção com
informações sobre quando, quanto e o que produzir.
Reuniões Diárias

● Kanban Board
– É uma tabela que serve para determinar tarefas
– exemplo: para executar, em andamento ou
– finalizada.
– Kanban permite um controle detalhado de
– produção com informações sobre quando, quanto
– e o que produzir
Reuniões Diárias
74

●
●
Revisão da Sprint = Sprint Review;
Apresentação dos resultados obtidos
– Revisar o trabalho que foi completado (ou não)
durante o Sprint;
– Incremento do produto
potencialmente utilizável
e funcional;
Revisão da Sprint
75

●
76
●
●
●
Uma demonstração
– Ocorre navegação do sistema;
– Apresenta-se o resultado da Sprint aos
stakeholders;
Todo o time participa
– Time, scrum master e PO;
Evento informal;
É limitado a um período de 4 horas.
Revisão da Sprint

●
77
●
●
●
Guiado pelo Scrum Master;
Ocorre após a revisão da sprint e antes da
próxima reunião de planejamento;
Inspeciona como foi a última sprint em termos
de
– Pessoas e relações;
– Processos e ferramentas;
Enquanto a revisão da sprint analisa o produto,
a retrospectiva analisa o processo
Retrospectiva da Sprint

●
78
●
●
Inspeciona o andamento do último Sprint;
Identifica os pontos positivos e negativos
– Os pontos negativos exigem melhoria;
Traça plano de ação para as melhorias já no
próximo Sprint.
Retrospectiva da Sprint

●
79
●
●
É considerado como resultado do Sprint.
Para saber quando uma finalidade do produto
está concluída é utilizado Definition of Done
(DoD).
Este documento consiste em uma lista de todas
as atividades que são necessárias para a
entrega do produto.
Produto Finalizado

Quem usa Scrum?
80

PDS
SCRUM
Prof. Pedrina Brasil
pedrina.brasil@ifrn.edu.br