Scrum é uma metodologia ágil para desenvolvimento de software que utiliza equipes multidisciplinares, ciclos curtos de desenvolvimento (sprints) e reuniões diárias para acompanhamento do progresso. O Product Owner define as prioridades do projeto no Product Backlog e o Scrum Master lidera a equipe no alcance dos objetivos definidos para cada sprint.

1. Scrum
Desenvolvimento ágil

2. Uma breve introdução
Concebido como uma metodologia para a indústria
automobilística, com nome análogo a formação usada pelos
times de Rugby, o Scrum visa ser uma metodologia de alcance
de objetivos de maneira ágil.
Suas equipes são enxutas e multidisciplinares, seus
processos não são engessados e mudanças fazem parte da
rotina.
A comunicação presencial entre a equipe é mais valorizada
que a geração de calhamaços de documentos impessoais.

3. Características
- Iterativo: Pequenos ciclos de desenvolvimento.
- Incremental: Construção de funcionalidades em
paralelo.
- Dinâmico: Mudanças são bem-vindas.
- Ágil: Planejamento de curto prazo, possibilidade de
responder a adversidades de maneira mais flexível.

4. Alguns exemplos reais
- Google
- Apple
- Amazon
- Spotify

5. Personas - P. O.
O papel do P.O. (product owner), é garantir os objetivos
dos stakeholders. É fundamental que possa contar com
uma equipe hábil e preparada para mudanças de última
hora.
Controla o backlog, prioriza as demandas e fiscaliza o
resultado.

6. Personas - Scrum Master
O Scrum Master deve prezar sempre pela evolução da
sprint, devendo tomar as atitudes necessárias para ajudar
o time a resolver qualquer problema, principalmente
aqueles que ultrapassam o âmbito técnico.
Participa das reuniões diárias, do planejamento da
sprint e acompanha o burn down chart.

7. Personas - Time de
desenvolvimento
Engenheiros, designers e programadores; todos
àqueles que estão envolvidos diretamente com a
construção das soluções.
Equipes multidisciplinares e auto-gerenciáveis.

8. Ferramentas - Product Backlog
Repositório de demandas conhecidas e priorizadas,
definidas pelo P.O.
Base para o planejamento das próximas sprints.
Equivalente ao Roadmap.
Pode ser alterado a qualquer hora pelo P.O.

9. Ferramentas - Sprint Backlog
Repositório das tarefas da sprint corrente.
Não deve ser alterado durante a sprint.
Tarefas distribuídas entre a equipe, sem interferência
do P.O.

10. Ferramentas - Sprint
Espaço de tempo definido para o atingimento de um
determinado objetivo.
As sprints tem como característica serem de curta
duração, não devendo haver interrupções ou mudanças
durante seu curso.

11. Ferramentas - Burn down Chart
Gráfico que exibe a estimativa de sucesso de uma
sprint, pode ser gerado manualmente ou através de uma
ferramenta integrada ao desenvolvimento da sprint.
É possível prever se a sprint falhará, acompanhando a
tendência deste gráfico.

12. Ferramentas - Burn down Chart

13. Controle - Sprint planning
Reuniões feitas com toda a equipe para que o próximo
sprint backlog seja definido.
O product backlog deve ser o guia desta reunião, pois é
nele em que os objetivos e prioridades foram traçadas,
servindo então de base para o planejamento da próxima
sprint.
Deve-se prezar pela objetividade, reuniões por volta de
2 horas são consideradas ideais.

14. Controle - Daily Meeting
Reuniões diárias entre o time e o scrum master.
Curtas, no máximo 15 minutos.
Recomenda-se realizar a reunião em pé, encurtando e
tornando a mais objetiva.
Identificação de problemas que podem impedir o
funcionamento da sprint; resolução pós-reunião.

15. Controle - Daily Meeting
Indagações que podem ser feitas a cada membro do
time de desenvolvimento:
- O quê eu fiz ontem?
- O quê vou fazer hoje?
- Existe algo que impeça o time de alcançar o objetivo?

16. Controle - Definição de pronto DoD
DoD (Definition of Done), ou definição de pronto, é um
documento que contém os passos que uma release deve
ser submetida para ser considerada pronta para funcionar
em ambiente produtivo.
Definido por todo o time, deve ser freqüentemente
revisto e revisitado ao final de cada sprint.

17. Controle - Sprint retrospective
Uma rápida reunião entre o time, cerca de 30m.
Visa apontar as maiores dificuldades encontradas no
decorrer da última sprint, encontrar pontos de falha e
pensar alternativas para contorná-las.

18. Controle - Sprint review
Incentiva o time a olhar para entrega efetuada e pensar
na coerência técnica do projeto, avaliando o que foi
entregue diante do que era esperado.
Pode-se aproveitar uma única reunião para fazer a
retrospectiva e o review.

19. Evolução
Fatalmente, as primeiras sprints tendem a falhar. Seja
por desconhecimento da capacidade de entrega da equipe,
da falta de conhecimento da metodologia ou por algum
percalço encontrado pelo caminho.
Deve-se anotar os sucessos e fracassos para serem
revistos, não se deve procurar culpados individualmente,
mas sim soluções para o time.

20. Referências
- http://www.mindmaster.com.br/scrum/
- https://www.scrumalliance.org
- http://scrummethodology.com/

21. Obrigado
Gian Vizzotto - gfvizzotto@gmail.com