Scrumexperienceotutorialscrumv16 091124165357 Phpapp01 PDF

SCRUM Experience = Tutorial SCRUM
SCRUM Experience
www.etcnologia.com.br
Rildo F Santos
(11) 9123-5358
(11) 9962-4260
Verso 17
rildo.santos@etecnologia.com.br
@rildosan
http://www.rildosan.com/
verso: 17
rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br
Rildo F. Santos, CSM, CSPO

Tem mais de 10.000 horas de experincia em Gesto de Negcios, Governana e
Engenharia de Software.
Formado em Administrao de Empresas, Ps-Graduado Didtica do Ensino Superior
e Mestre em Engenharia de Software pela Universidade Mackenzie.
Atua em Gesto de Negcio (Inovao, Processos e GRC) e em projetos de
Engenharia de Software utilizando mtodos Agile (SCRUM, Lean, XP e FDD) Agile
Coach.
Foi instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java na Sun

Microsystems e da IBM.
Conhece Arquitetura de Software, SOA (Arquitetura Orientado a Servio), RUP/UP Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outras
tecnologias.
Professor de curso de MBA da Fiap e foi professor de ps-graduao da Fasp e IBTA.
Tem forte conhecimentos de Gesto de Negcio (Inteligncia de Negcio, Gesto por

Processo, Inovao, Gesto de Projetos e GRC - Governance, Risk and Compliance),
SOX, Basel II e PCI;
Tem vivncia na implementao de Governana de TI e Gerenciamento de Servios
de TI, Conhecimento dos principais frameworks e padres: ITIL, Cobit, ISO 27001 e
ISO 15999;
Desempenhou diversos papis como: Estrategista de Negcio, Gerente de Negcio,
Gerente de Projeto, Arquiteto de Software, Projetista de Software e Analista de
Sistema em diversos projetos em empresas como: Bradesco, Editora Abril, Scopus,
Porto Seguro, Certagy, Secretria da Fazenda SP, Sonagol (Angola),
Honda, Dix-Amico, Bank Tokyo-Mitsubishi, Vivo, Hospital das Clinicas, Aos Villares,
Novabase do Brasil, Policia Militar do Estado de So Paulo entre outras.
Possui as certificaes: CSM - Certified SCRUM Master, CSPO - Certified SCRUM
Product Owner ,SUN Java Certified Instrutor , ITIL Foundation e Instrutor Oficial de
Cobit Foundation e Cobit Games;
membro: IIBA-International Institute of Business Analysis (Canada)
@rildosan
Blog: http://www.rildosan.com/
www.etecnologia.com.br
http://etecnologioa.ning.com
Verso 17
Nota do Autor:
Trabalho com desenvolvimento de software a quase 15 anos

entre idas e vindas.
Como todo desenvolvedor tenho preferncia por uma linguagem
de programao, no meu caso o Java.
Confesso que j utilizei diversos framework, padres e modelos
para o construir software, contudo, os Mtodos geis me
chamaram a ateno para um detalhe, que hoje julgo
extremamente importante...
A essncia dos mtodos geis so as pessoas e no o
processo, o respeito e a disciplina so outros aspectos que eu
considero grandiosos.
Nos ltimos dois anos estou trabalhando com SCRUM, o qual
me fascina pela simplicidade e o foco em resultado.
Escrevi este tutorial para compartilhar minha experincia com as
prticas SCRUM para as pessoas que esto tendo o primeiro
contato com os Mtodos geis e necessitam de guia ou uma
referncia para entender como SCRUM funciona na prtica.
Atualmente estou tentando empregar prticas do SCRUM em
outras reas de negcio (processo de negcio), este meu
desafio.
Verso 17
Play SCRUM
Verso 17
SCRUM:
As origens
The New, New
Product
Development
Game
O que SCRUM ?
SCRUM um processo iterativo e
Iterative,
incremental para desenvolvimento de
Incremental qualquer produto ou gerenciamento
Development de qualquer trabalho...
TimeBoxes
SmallTalk
Engineering Tools
SRUM :
Processo emprico de gerenciamento
e controle.
- Faz a inspeo e adaptao em
loops de feedback
- Faz entrega de valor ao cliente em
at 30 dias;
- Escalvel para suportar grandes
projetos
- Compatvel com CMM3 e ISO9001
- Extremamente simples, mas muito
resistente...
Valores do Scrum::
- Transparncia
-Integridade: assim que perceber
algo, faa algo
- Ser emprico
- Auto-organizao
- Entrega de valor
Ken Schwaber
SCRUM um Mtodo GIL para desenvolvimento de software

Verso 17
Manifesto gil:
Princpios por trs do Manifesto gil:

A prioridade satisfazer o cliente, entregando o mais rpido possvel e de forma contnua software
que tenha valor;
Requisitos mutantes so bem vindos, mesmo no final do desenvolvimento. Os processos geis
podem ser usados a favor de mudanas que tragam vantagem competitiva para o cliente;
importante entregar software funcionando freqentemente, mensalmente, quinzenalmente ou,
se possvel, toda semana;
Clientes e desenvolvedores devem trabalhar juntos diariamente num projeto;
Projetos devem ser feitos por indivduos motivados. Os indivduos precisam da confiana de que
seu trabalho ser realizado. Eles devem ter suas necessidades atendidas e trabalhar num ambiente
adequado;
Conversa face-a-face SEMPRE a melhor forma de comunicao;
Software funcionando a primeira medida de progresso;
O processo gil torna o desenvolvimento sustentvel. Patrocinadores, desenvolvedores e
usurios devem manter a paz indefinidamente;
Ateno constante excelncia tcnica e bom design aumenta a agilidade;
A chave SIMPLICIDADE: a arte de minimizar a quantidade de trabalho desnecessrio;
As melhores arquiteturas, requisitos e design surgem de equipes auto-organizados;
Em intervalos regulares, a equipe reflete como se tornar mais eficiente. Ento ajusta seu
comportamento para atingir esse objetivo.
http://agilemanifesto.org/
Verso 17
Como ser gil:
Como ser gil ?

Para ser gil preciso colocar
em prtica os valores e os
princpios geis (aqueles
descritos no Manifesto gil).
Quando utilizar os Mtodos os
geis ?
Antes de responder esta questo
faa uma outra pergunta,
questione: Se os Mtodos geis
ajudaro a melhorar os
resultados (ou sucesso) dos
projetos de desenvolvimento de
software ?
Se a resposta for SIM, no perca
tempo, arregace as mangas e v a
luta...
Lembre-se que o bom processo de desenvolvimento de software aquele que permite
que a equipe tenha sucesso
Verso 17
Iterativo e Incremental:
Entrega 1
Entrega 2
Entrega 3
Incremental
Iterativo
Devido
a
complexidade,
tamanho,
mudanas de requisitos, urgncia e
necessidade de demonstrar valor mais
rpido,
fica
quase
inconcebvel
desenvolver software utilizado o modelo
cascata,
ou
seja
desenvolver
todo o software de uma nica vez.
Desenvolvimento Iterativo e incremental
uma estratgia de planejamento (que
segue a linha dividir para conquistar ),
onde o software construdo em partes,
ou seja, em ciclos (iteraes), a cada
iterao feito um novo incremento (parte
do software funcional) at completar o
software.
Verso 17
TimeBox e Sprint
O que Timebox ?
um conceito diz que a quantidade de tempo
(horas ou dias) imutvel, ou seja, a quantidade de
horas no poder aumentar. Assim, evita-se atraso
no prazo de entrega e facilita o planejamento.
Entretanto, quanto se erra a estimativa de tempo
(leia-se: horas ou dias) de uma Sprint (leia-se:
iterao), neste caso recomendvel reduzir o
escopo da Sprint, desde que no afete a meta da
Sprint (isto discutido um mais a frente) ao invs
de aumentar a quantidade de horas/dias.
Timebox = Um prazo ou tempo (dias/horas por
exemplo) bem definido e imutvel.
O que uma Sprint ?

uma iterao (que pode ser parte de uma
release) que deve ser realizada de 2 a 4 semanas,
no qual a equipe do projeto dever produzir um
entregvel de valor para o cliente (lembre-se do dos
Princpios do Manifesto gil).
A entrega de valor a meta da Sprint que dever
esta bem definida e combinada com o cliente, antes
do comeo da execuo da Sprint.
O conceito de Timebox aplicado a Sprint.
O conceito de timebox aplicado as cerimnias (reunies) do

Scrum. Todas as reunies so Timeboxed:
- Reunio de Planejamento da Sprint (8 horas)
- Reunio Diria (15 minutos)
- Reunio de Reviso da Sprint (4 horas*)
- Reunio de Retrospectiva da Sprint (3 horas*)
Nota: * A quantidade de horas pode variar de acordo com a necessidade (por exemplo, apresentao do que ser
entregue ao cliente) ou aquilo que ser discutido/debatido, neste caso a Retrospectiva ela poder variar entre 1 a 3 horas
Verso 17
No existe Bala de Prata:
SCRUM no a Bala de Prata:
Veja Lei F. Brooks,

No existe bala de prata
O SCRUM no a soluo completa para os problemas de produtividade,

complexidade, custo, prazo e qualidade do processo de desenvolvimento de
software.
No existe soluo mgica para problemas complexos

Contudo, voc pode utilizar o SCRUM para:
- SCRUM ideal para desenvolvimento de software complexos onde os requisitos
mudam rapidamente;
- SCRUM processo gil para gerenciar e controlar desenvolvimento de trabalho;
- SCRUM possibilita que voc utilize as praticas de engenharia existentes e que j
so conhecidas;
- SCRUM baseado na abordagem de equipe auto-gerencivel e multifuncional;
SCRUM trabalha com conceito iterativo e incremental desenvolver software e/ou
produtos;
- SCRUM o caminho para detectar e causa raiz e a remoo de qualquer coisa
que esteja impedindo o desenvolvimento e/ou entrega de software/produtos;
- SCRUM o caminho para maximizar a produtividade;
- SCRUM um forma para desenvolvimento de equipes e de indivduos
Verso 17
10
Algumas empresas que esto usando SCRUM:
Quais empresas esto

utilizando o
SCRUM?
Algumas empresas
brasileiras
Verso 17
11
A ALMA do SCRUM:
Reviso
da Sprint
Retrospectiva
da Sprint
Planejamento
da Sprint
Reunio
diria
24 horas
Produto
Backlog
Viso
Sprint
Backlog
2-4 Semanas
Produto
Burndown
Legenda:
Cerimnias
artefatos
Papis
Product Owner (PO)
ScrumMaster (SM)
Equipe Scrum
Verso 17
Cerimnias
Artefatos
Planejamento da Sprint Product Backlog

Reunio Diria
Sprint Backlog
Reviso da Sprint
Burndown (grfico)
Retrospectiva da Sprint
12
Papis SCRUM:
O SCRUM tem somente trs papis: Product Onwer (PO), SCRUM
Master (SM) e a equipe SCRUM.
Product Owner, responsvel por:

- Definir a Viso do Produto
- Elaborar e manter o Product
Backlog
- Definir a prioridade e ROI;
- Representar o cliente
- Aceitar ou rejeitar os entregveis
SCRUM Master responsvel por:
- Ser um lder (servidor);
- Remover impedimentos;
- Proteger a equipe;
- Ajudar o PO (com Product Backlog);
- Ser o facilitador da equipe;
- Garantir as prticas SCRUM.
Equipe SCRUM responsvel por:
- Fazer estimativa;
- Definir as tarefas;
- Desenvolver o produto;
- Garantir a qualidade do produto;
- Apresentar o produto ao cliente
Equipe: auto-gerencivel e multifuncional
Verso 17
13
A Equipe e Comprometimento:
Envolvidos
Comprometidos
Stakeholders
(clientes e usurios
finais)
Product Onwer
Equipe
SCRUM Master
A equipe Scrum formado por pessoas comprometidas em realizar as tarefas

da Sprint Backlog. As pessoas da equipe devero possuir habilidades suficientes
para desenvolver, testar, criar/desenhar interfaces grficas e etc, ou seja, tudo
que que realmente preciso para entregar o software funcionando.
O tamanho da equipe algo muito importante, pois, o SCRUM recomenda que o
tamanho da equipe seja de 6 a 9 pessoas. Entretanto, podemos ter equipe
menores, de 4 a 9, por exemplo.
Acertar o tamanho da equipe um Fator Critico de Sucesso. s vezes
necessrio reduzir o tamanho de uma equipe para aumentar a produtividade.
(Oooops, isto parece antagnico, mas as equipe menores so aquelas que
produzem os melhores resultados)
A equipe tambm possui responsabilidades entre elas participar das cerimnias,
que as so reunies que acontecem em momentos distintos da Sprint
Verso 17
14
Cerimnias:
Reunio de Planejamento da Sprint (8 horas)
Participantes: PO, Equipe e SCRUM MASTER
Esta reunio primeira reunio, seu objetivo fazer
o planejamento da Sprint. Ela dividida em duas partes.Na
primeira parte o PO definir prioridade, seleo dos itens do
backlog e meta da Sprint.
Na segunda parte a equipe definir a Sprint Backlog (que so
as tarefas necessrias para cumprir a meta).
Reunio Diria (15 minutos)

Participante: Equipe e SCRUM MASTER
Nesta reunio somente membros da equipe devem
participar. A durao dela de 15 minutos. As pessoas
fazem a reunio de p. O objetivo desta reunio fazer
que as pessoas respondam 3 questes:
- O que eu fiz ontem ?
- O que vou fazer hoje ?
- Encontrei algum impedimento ?
Reviso da Sprint (4 horas*)
Participantes: PO, Equipe e SCRUM MASTER
Esta reunio acontece no final da Sprint, opcionalmente outras

pessoas podem ser convidadas (se necessrio).
O objetivo da reunio apresentar o que a equipe fez durante a
Sprint e fazer a entrega do produto (software funcionando) para o
PO. (Geralmente apresentado uma demo do software).
Geralmente ela feita em um auditrio ou em uma sala de reunio
Retrospectiva da Sprint (3 horas*)
Participantes: Equipe e SCRUM MASTER
Esta reunio acontece logo aps a Reviso da Sprint.
O objetivo dela avaliar o que deu certo e que deu errado
durante a Sprint, e fazer os ajustes possveis para a prxima
Sprint, ou seja, o ciclo de melhoria contnua.
Nota: * A quantidade de horas pode variar de acordo com a necessidade (por exemplo, apresentao do que ser
entregue ao cliente) ou aquilo que ser discutido/debatido, neste caso a Retrospectiva ela poder variar entre 1 a 3 horas
Verso 17
15
Artefato: Product Backlog

Product Backlog uma lista contendo todas as funcionalidades
desejadas para um produto.
Exemplo de Product Backlog: Sistema de Reserva On-Line
Nvel de
Prioridade
Categoria
Descrio do Item Backlog
Reserva
Os clientes podero fazer reserva de apartamento
Reserva
Os clientes podero cancelar a reserva
Reserva
Os clientes podero fazer alteraes de data da reserva
Reserva
Os cliente podero fazer consulta de reservas
Reserva
Criao de o Book de Reserva
Pagamento
O meio de pagamento da reserva sero por carto de

crdito
Apartamento
Os apartamentos devero ser cadastros
Apartamento
Os apartamentos so classificados por categoria
Cliente
Precisamos registrar os dados dos clientes
Product Owner (PO), responsvel por

elaborar e manter Product Backlog atualizado,
bem como priorizar seus itens.
Product Owner
Verso 17
16
Estria do Usurio (User Story):

O que uma estria (user story) ?
uma pequena descrio, que detalha um item
do Product Backlog.
Para que serve a Estria:

Uma estria ajuda no entendimento e tambm ,
utilizada como lembrete e para as atividades de
planejamento. Ele tambm permite fazer a
estimativa de velocidade da equipe e a durao da
Sprint. Geralmente a estimativa feita em pontos
(story points) ou horas/dias (dias ideais).
Como escrever uma estria:
Conversaes sobre a histria, entre os
desenvolvedores, clientes de modo a detalhar a o
item e esclarecer todas as dvidas sobre o que
deve ser feito.
Exemplos de Estrias do Usurio:
Titulo: Pagamento com Carto de Crdito
Prioridade: 1-Alta
Os clientes (hospedes) podero fazer o pagamento da estadia e dos

servios com Carto de Crdito.
Os carto aceitos so: Visa, Master e Amex.
Titulo: Exibir preo do produto
Prioridade: 3-Baixa
Quando um cliente passar um produto pelo leitor do scanner e o

cdigo de barra (cdigo do produto) for vlido o sistema dever
buscar o preo do produto e exibi-lo na tela do scanner
Titulo: Autenticao de usurio
Prioridade: 2-Mdia
O usurio dever fornecer uma identificao vlida (e-mail e senha), o

sistema dever autentic-lo de acordo com User Profile. Se autenticao
for positiva o usurio dever receber a autorizao de acesso.
Caso contrrio receber uma mensagem de identificao invlida
Verso 17
17
Estimativa* e o Planning Poker:

Para fazer estimativa de velocidade da equipe ou de durao da Sprint, antes
preciso o escrever as estrias do usurio.
O Planning Poker a prtica que ajuda na estimativa de uma estria ou
de uma tarefa.
Geralmente o Planning Poker usa uma escala de
pontos, que pode ser baseada no Fibonacci:
(1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala.
Jogando o Planning Poker:
Antes de comear o jogo, ou seja, definir os pontos para
as estrias, importante definir um valor de
referncia. Exemplo: Identificar a estria que pode ser
atribudo dois pontos, ento ela ser utilizada como
referncia para pontuao das demais estrias.
Pessoal, qual
estimativa para
essa estria...
5?
Product Owner
Equipe
Equipe
Na reunio de Planejamento da Sprint, a equipe joga o Planning Poker e

define a estimava de velocidade da equipe e a durao da Sprint.
Nota 1 Estimativa*
Para fazer as estimativa, voc deve levar em considerao outros aspectos alm da codificao, como por exemplo: testes
de aceitao, teste unitrios preparao do ambiente de teste e outras coisas que so necessrio e importantes (mesmo
que de baixo valor) para que voc entregue o software funcionando.
Verso 17
18
Artefato: Sprint Backlog

O Sprint Backlog uma lista de tarefas que equipe se compromete a fazer
em uma Sprint. A Sprint Backlog elaborada na segunda parte da
reunio de Planejamento da Sprint.
Para atingir a meta da Sprint a equipe dever fazer as tarefas da Sprint
Backlog.
Titulo: Precisamos registrar os dados dos clientes
Estria do Usurio:
Selected Product Backlog (itens selecionados do Product Backlog)
Prioridade: 1-Alta
Todos os dados do cliente dever ser registrado. A busca de cliente

dever ser fcil e intuitiva.
Quando os clientes esto registrado, ser possvel alterar os dados
se necessrio.
O cliente dever ter um status para que se possa definir quais
so os clientes ativos e os inativos
Pontos: 8
Tarefa:
Incluir novo
cliente
Cadastro
de Cliente
Sprint Backlog
consultar
cliente
alterar
cliente
Dicas para montar um bom Sprint Backlog:

1 Toda a equipe deve participar da elaborao da Sprint Backlog;
2 Faa uma definio de feito (DoD), veja o prximo slide;
3 Tente identificar todas as tarefas, lembre-se que algumas tarefas so puramente tcnicas, por
exemplo: realizao de Teste Unitrio.
4 Respeite o tempo para realizao desta atividade, pois a Reunio de Planejamento um timebox.
Verso 17
19
Definio de Feito (DoD):
Ao final de cada Sprint a equipe dever fazer uma entrega valor para o cliente
(PO e demais Stakeholders).
Segundo Manifesto gil, valor para o cliente igual a software
funcionando.
Logo para fazer tal entrega, na reunio de Planejamento da Sprint, ser
imprescindvel estabelecer a Definio de Feito.
Isto evitar problemas e frustraes futuras nas reunies de Reviso e
Retrospectiva da Sprint.
Definir claramente quando o

produto estar Feito:
Feito, para desenvolvedor:
- Encerrou a codificao...
Feito, para Analista de Teste
(Q&A):
- Quando ele encerrou o teste e
no encontrou nenhum bug...
Feito, para PO:
- Quando foi entregue...
Feito, para os usurios finais
e/ou clientes:
- Quando o software comeou a
funcionar em ambiente de
produo...
Evite: A sndrome dos 90% feito (pronto).

Verso 17
20
Artefato: Burndown
Exemplos de Burndown:
*Horas
Pois, ele representa o trabalho

restante sobre tempo, ou seja, ele
permite visualizar o progresso e/ou a
evoluo do trabalho executado pela a
equipe e a quantidade trabalho x tempo
(pontos) que ainda faltam para
completar a Sprint.
Atualizao do Burndown diria, isto
facilita a tomada de deciso, podemos
decidir em melhorar a produtividade da
equipe e/ou para mitigar risco da Sprint.
Tempo (dias)
Exemplo:
Atravs da leitura do Burndown
podemos decidir, que devemos
adicionar novas tarefas na Sprint
(velocidade da equipe est acima do
planejado, melhorando sua
produtividade) ou retirar tarefas (a
velocidade da equipe est abaixo do
planejado, caso no seja feita reduo
de tarefas a meta da Sprint estar
comprometida).
O ideal, neste caso, retirar as tarefas
que no afetem a meta da Sprint.
Se a meta for afetada pode-se tambm
decidir pelo cancelamento da Sprint.
Pontos
O grfico Burndown a principal

ferramenta de gerenciamento do
processo de desenvolvimento de
software.
Tempo (dias)
Burndown demonstra a produtividade da equipe

* Dias Ideais (Ideal Days), uma outra forma de fazer estimativa, ele baseado na durao de tarefas.
- Dias ou horas unidade bem definida, contudo o tempo ideal quase nunca igual ao tempo real...
Verso 17
21
Gesto Vista: Task Board:
Gesto Vista: D visibilidade e transparncia ao

desenvolvimento de software
Verso 17
22
Road Map: SCRUM

Viso do
Produto
Planejamento
da Sprint
Product
Backlog
Selected Product
Backlog
Sprint
Backlog
Tarefas
da Sprint
Reunio
diria
Equipe
Product
Onwer
facilita
ajuda
SCRUM
Master
facilita
Execuo da
Sprint
facilita
Reviso da Sprint
Produto
Verso 17
23
Estudo de Caso
baseado em fatos reais
Verso 17
24
Product Backlog: Sistema de Reserva On-Line
Nvel de
Prioridade
Categoria
Reserva
Os clientes podero fazer reserva de

apartamento
Reserva
Reserva
Os clientes podero fazer alteraes de data

da reserva
Reserva
Reserva
Pagamento
O meio de pagamento da reserva sero por

carto de crdito
Apartamento
Apartamento
Os apartamentos so classificados por

categoria
Cliente
Product Owner define os itens da Product Backlog e o nvel

de prioridade de cada item.
Scrum Master deve ajudar o Product Owner na elaborao

do Product Backlog.
Verso 17
25
Nvel de
Prioridade
Categoria
Reserva

apartamento
Reserva
Reserva
Os clientes podero fazer alteraes de data

da reserva
Reserva
Reserva
Pagamento

carto de crdito
Apartamento
Apartamento

categoria
Cliente
Scrum Master analisa o Product Backlog junto

com PO e ele explica, que para facilitar o plano de
construo do software, ser necessrio mudar a
prioridade dos itens do Product Backlog.
O PO aceita a sugesto e faz as mudanas.
A mudana de prioridade dos itens do backlog vai facilitar a definio

da release e suas iteraes (Sprints) e no plano de construo do
software.
Verso 17
26
Reunio de Planejamento da Sprint

Nvel de
Prioridade
Categoria
Estimativa
em pontos
Reserva

apartamento
Reserva
Reserva
Os clientes podero fazer alteraes de

data da reserva
Reserva
Os cliente podero fazer consulta de

reservas
Reserva
Pagamento

carto de crdito
Apartamento
Apartamento

categoria
Cliente
Reunio de Planejamento da Sprint (1a. Parte):

Participantes: PO, Equipe e SCRUM Master (facilitador)
Se for a primeira reunio o PO dever apresentar a viso

do produto, expectativa e prioridades.
Nesta reunio, PO dever definir uma meta para Sprint e falar
sobre quais so os itens so mais prioritrios do Product
Backlog.
A equipe realizar o planejamento do que dever ser entregue
no final da Sprint (de 2 a 4 semanas).
A equipe dever selecionar quais os itens sero feitos na
Sprint, resultando na Selected Product Backlog.
Verso 17
27
Viso inicial da primeira Release do Produto:

Sprint #1
Entrega 1
A Apartamento
A C
Cliente
Sprint #2
Releases
Entrega 2
Reserva
Pagamento
R P
Sprint #3
A C
Entrega 3
Book de
Reserva
R P
B
Produto
Como conhecedor do negcio, o PO fez uma sugesto de

como produto dever ser desenvolvido (Build Plan).
A sugesto ser apresentada a equipe SCRUM..
Verso 17
28
Reunio de Planejamento da Sprint

Nvel de
Prioridade
Categoria
Estimativa
em pontos
Reserva

apartamento
Reserva
Reserva
Os clientes podero fazer alteraes de

data da reserva
Reserva
Os cliente podero fazer consulta de

reservas
Reserva
Pagamento
O meio de pagamento da reserva sero

por carto de crdito
Apartamento
Apartamento

categoria
Cliente
Precisamos registrar os dados dos

clientes
Continuao (da 1. parte da reunio)

A equipe dever se preocupar em levantar mais detalhes dos itens
selecionados do Selected Product Backlog , escrever estrias
podem ser uma tcnica til para melhorar entendimento dos itens
selecionados (a).
Para estimar a velocidade da equipe, que necessria para
implementar os itens selecionados e durao da Sprint, ser
utilizadas as estrias para fazer as estimativas em pontos (ou
horas/dias) , atravs do Planning Poker. (b)
Legenda:
(a) pg: 31
(b) pg: 31
(c) pg: 32
Reunio de Planejamento da Sprint: (2a. Parte)

Participante: Equipe (e SCRUM Master - opcional)
E por fim as estrias sero divididas em tarefas, gerando o Sprint
Backlog. (c)
Decidindo que executar as Tarefas: Cada pessoa da equipe deve
escolher as tarefas da Sprint Backlog que deseja fazer.
Verso 17
Itens
selecionados
29
Fazendo Estimativa com Planning Poker:

Estria do Usurio:
Prioridade: 1-Alta


se necessrio.

Pessoal, qual
estimativa para
essa estria...
8
Product Owner
5?
Equipe
Equipe
Na reunio de Planejamento da Sprint, a equipe joga o Planning Poker

e define a estimava de velocidade da equipe, necessria para
implementas as estrias (na verdade as tarefas)..
Verso 17
30
Tarefas, quebrando a Estria...

As estrias so divididas (quebradas) em tarefas.
As tarefas devem compor a Sprint Backlog...
Selected Product Backlog (itens selecionados do Product Backlog)
Estria do Usurio:
Prioridade: 1-Alta

se necessrio.
Pontos: 8
Tarefa:
Incluir novo
cliente
Cadastro
de Cliente
Sprint Backlog
consultar
cliente
alterar
cliente
Verso 17
31
Check List do Planejamento da Sprint:
Primeira parte da reunio:

1.1 A viso do produto foi completamente
entendida;
1.2 Prioridade dos itens do Product Backlog
definida;
1.3 Os itens do backlog que sero feito na Sprint
so escolhidos;
1.4 A meta da Sprint (o que deve ser entregue no
final da Sprint) foi estabelecida ;
Segunda parte da reunio:
2.1 Os itens so detalhados atravs da escrita de
estrias;
2.2 Estimativa em Pontos estabelecida. (as
estrias so utilizadas para fazer as estimadas
2.3 - As estrias so quebradas em tarefas;
2.4 - Sprint Backlog definido;
2.5 As pessoas da equipe definem entre elas quem
vai fazer as tarefas do Sprint Backlog.
Outros itens (fora da reunio do planejamento,

mas necessrios para comear a Sprint):
3.1- Preparar o Task Board quadro de tarefas
(tambm chamado de quadro de Kanban)
3.2 - Preparar o grfico Burndown
3.3 - Fazer o Kick-off (Sprint #0)
Verso 17
32
Task Board: Sprint #1 - Dia 0:

Sprint Backlog*
Em Execuo
Concludo
BurnDown
Cadastro de
Categoria de
Apartamentos
Cadastro de
Apartamentos
Cadastro de
Clientes
Nota:
Optamos por apresentar somente as atividades e no as tarefas, somente por questo de facilitar a apresentao.
Verso 17
33
Burndown. Sprint #1 - Dia 0:

Por que 3 dias ?
a primeira vez que a equipe utiliza o SCRUM para o
desenvolver um software, logo ela no tem nenhum
histrico de desenvolvimento, que possa ser usado para
definir a quantidade de tempo que ela levar para fazer 23
pontos.
Contudo, a equipe, depois de muita discusso, chegou ao
entendimento que seria preciso de 3 dias para fazer todas
as tarefas do Sprint Backlog.
23
Pontos
30
20
10
1 dia
2
dia
Tempo
3 dia
Estimado
Real
Verso 17
34
[Kick-off] Sprint #1 - Dia 0:

Sprint Backlog
Cadastro de
Categoria de
Apartamentos
Cadastro de
Clientes
Cadastro de
Categoria de
Apartamentos
Cadastro de
Apartamentos
SCRUM Master
?
Cadastro de
Clientes
Equipe
Verso 17
35
Task Board da Sprint #1: Dia 1 (aps o Kick-off):

Sprint Backlog
Em Execuo
Concludo
BurnDown
Cadastro de
Categoria de
Apartamentos
Cadastro de
Apartamentos
Cadastro de
Clientes
Verso 17
36
Burndown da Sprint: #1 Final do Dia 1:
23
Pontos
30
20
10 pontos
13
10
1 dia
2
dia
Tempo
3 dia
Estimado
Real
Verso 17
37
A Primeira Reunio Diria:

Sprint Backlog
Cadastro de
Categoria de
Apartamentos
OK
Cadastro de
Apartamentos
Problemas no
Servidor de
Teste
Cadastro de
Apartamentos
SCRUM Master
Cadastro de
Clientes
Equipe
Check List Responder 3 questes:
O que foi feito ontem?
O que voc planeja fazer hoje?
Voc tem algum impedimento?
Verso 17
15
minutos
38
Task Board da Sprint: #1 Aps primeira reunio

Sprint Backlog
Em Execuo
Concludo
BurnDown
Cadastro de
Categoria de
Apartamentos
Cadastro de
Apartamentos
Problemas no
Servidor de
Teste
Cadastro de
Clientes
Verso 17
SCRUM Master
dever resolver
(remover) este
impedimento
39
Task Board da Sprint: #1 Impedimento

Sprint Backlog
Em Execuo
Concludo
BurnDown
Cadastro de
Categoria de
Apartamentos
Cadastro de
Apartamentos
Problemas no
Servidor de
Teste
Cadastro de
Clientes
SCRUM Master
dever resolver
(remover) este
impedimento
SCRUM Master
Cabe ao SCRUM Master
remover todos os impedimentos,
identificados e demonstrados no Task Board (quadro de tarefas), para
que estes no afetem o desempenho da equipe. Caso contrrio, o
impedimento poder comprometer a meta e a entrega de valor que deve
ocorrer no final da Sprint.
Aps remoo do impedimento o SCRUM podemos registrar em base de
conhecimento a causa raiz do impedimento, esta informao dever ser
utilizada para melhorar o processo, logo ser discutida na Retrospectiva
da Sprint.
Problemas no
Servidor de
Teste
O que um impedimento ?
Impedimento tudo aquilo que impede a equipe de realizar
seu trabalho e atingir a meta da Sprint.
Um impedimento pode ser um problema de rede, falhas no
servidor, falta de servidor para testes, a lentido do banco
de dados do ambiente de teste ou falta de informao
para implementao de uma tarefa.
Verso 17
40
Burndown da Sprint: #1 2. Dia:
23
Pontos
30
20
10 pontos
13
10
8
pontos
5
1 dia
2
dia
Tempo
3 dia
Estimado
Real
Verso 17
41
A Segunda Reunio Diria

Sprint Backlog
Cadastro de
Categoria de
Apartamentos
Cadastro de
Apartamentos
OK
OK
Cadastro de
Clientes
Cadastro de
Apartamentos
OK
SCRUM Master
Cadastro de
Clientes
Equipe

O que voc planeja fazer hoje?
Verso 17
15
minutos
42
Task Board da Sprint #1 - 2. Dia:

Sprint Backlog
Em Execuo
Concludo
BurnDown
Cadastro de
Categoria de
Apartamentos
Cadastro de
Apartamentos
Cadastro de
Clientes
Verso 17
43
Burndown da Sprint #1 - 3. Dia
23
Pontos
30
20
10 pontos
13
10
8
pontos
5
5
pontos
1 dia
2
dia
Tempo
3 dia
Estimado
Real
Verso 17
44
A Terceira Reunio Diria:
Sprint Backlog
Cadastro de
Categoria de
Apartamentos
Cadastro de
Clientes
OK
OK
Cadastro de
Apartamentos
OK
Cadastro de
Clientes
OK
?
SCRUM Master
Equipe

Verso 17
15
minutos
45
Task Board da Sprint #1 - 3. Dia:

Sprint Backlog
Em Execuo
Concludo
BurnDown
Cadastro de
Categoria de
Apartamentos
Cadastro de
Apartamentos
Cadastro de
Clientes
Verso 17
46
Reviso da Sprint:
Reunio da Reviso da Sprint
Product
Owner
4
horas
Equipe
SCRUM Master
Equipe apresenta que foi produzido e faz entrega para PO, que avalia o
valor da entrega. PO pode aceitar ou rejeitar a entrega do produto.
Verso 17
47
Reunio Retrospectiva da Sprint
impedimentos
As retrospectivas so a essncia do conceito de

Inspeo e Adaptao.
Problemas no
Servidor de
Teste
Velocidade
da equipe...
??
??
SCRUM Master
Equipe
3
horas
Equipe discute o que deu errado e que deu certo... O que precisa ser
melhorado para a prxima Sprint
Verso 17
48
Lies Aprendidas, o que deve melhorado para a prxima Sprint
OK
Cadastro de
Categoria de
Apartamentos
Pontos de
Ateno
Velocidade da
equipe
Ser necessrio
mais ateno na
hora de estimar
as estrias
Verso 17
=
Atitude:
Para uma equipe (time)
SCRUM funcionar ser
necessrio mudana de
atitude, caso contrrio
isto poder afetar
o desempenho da equipe
Cadastro de
Apartamentos
Cadastro de
Clientes
O Que Deve
Ser Melhorado
Impedimentos:
Problemas no
Servidor de
Teste
Planejamento:
Prestar ateno na hora
do planejamento da
Sprint, para identificar
se todos os recursos
necessrio esto
disponveis
49
Nova Sprint (Sprint #2):

Entregue
Sprint #1
Entregada 1
Nova Sprint
A Apartamento
Cliente
A C
Sprint #2
Release
Entrega 2
Reserva
Pagamento
R P
Sprint #3
A C
Entrega 3
Book de
Reserva
R P
B
Produto
Comear a Sprint # 2, fazer o Planejamento da Sprint:

- Definir os itens selecionados do Product Backlog
- ...
Verso 17
50
Vendendo a idia do SCRUM
Verso 17
51
Vendendo a idia do SCRUM:

Agora discutiremos a parte, que para muitos
considerada a mais difcil e as vezes quase
intransponvel.
Que vender a idia do SCRUM (do uso do
SCRUM) para seu chefe, dono da empresa,
gerente de TI e etc..
Poderamos reunir muitos argumentos para fazer

esta venda, todavia, acredito que a melhor forma vender os resultados que
podem ser alcanadas com a adoo das prticas SCRUM.
O que NO VENDER:
- No tente vender o SCRUM (ou qualquer outra coisa) que voc no acredite...para
vender ou influenciar pessoas, voc tem que ter comprado a idia primeiro.
- Jamais venda aquilo que no se possa entregar.
No venda o SCRUM pelo SCRUM, venda os resultados (veja a lista abaixo) que voc
e sua equipe podero atingir utilizando o SCRUM.
No tente vender a idia do SCRUM por puro modismo (somente por que na empresa
em que seus amigos trabalham esto usando SCRUM e voc no quer ficar de fora
desta moda)
No tente vender a idia sem fatos (veja as quais empresas que j utilizam o SCRUM,
obtenha dados destas empresas, por exemplo: se os clientes esto mais satisfeitos,
se produtividade aumentou, se as pessoas esto mais motivadas, se os custos
reduziram e se houve de fato uma diminuio no prazo de entrega dos produtos )
O que os chefes gostam de comprar:
Aumento de produtividade (sem a contratar novas pessoas), para muitos chefes isto
sonho encantado;
- Reduo no prazo de entrega de produtos;
- Reduo de custo;
- Busca pela excelncia da qualidade, ou seja, melhorar a qualidade dos produtos e/ou
servios continuamente sem a necessidade de comprar novas ferramentas;
- Pessoas trabalhando com foco em resultado;
- Comear qualquer coisa, sem ter que fazer investimento inicial;
- A sensao de controle absoluto (todo chefe gostaria de saber o que seu o pessoal
esta fazendo..) . O Quadro de Tarefas e Product Backlog produzem esta sensao,
pois tudo que imagina para controlar, est vista.
- Clientes mais satisfeitos
- E por fim: A liberdade de fazer mudanas de requisitos, mesmo que a fase de
desenvolvimento esteja em estgio avanado.
Verso 17
52
Como comear:
Projeto Piloto:
Selecione um ponto de partida, escolha um projeto piloto. Mas,
tome muito cuidado com projeto piloto. Pois, ele deve ser bemsucedido e deve ter alguma importncia para o negcio, mas no
devem ser deve ser critico ao negcio (de misso critica).
O projeto piloto deve ser de curta durao (inferior a trs meses).
Os prximos projetos:
Os prximos projetos (trs, que um nmero mgico) so uteis
para equipe aprender as prticas geis, ganhar maturidade e
mensurar a velocidade.
As pessoas:
Ser necessrio ter SCRUM Master e Product Owner
Experientes.
Fornea treinamento a todas as pessoas da equipe, simule
bastante antes de comear, tenha certeza que todos entenderam as
prticas do SCRUM.
A Equipe:
A equipe deve ter auto-gesto, ser auto-organizada e as pessoas
deve ser multidicisplinar.
Prepare as ferramentas:
- Task Board (Quadro de Tarefas) extremamente importante para
dar visibilidade ao desenvolvimento de software e para Gesto
Vista;
- Post-its (...),
- Canetas e pinceis,
- Cartas para Planning Poker;
- Cartes para estrias;
- etc
Estimativa: Inicialmente voc pode fazer as estimativas baseada
em horas ou dias (dias ideais), pois, ela mais fcil para equipe
entender. Quando a equipe tiver com mais, comece usar pontos
(Story points).
Nos primeiros projetos considere uma ajuda externa, a contratao
de Agile Coach poder ser bastante til.
Considere Pessoas, Processos, Tecnologia e Ferramentas.
Lembre-se que a Colaborao um fator-chave para o sucesso;
Esteja preparado para viver o desafio.

Verso 17
53
Mini-Vocabulrio
Sprint = iterao
Product Backlog = Lista de requisitos funcionais
de um produto (com o nvel de prioridade definido)
Product Owner = Analista de Negcio ou Especialista de Negcio
SCRUM Master = Lder servidor, se papel muito prximo de tcnico de

futebol ele trabalha para que a equipe produza resultado, mas no entra
em campo para jogar.
Task board = Quadro de tarefas
Impedimento = tudo aquilo que pode impedir a equipe de

realizar seu trabalho, seja falta de informao ou falta de recursos de infraestrutura.
Execuo das prticas do SCRUM = muito parecido com o velho e
infalvel PDCA.
Timebox = tempo (horas/ias) bem definido e imutvel, sonho de todo
gestor de projeto.
Burndown = um grfico que ele representa o trabalho restante sobre
tempo
Equipe SCRUM = Equipe engajada, auto-gesto

e multifuncional (pig dream team).
Verso 17
54
Referncias
Agile Project Management with Scrum
Autor: Ken Schwaber
Agile Software Development with Scrum
Autor: Ken Schwaber e Mike Beedle
The Enterprise and Scrum

Autor: Ken Schwaber
Agile Retrospectives: Making Good Teams Great Autores: Esther Derby, Diana Larsen e Ken Schwaber
Jeff Suttherland:
http://jeffsutherland.com
Ken Schwaber:
http://www.controlchaos.com
www.mountaingoatsoftware.com/scrum
www.scrumalliance.org
www.mountaingoatsoftware.com/scrum-a-presentation
Verso 17
55
SCRUM (em nica pgina)
Verso 17
56
SCRUM. Rugby
SCRUM no jogo de
Rugby:
A formao fixa chamada

de Scrum, os fowards,
que um conjunto de
oito jogadores
abraados, realizam
uma fora onde o
objetivo empurrar o
outro time.
Essa jogada s eficaz
quando os oito
fowards fazem fora
ao mesmo tempo e na
mesma direo, fazendo
assim que o vetor
resultante, de suas
foras individuais, seja
maior que o do time
adversrio e possa
assim pegar bola.
Verso 17
57
Notas:
Marcas Registradas:
Todos os termos mencionados e reconhecidos como Marca

Registrada e/ou comercial so de responsabilidade de seus
proprietrios. O autor informa no estar associada a nenhum produto
e/ou fornecedor apresentado neste material. No decorrer deste,
imagens, nomes de produtos e fabricantes podem ter sido utilizados,
e desde j o autor informa que o uso apenas ilustrativo e/ou
educativo, no visando ao lucro, favorecimento ou desmerecimento
do produto/fabricante.
Melhoria e Reviso:
Este material esta em processo constante de reviso e melhoria, se
voc encontrou algum problema ou erro envie um e-mail para ns.
Criticas e Sugestes:
Ns estamos abertos para receber criticas e sugestes que possam
melhorar o material, por favor envie um e-mail para ns.
Imagens:
Google, Flickr e Banco de Imagem.
Rildo F dos Santos (rildo.santos@etecnologia.com.br)
Verso 17
58
Licena:
Verso 17
59
SCRUM Experience
www.etcnologia.com.br
Rildo F Santos
(11) 9123-5358
(11) 9962-4260
Verso 17
rildo.santos@etecnologia.com.br
@rildosan
http://www.rildosan.com/
verso: 17

Scrumexperienceotutorialscrumv16 091124165357 Phpapp01 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Scrumexperienceotutorialscrumv16 091124165357 Phpapp01 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

SCRUM Experience = Tutorial SCRUM

Rildo F. Santos, CSM, CSPO

SCRUM Experience = Tutorial SCRUM

Foi instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java na Sun

Tem forte conhecimentos de Gesto de Negcio (Inteligncia de Negcio, Gesto por

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

Trabalho com desenvolvimento de software a quase 15 anos

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

SCRUM um Mtodo GIL para desenvolvimento de software

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

Princpios por trs do Manifesto gil:

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

Como ser gil:

Como ser gil ?

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

O que uma Sprint ?

O conceito de timebox aplicado as cerimnias (reunies) do

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

No existe Bala de Prata:

SCRUM no a Bala de Prata:

Veja Lei F. Brooks,

O SCRUM no a soluo completa para os problemas de produtividade,

No existe soluo mgica para problemas complexos

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

Algumas empresas que esto usando SCRUM:

Quais empresas esto

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

Planejamento da Sprint Product Backlog

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

Product Owner, responsvel por:

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

A equipe Scrum formado por pessoas comprometidas em realizar as tarefas

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

SCRUM Experience = Tutorial SCRUM

Reunio Diria (15 minutos)

Esta reunio acontece no final da Sprint, opcionalmente outras

rildo.santos@etecnologia.com.br | @rildosan | www.etecnologia.com.br

Artefato: Product Backlog

SCRUM Experience = Tutorial SCRUM

Descrio do Item Backlog

Os clientes podero fazer reserva de apartamento

Os clientes podero cancelar a reserva

Os clientes podero fazer alteraes de data da reserva

Os cliente podero fazer consulta de reservas

Criao de o Book de Reserva

O meio de pagamento da reserva sero por carto de

Os apartamentos devero ser cadastros

Os apartamentos so classificados por categoria

Precisamos registrar os dados dos clientes