Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE

SCRUM
Transformando equipes em TIMES COM
CONSTANTE ENTREGA DE VALOR AO CLIENTE

©2009 - Hélio Medeiros e Germano Carvalho

Quem somos ?

Hélio Medeiros
Analista de Sistemas
SINFO - UFRN

Blog: http://heliomedeiros.com
Email: helio.cabralmedeiros@gmail.com ©2009 - Hélio Medeiros e Germano Carvalho

Quem somos ?

Germano Carvalho
Analista de Sistemas
Unimed Natal


NOSSO SOFTWARE
FUNCIONA ?


Será
mes ?
mo ?


ENTÃO OS PROJETOS DE
SOFTWARE FUNCIONAM ?


? !


O MODELO ANTIGO NÃO
FUNCIONA !!!


QUE TAL UM NOVO MODELO ?
PRONTO PARA A PROPOSTA !!!


JET OS TRE SS !!!
PRO OS S
MEN
COM


QUE REALM ENTE FUNCIONEM !


ONDIZEM COM AS NECESSIDADES
QUE C


DE FORM A ÁGIL E PRODUTIVA


Nossa Product Backlog

Parte 1 - Metodologias Ágeis
Parte 2 - Conhecendo o Scrum
Parte 3 - Experimentando agilidade com Scrum


Nosso Sprint Backlog

1 Metodologias Ágeis


Realidade da AGILE ?

Será que vai vingar ?
Será que não vai vingar ?
Vale a pena investir nisso?
Caso eu invista, conseguirei aproveitar algum
conhecimento ?



200 equipes

entrevista fornecida para o Application Development Trends, Gabrielle Beneﬁeld - diretora de métodos e práticas do Yahoo!


a
a rlos Silveir
Antônio C


Parte 1 - Metodologias Ágeis

Realidade da AGILE;

Por que precisamos de uma metodologia?

Introdução às metodologias ágeis;


Precisamos de metodologia ?
Como escolher uma ?

Gato de Cheshire.
Alice no país das maravilhas, de Lewis Carroll

Como escolher uma ?

ONDE se aplica
O QUE inﬂuencia
Quais as visões históricas empregadas aos projetos;
Qual o propósito de um processo de desenvolvimento;
Quais a estatísticas caóticas para projetos de software;


O que é projeto ?
Apenas 3 décadas... mais várias visões diferentes

“Um projeto é um problema
agendado para solução”

Dr. Joseph M. Juran
O "pai" da qualidade, criador do
princípio de pareto (80-20)

“Um projeto é uma coleção de valor
agendada para realização”
David J. Anderson
Criador do FDD e uma das maiores
mentes de Agile mundial


O que é projeto ?
Composição de um ambiente de um projeto de software


O que é projeto ?
Exemplo de inﬂuência causada pelos itens do ambiente de projeto

2ª
SEXTA-FEIRA

CULTURA
{

ESPOSA JAPONESA
CARDÁPIO JAPONÊS
TRADIÇÕES JAPONESAS
> MANTER SO COSTUMES


O que é projeto ?

encontrar seu amigo
Steve... vegetariano...
na 2ª sexta e pedir emprego em
um jantar... NA SUA CASA...
FICAR DESEMPREGADO PODE SER BEM DIFÍCIL?
acontece...

O que é projeto ?


O que é projeto ?

Eu conheço algum prato vegetariano ?
Eu tenho utensílios para preparar estes pratos ?
Será que minha esposa possui as técnicas
necessárias ao preparo dos pratos ?
O que será que minha família está pensando
enquanto a estas mudanças ? Estão felizes ?
Receptivos ? Colaborativos ?


O que é projeto ?
Características dos componentes

Pessoas
- Conhecimento e habilidades
- Motivação e comprometimento
-Reconhecimento
Processos
- Disciplina e coordenação
-Crescimento
- Gerenciamento
- Padronização
- Institucionalização

Cultura
- Personalidade coletiva
- Risco X Segurança Ferramentas
- Ética - Produtividade
- O “jeito de ser” da empresa - Controle
- Eﬁciência
- Automação


Atividade
Analisando os componentes de um contexto qualquer

Escolha um contexto qualquer e
descreva resumidamente:

1. Que pessoas estão envolvidas ?
2. Quais processos são observáveis ?
3. Quais tecnologias são aplicadas ?
4. Como a cultura inﬂuencia ou é
inﬂuenciada ?


Como categorizar a complexidade de um projeto de software ?

Ogunnaike and Ray:
Process Dynamics, Modeling and Control


O Chaos Report

Falhou Necessitou adequações Bem sucedido

100%
33% 35% 33%

75%

43% 46% 52%
50%

25%
24%
19% 15%
0%
2004 2006 2009


O Chaos Report

Aumento nos custos
Aumento no tempo
Alteração de funcionalidades
70

35

0
Adequações necessárias


O Chaos Report

Isso signiﬁca que, se fabricássemos aviões...

32%
pousariam sem
problemas

44%
pousariam com
problemas

24%
cairiam


Quais itens analisar na escolha ?

COMO lidar com REQUISITOS;

COMO melhorar a COMUNICAÇÃO;

COMO estimar as ATIVIDADES;

COMO entregarmos os PRODUTOS;

COMO difundir o CONHECIMENTO;

QUAL o ciclo de vida do PRODUTO;

COMO organizar nossa PRODUÇÃO;

COMO conseguiremos QUALIDADE;

Atividade
Por que precisamos de uma metodologia?

Cite quais são os principais
p ro b l e m a s n o p ro c e s s o d e
desenvolvimento de software que
você esteja envolvido.

Cite o que você espera de uma
metodologia para desenvolvimento
de software.


Introdução às abordagens ágeis
O que NÃO é agilidade?


O que é agilidade?

“Agilidade é a habilidade para criar e responder à
mudança, para lucrar num ambiente turbulento de
negócios.”

“Agilidade é a habilidade para equilibrar
ﬂexibilidade e estabilidade.”
Jim Highsmith
Um dos principais escritores sobre
AGILE e criador da ASD.


Os princípios


O manifesto Ágil

Kent Beck, Jim Highsmith, Alistair
Cockburn, Martin Fowlor, Ken
Shwaber e Jeff Sutherland;


O manifesto Ágil

Indivíduos e a interação
mais que processos e ferramentas
entre eles

Produto em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

http://agilemanifesto.org ©2009 - Hélio Medeiros e Germano Carvalho

Desenvolvimento iterativo

custo fixo

conjunto de funcionalidades;

priorizado pelo cliente

podemos perder funcionalidades, nunca
datas;

prioridades no “final da lista” podem ficar
de fora;

Flexibilidade está nas funcionalidades,
não no prazo ou no custo;



Produto

release 1 release 2 release 3 ... release n
novo release a cada X meses

iteração 1 iteração 2 iteração 3 iteração 4 ...
novo iteracao a cada X semanas



O Release 1 terá as seguintes
Produto funcionalidades:

- Funcionalidade A - Funcionalidade G
- Funcionalidade B - Funcionalidade H
release 1 - Funcionalidade C - Funcionalidade I
- Funcionalidade D - Funcionalidade J
- Funcionalidade E - Funcionalidade L
- Funcionalidade F - Funcionalidade Z

iteração 1 iteração 2 iteração 3 iteração 4 ...
Func. B
Func. A Func. C Func. D
Func. F
Func. E Func. H Func. I
Func. J
Func. G Func. L
Func. Z

O ciclo de vida de projetos ágeis

Exploração
Visão

Funcionalidades Prontas

Especulação
Adaptação

Visão do Produto

Fechamento
Produto Final


2 Conhecendo o Scrum


O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em
primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que se
tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;


O que é Scrum ?
Depende de onde você está


O que é Scrum ?
O origem do Scrum

Criada no início da década de 1990
Estados Unidos.

TA nt
YO eme
TO nag
a
nM
Lea


O que é Scrum ?
Scrum NÃO é uma bala de prata!


O que é Scrum ?
A objetividade do Scrum

papéis bem diﬁnidos, e é de fácil adaptação;
SCRUM APONTA OS ERROS !
Um dos aspectos positivos do Scrum é a sua adaptabilidade,
portanto, o conhecimento das suas práticas é extremamente
importante, por permitir a aplicação das mesmas de forma
variada.


O que é Scrum ?
Problemas com a adaptabilidade

Sprint Planning Meeting
Um dia inteiro sem produção ?

Daily Meeting
Horários ? Para que?


O que é Scrum ?
Liderança-colaboração SIM ! Comando-controle NÃO !

Comando - Controle

Liderança - Colaboração

Comando-Controle é muito lento porque:
✓Não permite processar informações rapidamente;
✓Não permite tomar decisões rapidamente;
✓Não envolve ou motiva ao trabalho;
✓Não propicia responsabilidade diária sobre o andamento à equipe;

Atividade
A arte do possível

Explore a diferencça entre planejar uma viagem se
cada sentença começa com:

“ Sim, mas ”

“ Sim, e ”


O ciclo de vida do SCRUM?

© 2007 Alexandre Magno - As Armadilhas do Scrum



O ciclo de vida do Scrum é baseado em iterações bem
deﬁnidas de duas a quatro semanas, chamadas SPRINTS.
Antes de cada Sprint, realiza-se uma reunião de
planejamento ( Sprint Planning Meeting ) em que o time
(Team Members) de desenvolvimento tem contato com o
cliente ( Product Owner ) para priorizar o trabalho que
precisa ser feito, selecionar e estimar as tarefas que o time
pode realizar dentro da Sprint.
A próxima fase é a execução da Sprint.



Durante a execução da Sprint, o time controla o andamento
do desenvolvimento realizando Reuniões Diárias ( Daily
Meeting ) de não mais de 15 minutos de duração, e
observando o seu progresso usando um gráﬁco chamado
Sprint Burndown.
Ao ﬁnal de cada Sprint, deve-se realizar uma Reunião de
Revisão ( Sprint Review ), em que o time demonstra o
produto gerado na Sporint e valida se o objetivo foi atingido.
Logo em seguida, realiza-se a Reunião de Retrospectiva
( Sprint Retrospective ), uma reunião de lições aprendidas,
com o objetivo de melhorar o processo, time eou produto
para a próxima Sprint.

Os papéis no Scrum
Pigs e chickens são papéis no Scrum ?


Os papéis no Scrum
Pigs e chickens são papéis no Scrum ?

Os termos pig ( porco ) e chicken ( galinha ) são utilizados
em Scrum de forma informal.
Pig: Alguém que ocupa um dos três papéis do Scrum ( Team
memeber, Product owner, Scrum Master) e tem um total
comprometimento com o projeto.
Chicken: Alguém que tem interesse no produto a ser gerado,
mas não ocupa nenhum papel formal do Scrum.


Os papéis no Scrum
O Product Owner (PO)

O Product Owner representa o cliente ou
patrocinador do projeto, e faz parte do time
que entregará o produto.


Os papéis no Scrum
O Product Owner (PO)

Deﬁne funcionalidades
Faz o plano de Release
Product vision
ROI
Priorização
Ajusta escopo
Aceita ou rejeita um Sprint
Disponibilização técnicos de domínio


Os papéis no Scrum
O Scrum Master (SM)

O Scrum Master, diferentemente dos
gerentes de projeto na maioria das práticas
e metodologias, difere do tradicional
“comando e controle”. Em Scrum, um SM
trabalha com e, principalmente, para o
time.


Os papéis no Scrum
O Scrum Master (SM)

Responsável pelo processo
Gerenciamento
Valores e princípios
Remove impediemntos
Garante a produtividade
Colaboração entre papéis
Protege o time de Interferências


Os papéis no Scrum
Os membros do time

Os membros do time são pessoas que
estão comprometidos a fazer o trabalho
necessário para atingir a meta de uma
Sprint.
Em Scrum não temos arquitetos,
testers ou programadores, temos sim,
membros com perﬁs de arquiteto, de
tester ou de programador... mas que
podem atuar em papeis secundários
para garantir o alcance da meta.


Os papéis no Scrum
Os membros do time

Suas responsabilidades são:

Deﬁnir a meta do Sprint;
Estar comprometido com o trabalho
Colaborar com outros membros do time
e ajudar a torná-lo auto-gerenciado;
Estimar itens do backlog de forma
realista;
Participar das reuniões diárias;
Compartilhar conhecimento com a equipe
Manifestar impedimentos;


Os papéis no Scrum
Fluxo simples

Coloca itens
(priorizados) Pega itens

Product owner
Time
Product Backlog
Coloca

Serve O que sobrar...
devolve

Scrum Master Sprint Backlog

O que é Scrum?
O conceito de Sprint: Entregando frequentemente software de
valor;
primeiro plano;
tornem grandes;

O conceito de Sprint
Característivas

2, 3 ou 4 semanas;
Frequentemente entregando algo de valor para o cliente;
Time multi-funcional com não mais que oito membros;
Cada Sprint deve ter uma meta específica que represente o
desejo do cliente para aquele time-box específico;
Os membros do time da Sprint são os responsáveis por
estimar os itens que compõem o desejo do cliente e dar a
palavra final sobre o que será possível ser desenvolvido
naquele time-box;


Composição

Planejamento ( Sprint Planning Meeting ):
Daily Scrum
Execução ( The Sprint ):
Revisão ( Sprint Review ):
Retrospectiva ( Sprint Retrospective ):


Cancelamento

O cancelamento de um Sprint antes de seu termino acontece
nas seguintes condições:
O time pode cancelar se sentir que não conseguirá atingir a
sua meta, lembrando que cancelamentos consecutivos são
falhas apontadas pelo Scrum, qual o problema ?
Gerentes podem cancelar um Sprint caso fatores externos
inﬂuenciem diretamente no valor da meta do Sprint;
Caso um Sprint seja cancelado deve ser iniciado o
planejamento do próximo Sprint imediatamente;


O que é Scrum?
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente
em primeiro plano;
tornem grandes;


Product Backlog
Entendendo

O Product Backlog representa em ítens a visão do produto
e é o primeiro passo a ser dado em todo projeto Scrum;
O Product Backlog existirá por todo o ciclo de vida do
projeto, e não da Sprint.
Este é regularmente atualizado pelo Product Owner para
reﬂetir mudanças e necessidades do cliente, mudanças
estratégicas ou tecnológicas, novas idéias...
O Product Backlog pode ser composto por diferentes tipos
de itens: funcionalidades, exploração técnica, estudo,
documentação, bugs, requisitos de desenvolvimento...
Só exisite um Product Backlog durante todo o projeto.

Product Backlog
A física do Product Backlog

Alta Prioridade

Cada Sprint implementa os requisitos
de prioridade mais alta

Cada novo item é priorizado e
inserido pelo PO a qualquer
momento

Todos os itens podem ser
repriorizados pelo PO

Itens podem ser removidos
pelo PO a qualquer momento
Baixa Prioridade

Product Backlog
Exemplo

PRODUCT BACKLOG
P R OD U C T BAC K L OG

Id Item Estimativa Prioridade
1 Refatorar o banco de dados 32 10
2 Relatório de Vendas por unidade e período 8 8

3 Suporte a cartão de crédito Visa no processo de Vendas 13 9
4 Relatório Gerencial com Estatísticas de Vendas 5 7

5 Alterações na tela de entrada do sistema 5 6

6 Estudar nova versão da framework de mapeamento O/R 5 5

7 Consulta parametrizada de Vendas 3 4

8 Criação do Help 13 4

9 Implementar internacionalização 8 2
Total 92 6


Regras

A Sprint Planning Meeting ou Reunião de Planejamento, é dividida
em duas partes, e entra em cena no início de cada Sprint.

Além de todos os comprometidos (PO, SM e Time), alguns
envolvidos podem ser convidados a participar em determinados
momentos da reunião, desde que agreguem valor à mesa e
tenham seu convite aprovado pelo Product Owner.


Regras

Pela prática, é percebido que a duração desta reunião segue
a seguinte tabela:

DURAÇÃO
Sprint SPM #1 SPM #2
4 semanas 4 horas 4 horas


SPM #1

Na primeira parte, o Product Owner e o time, sendo facilitados
pelo Scrum Master, realizamuma revisão no Product Baklog,
discutindo sobre o propósito e metas de cada item e dando a
oportunidade para que o PO exponha seus desejos. O time
seleciona os itens que acredita que possam ser desenvolvidos
na próxima Sprint e deﬁne a meta.
PRODUCT BACKLOG
P R ODUCT B AC K L OG

Id Item Estimati Priorida
va de
Meta do Sprint:
1 Refatorar o banco de dados 32 10
2 Relatório de Vendas por unidade e período 8 8 Refatorar o banco de dados e
implementar relaórios de vendas
3 Suporte a cartão de crédito Visa no 13 9
processo de Vendas necessáirios para as tomadas de
4 Relatório Gerencial com Estatísticas de 5 7
decisões ﬁnais.
Vendas
Total 58 9


SPM #1

Velocidade é uma medida de
produtividade do time;
Esta medida representa a taxa de trabalho
que o time conseguiu completar durante
um Sprint;
E serve de guia para o planejamento de Sprints. Por exemplo,
se na Sprint anterior o time foi capaz de completar 55 pontos,
esta quantidade de trabalho realizado passa a ser a velocidade
do time e contribuirá durante o planejamento do próximo sprint;
Serve de guia para o planejamento de Releases e progresso de
projeto. Ex.: Temos um Product Backlog de 165 pontos.

SPM #1

Product Backlog

Selecionar Sprint Backlog
Como? Não sei nossa velocidade

Executado com 13
Mini-Sprint Backlog
pontos ( ou X horas)

Sprint Backlog
Velocaidade Inicial: 34
pontos ( ou x * 3 horas )

Atividade
Jogo da Velocidade

Quantas bolas de tênis você e
seu time conseguem colocar
no mochila em 2 minutos ?


SPM #1

Durante esta reunião o Product
Owner ainda pode realizar alterações
na priorização de itens;
Deve se discutir também sobre
estimativas iniciais ou revisão/
adaptação da estimativa dos itens;
O esforço estimado entre os itens
selecionados deve ser negociado
entre o time e o PO, sempre
praticando o bom senso;


SPM #1

Existem diversas técnicas de
estimativas que podem ser utilizadas
em projetos Scrum. O Planning Poker
é uma das mais populares, onde
utilizam-se cartas numeradas
seguindo a tabela de ﬁbonacci.


Planning Poker...?

O Planning Poker:
vem sendo a melhor técnica utilizada em projetos que
utilizam processos ágeis;
combina opinião de especialistas, analogias, bom senso e
uma forma agradável para se gerar estimativas;
envolve todos os perﬁs de membros (programadores,testers,
DBAs, analistas, designers entre outros);
utiliza-se dos números da sequência de Fibonacci;
deve ser aplicado para qualquer novo Item;


Como funciona o Planning Poker ?

Cada participante deve possuir o seu conjunto de cartas
contendo os valores válidos, de acordo com a escala adotada;
Para cada Product Backlog Item a ser estimado, o facilitador
(normalmente o Product Owner ou Especialista de Négocio)
deve realizar uma breve descrição;
Após todas as dúvidas sobre o item serem respondidas, cada
membro do time deve escolher uma carta representando a sua
estimativa. A carta selecionada não deve ser vista pelos outros
membros do time enquanto todos ainda não tenham
selecionado a sua;

Estimating & Planning - Mike Cohn


Todos devem, ao mesmo tempo,
mostrar sua carta de estimativa;
Se as estimativas divergem, os
participantes que apresentaram carta
com maior e menor valor devem
explicar o motivo que o levaram a
escolhê-la. Isto não deve de forma
alguma ser feita de forma agrssiva,
ou mesmo defensiva, mas apenas
como uma troca de conhecimento
entre visões diferentes sobre o
esforço necessário para a conclusão
do item. Estimating & Planning - Mike Cohn


Após as devidas explicações, inicie um novo Round repetindo o
ciclo, até que haja um consenso quanto ao tamanho do item;
Normalmente, as estimativas entram em convergência já no
segundo round, ou no máxima no terceiro. Mas caso isso não
aconteça, o ciclo deve ser continuado.

1 2 3 5 13


Vídeo
Experiências com Planning Poker


Por que o Planning Poker funciona ?

Apresenta múltiplas opniões de especialistas quanto à
estimativa de um item, e como Scrum trabalha com times
multi-perﬁs temos praticamente todas as áreas de
conhecimento cobertas;
Porque Planning Poker estimula o dialogo durante os rounds, e
cada membro do time tem que explicar o porque de sua
estimativa, ampliando o compartilhamento de conhecimento;
Estudos mostram que estimativas feitas em grupo vem sendo
mas bem sucedidas que estimativas individuais;

Estimating & Planning - Mike Cohn

SPM #2

A segunda parte da reunião de planejamento deve ocorrer
imediatamente após a ﬁnalizar da primeira, sendo nela :
criada a lista de tarefas, por meio da decomposição dos itens
do Product Backlog, chamada Sprint Backlog;
detalhada algum item ou removevida dúvidas quanto ao
objetivo do mesmo, pelo PO ou especialista convidado;
elaborada a estratégia de desenvolvimento que será utilizada
para que a meta da Sprint seja atingida. Sendo necessário
responder como construirão as funcionalidades do produto
durante o Sprint;

SPM #2

Os membros do time devem escolher suas tarefas e então
estimá-las em horas;
Tarefas devem ter de 1 a 16 horas de duração. Tarefas maiores
deverão ser quebradas em duas ou mais.


Características do Sprint Backlog

Itens do Product Backlog devem ser decompostos em tarefas
(Tasks);
As tarefas devem ter estimativas de 1 a 16 horas;
Qualquer membro do time pode adicionar, remover ou alterar
tarefas do Sprint Backlog;
As tarefas são escolhidas pelos membros do time, e não
designadas a eles;


Características do Sprint Backlog

SPRINT BACKLOG
SP R IN T BAC K L OG

Id Item Estimativa
1 Refatorar o banco de dados 32
Mapear as tabelas que serão refatoradas 6hrs
Deﬁnir estratégias de refatoração 2hrs
Montar/Gerar script de refatoração 8hrs
Aplicar script de refatoração 2hrs
Avaliar eﬁciência da refatoração 6hrs
Total 24 hrs


O que é Scrum?
primeiro plano;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que
se tornem grandes;


Scrum Daily Meeting
Se reunir todo dia ? Impossível!

Uma vez iniciado o Sprint, inicia-se a
realização das reuniões diárias (Scrum
Daily Meeting);
Uma Daily Meeting é uma reunião com:
duração exata de 15 minutos
realizadas no mesmo local e horário
com participação do SM e membros
do time;
não havendo um SM presente, deve
ser deﬁnido o facilitador;

Scrum Daily Meeting
Se reunir todo dia ? Impossível!

Cada membro deve relatar ao time sobre
os progressos e obstáculos que encontrou
em seu caminho. Em suma, três perguntas
devem ser respondidas por cada um
deles:
1. O que ﬁz (quanto andei) desde a última
reunião diária ?
2. O que pretendo fazer ( quanto andarei )
até a próxima reunião diária ?
3. Estou encontrando impedimentos ?
Quais ?


Atividade
Armadilhas das Reuniões !

Você está preparado para enfrentar as
armadilhas das reuniões diárias ?


Scrum Daily Meeting
O quadro de acompanhamento

Tarefas Em Em Em
Item Conluído Horas
desejadas análise desenvolvimento Teste
Aplicar
Script de Montar Deﬁnir
Refatorar
refatoração script de estratégia
banco de
refatoração refatoração
dados 02 24
08 02
13 Avaliar
Estimativa em eﬁciência Mapear as
complexidade da tabelas
refatoração que serão
06 refatoradas
Estimativa 06
em tempo


Scrum Daily Meeting
O quadro de acompanhamento


Scrum Daily Meeting
Sprint Backlog

SPRINT BACKLOG
SP R I N T BAC K L OG

Id Item
julho/09
1 Refatorar o banco de dados 11 12 13
Mapear as tabelas que serão refatoradas 6hrs 6 0 0
Deﬁnir estratégias de refatoração 2hrs 2 0 0
Montar/Gerar script de refatoração 8hrs 0 8 0
Aplicar script de refatoração 2hrs 0 0 2
Avaliar eﬁciência da refatoração 6hrs 0 0 6
Tota 24 hrs 16 hrs 8 hrs 0 hrs
l


Scrum Daily Meeting
Sprint Burndown

Ideal Real
Após a reunião diária, os
membros atualizam o 100
montante de tempo que 90
resta para o cumprimento 80
de cada tarefa no Sprint 70
60
Backlog.
50
40
Esta informação é
30
acrescida a um gráﬁco 20
chamado Sprint Burndown. 10
0
Este gráﬁco mostra o 11/7 12/7 13/7 14/7 15/7
projeto dia-a-dia


Sprint Review
E o resultado foi...

Durante o Sprint Review devemos:
avaliar que esta sendo entregue ?
realizar uma apresentação do produto
que foi gerado durante a Sprint.
Devem participar do Sprint Review o PO,
o SM e os membros do time, clientes e
executivos desde que convidados pelo
PO.
A apresentação dura 30 minutos


Sprint Retrospective
Aprendendo com os acertos... mas principalmente com os erros

A Sprint Retrospective é uma das
ferramentas mais importantes para que você
obtenha sucesso com Scrum;
Esta é a oportunidade que o time tem para
discutir sobre o que funcionou e o que não
durante a Sprint;
Product Owner, Scrum Master e os membros
do time devem participar da retrospectiva.
Uma boa estratégia é convidar alguém neutro
para facilitar a reunião;


Sprint Retrospective
Aprendendo com os acertos... mas principalmente com os erros

A estrutura da Sprint Retrospective é bem
simples. Divida um quadro branco ou poster
em duas áreas com os seguintes títulos: “O
que funcionou bem ?” e “O que pode ser
melhorado ?”. Após isso, cada membro deve
colocar post-its em cada uma das áreas
indicando os itens que, em sua opnião,
merecem estar ali;
Então, o time visualiza os itens citados,
discute sobre e planeja ações a serem
tomadas para a próxima Sprint.



3 Experimentando
agilidade com Scrum


Atividade
Jogo do Planejamento

O Product Owner deverá entregar a cada equipe um
Product backlog priorizado representando os desejos de
seu cliente;

Planejamento (15 minutos)

1. O time deve estimar os itens do Product backlog ;
2. O time deve selecionar os itens do Product backlog
que poderão ser entregues no ﬁnal do Sprint.

Execução (30 minutos)

1. O time deve executar as atividades da Sprint.

Revisão (2 minutos)

1. O time deve apresentar o que foi deﬁnido para o Sprint.


VOCES PODEM FAZER SOFTWARE
QUE FUNCIONA

EM UM AMBIENTE ÁGIL E PRODUTIVO

SE VOCÊS ACHAVAM QUE ISSO SERIA IMPOSSÍVEL...

EXISTEM MUITOS QUE JÁ O ESTÃO FAZENDO

Indivíduos e a processos e
interação entre eles mais que ferramentas

Produto em documentação
“Estamos descobrindo maneiras melhores
mais que
funcionamento abrangente
de desenvolver software fazendo-o nós
mesmos ecom o
Colaboração ajudando outros a fazê-lo. Através
negociação de
mais que
desse trabalho, passamos a contratos
cliente valorizar:

Responder a
mais que seguir um plano
mudanças

http://agilemanifesto.org ©2009 - Hélio Medeiros e Germano Carvalho

PERGUNTAS ?


ISSO é TUDO PESSOAL !!

Hélio Cabral Medeiros Germano Carvalho
helio.cabralmedeiros@gmail.com
germano.carv@gmail.com
http://heliomedeiros.com/


Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE

Recomendados

Recomendados

Más contenido relacionado

Similar a Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE

Similar a Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE (20)

Más de Hélio Medeiros

Más de Hélio Medeiros (20)

Último

Último (8)

Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE