Rodrigo Martins Pagliares

pagliares@[Link]
`
Agenda
Parte 0: Apresentação
Parte 1: Introdução aos Métodos Ágeis
Parte 2: Conceitos Fundamentais
Parte 3: O Coração e a Alma do Scrum
Parte 4: Perguntas Frequentes
Parte 6: Referências
Parte 7: Simulado
2
Apresentação

3
 Rodrigo Martins Pagliares
Professor do Curso de Bacharelado em Ciência da
Computação – UNIFAL – MG

Mestre em Ciência da Computação – UFSC - 2002

9 anos de experiência docente em cursos de graduação em

Sistemas de Informação e Ciência da Computação

8 anos de experiência na coordenação de curso de

bacharelado em Sistemas de Informação

E-mail: pagliares@[Link]

Twitter: [Link]/pagliares
4
Introdução aos
Métodos Ágeis

5
Mini-Agenda
1. O que é desenvolvimento ágil de software?
2. Abordagem Tradicional – “Cascata”
3. Abordagem Ágil – “Espiral”
4. O Manifesto Ágil
5. Surgimento dos métodos ágeis
6. Conceitos similares entre os métodos ágeis
7. Exemplos de métodos ágeis
8. O Scrum no Brasil
6
O que é desenvolvimento ágil de
software?
Abordagem Tradicional – “Cascata”

Análise Desenho Desenvolvimento Testes Implantação

Problema: Grande risco de não entregar software

Continuamente para reduzir as incertezas.
 Abordagem Ágil – “Espiral”

Desenvo
Implantaç Desenvo
Implantaç Desenvo
Implantaç
Análise
Desenho
Testes Análise
Desenho
Testes Análise
Desenho
Testes
lvimento
ão lvimentoão lvimento
ão
O Manifesto Ágil
• Resultado do encontro de 17 grandes
pensadores do desenvolvimento de software

• Ocorrido em fevereiro de 2001, Utah – EUA

• Martin Fowler, Ken Schwaber, Robert C.

Martin, Kent Beck, Alistair Cockburn, Warn
Cunningham, Jim HighSmith, Ron Jeffries, Jon
Kern, Steve Mellor, Jeff Sutherland, dentre
outros.
10
O Manifesto Ágil
O Manifesto Ágil
• Ken Schwaber apresentou um conjunto de
práticas para a gestão de projetos de software
altamente focada em objetivos

• SCRUM é um método ágil e leve para

planejamento e acompanhamento de um
projeto.

12
O Manifesto Ágil
• O SCRUM:
• Não especifica os detalhes de como é feita a
engenharia de software.
• Usa práticas iterativas e incrementais já
fundamentadas no XP – Extreme Programming

• Compatível com os padrões CMMI e PMBOK

13
Muitos dos
métodos ágeis,
como o SCRUM,
já estavam em
estudo desde os
anos 80.
A maioria dos
métodos ágeis
possui conceitos
similares.
Desenvolvimento
Iterativo
 Criar o modelo do
domínio

Criar a Tela de
cadastro de cliente

Implementar o
componente de
integração com o
banco de dados

Trabalho a partir de
listas de tarefas
Desenvolver uma
Pequena
Funcionalidade
por vez
Ritmo
Sustentável
Equipes Multi-
Funcionais e Auto
Organizáveis
Confiança na
equipe
Entregas Prontas
para Produção
 Testes e Builds
Automatizados
(Integração Contínua).
Aceitação de
Mudanças
Inspeção
e
Adaptação
Métodos
Ágeis
 Scrum
Sprint Daily Scrum
Retrospective
XP
TDD Sustainable Sprint
Product Pace Backlog
Owner Continuous
Integration Refactoring

Scrum Sprints
Planning Co-located
Master
Game Teams

Collective Burndown
Sprint Ownership Chart
Review
Sprint
Product Planning
Backlog
O SCRUM no Brasil
Abril Digital Powerlogic UOL Microsoft

Aspercom Dígitro Keeplay Game SG Sistemas

Studios
C.E.S.A.R Tecgraf Euax Gestão de Instituto Nokia de
Projetos Tecnologia
Caelum Visie Padrões Locaweb CVale
Web
[Link] Stefanini IT Vivo BSA

H2J Soluções Petrobras DB1 Informática B2ML Sistemas

Aurum Borland/Microfocu Accion Gol
s
ProcessMind B5S Tecnologia Add Technologies Visual Systems

Fonte: Grupo de usuários “Scrum-Brasil” 28

Conceitos
Fundamentais

29
Mini-Agenda
1. O Coração e a Alma do SCRUM
2. Papéis
3. Artefatos
4. Time Box
5. Impedimentos
6. Definição de PRONTO

30
O Coração e a Alma do Scrum

31
 Papéis

Scrum Master Scrum Team

Product Owner

Stakeholders e
Usuários
O Product Owner
• Pessoa responsável por gerenciar o Product
Backlog e assegurar o valor do trabalho
desenvolvido pelo Time
Responsabilidades:
• Define as funcionalidades do produto
• Concentra informações vindas dos stakeholders do
sistema
• Responsável pelo ROI do projeto
• Prioriza o Product Backlog
• Pode alterar as prioridades fora do sprint
• Aceita ou rejeita os resultados dos trabalhos Product Owner

33
O Time
• Grupo de pessoas diretamente ligadas ao trabalho
a ser feito
Características:
• Multi-funcional e auto-Organizável Scrum Team

• Formado por até 7 pessoas (+ - 2)

• Define, em colaboração com os demais papéis
Scrum, o Objetivo do SPRINT e especifica os
resultados do trabalho
• Se esforça para atingir o Objetivo do SPRINT
• Demonstram o resultado do SPRINT para o Product
Owner e demais Stakeholders
34
O ScrumMaster
• Desempenha um papel de liderança gerenciando
os interesses do Product Owner mediante à
equipe.
Funções:
• Colaboração intensa com o P.O e o Time
• Melhorar o bem estar e a produtividade da equipe de
desenvolvimento promovendo a criatividade e o
conhecimento.
• Estimular uma comunicação e cooperação entre as
pessoas da equipe

35
Scrum Master
O ScrumMaster
Funções (continuação):
• Proteger a equipe de interferências externas
• Remover impedimentos Scrum Master

• Garantir que os princípios e regras do SCRUM sejam

sendo respeitados
• Convidar, auxiliando o Product Owner, pessoas
apropriadas para as reuniões de acompanhamento
• Reunião Diária, Revisão do Sprint, Retrospectiva do
Sprint

36
O ScrumMaster
Scrum Master
Funções (cont.):
• Remover barreiras entre o Time de desenvolvimento e
o cliente
• Auxílio essencial do Product Owner
• O cliente que deve direcionar as funcionalidades
desenvolvidas

• Auxiliar o Product Owner a maximizar o ROI atingindo

seus objetivos com o SCRUM

• Promover práticas de engenharia para que cada

pedaço da funcionalidade seja potencialmente 37

implantável
 Artefatos

Visão do Plano de
Produto Product Backlog Liberações

Sprint/Release Lista de
Sprint Backlog Burndown Impedimentos
Time-Box
Time-Box
• Conceito importante para acompanhamento
• Quando definimos um objetivo e um período de
tempo, forçamos a equipe a se concentrar naquilo
que é mais importante sem gastar tempo com coisas
desnecessárias para o objetivo

• Pilar importante do SCRUM que agrega valor de

negócio num curto período de tempo.

40
Impedimentos
• Qualquer tipo de problema que um membro
do time possa estar enfrentando que impede
o andamento dos trabalhos.
• Reportados diretamente ao Scrum Master
• Papel responsável por remover essas barreiras.
• Pode obter auxílio do Product Owner

41
Definição de “PRONTO”
• Os itens mais importantes do Product Backlog
são as principais funcionalidades do sistema
• Podem ser casos de uso, cenários, histórias de
usuário ou outros.
• Como o Time sabe que um item do Product
Backlog está pronto?
• O detalhe aqui é que o Time, juntamente com o
SCRUM Master, em concordância com o Product
Owner, devem ter a sentença daquilo que o projeto
define como “PRONTO”

42
Definição de “PRONTO”
• O SCRUM não considera funcionalidades 50%
realizadas como é normal nas abordagens
tradicionais de gestão de projetos.
• Item só está pronto quando é Potencialmente
Implantável de acordo com a definição de
PRONTO
• SÇRUM é direcionado por objetivos e não por
tarefas.

43
Definição de “PRONTO”
• É comum aos desenvolvedores acharem que
ao terminar a codificação, a funcionalidade
está pronta
• No SCRUM, uma funcionalidade do Product
Backlog só está pronta quando potencialmente
implantável.
• Ou seja, tem o potencial de entrar em produção
assim que o Product Owner decidir.

44
Definição de “PRONTO”
• Alguns exemplos da definição de “Pronto”
• Analisado, projetado, implementado e refatorado.
• Ter sido feito os testes unitários e de aceitação e
gerado a documentação e usuário
• Builds integrados com camada de apresentação,
negócios, persistência e recursos.

45
Definição de “PRONTO”
• O foco em OBJETIVOS é um dos pilares
importantes do SCRUM,
• Um time que realmente segue a metodologia
SCRUM planeja baseada em OBJETIVOS
• Executa tarefas baseada em OBJETIVOS
• Reportaandamento do projeto baseada em
OBJETIVOS e não em porcentagens.

46
O Coração e a
Alma do Scrum

47
Mini-Agenda
1. O Coração e a Alma do Scrum
2. Iniciação do Projeto
3. Planejamento do Sprint
4. Planning Poker
5. Sprint
6. Revisão do Sprint
7. Retrospectiva do Sprint
8. Incremento de Produto
48
O Coração e a Alma do Scrum
Desenvolvimento
Atualizar o
Product
Backlog

Scrum Diário

Sprint

Revisão
do Sprint Increment
Iniciação o de
do Projeto Produto
Planejamen
to do Sprint

Retrospectiva
do Sprint
Iniciação do
Projeto
 Criação do
Product Backlog

Product Backlog
Product Owner

Scrum Master

Stakeholders e
Scrum Team Usuários
 Porcos, Galinhas e Artefatos

Visão do Product Backlog

Business Case produto

Plano de
Time Scrum Liberação

Stakeholders e Scrum Master

Product Owner Usuários
Product Backlog
História de Usuário
• INVEST
• Invista em boas Histórias.

• No Scrum, requisitos são normalmente

capturados como Histórias de Usuário
• Uma História do Usuário é uma
descrição de objetivos do usuário para
com o sistema

54
História de Usuário

Historias de Usuário são parecidas com

descrições de funcionalidades

55
História de Usuário

Historias de Usuário destacam o papel do

usuário

56
História de Usuário

O Objetivo que eles estão tentando atingir

57
História de Usuário

E o valor do objetivo

58
História de Usuário

Enquanto <tipo do usuário>,

eu quero <atingir um objetivo>, de forma
a obter <algum valor>

59
História de Usuário

Existem historias de usuário boas e ruins

60
História de Usuário

Usando objetivos S.M.A.R.T, Bill Wake

nos aconselha a I.N.V.E.S.T em
historias de usuário

61
História de Usuário
I.N.V.E.S.T
Independent
Negotiable
Valuable
Estimable
Sized right
Testable
62
História de Usuário
• Independente
• Evite dependências entre histórias
• Escreva histórias para estabelecer o alicerce do
sistema
• Combine histórias similares em uma única iteração
quando apropriado.

63
História de Usuário
• Negociável
• Histórias não são contratos
• Muitos detalhes sugerem que não existe nada mais
a explorar
• Saiba quando não é possível negociação. Algumas
restrições são fixas.

64
História de Usuário
• Valorosa
• Exiba o valor da história para os clientes e outros
Stakeholders.

65
História de Usuário
• Estimável
• Apresente detalhes suficientes para estimativa do
esforço de trabalho.
• Histórias devem ser pequenas para serem
estimadas
• Mas não muito pequenas.

66
História de Usuário
• Tamanho Correto
• Historias devem ser pequenas o suficiente para
serem completadas em um Sprint
• Não recomendamos historias maiores que duas
semanas.
• Quanto mais próximo de se trabalhar em uma
historias, mais especifica ela deve ser.
• Historias podem iniciar em um nível alto de
abstração (epic)
• Mas elas precisam ser quebradas em momento
oportuno

67
História de Usuário
• Testável
• O critério de aceitação deve estar presente em uma
historia
• Os testes devem ser automatizados sempre que
possível

68
 História de Usuário

Enquanto (papel)
Condições de
eu quero (algo)
Aceitação ou
para (benefício).
Narrativa
História de Usuário
Pesquisar Catálogo

Enquanto usuário registrado eu quero poder

pesquisar o catálogo online atrás de itens para
compra.

Pontos: 3 Valor de negócio: 600

História de Usuário
Narrativa
1. Abrir a página de busca.
2. Entrar com vários critérios de busca.
3. Iniciar a busca.
4. Visualizar os resultados dos itens do catálogo que contém
uma ou mais palavras-chave em seu título ou descrição

Testes
• Strings entre aspas usadas para busca exata.
• Testar os operadores E, OU, +, e -.
• Os resultados devem estar disponíveis em até 5 segundos
• Tentar caracteres inválidos.
História de Usuário
Tarefas S.M.A.R.T
Specific
Measurable
Achievable
Relevant
Time Boxed

72
História de Usuário
Tarefas S.M.A.R.T
• Específica
• A Tarefa deve ser específica o suficiente para que
todos envolvidos a compreendam.

• Mensurável
• Podemos declarar a tarefa como pronta?

• Realizável
• O dono da tarefa deve ser capaz de implementá-la
• Qualquer um pode solicitar auxílio

73
História de Usuário
Tarefas S.M.A.R.T
• Relevante
• Cada tarefa deve contribuir para a implementação
da História de Usuário

• Time-Boxed
• Uma tarefa deve ser limitada a uma duração
específica.

74
Planejamento
do Sprint
Planejamento do Sprint

Product Owner Product Backlog

Scrum Master

Time Scrum Sprint Backlog

Planejamento do SPRINT
• O SPRINT inicia com um planejamento
feito em duas partes
• Criação do PRODUCT BACKLOG priorizado
• Definição do SPRINT BACKLOG

• No planejamento, todos os envolvidos

planejam quais serão os objetivos a
serem finalizados nos próximos 28 dias
• Caso seja utilizado um sprint de 30 dias.

77
Planejamento do SPRINT
Parte 1 Parte 2

Product Backlog Sprint Backlog

Priorizado e Detalhado

Time-Box: 4 horas Time-Box: 4 horas

Time-Box: 1 dia
78
Planejamento do Sprint
• Primeira Parte
• Scrum Master e Product Owner para
definição/verificação/detalhamento do Product Backlog
• Product Backlog pode ser representado em documento
comum ou planilha onde constam todas as
funcionalidades do sistema.
• Segunda Parte
• Scrum Master, Time e Product Owner (opcional) se
reúnem para planejamento do Sprint baseado no
product backlog criado ou atualizado.
• Product Owner e Scrum Master apenas definem a
ordem das coisas, não os prazos, que são fornecidos
pelo Time.
79
Planejamento do Sprint
• Na primeira parte da reunião, a conversa deve
focar no ROI do projeto.

• O trabalho de ordenar o Product Backlog é

uma importante tarefa, pois o Product Owner
decidirá aquilo que agregará mais valor ao
software para ser entregue no final do sprint.

80
 Planejamento do Sprint
• Primeira Parte – Product Backlog Inicial
ID Descrição Sprint Esforço Conclusão
1 Gerenciar Reservas

2 Efetuar Pagamento
3 Fazer check-in
4 Fazer check-out

5 Gerar relatórios
6 Gerenciar Reservas Online
7 Registrar consumo

Itens na parte superior possuem maior valor de negocio e são detalhados

81

na reunião.
Planejamento do Sprint
• Na segunda parte da reunião:
• Selecionar quais itens potencialmente
implantáveis serão implementados no sprint
• Cabe ao Time:
• Fazer a estimativa dos itens potencialmente
implantáveis usando, por exemplo, Planning Poker
• O Time quebra cada item selecionado em tarefas
menores que podem ser cumpridas em um dia
(desejável).

82
Planejamento do Sprint
• Os itens que aparecem no Product Backlog são
qualquer tipo de funcionalidade ou tarefa que possua
um valor para o Product Owner.

• Funcionalidade Potencialmente Implantável

• Significa que quando esse item do Product Backlog for
finalizado ele estará completamente funcional e resolvendo
algum problema de negócio dos stakeholders

83
 Planejamento do Sprint

Scrum Master

Planning Poker
Planejamento do Sprint
• Principal problema de estimativas em grupo:
• Impacto que a opinião dos outros tem sobre a sua.

• Existe uma técnica para isolar esse efeito,

chamada Planning Poker
• Cada membro da equipe recebe um conjunto de
cartas com os números 1, 2, 3, 5, 8 da seqüência
de Fibonacci.
• Outros números são possíveis

85
Planejamento do Sprint
Planning Poker
• Escala bastante usada porque não deixa
tantas dúvidas na escolha do número de
Fibonacci que representa o esforço.

86
Planejamento do Sprint
Planning Poker
• Não recomenda-se o uso dos números 13 e
21.
• Quanto maior o número, mais difícil o
planejamentos das iterações.
• Trabalhar com objetivos menores permite uma
gestão melhor e estimativa mais precisa
• Números maiores podem ser usados para Temas e
Epics
• Normalmente 20, 30, 50, 100

87
 Planejamento do Sprint

3 5

3 8

Scrum Master
Planning Poker
 Planejamento do Sprint

Pesquisar Catálogo: esforço :3

Enquanto usuário registrado eu que poder
pesquisar o catálogo online atrás de itens para
compra.
Valor de Negócio: 600
.
Planejamento do Sprint
ID Descrição Sprint Esforço Conclusão

Granularidade aumentando
1 Enquanto Agente de Reservas 1 8
eu gostaria de criar uma nova
Reserva
2 Enquanto Agente de Reservas 1 3
eu quero poder consultar uma
Reserva existente pelo número
ou pelo nome do hóspede

3 Uma Reserva possui um ou 1 1

mais quartos para um período
específico de tempo

4 Efetuar Pagamento 30
5 Fazer check-in 20
6 Fazer check-out 20
7 Gerar relatórios 8 90
Planejamento do Sprint
Estimativas com Pontos de Historia
• Esforço adicional nas estimativas para os
requisitos agrega pouco valor após certo
ponto

91
Fonte: COHN, M. Agile Estimating and Planning, página 50.
Planejamento do Sprint
Estimativas e Métricas Ágeis
• No SCRUM, usam-se métricas ágeis e o
conceito de velocidade para obter prazos a
partir de uma lista de funcionalidades.

• É importante ressaltar que essas métricas são

otimizadas com equipes consistentes de baixa
rotatividade

92
Planejamento do Sprint
Pontos, Velocidade e Prazo
• Uma estimativa se obtém através de uma
medida de esforço e a velocidade para vencer
este esforço.
• Recomenda-se esforço não atrelado a uma
unidade de tempo (esforço relativo).
• A velocidade significa qual é a minha
performance esperada dentro do Sprint
• Nessa performance estão embutidos as restrições
do ambiente, os riscos e a produtividade.

93
Planejamento do Sprint
Pontos, Velocidade e Prazo
• Para projetos de software, utilizamos “Pontos”
para mensurar o esforço do Product Backlog
• Os pontos representam o tamanho funcional e a
complexidade técnica do item do Product Backlog

94
Planejamento do Sprint
Estimando a Velocidade
• Para obter o prazo, precisamos saber quantos
pontos conseguimos vencer dentro de um
período de tempo.
• Pontos do sprint:
• Quantidade de pontos que a equipe consegue
entregar dentro do TimeBox de aproximadamente
30 dias.

95
Planejamento do Sprint
• Nos primeiros sprints a incerteza com relação
à produtividade da equipe é muito grande
• Então, para o primeiro Sprint, simplesmente
perguntamos à equipe o que ela acredita entregar
até o fim do Sprint.

96
 Planejamento do Sprint
Velocidade Product Backlog
3
8 Pontos de História Sprint 1 3

Sprint 2 2

Sprint 3 2

Sprint 4
5

Sprint 5 5

Total Pontos: 37
Planejamento do Sprint
Estimando o prazo do projeto
• Pegando 8 pontos por Sprint já temos uma
previsão inicial de 5 Sprints

Total de pontos = 37
Velocidade Estimada = 8
Prazo = 37/08 = 4,625 = 5 Sprints

98
 Planejamento do Sprint
Product Backlog
3
Plano de Liberações Sprint 1 3

2
Liberação 1
3

Sprint 2 2

Product Backlog Sprint 3 2

3
Liberação 2
Sprint 4
5

Sprint 5 8
Plano de
Liberação
Velocidade: 8 Pontos de História
Planejamento do Sprint
Sprint Backlog
• O Sprint Backlog é o produto de trabalho
do dia de planejamento
• Quadro montado a cada Sprint

• É importante que os itens do topo da lista

sejam resolvidos primeiro
• Toda metodologia de gerenciamento de
projetos é baseada em planejamento,
execução, controle e avaliação
• No SCRUM isso não é diferente
100
Planejamento do Sprint
Sprint Backlog
• Cada item do Product Backlog
selecionado para o Sprint é quebrado em
tarefas menores, mensuradas em horas
• Sugere-se que cada quebra individual não
ultrapasse 16h.
• Esta quebra de cada item é chamado SPRINT
BACKLOG

101
Planejamento do Sprint
Sprint Backlog
• O Time deve consultar o ScrumMaster e o
Product Owner nos casos de dúvidas que irão
surgir no momento do detalhamento do item
em tarefas.

• O detalhamento ideal esclarece tudo aquilo

necessário para tornar o item em algo pronto.
• Isso vai ocorrendo no decorrer do sprint.

102
 Planejamento do Sprint
Pesquisar Catálogo: 3
Enquanto usuário registrado eu
quero pesquisar o catálogo
online atrás de itens para
compra.

Criar a Página de Busca: 8h

Criar a classe de Consulta: 4h

Criar testes unitários: 2h

Criar o método de busca: 8h

 Planejamento do Sprint
Sprint Backlog
Histórias de Usuário Pendente Em progresso Pronto Impedimento

Criar Form para Criar Modelo de Dados DAO

Enquanto xxxxx, eu Cadastro dos Genérico
quero …..l dadoss
Criar Testes Unitários

Autenticar Administrador

Criar Form para

inclusão de notícias Autenticar Colunista

Enquanto xxxxx, eu
quero …..l Permitir upload de
vídeo atrelado à notícia

Criar Modelo de Dados

Criar página principal

do portal

Enquanto xxxxx, eu Definir Layout do portal

quero …..l
Criar CSS externo
Planejamento do Sprint
Estimativas e o Product Backlog
• É importante que no planejamento do
Primeiro Sprint ou numa fase inicial de
concepção, a maioria dos itens do Product
Backlog esteja com uma estimativa inicial de
esforço em Pontos de História
• São necessários de 3 a 4 Sprints para que a
produtividade da equipe seja melhor adaptada
a realidade.

105
Sprint
Sprint
Iterativo e Incremental
• Processos iterativos minimizam riscos
oferecendo uma rápida avaliação dos
usuários a respeito daquilo que está
sendo desenvolvido
• Iteração é um período de tempo fixo
onde a equipe está trabalhando para
que, ao final deste período, algo de valor
seja demonstrado para os usuários
107
Sprint
Iterativo e Incremental
• No SCRUM, a iteração é chamada de
SPRINT.
• Período de tempo de um SPRINT pode
variar
• Recomendável 30 dias !

• Um PROJETO SCRUM é composto por

vários SPRINTS de mesmo tamanho.
108
 Sprint
30 dias
Iterativo e Incremental
30 dias
Sprint 4
30 dias
Sprint 3
30 dias
Sprint 2

Sprint 1

Tempo
109
Sprint
Time Box
• Durante o SPRINT, a equipe faz de tudo
para que os objetivos sejam alcançados.
Planejamento do Sprint: Partes 1 e 2

Dia 1
30 dias

Dia 2

Dia .....

Dia 29

Revisão do Sprint/Retrospectiva do Sprint 110

Sprint
Desenvolvimento
• Durante os 28 dias após o planejamento
a equipe trabalha e colabora entre si em
constante comunicação.
• No último dia do SPRINT todo o trabalho
da equipe é avaliado juntamente com o
PRODUCT OWNER
• O PRODUCT OWNER pode dar novos
direcionamentos para o projeto
111
 Sprint

Gestão de Integração
Configuração Contínua

Desenvolvedor

Testes de
Testes Unitários Funcionalidade

Desenvolvimento
Sprint
Utilizando o Burndown Chart
• Usado para reportar o andamento do projeto
de maneira mais amigável

Sprint Burndown

113
Pontos de História Restantes 35 pontos.

0 pt.

Tempo (dias)

Sprint Burndown
Sprint
Utilizando o Burndown Chart
• Eixo X
• Duração do Sprint .

• Eixo Y
• Número de pontos “a serem vencidos” que
representam o peso das funcionalidades
potencialmente implantáveis do Product Backlog.

115
Sprint
Utilizando o Burndown Chart
• Interseção abaixo da linha azul
• velocidade está acima do planejado.

• Interseção acima da linha azul

• Não estamos vencendo os pontos na velocidade
planejada
• tendência é não cumprirmos o prazo.

116
Sprint
Encerrando o Sprint
• A data final do Sprint é o marco para o fim do
Sprint e não as funcionalidades implementadas.
• O Sprint termina mesmo que esses 3 itens não
estejam “prontos”
• O Sprint de tamanho fixo durante todo o projeto é
um importante mecanismo para mensurar a real
produtividade do time melhorando as estimativas a
cada Sprint.

MELHOR PERDER FUNCIONALIDADES DO QUE

DATAS ! 117
Scrum Master Time Scrum

Reunião
Diária
 Reunião Diária

Scrum Master Time Scrum

Sprint Lista de
Sprint Backlog Burndown Impedimentos
Reunião Diária
• Ocorre todos os dias durante o Sprint

• Encontro entre o Scrum Master, o Time e

qualquer pessoa interessada no projeto.

• TIME-BOX de 15 minutos no máximo

• Não dure duas ou 3 horas comprometendo a
produtividade da equipe

120
Reunião Diária
• Três perguntas devem ser respondidas:
1. O que eu fiz desde a última reunião diária?
2. O que eu pretendo fazer até amanhã?
3. Tem alguma coisa impedindo o meu trabalho?

121
Reunião Diária
• É aconselhável que a reunião diária ocorra
todo o dia no mesmo horário.

• A reunião diária promove auto-organização,

um maior comprometimento das pessoas e
um compartilhamento de responsabilidades

122
Inspeção
e
Adaptação
Revisão do
Sprint
 Revisão do Sprint

Produto
Product Owner Finalizado Scrum Master

$
$ $

Stakeholders e
Scrum Team Usuários

$ $
$ $ $ $
Revisão do Sprint
• Importante ponto de inspeção do SCRUM.
• Ocorre no último dia do SPRINT e representa
o momento que o TIME e o SCRUM Master
demonstram as funcionalidades
potencialmente implantáveis para o Product
Owner
• A funcionalidade potencialmente implantável é
a única medida real a respeito do andamento
do projeto que pode reduzir a incerteza

126
Revisão do Sprint
• É inadmissível para a filosofia do
SCRUM que ao final do Sprint sua
equipe só entregue documentos para o
Product Owner.

127
Inspeção
e
Adaptação
Comprometimento: 12 Entregue: 11
ID Descrição Sprint Esforço Conclusão
1 Enquanto Agente de Reservas 1 8
eu gostaria de criar uma nova
Reserva
2 Enquanto Agente de Reservas 1 3
eu quero poder consultar uma
Reserva existente pelo número
ou pelo nome do hóspede

3 Uma Reserva possui um ou 1 1

mais quartos para um período
específico de tempo

4 Efetuar Pagamento 30
5 Fazer check-in 20
6 Fazer check-out 20 129

7 Gerar relatórios 8
Inspeção e Adaptação
• De acordo com a figura anterior, o item “Uma
reserva possui um ou mais...” não foi
implementado
• Será entregue no Sprint 2 caso a prioridade seja
mantida.
• Nessa situação, deve ser avaliada a causa do
não cumprimento .
• Uma possibilidade é a velocidade do time ser
menor que a prevista.
• Lembre-se: o Product Backlog é atualizado
constantemente durante o projeto.
130
Inspeção e Adaptação
• Com o replanejamento pode ser que surja um
novo Sprint. Nesse caso o Product Owner
deve decidir se deseja:
• Aumentar o custo (aumentar a equipe, horas
extras)
• Aumentar o prazo
• Abrir mão de funcionalidades.

• O Scrum possui dois valores importantes:

“TRANSPARÊNCIA” e a “ARTE DO POSSÍVEL”

131
Retrospectiva
do Sprint
Retrospectiva do Sprint

Product Owner Scrum Master

Stakeholders e
Scrum Team Usuários
Retrospectiva do Sprint
• O SCRUM é um conjunto de práticas focadas
em melhoria contínua do processo.
• O SCRUM como controle empírico, não prega
uma rigidez do processo, ao invés, promove
constante adaptação das práticas mesmo
durante o projeto.
• O processo pode mudar de um SPRINT para
outro sempre buscando uma melhoria na
produtividade ou qualidade do produto final.

134
Retrospectiva do Sprint
• Finalmente, temos um momento de
retrospectiva
• Discussão sobre lições aprendidas e ajustes
necessários no processo
• Planejamento do novo SPRINT.

• Todos os Sprints possuem uma estrutura

exatamente igual
• Planejamento, cumprimento, avaliação do
resultado e ajuste o processo

135
Inspeção
e
Adaptação
 Retrospectiva do Sprint
O que caminhou bem? O que poderia melhorar?
Mais
Gestão com Melhorar
tempo
maior os testes
refatora
visibilidade unitários
ndo

Daily
Eu gostei Scrum Testes
Mais clara
do quadro muito unitários
a idéia de
de tarefas longa
em que
trabalhar
Feedback
mais
rápido da
gerência
Líções Aprendidas

Time Box: 3 horas

Retrospectiva do Sprint
• Nessa reunião o objetivo é a transparência
interna do TIME.
• O SCRUM Master deve avaliar os pontos
apresentados e prover os recursos necessários
para que as mudanças ocorram.
• Um dos problemas mais comuns é a equipe não
buscar ou se empenhar para que as mudanças
no processo ocorram.
• A adaptação contínua é um fundamento importante para
controlar projetos críticos e esses pontos de melhorias
devem ser valorizados
• As lições aprendidas é um fundamento em muitas
metodologias de gestão de projetos. 138
Repita,
Repita
Perguntas
Frequentes

140
Perguntas Freqüentes

Itens ordenados pelo Product Owner são bacanas,

mas o que acontece quando eu tenho
funcionalidades que precisam ser completadas
antes de outras?

141
Perguntas Freqüentes

O que acontece quando o Product Owner aparece

com um novo requisito e não conseguimos
encaixá-lo no sprint atual?

142
Perguntas Freqüentes

O que acontece se já estivermos no último sprint

previsto e o Product Owner aparece com uma
nova funcionalidade?

143
Perguntas Freqüentes

Não seria melhor adicionar termos técnicos e

algumas idéias da equipe nas histórias do usuário
para torná-las mais úteis para todos?

144
Perguntas Freqüentes

E se eu atingir o fim do sprint e não tiver nada para

exibir para o Product Owner?

145
Perguntas Freqüentes

Qual deve ser o tamanho de uma tarefa?

146
Perguntas Freqüentes

O que acontece se eu descobrir uma grande tarefa

ausente?

147
Perguntas Freqüentes

Uma questão importante e que tomará tempo para

ser discutida surgiu no Daily Scrum. Devemos
aumentar o time-box para 1h para resolver o
problema?

148
Perguntas Freqüentes

O Scrum diário deve acontecer realmente todos os

dias?

149
Referências

150
Ken Schwaber

151
Mike Cohn

152
Sites Importantes
Manifesto ágil - [Link]

Agile Alliance - [Link]

Scrum Alliance - [Link]

153
Sobre estes Slides
Template e figuras destes slides usados a
partir de apresentações de Scrum presentes em
[Link]

154
Traduções Utilizadas
• Release Plan - Plano de Liberaçoes
• Sprint Review – Revisao do Sprint
• Sprint Retrospcective – Retrospectiva do
Sprint
• Daily Scrum – Reuniao Diaria
• Sprint Planning – Planejamento do Sprint
• User Stories – Historias de Usuario
• Story Points – Pontos de Historia
155
Termos não traduzidos
• Business Case

156
Simulado

157
Obrigado !