O documento descreve os princípios e papéis do Scrum, incluindo seu desenvolvimento por Ken Schwaber e Jeff Sutherland em 1995. Ele define Scrum como um framework para gerenciar projetos complexos de forma iterativa e incremental, com papéis como Product Owner, Scrum Master e Development Team.
1. CSM - João Antonio Ferreira joao.parana@gmail.com
Guia do Scrum
As regras do jogo
1
2. CSM - João Antonio Ferreira joao.parana@gmail.com
Baseado no guia da
https://www.scrumalliance.org
Inicio de tudo :
Ken Schwaber e Jeff Sutherland em 1995.
O Guia do Scrum documenta o Scrum conforme
desenvolvido e sustentado por mais de 20 anos via
Scrum Alliance
2
3. CSM - João Antonio Ferreira joao.parana@gmail.com
O propósito do Guia do Scrum:
contém a definição do Scrum
papéis, eventos, artefatos e as
regras do Scrum
3
4. CSM - João Antonio Ferreira joao.parana@gmail.com
Definição do Scrum:
Um framework dentro do qual
pessoas podem tratar e resolver
problemas complexos e adaptativos,
enquanto produtiva e criativamente
entregam produtos com o mais alto
valor possível.
4
5. CSM - João Antonio Ferreira joao.parana@gmail.com
Scrum é:
1. Leve
2. Simples de entender
3. Difícil de dominar
5
6. CSM - João Antonio Ferreira joao.parana@gmail.com
Scrum é um framework
estrutural que está sendo
usado para gerenciar o
desenvolvimento de produtos
complexos
6
7. CSM - João Antonio Ferreira joao.parana@gmail.com
Cada componente dentro do
framework serve a um
propósito específico e é
essencial para o uso e sucesso
do Scrum.
7
8. CSM - João Antonio Ferreira joao.parana@gmail.com
As regras do Scrum integram
os eventos, papéis e artefatos,
administrando as relações e
interações entre eles.
8
9. CSM - João Antonio Ferreira joao.parana@gmail.com
Teoria do Scrum
9
10. CSM - João Antonio Ferreira joao.parana@gmail.com
Dicionário:
Usaremos os acrônimos abaixo
PO - Product Owner
SM - Scrum Master
DEV - Developer Team
10
11. CSM - João Antonio Ferreira joao.parana@gmail.com
Scrum é fundamentado nas teorias
empíricas de controle de processo.
O empirismo afirma que o
conhecimento vem da experiê ncia
e de tomada de decisões baseadas
no que é conhecido.
11
12. CSM - João Antonio Ferreira joao.parana@gmail.com
O Scrum emprega uma
abordagem iterativa e
incremental para aperfeiçoar
a previsibilidade e o controle de
riscos.
12
13. CSM - João Antonio Ferreira joao.parana@gmail.com
Trê s pilares apoiam a
implementação de controle de
processo empírico:
transparê ncia, inspeção e
adaptação.
13
14. CSM - João Antonio Ferreira joao.parana@gmail.com
Transparê ncia - Aspectos
significativos do processo devem
estar visíveis a todos os
responsáveis pelos resultados. Uma
linguagem comum (ubíqua)
referindo-se ao processo deve ser
compartilhada por todos os
participantes
14
15. CSM - João Antonio Ferreira joao.parana@gmail.com
Uma definição comum do
significado de “Pronto” deve
ser compartilhada por aqueles
que realizam o trabalho e por
aqueles que aceitam o
resultado do trabalho.
15
16. CSM - João Antonio Ferreira joao.parana@gmail.com
Inspeção - Os usuários Scrum
devem, frequentemente, inspecionar
os artefatos Scrum e o progresso em
direção a detectar variações. Esta
inspeção não deve, no entanto, ser
tão frequente que atrapalhe a
própria execução das tarefas.
16
17. CSM - João Antonio Ferreira joao.parana@gmail.com
Adaptação - Se um ou mais
aspectos de um processo desviou
para fora dos limites aceitáveis, o
processo ou o material sendo
produzido deve ser ajustado. O
ajuste deve ser realizado o mais
breve possível para minimizar mais
desvios.
17
18. CSM - João Antonio Ferreira joao.parana@gmail.com
O Scrum prescreve quatro Eventos
formais, nos limites da Sprint:
1. Reunião de planejamento
2. Reunião diária
3. Reunião de revisão
4. Reunião de Retrospectiva
18
19. CSM - João Antonio Ferreira joao.parana@gmail.com
O Time Scrum é composto :
Scrum Master
Produt Owner
Developer Team
19
20. CSM - João Antonio Ferreira joao.parana@gmail.com
Times Scrum são:
auto-organizáveis
multifuncionais.
20
21. CSM - João Antonio Ferreira joao.parana@gmail.com
Times auto-organizáveis
escolhem qual a melhor forma
para completarem seu
trabalho, em vez de serem
dirigidos por outros de fora do
Time.
21
22. CSM - João Antonio Ferreira joao.parana@gmail.com
Times multifuncionais
possuem todas as
competê ncias necessárias
para completar o trabalho sem
depender de outros que não
fazem parte da equipe.
22
23. CSM - João Antonio Ferreira joao.parana@gmail.com
O modelo de time no Scrum é
projetado para aperfeiçoar a
flexibilidade, criatividade e
produtividade.
23
24. CSM - João Antonio Ferreira joao.parana@gmail.com
Times Scrum entregam
produtos de forma iterativa e
incremental, maximizando as
oportunidades de
realimentação.
24
25. CSM - João Antonio Ferreira joao.parana@gmail.com
Entregas incrementais de
produto “Pronto” garantem que
uma versão potencialmente
funcional do produto do trabalho
esteja sempre disponível ao
final de cada Sprint.
25
26. CSM - João Antonio Ferreira joao.parana@gmail.com
O PO - ou dono do produto, é o
responsável por maximizar o valor
do produto e do trabalho do DEV.
Como isso é feito pode variar
amplamente através das
organizações, Times Scrum e
indivíduos.
26
27. CSM - João Antonio Ferreira joao.parana@gmail.com
O PO é a única pessoa responsável por gerenciar o
Backlog do Produto.
O gerenciamento do Backlog do Produto inclui:
1. Expressar claramente os itens do Backlog do Produto
2. Ordenar os itens do Backlog do Produto para alcançar as metas
3. Garantir o valor do trabalho realizado pelo DEV
4. Garantir que o Backlog do Produto seja visível, transparente,
claro para todos
5. Mostrar no que o Time Scrum vai trabalhar a seguir
5. Garantir que o DEV entenda os itens do Backlog do Produto no
nível de detalhe necessário.
27
28. CSM - João Antonio Ferreira joao.parana@gmail.com
O PO pode fazer o trabalho
dele, com a ajuda do DEV. No
entanto, o PO continua sendo o
responsável pelos resultados do
trabalho.
28
29. CSM - João Antonio Ferreira joao.parana@gmail.com
O PO é uma pessoa e não um
comitê .
29
30. CSM - João Antonio Ferreira joao.parana@gmail.com
O PO pode representar o desejo
de um comitê no Backlog do
Produto, mas aqueles que
quiserem uma alteração nas
prioridades dos itens de Backlog
devem convencer o PO.
30
31. CSM - João Antonio Ferreira joao.parana@gmail.com
Para que o PO tenha sucesso,
toda a organização deve
respeitar as suas decisões.
31
32. CSM - João Antonio Ferreira joao.parana@gmail.com
As decisões do PO são visíveis no
conteúdo e na priorização do
Backlog do Produto. Ninguém além
do PO tem permissão para falar com
o DEV sobre diferentes
configurações de prioridade, e o DEV
não tem permissão para agir sobre o
que outras pessoas disserem.
32
33. CSM - João Antonio Ferreira joao.parana@gmail.com
O DEV consiste de profissionais
que realizam o trabalho de
entregar uma versão usável
que potencialmente incrementa
o produto “Pronto” ao final de
cada Sprint.
33
34. CSM - João Antonio Ferreira joao.parana@gmail.com
Somente integrantes do DEV
criam incrementos.
34
35. CSM - João Antonio Ferreira joao.parana@gmail.com
Os DEV - Times de
Desenvolvimento são
estruturados e autorizados pela
organização para organizar e
gerenciar seu próprio trabalho.
35
36. CSM - João Antonio Ferreira joao.parana@gmail.com
A sinergia resultante aperfeiçoa
a eficiê ncia e a eficácia do
DEV - DEV como um todo.
36
37. CSM - João Antonio Ferreira joao.parana@gmail.com
Os DEV tem as seguintes características:
1. Eles são auto-organizados. Ninguém diz ao DEV como transformar
o Backlog do Produto em Incremento de Produto
2. DEV são multifuncionais, possuindo todas as habilidades
necessárias, enquanto equipe, para criar o Incremento do Produto
3. O Scrum não reconhece títulos para os integrantes do DEV que
não seja o Desenvolvedor, independentemente do trabalho que está
sendo realizado pela pessoa. Não há exceções para esta regra.
4. Individualmente os integrantes do DEV podem ter habilidades
especializadas e área de especialização, mas a responsabilidade
pertence ao DEV como um todo
5. DEV não contém sub-times dedicados a domínios específicos de
conhecimento, tais como teste ou análise de negócios.
37
38. CSM - João Antonio Ferreira joao.parana@gmail.com
Tamanho do DEV
Deve ser pequeno o suficiente
para se manter ágil e grande o
suficiente para completar uma
parcela significativa do trabalho
dentro dos limites da Sprint.
38
39. CSM - João Antonio Ferreira joao.parana@gmail.com
Menos de trê s integrantes no
DEV diminuem a interação e
resultam em um menor ganho
de produtividade.
39
40. CSM - João Antonio Ferreira joao.parana@gmail.com
Times de desenvolvimento
menores podem encontrar
restrições de habilidades durante
a Sprint, gerando um DEV incapaz
de entregar um incremento
potencialmente utilizável
(Incremento de Produto).
40
41. CSM - João Antonio Ferreira joao.parana@gmail.com
Havendo mais de nove
integrantes é exigida muita
coordenação. Pode causar
problemas de Comunicação e
Gestão.
41
42. CSM - João Antonio Ferreira joao.parana@gmail.com
Times de Desenvolvimento
grandes geram muita
complexidade para um
processo empírico gerenciar.
42
43. CSM - João Antonio Ferreira joao.parana@gmail.com
Os papéis de PO e de SM Não
SÃO incluídos nesta contagem,
a menos que eles também
executem o trabalho do
Backlog da Sprint.
43
44. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM - responsável por
garantir que o Scrum seja
entendido e aplicado.
44
45. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM faz isso para garantir que
o Time Scrum adere à teoria,
práticas e regras do Scrum. O
SM é um facilitador para o Time
Scrum (servo e lider).
45
46. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM ajuda aqueles que estão
fora do Time Scrum a entender
quais as suas interações com o
Time Scrum são úteis e quais
não são.
46
47. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM ajuda todos a mudarem
estas interações para
maximizar o valor criado pelo
Time Scrum.
47
48. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM trabalhando para o PO
O SM serve o PO de várias maneiras:
1. Aplicando técnicas para o gerenciamento do Backlog
2.Comunicando claramente a visão do Produto, objetivos e
itens do Backlog para o DEV
3. Ensinando ao Time Scrum a criar itens de Backlog do
Produto de forma clara e concisa
4. Compreendendo a longo-prazo o planejamento do
Produto no ambiente empírico
5. Compreendendo e praticando a agilidade
6. Facilitar os eventos Scrum conforme exigidos
48
49. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM trabalhando para o DEV
O SM serve ao DEV de várias maneiras:
1. Treinar o DEV em autogerenciamento e
interdisciplinaridade
2. Ensinar e liderar o DEV na criação de produtos de
alto valor
3. Remover impedimentos para o progresso do DEV
4. Facilitar os eventos Scrum conforme exigidos
5. Treinar o DEV em ambientes organizacionais nos
quais o Scrum não é totalmente adotado ou
compreendido.
49
50. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM trabalhando para a Organização
O SM serve a Organização de várias maneiras:
1. Liderando e treinando a organização na adoção do Scrum
2. Planejando implementações Scrum dentro da organização
3. Ajudando funcionários e partes interessadas a
compreender e tornar aplicável o Scrum e o
desenvolvimento de produto empírico
4. Causando mudanças que aumentam a produtividade do
Time Scrum
5. Trabalhando com outros SMs para aumentar a eficácia da
aplicação do Scrum nas organizações.
50
51. CSM - João Antonio Ferreira joao.parana@gmail.com
Eventos Scrum
Eventos prescritos são usados no
Scrum para criar uma rotina e um
ritmo
Servem também para minimizar a
necessidade de reuniões extras.
51
52. CSM - João Antonio Ferreira joao.parana@gmail.com
Todos os eventos são eventos
time-boxed, de tal modo que
todo evento tem uma duração
máxima.
52
53. CSM - João Antonio Ferreira joao.parana@gmail.com
Uma vez que a Sprint começa,
sua duração é fixada e não pode
ser reduzida ou aumentada.
Os eventos restantes podem
terminar sempre que o propósito
do evento é alcançado.
53
54. CSM - João Antonio Ferreira joao.parana@gmail.com
Além da Sprint, que é um
container para outros eventos,
cada evento no Scrum é uma
oportunidade de inspecionar
e adaptar alguma coisa.
54
55. CSM - João Antonio Ferreira joao.parana@gmail.com
Estes eventos são especificamente
projetados para permitir uma
transparê ncia e inspeção criteriosa.
A não inclusão de qualquer um dos
eventos resultará na redução da
transparê ncia e da perda de
oportunidade para inspecionar e adaptar.
55
56. CSM - João Antonio Ferreira joao.parana@gmail.com
Sprint é o coração do Scrum
um time-boxed de um mê s ou
menos, durante o qual um “Pronto” é
criado.
Pronto » versão incremental
potencialmente utilizável do produto,
também chamado: Incremento de
Produto 56
57. CSM - João Antonio Ferreira joao.parana@gmail.com
Sprints tem durações coerentes
em todo o esforço de
desenvolvimento.
Uma nova Sprint inicia
imediatamente após a
conclusão da Sprint anterior.
57
58. CSM - João Antonio Ferreira joao.parana@gmail.com
As Sprints são compostas por:
1. uma reunião de planejamento
2. reuniões diárias
3. o trabalho de desenvolvimento
4. uma reunião de revisão
5.uma reunião retrospectiva
58
59. CSM - João Antonio Ferreira joao.parana@gmail.com
Durante a Sprint:
1. Não são feitas mudanças que possam
por em perigo o objetivo da Sprint
2. As metas de qualidade não diminuem
3. O escopo pode ser esclarecido e
renegociado entre o PO e o DEV
59
60. CSM - João Antonio Ferreira joao.parana@gmail.com
Cada Sprint pode ser considerada um projeto
com horizonte de até um mê s.
Como os projetos, as Sprints são utilizadas
para realizar algo.
Cada Sprint tem a definição do que é para
ser construído, um plano flexível que irá
guiar a construção, o trabalho e o por fim o
resultado que é o Incermento de Produto.
60
61. CSM - João Antonio Ferreira joao.parana@gmail.com
Sprints são limitadas a um mê s corrido.
Quando o horizonte da Sprint é muito longo,
o risco pode crescer consideravelmente.
Sprints permitem previsibilidade que garante
a inspeção e adaptação em direção à meta.
Sprints de um mês, também limitam o risco
ao custo de apenas um mê s corrido.
61
62. CSM - João Antonio Ferreira joao.parana@gmail.com
Cancelamento da Sprint:
Uma Sprint pode ser cancelada antes do
time-boxed da Sprint terminar.
Somente o PO tem a autoridade para
cancelar a Sprint, embora ele possa
fazer isso sob influê ncia das partes
interessadas, do DEV ou do SM.
62
63. CSM - João Antonio Ferreira joao.parana@gmail.com
A Sprint poderá ser cancelada se o objetivo da Sprint
se tornar obsoleto.
Isto pode ocorrer se a organização mudar sua direção
ou se as condições do mercado ou das tecnologias
mudarem.
Geralmente a Sprint deve ser cancelada se ela não faz
mais sentido às dadas circunstâ ncias.
No entanto, devido a curta duração da Sprint,
raramente cancelamentos fazem sentido.
63
64. CSM - João Antonio Ferreira joao.parana@gmail.com
Quando a Sprint é cancelada, qualquer item de
Backlog do Produto completado e “Pronto” é
revisado.
Se uma parte do trabalho estiver potencialmente
utilizável, o PO pode aceitar.
Todos os itens de Backlog do Produto incompletos
são reestimados e colocados de volta no Backlog do
Produto pois o trabalho feito se deprecia
rapidamente e deve ser frequentemente reestimado.
64
65. CSM - João Antonio Ferreira joao.parana@gmail.com
O cancelamento de Sprints consome recursos
Todos tem que se reagrupar em outra
reunião de planejamento da Sprint para
iniciar outra Sprint.
Cancelamentos de Sprints são
frequentemente traumáticos para o Time
Scrum, e são muito incomuns.
65
66. CSM - João Antonio Ferreira joao.parana@gmail.com
Reunião de Planejamento da Sprint:
O trabalho a ser realizado na Sprint
é planejado na reunião de
planejamento da Sprint.
Este plano é criado com o trabalho
colaborativo de todo o Time Scrum.
66
67. CSM - João Antonio Ferreira joao.parana@gmail.com
Reunião de planejamento da Sprint possui um time-box
com no máximo oito horas (±5%) para uma Sprint de um
mê s de duração.
Para Sprints menores, este evento é menor e proporcional.
Exemplo: 2 horas para um Sprint de uma semana.
O SM garante que o evento ocorra e que os participantes
entendam seu propósito.
O SM ensina o Time Scrum a manter-se dentro dos limites
do time-box.
67
68. CSM - João Antonio Ferreira joao.parana@gmail.com
A reunião de planejamento da Sprint
responde as seguintes questões:
1. O que pode ser entregue como
resultado do incremento da próxima
Sprint?
2. Como será realizado o trabalho
necessário para entregar o incremento?
68
69. CSM - João Antonio Ferreira joao.parana@gmail.com
Tópico 1: O que pode ser entregue na Sprint?
O DEV trabalha para prever as funcionalidades
que serão desenvolvidas durante a Sprint.
O PO debate o objetivo que a Sprint deve realizar
e os itens de Backlog que atingirão o objetivo da
Sprint.
Todo o Time Scrum colabora com o entendimento
do trabalho da Sprint.
69
70. CSM - João Antonio Ferreira joao.parana@gmail.com
As entradas da reunião de planejamento da Sprint são:
1. Backlog do Produto
2. O mais recente incremento do produto
3. A capacidade projetada do DEV na Sprint
4. Desempenho passado do DEV (empirico).
A saída é: O número de itens selecionados do Backlog
do Produto para a Sprint como selecionado pelo DEV
70
71. CSM - João Antonio Ferreira joao.parana@gmail.com
Somente o DEV pode avaliar o
que pode ser completado ao
longo da próxima Sprint.
71
72. CSM - João Antonio Ferreira joao.parana@gmail.com
Após o DEV escolher os itens de Backlog do
Produto que irá entregar na Sprint, o Time Scrum
determina a meta da Sprint.
A meta da Sprint é o objetivo que será
conhecido dentro da Sprint através da
implementação do Backlog do Produto, e esta
fornece orientação para o DEV sobre o porque
dele estar construindo o incremento.
72
73. CSM - João Antonio Ferreira joao.parana@gmail.com
Tópico 2: Como o trabalho escolhido será feito, ou seja,
como ficará Pronto?
Tendo definido o objetivo da Sprint e selecionado os
itens de Backlog do Produto da Sprint, o DEV decide
como irá construir essas funcionalidades durante a
Sprint e transformá-las em um incremento de produto
“Pronto”.
Os itens de Backlog do Produto selecionados para a
Sprint, junto com o plano de entrega destes itens é
chamado de Backlog da Sprint.
73
74. CSM - João Antonio Ferreira joao.parana@gmail.com
O DEV frequentemente inicia o desenho do sistema
e do trabalho necessário para converter o Backlog
do Produto em um incremento utilizável do produto.
O trabalho pode ser de vários tamanhos ou
esforços.
O trabalho suficiente é planejado durante o
planejamento da Sprint pelo DEV para prever o que
este acredita que poderá realizar durante o Sprint.
74
75. CSM - João Antonio Ferreira joao.parana@gmail.com
Com o trabalho planejado pelo
DEV para os primeiros dias da
Sprint concluído este é
decomposto em tarefas até o
final da reunião, em unidades
de um dia de duração ou
menos.
75
76. CSM - João Antonio Ferreira joao.parana@gmail.com
O DEV se auto-organiza para
realizar todo o trabalho do
Backlog da Sprint, tanto
durante a reunião de
planejamento quanto durante a
Sprint
76
77. CSM - João Antonio Ferreira joao.parana@gmail.com
O PO pode ajudar a esclarecer os itens
de Backlog do Produto selecionados e
nas decisões conflituosas de troca.
Se o DEV determina que tem excesso
ou falta de trabalho, os itens do
Backlog da Sprint pode ser
renegociados com o PO.
77
78. CSM - João Antonio Ferreira joao.parana@gmail.com
O DEV também pode convidar
outras pessoas para participar
desta reunião de forma a
fornecer opinião técnica ou de
domínios específicos.
78
79. CSM - João Antonio Ferreira joao.parana@gmail.com
No final da reunião de planejamento
da Sprint, o DEV deve ser capaz de
explicar ao PO e ao SM como
pretende trabalhar como equipe
auto-organizada para completar o
objetivo da Sprint e criar o
incremento de produto acordado.
79
80. CSM - João Antonio Ferreira joao.parana@gmail.com
Objetivo ou meta da Sprint:
A meta da Sprint é um objetivo
definido que pode ser satisfeito
através da implementação de
parte do Backlog do Produto
chamado Backlog do Sprint.
80
81. CSM - João Antonio Ferreira joao.parana@gmail.com
O objetivo do Sprint fornece uma direção para o DEV sobre
o porquê de estar construindo o incremento.
O objetivo da Sprint dá ao DEV alguma flexibilidade a
respeito da funcionalidade que será completada dentro dos
limites da Sprint.
Os itens do Backlog do Produto selecionados entregam uma
função coerente, que pode ser o objetivo da Sprint.
O objetivo da Sprint pode ser qualquer outro que seja
coerente e que faça o DEV trabalhar em conjunto em vez
de em iniciativas separadas.
81
82. CSM - João Antonio Ferreira joao.parana@gmail.com
Conforme o DEV trabalha, ele mantém o
objetivo da Sprint em mente.
A fim de satisfazer o objetivo da Sprint,
implementam a funcionalidade e a tecnologia.
Caso o trabalho acabe por se mostrar
diferente do esperado pelo DEV, eles
colaboram com o PO para negociar o escopo
do Backlog da Sprint dentro da propria Sprint.
82
83. CSM - João Antonio Ferreira joao.parana@gmail.com
Reunião Diária:
A Reunião Diária do Scrum é um evento time-
boxed de 15 minutos, para que o DEV possa
sincronizar as atividades e criar um plano para as
próximas 24 horas.
Esta reunião é feita para inspecionar o trabalho
desde a última Reunião Diária, e prever o
trabalho que deverá ser feito antes da próxima
Reunião Diária.
83
84. CSM - João Antonio Ferreira joao.parana@gmail.com
A Reunião Diária é mantida no mesmo horário e
local todo dia para reduzir a complexidade.
Durante a reunião os membros do DEV esclarecem:
1. O que eu fiz ontem que ajudou o DEV a atender
a meta da Sprint?
2. O que eu farei hoje para ajudar o DEV a atender
a meta da Sprint?
3. Eu vejo algum obstáculo que impeça a mim ou o
DEV atender a meta da Sprint?
84
85. CSM - João Antonio Ferreira joao.parana@gmail.com
O DEV usa a Reunião Diária para:
inspecionar o progresso em
direção ao objetivo da Sprint e
para inspecionar se o progresso
tende no sentido de completar o
trabalho do Backlog da Sprint
85
86. CSM - João Antonio Ferreira joao.parana@gmail.com
A Reunião Diária aumenta a
probabilidade do DEV atingir o
objetivo da Sprint.
86
87. CSM - João Antonio Ferreira joao.parana@gmail.com
Todos os dias, o DEV deve
avaliar como pretende trabalhar
em conjunto, num time auto-
organizado, para completar o
objetivo da Sprint e criar um
incremento esperado de produto
antes do final da Sprint.
87
88. CSM - João Antonio Ferreira joao.parana@gmail.com
O membros do DEV
frequentemente se encontram
imediatamente após a Reunião
Diária para discussões
detalhadas, ou para adaptar, ou
re-planejar, o restante do
trabalho da Sprint.
88
89. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM assegura que o DEV faça
a reunião, mas o DEV é
responsável por conduzir a
Reunião Diária.
89
90. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM ensina ao DEV a manter
a Reunião Diária dentro do
time-box de 15 minutos.
90
91. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM reforça a regra de que
somente os integrantes do DEV
participem da Reunião Diária.
91
92. CSM - João Antonio Ferreira joao.parana@gmail.com
Reuniões Diárias melhoram as
comunicações, eliminam outras reuniões,
identificam e removem impedimentos para
o desenvolvimento, destacam e promovem
rápidas tomadas de decisão, e melhoram o
nível de conhecimento do DEV.
Esta é uma reunião chave para inspeção e
adaptação.
92
93. CSM - João Antonio Ferreira joao.parana@gmail.com
Revisão da Sprint:
Revisão da Sprint é executada
no final da Sprint para
inspecionar o incremento e
adaptar o Backlog do Produto
se necessário.
93
94. CSM - João Antonio Ferreira joao.parana@gmail.com
Durante a reunião de Revisão da Sprint o Time Scrum
e as partes interessadas colaboram sobre o que foi
feito na Sprint.
Com base nisso e em qualquer mudança no Backlog
do Produto durante a Sprint, os participantes
colaboram nas próximas coisas que podem ser feitas
para otimizar a entrega de valor.
Esta é uma reunião informal e a apresentação do
incremento destina-se a motivar e obter comentários e
promover a colaboração e o feedback do Cliente.
94
95. CSM - João Antonio Ferreira joao.parana@gmail.com
Esta é uma reunião time-boxed de 4 horas de
duração para uma Sprint de um mê s.
Para Sprints menores, este evento é usualmente
menor.
O SM garante que o evento ocorra e que os
participantes entendam o seu objetivo.
O SM ensina a todos a manter a reunião dentro
dos limites do Time-box.
95
96. CSM - João Antonio Ferreira joao.parana@gmail.com
A Reunião de Revisão inclui os seguintes elementos:
1. Participantes: Time Scrum e os Stakeholders chaves convidados pelo PO
2. O PO esclarece quais itens do Backlog ficaram “Prontos” e quais não
3. O DEV fala sobre o que foi bem durante a Sprint, quais problemas
surgiram e como foram resolvidos
4. O DEV demonstra o trabalho que está “Pronto” e responde as questões
sobre o incremento
5. O PO discute o Backlog do Produto tal como está. Ele projeta as prováveis
datas de conclusão baseado no progresso observado
6. O grupo todo colabora sobre o que fazer a seguir
7. O grupo fornece valiosas entradas para a Reunião de Planejamento da
próxima Sprint
8. Análise de como o mercado ou o uso potencial do produto pode ter
mudado e o que é a coisa mais importante a se fazer a seguir
9. Análise da linha do tempo, orçamento, potenciais capacidades, e mercado
para a próxima versão esperada do produto
96
97. CSM - João Antonio Ferreira joao.parana@gmail.com
O resultado da Reunião de Revisão da
Sprint é um Backlog do Produto
revisado que define o provável Backlog
da próxima Sprint.
O Backlog do Produto pode também ser
ajustado completamente para atender
novas oportunidades do negócio
97
98. CSM - João Antonio Ferreira joao.parana@gmail.com
Retrospectiva da Sprint:
A Retrospectiva da Sprint é uma
oportunidade para o Time Scrum
inspecionar a si próprio e
criar um plano para melhorias a
serem aplicadas na próxima Sprint
98
99. CSM - João Antonio Ferreira joao.parana@gmail.com
A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes
da reunião de planejamento da próxima Sprint.
Esta é uma reunião time-boxed de trê s horas para uma Sprint de
um mê s.
Para Sprint menores, este evento é menor.
O SM garante que o evento ocorra e que os participantes entendam
seu propósito.
O SM ensina todos a mantê -lo dentro do time-box.
O SM participa da reunião como um membro auxiliar do time devido
a sua responsabilidade pelo processo Scrum.
99
100. CSM - João Antonio Ferreira joao.parana@gmail.com
O propósito da Retrospectiva da Sprint é:
1. Inspecionar como a última Sprint foi em
relação às pessoas, os relacionamentos, os
processos e às ferramentas
2. Identificar e ordenar os principais itens que
foram bem e as potenciais melhorias
3. Criar um plano para implementar melhorias no
modo que o Time Scrum faz seu trabalho
100
101. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM encoraja o Time Scrum a melhorar
o processo de desenvolvimento e as
práticas para fazê -lo mais efetivo e
agradável para a próxima Sprint.
Durante cada Retrospectiva da Sprint, o
Time Scrum planeja formas de aumentar
a qualidade do produto, adaptando a
definição de “Pronto” quando apropriado.
101
102. CSM - João Antonio Ferreira joao.parana@gmail.com
Ao final da Retrospectiva da Sprint, o Time Scrum
deverá ter identificado melhorias que serão
implementadas na próxima Sprint.
A implementação destas melhorias na próxima Sprint
é a forma de adaptação à inspeção que o Time Scrum
faz a si próprio.
A Retrospectiva da Sprint fornece um evento dedicado
e focado na inspeção e adaptação, no entanto, as
melhorias podem ser adotadas a qualquer momento
durante a Sprint.
102
103. CSM - João Antonio Ferreira joao.parana@gmail.com
Artefatos do Scrum:
Os artefatos do Scrum representam o trabalho ou
o valor para o fornecimento de transparê ncia e
oportunidades para inspeção e adaptação.
Os artefatos definidos para o Scrum são
especificamente projetados para maximizar a
transparê ncia das informações chave de modo
que todos tenham o mesmo entendimento dos
artefatos.
103
104. CSM - João Antonio Ferreira joao.parana@gmail.com
Backlog do Produto:
O Backlog do Produto é uma lista ordenada
de tudo que deve ser necessário no produto,
e é uma origem única dos requisitos para
qualquer mudança a ser feita no produto.
O PO é responsável pelo Backlog do Produto,
incluindo seu conteúdo, disponibilidade e
ordenação.
104
105. CSM - João Antonio Ferreira joao.parana@gmail.com
Um Backlog do Produto nunca
está completo.
Os primeiros desenvolvimentos
apenas estabelecem os
requisitos inicialmente
conhecidos e melhor entendidos.
105
106. CSM - João Antonio Ferreira joao.parana@gmail.com
O Backlog do Produto evolui tanto quanto o
produto e o ambiente no qual ele será utilizado
evoluem.
O Backlog do Produto é dinâmico; mudando
constantemente para identificar o que o produto
necessita para ser mais apropriado, competitivo e
útil.
O Backlog do Produto existirá enquanto o produto
também existir.
106
107. CSM - João Antonio Ferreira joao.parana@gmail.com
O Backlog do Produto lista todas as
características, funções, requisitos,
melhorias e correções que formam as
mudanças que devem ser feitas no
produto nas futuras versões.
Os itens do Backlog do Produto possuem
os atributos de descrição, ordem,
estimativa e valor.
107
108. CSM - João Antonio Ferreira joao.parana@gmail.com
A medida que um produto é usado, ganha valor,
e o mercado oferece retorno, o Backlog do
Produto torna-se uma lista maior e mais
completa.
Requisitos nunca param de mudar, então o
Backlog do Produto é um artefato vivo.
Mudanças nos requisitos de negócio, condições
de mercado ou tecnologia promovem mudanças
no Backlog do Produto.
108
109. CSM - João Antonio Ferreira joao.parana@gmail.com
Múltiplos Times Scrum podem trabalhar
juntos no mesmo produto final.
Um Backlog do Produto é usado para
descrever o trabalho previsto para o
produto.
Um atributo do Backlog do Produto que
agrupe itens pode ser então aplicado.
109
110. CSM - João Antonio Ferreira joao.parana@gmail.com
O refinamento do Backlog do Produto
é a ação de adicionar detalhes,
estimativas e ordem aos itens no
Backlog do Produto.
Este é um processo contínuo em que
o PO e o DEV colaboram nos detalhes
dos itens do Backlog do Produto.
110
111. CSM - João Antonio Ferreira joao.parana@gmail.com
Durante o refinamento do Backlog do Produto,
os itens são analisados e revisados.
O DEV decide como e quando o refinamento
está “Pronto”. Este refinamento usualmente não
consome mais de 10% da capacidade do DEV.
Entretanto os itens do Backlog do Produto
podem ser atualizados a qualquer momento
pelo PO ou a critério do PO.
111
112. CSM - João Antonio Ferreira joao.parana@gmail.com
Os itens do Backlog do Produto de ordem
mais alta (topo da lista) devem ser mais
claros e mais detalhados que os itens de
ordem mais baixa.
Estimativas mais precisas são feitas baseadas
em maior clareza e maior detalhamento.
Quanto menor a ordem na lista, menos
detalhes.
112
113. CSM - João Antonio Ferreira joao.parana@gmail.com
Os itens do Backlog do Produto que irão ocupar o
desenvolvimento na próxima Sprint são mais refinados, de
modo que todos os itens possam ser “Prontos” dentro do
time- boxed da Sprint.
Os itens do Backlog do Produto que podem ser “Prontos”
pelo DEV dentro da Sprint são considerados como
“Preparados” - READY - para seleção no Planejamento da
Sprint.
Itens do Backlog do Produto geralmente adquirem este
grau de transparê ncia através das atividades de
Refinamento.
113
114. CSM - João Antonio Ferreira joao.parana@gmail.com
O DEV é responsável por todas as
estimativas.
O PO deve influenciar o Time, ajudando no
entendimento e nas decisões conflituosas de
troca
Apenas as pessoas que irão realmente
realizar o trabalham (o time DEV) fazem a
estimativa final.
114
115. CSM - João Antonio Ferreira joao.parana@gmail.com
Monitorando o Progresso a Caminho do Objetivo:
Em qualquer ponto do tempo, o total do trabalho restante para
alcançar o objetivo pode ser somado.
O PO acompanha o total do trabalho restante pelo menos a cada
Reunião de Revisão da Sprint.
O PO compara este valor com o trabalho restante na Reunião de
Revisão da Sprint anterior, para avaliar o progresso na direção de
completar o trabalho previsto, pelo tempo estimado para alcançar o
objetivo.
Esta informação deve ser transparente para todas as partes
interessadas.
115
116. CSM - João Antonio Ferreira joao.parana@gmail.com
Várias práticas como burndown, burnup e outras
práticas de estimativa tem sido usadas para prever o
progresso.
Estas tem se provado úteis. Entretanto, não
substituem a importâ ncia do empirismo.
Em ambientes complexos, o que acontecerá é
desconhecido.
Somente o que tem acontecido pode ser usado para
uma tomada de decisão a respeito do que virá.
116
117. CSM - João Antonio Ferreira joao.parana@gmail.com
Backlog da Sprint:
O Backlog da Sprint é um conjunto de itens do
Backlog do Produto selecionados para a Sprint,
juntamente com o plano para entregar o incremento
do produto e atingir o objetivo da Sprint.
O Backlog da Sprint é a previsão do DEV sobre qual
funcionalidade estará no próximo incremento e sobre
o trabalho necessário para entregar essa
funcionalidade em um incremento “Pronto”.
117
118. CSM - João Antonio Ferreira joao.parana@gmail.com
O Backlog da Sprint torna
visível todo o trabalho que o
DEV identifica como necessário
para atingir o objetivo da
Sprint.
118
119. CSM - João Antonio Ferreira joao.parana@gmail.com
O Backlog da Sprint é um plano com detalhes
suficientes para que as mudanças no progresso sejam
entendidas durante a Reunião Diária.
O DEV modifica o Backlog da Sprint ao longo de toda a
Sprint, e o Backlog da Sprint vai surgindo durante a
Sprint.
Esta modificação ocorre quando o DEV trabalha
segundo o plano e aprende mais sobre o trabalho
necessário para alcançar o objetivo da Sprint durante
a sua realização.
119
120. CSM - João Antonio Ferreira joao.parana@gmail.com
Sempre que um novo trabalho é necessário, o
DEV adiciona este ao Backlog da Sprint.
Conforme o trabalho é realizado ou completado,
a estimativa do trabalho restante é atualizada.
Quando elementos do plano são considerados
desnecessários, eles são removidos.
Somente o DEV pode alterar o Backlog da Sprint
durante a Sprint.
120
121. CSM - João Antonio Ferreira joao.parana@gmail.com
O Backlog da Sprint é
altamente visível, uma imagem
em tempo real do trabalho que
o DEV planeja completar
durante a Sprint, e pertence
exclusivamente ao DEV.
121
122. CSM - João Antonio Ferreira joao.parana@gmail.com
Monitorando o Progresso da Sprint:
Em qualquer ponto do tempo na Sprint, o total do trabalho
remanescente dos itens do Backlog da Sprint pode ser somado.
O DEV monitora o total do trabalho restante pelo menos a cada
Reunião Diária.
O DEV acompanha estes resumos diários e projeta a
probabilidade de alcançar o objetivo da Sprint.
Com o rastreamento do trabalho restante em toda a Sprint, o
DEV pode gerenciar o seu progresso.
122
123. CSM - João Antonio Ferreira joao.parana@gmail.com
Incremento:
O incremento é a soma de todos os itens do Backlog do
Produto completados durante a Sprint e o valor dos
incrementos de todas as Sprints anteriores.
Ao final da Sprint um novo incremento deve estar “Pronto”,
o que significa que deve estar na condição utilizável e
atender a definição de “Pronto” do Time Scrum.
Este deve estar na condição utilizável independente do PO
decidir por liberá-lo realmente ou não.
123
124. CSM - João Antonio Ferreira joao.parana@gmail.com
Transparê ncia do Artefato:
Scrum invoca transparê ncia.
Decisões para otimizar o valor e o controle de riscos são feitos
com base na percepção existente do estado dos artefatos.
Na medida em que a transparê ncia é plena, estas decisões
tem uma base sólida.
Na medida em que os artefatos não são completamente
transparentes, estas decisões podem ser falhas, valores podem
diminuir e riscos podem aumentar.
124
125. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM deve trabalhar com o PO, DEV, e
outras partes envolvidas para entender
se os artefatos estão plenamente
transparentes.
Há práticas para lidar com
transparê ncia incompleta, o SM deve
ajudar todos a aplicar a mais apropriada
prática na falta de uma transparê ncia
plena. 125
126. CSM - João Antonio Ferreira joao.parana@gmail.com
O SM pode detectar
transparê ncia incompleta pela
inspeção dos artefatos,
percebendo padrões, ouvindo
atentamente o que está sendo
dito, e detectando diferenças
entre o esperado e o resultado
real. 126
127. CSM - João Antonio Ferreira joao.parana@gmail.com
O trabalho do SM é trabalhar com o Time
Scrum e organizar o aumento da
transparê ncia dos artefatos.
Este trabalho geralmente envolve
aprendizagem, convencimento e mudança.
Transparê ncia não ocorre de um dia para
o outro, mas é o caminho.
127
128. CSM - João Antonio Ferreira joao.parana@gmail.com
Definição de “Pronto”
Quando o item do Backlog do Produto ou um
incremento é descrito como “Pronto”, todos
devem entender o que o “Pronto” significa.
Embora, isso varie significativamente de um
extremo ao outro para cada Time Scrum, os
integrantes devem ter um entendimento
compartilhado do que significa o trabalho estar
completo, assegurando a transparê ncia.
128
129. CSM - João Antonio Ferreira joao.parana@gmail.com
Esta é a “Definição de Pronto”
para o Time Scrum e é usado
para assegurar quando o
trabalho estará realmente
completo no incremento do
produto.
129
130. CSM - João Antonio Ferreira joao.parana@gmail.com
A “Definição de Pronto” orienta
o DEV no conhecimento de
quantos itens do Backlog do
Produto podem ser
selecionados durante a Reunião
de Planejamento da Sprint.
130
131. CSM - João Antonio Ferreira joao.parana@gmail.com
O propósito de cada Sprint é
entregar incrementos de
funcionalidades potencialmente
utilizáveis que aderem à
definição atual de “Pronto” do
Time Scrum.
131
132. CSM - João Antonio Ferreira joao.parana@gmail.com
O DEV entrega um incremento de
funcionalidade do produto a cada Sprint.
Este incremento é utilizável, assim o PO pode
escolher por liberá-lo imediatamente.
Se a definição de “pronto” para um incremento
é parte das convenções, padrões ou diretrizes
de desenvolvimento da organização, todos os
Times Scrum devem segui-la
132
133. CSM - João Antonio Ferreira joao.parana@gmail.com
Se “pronto” para um incremento não é uma
convenção de desenvolvimento da organização,
o DEV do Time Scrum deve definir uma definição
de “pronto” apropriada para o produto.
Se há múltiplos Times Scrum trabalhando no
lançamento do sistema ou produto, os times de
desenvolvimento de todos os Times Scrum
devem mutuamente definir a definição de
“Pronto” em comum acordo.
133
134. CSM - João Antonio Ferreira joao.parana@gmail.com
Cada incremento é adicionado a todos os
incrementos anteriores e completamente
testado, garantindo que todos os
incrementos funcionam juntos.
Com um Time Scrum maduro, é
esperado que a sua definição de “Pronto”
seja expandida para incluir critérios mais
rigorosos de alta qualidade.
134
135. CSM - João Antonio Ferreira joao.parana@gmail.com
Conclusão
Papéis, artefatos, eventos e regras do Scrum são
imutáveis
Embora seja possível implementar somente
partes do Scrum, o resultado final não é Scrum.
Scrum existe somente na sua totalidade,
funcionando bem como um container para outras
técnicas, metodologias e práticas.
135
136. CSM - João Antonio Ferreira joao.parana@gmail.com
Livros
Scrum: Gestão ágil para projetos de sucesso de
Rafael Sabbagh - Editora casa do Código
The Art of Doing Twice the Work in Half the Time
de Jeff Sutherland
136