O documento resume conceitos fundamentais do Scrum como Sprints, Product Backlog, Sprint Backlog e papéis como Scrum Master e Product Owner. Sprints são períodos de tempo para o time agregar valor, geralmente 2 semanas. O Product Backlog é uma lista ordenada de requisitos e o Sprint Backlog contém itens selecionados para uma Sprint. O Scrum Master auxilia o time e o Product Owner é responsável pelo Product Backlog.
2. Resumo sobre Scrum e Sprint
●
O Scrum é uma estrutura
que ajuda as equipes a
trabalharem juntas
●
Uma das principais
características do Scrum
é a utilização de ciclos
de desenvolvimento
sucessivos, que se
repetem a cada
determinado período de
tempo, os quais
chamamos de Sprints
●
Sprint é a time-box
básica do Scrum. Ela
é o tempo que o time
tem para agregar
valor para o usuário
do projeto.
●
Duração do sprint é
de 2 semanas
3. Critérios para aumentar a Sprint
●
O time é muito
pequeno e a
tecnologia não os
ajuda a produzir valor
rapidamente.
●
Meu cliente passa
uma semana em
Chicago e outra aqui,
alternando.
●
Falta conhecimento
técnico para o time.
4. O que é o Review Meeting?
●
A Review Meeting é
uma reunião para
mostrar o que o time
produziu nessa Sprint
para o cliente ou
usuário.
●
Participam dessa
reunião o time todo
(desenvolvedores,
Product Owner e
Scrum Master)
5. Novas ideias?
●
Ao avaliar o que foi
feito, o cliente pode
encontrar erros de
entendimento, bugs
ou mesmo ter ideias
novas sobre o
projeto.
●
O Product Owner
deve anotar as
modificações que
serão necessárias.
6. Encontrei um bug durante o desenvolvimento.
●
Isso desfoca a
reunião, pode
consumir todo o time-
box
7. Retrospective Meeting
●
O último timebox
dentro de uma Sprint
é o que chamamos
de reunião de
Retrospectiva.
●
A ideia de uma
Retrospectiva é pôr em
prática o conceito de
melhoria contínua.
Nessa reunião, o time
todo (PO, Scrum Master
e Desenvolvedores) se
foca em descobrir como
melhorar ainda mais o
time, o processo e o
projeto já na próxima
Sprint.
8. Ações no Scrum
●
Ações, por outro lado,
envolvem os
membros do time. Se
o problema em
questão é que o
cliente desaparece e
não conseguimos
tirar dúvidas com
eles:
●
desejo: o cliente vai
entender a importância de
estar presente
●
uma ação: o Scrum Master
vai explicar as perdas e
ganhos de uma maior
participação do cliente
●
outra ação: em toda história
daqui para a frente, haverá
também o contato de quem
pode sanar dúvidas dos
desenvolvedores desse item
em particular.
9. Retrospectiva
●
O resultado de uma
retrospectiva é uma
lista,
preferencialmente
curta, de ações que
serão tomadas
durante o próximo
Sprint para melhorar
ainda mais o time e o
andamento do
projeto.
10. Daily Scrum
●
Para todos saberem
como está o
andamento das
tarefas e histórias
nessa Sprint,
evitando retrabalho e
ajudando uns aos
outros. A Timebox é
de 15 minutos.
●
Com o Daily Scrum, o
time evita com que
problemas durem
muitos dias e que
desenvolvedores
façam trabalhos
repetidos
11. Quais são as 3 perguntas que o time responde em
um Daily Scrum?
●
O que fiz desde o
último Daily Scrum?
●
O que pretendo fazer
até o próximo?
●
Quais problemas me
atrapalharam?
12. Planning Meeting
●
No Scrum, toda
Sprint começa com
uma reunião para
entendermos os itens
a serem feitos,
planejarmos o que
cabe no tempo
disponível e
definirmos a meta
para o time nessa
Sprint.
●
O time todo (todos os
desenvolvedores,
Product Owner e
Scrum Master)
participa dessa
reunião.
13. O timebox dessa reunião é de 5% do tempo total
da Sprint
●
É importante que o
P.O. já tenha feito
esse processo antes
do Planning começar,
para que o timebox
seja suficiente para
essa reunião!
●
Em preparação para
essa reunião, o P.O. já
deve ter olhado as
histórias mais prioritárias
do projeto, confirmando o
entendimento delas com
o cliente, melhorando sua
clareza, quebrando
grandes funcionalidades
em partes menores que
já agreguem valor para o
cliente
14. A mecânica da reunião
●
Enquanto não passar um pouco do
que o time consegue fazer na Sprint:
●
P.O. explicando o item de maior
prioridade da visão de negócios;
●
Desenvolvedores tiram dúvidas de
entendimento e o discutem
tecnicamente;
●
Desenvolvedores atribuem uma
estimativa de esforço à história.
●
Desenvolvedores e P.O. negociam o
Sprint Backlog
●
Time todo monta uma meta para a
Sprint
15. Resumindo a reunião
●
toda Sprint começa com
uma reunião para
entendermos os itens a
serem feitos, planejarmos
o que cabe no tempo
disponível e definirmos a
meta para o time nessa
Sprint. A reunião consome
5% do tempo da Sprint
então, para Sprint de uma
semana, a reunião dura
no máximo 2 horas.
16. User story?
Mas o que chamamos de uma história de usuário?
●
um item que agrega valor
pro usuário
●
Uma história representa
algo que agrega valor para
o usuário da aplicação.
Seja no Product Backlog,
como um item a fazer, ou
no nosso histórico do que
foi feito no projeto,
histórias representam o
valor que agrega(re)mos
para o usuário!
18. O que é Product Backlog?
●
uma lista ordenada
de todos os requisitos
que se tem
conhecimento de que
precisam estar no
produto.
19. Característica do Product Backlog
●
1. Priorização
●
O Product Backlog é
organizado de forma
a priorizar e detalhar
mais os requisitos
considerados mais
importantes.
●
2. Visibilidade
●
O Product Backlog
deve estar visível para
todo o Scrum Team
(Time de Scrum) para
que todos tenham
conhecimento das
funcionalidades
desejadas para o
produto que está
sendo desenvolvido.
20. Característica do Product backlog
●
3.Ordenação de itens
●
Ordenar os itens do
Product Backlog é uma
atividade contínua. Ou
seja, o Product Owner
está constantemente
fazendo ajustes na
ordem e no
detalhamento desses
itens, de acordo com
novas informações que
surgem sobre o produto
22. Ultimos pontos do Product backlog
●
O P.O. é responsável
por mantê-lo
atualizado e
priorizado de modo a
agregarmos o
máximo de valor
possível para o
cliente a cada
iteração.
●
a única pessoa que de
fato o altera é o Product
Owner -- inclusive, o papel
é chamado dessa forma
porque o P.O. é dono do
Product Backlog, Os itens
do Product Backlog são
sempre mutáveis: o P.O.
pode adicionar itens,
removê-los e re-priorizá-
los sempre que achar que
consegue agregar mais
valor ao projeto dessa for
23. Sprint Backlog
●
Simplificando: Uma vez que
itens cheguem ao topo do
Product Backlog, eles serão
discutidos em uma Planning
Meeting, quebrados em
alguns sub-itens técnicos e,
se escolhidos para serem
executados, esses itens e
sub-itens comporão o
chamado Sprint Backlog: a
lista ordenada de itens
funcionais e seus sub-itens
técnicos que serão feitos
durante essa Sprint.
●
Diferente do Product
Backlog, apenas o time
pode influenciar e alterar
o Sprint Backlog, o Sprint
Backlog é formado dos
itens mais prioritários do
Product Backlog e é uma
indicação séria de
problemas sistêmicos se
os itens mais prioritários
precisarem sofrer
grandes modificações
24. Bizu sobre o Sprint backlog
●
Se os itens mais
prioritários não
fizerem sentido nas,
digamos, 2 semanas
de Sprint, isso indica
que o P.O. não fez
um bom trabalho de
refinamento e de
descobrir com
usuários o que eles
realmente precisam
25. Quem altera os Backlogs?
●
o cliente pode pedir
que o PO altere o
Product Backlog, mas
não o Sprint Backlog
●
Product Backlog: apenas o
P.O. altera, mas todos
podem influenciá-lo, tanto
desenvolvedores, scrum
master e clientes
●
Sprint Backlog: o cliente não
pode alterá-lo ou influenciá-
lo. Apenas o time altera
esse backlog, renegociando
internamente o escopo
quando necessário,
quebrando melhor as
histórias em tarefas, etc.
27. O que é uma tarefa (task)?
●
Tarefas são subitens
de uma história, mais
focados na parte
técnica. servem para
conseguirmos
trabalhar
paralelamente sobre
uma história e, assim,
aumentar a velocidade
de produção de valor
para o usuário!
28. Diferença entre Product e Sprint Backlogs
●
O Product Backlog só
tem histórias e o
Sprint Backlog tem
histórias e tarefas.
●
o Product Backlog
foca no que agrega
valor para o usuário
(histórias)
●
Sprint Backlog
acrescenta a isso as
subdivisões técnicas
das histórias (tarefas)
29. Scrum Master
●
a função principal do
Scrum Master é focar no
processo e se assegurar
que o time esteja tirando
o maior proveito possível
dele. Um bom Scrum
Master é um facilitador e
coach excelente, que atua
como Líder Servidor, isto
é, livrando o time dos
problemas que o impede
de ter uma melhor
performance.
●
a pessoa que tem o
papel de Scrum Master
tem que entender muito
bem o Scrum e ser
capaz de passar isso
para todos os
envolvidos no projeto:
desenvolvedores,
Product Owner, clientes
e a própria organização
na qual o time está
inserido.
31. Como é a atuação do Scrum Master nas reuniões
do time?
●
ele age apenas
quando necessário,
para ajudar o time a
chegar no objetivo da
reunião dentro do
timebox
●
manter a reunião
produtiva e dentro do
timebox combinado.
Ele não coordena
reuniões como faria
um chefe tradicional,
apenas ajuda o time a
manter o foco!
32. Product Owner (P.O.)
●
Durante o andamento do projeto
que usa Scrum, o Product Owner
(P.O.) deve:
●
participar das reuniões;
●
responder dúvidas dos
desenvolvedores sobre histórias
ou indicar quem poderia
respondê-las melhor;
●
deixar claro para o time qual o
valor de negócios de cada Sprint;
●
obter feedback e expectativas
dos diversos clientes e extrair
delas as necessidades;
●
manter o Product Backlog
atualizado, isto é:
●
adicionar itens novos;
●
remover itens
desatualizados;
●
revisar a priorização do
backlog constantemente;
●
refinar histórias mais
importantes em
preparação para o
próximo Planning.
33. Qual a diferença entre um cliente e um product
owner?
●
Diferentemente de
clientes/usuários, o P.O.
é uma pessoa só e
trabalha diariamente
com o time no decorrer
do projeto. Product
Owner é uma pessoa
que faz parte do time e
está disponível para
ajudá-lo a produzir o
maior valor possível
para os clientes.
34. Como o time deve proceder quando um usuário ou
cliente pede uma funcionalidade diretamente para o
desenvolvedor?
●
leva o cliente até o
P.O. e eles
conversarão para
adicionar o pedido ao
Product Backlog se
fizer sentido
●
O Product Owner mantem
o Product Backlog
atualizado com o objetivo
de agregar o maior valor
possível a cada momento.
Se esse pedido não foi
priorizado, pode haver
excelentes razões para
isso e deixar o cliente se
intrometer sem passar
pelo P.O. pode ser
prejudicial para a entrega
de valor do projeto.
35. Atualização do Backlog
●
O P.O. adiciona novos itens,
remove itens que não fazem
mais sentido e, muito
frequentemente, reprioriza as
histórias para aumentar o valor
a ser agregado pelo time.
●
Outra atividade é o
refinamento das histórias mais
prioritárias do Product Backlog
em histórias menores que
ainda agreguem valor para o
cliente.
36. Time dos desenvolvedores
●
A vida dos
desenvolvedores dentro de
um ambiente ágil é mais
complexa do que em um
ambiente tradicional, onde
eles podem apenas seguir
ordens e já fazem seu
trabalho. Ao mesmo tempo,
as possibilidades de
crescimento pessoal aqui
são muitas e a autonomia
dada a esse grupo é muito
interessante.
●
Desenvolvedores devem:
●
Decidir a abordagem técnica
para os problemas
apresentados;
●
Trocar informações e ajudar os
companheiros de time;
●
Estimar as histórias durante o
planning;
●
Escolher sua próxima tarefa a
ser feita, considerando as
prioridades da Sprint;
●
Buscar a qualidade do projeto
e a redução de erros.
37. Time dos desenvolvedores
●
desenvolvedores não
devem:
●
Considerar dúvidas
técnicas como
impedimentos - elas são
apenas problemas;
●
Esperar que alguém
decida as atividades a
serem feitas por eles;
●
Se recusar a aprender um
pouco sobre outras áreas
de desenvolvimento.
38. Por que os papéis de Scrum Master e Product
Owner não podem ser ocupados pela mesma
pessoa?
●
Há muitas responsabilidades
focadas na entrega de valor
que são dos Product Owners.
Há muitas responsabilidades
focadas em processos que
são do Scrum Master.
●
Juntar ambos os papéis é um
acúmulo muito grande de
responsabilidades e
frequentemente leva ao
desbalanceando o equilíbrio
do Scrum.
39. conceito de Melhoria Contínua
●
Qualquer ponto que causa dor ao
time no momento é uma
oportunidade de melhoria para o
futuro -- e é um treino contínuo
enxergar problemas como
oportunidades.
●
Melhoria contínua é também, na
minha opinião, uma forma de pensar
que nos torna mais responsáveis
pelo estado em que nos
encontramos no momento. É uma
responsabilização que ajuda a sair
do hábito de reclamar e procurar
culpados. E é algo que pode ser
levado para outros aspectos da vida
facilmente.
40. Quem é o desenvolvedor?
●
Programadores,
arquitetos, DBAs,
analistas, testers,
pessoas de
usabilidade e
quaisquer outros
papéis que ajudem o
produto a evoluir.
