O documento resume os principais conceitos e práticas do framework Scrum para desenvolvimento de software, incluindo o ciclo de vida de um projeto Scrum com Product Backlog, Sprints, Daily Scrum, Planning, Retrospectiva e papéis como Product Owner e Scrum Master.

1. Desenvolvendo software com
qualidade e agilidade.

2. Sabe os problemas?

3. Eles podem se tornar…

4. Pesadelos!

5. E mais pesadelos!

6. Problemas Perversos.
> Mudanças rápidas nos requisitos.
> Design.
> Longa Implementação.
> Pouca cobertura de testes.
> Implantação duvidosa e temida.

7. Resolvemos assim:

8. Quando usar?

9. Quando usar?
> Pequenas startups
> Grandes empresas.
> Desenvolvimento interno.
> Desenvolvimento contratado.
> Sistemas contratados com preço fixo.
> Etc.

10. Scrum?
> Alguns dizem que SCRUM não é uma metodologia, mas sim um
framework.
> Não espere que ele diga o que fazer.
> E sim, você vai ter que adaptar o processo para a sua situação.

11. Nokia Scrum Standards
> Uma equipe de Scrum deve ter um product owner e saber
quem ele é.
> O product owner deve ter um product backlog com
estimativas criadas pela equipe.
> A equipe deve ter um gráfico burndown e saber sua
velocidade. Não deve haver nenhuma interferência externa sobre
a equipe durante uma sprint.

12. Ciclo

13. Product Backlog
> É o coração do SCRUM.
> Resume-se a uma lista de requisitos, ou melhor, coisas que o
cliente deseja.
> Também chamado de “histories”.
> Atrela as estimativas e importância para o P.O. em sua
descrição.

14. Sprint Backlog
É uma lista de atividades (histories) que um time vai atuar dentro
de uma sprint e pode ser representado pela Kanban.

15. Kanban

16. Sprint
Uma sprint é a unidade básica do desenvolvimento em Scrum.

17. Product Owner
> Responsável por definir os itens que compõem o Product
Backlog e os prioriza nos plannings.
> Deve usar constantemente o produto, para poder revisar os
requisitos.
> Discutir com o time é sempre saudável.
> Analisar o uso dos concorrentes.
> E se posicionar como usuário. Se um produto serve a um
usuário técnico, o PO deve ser capaz de entendê-lo.

18. Scrum Master

19. Scrum Master
> Ele é quem assegura que a equipe respeite e siga os valores e as
práticas do Scrum.
> Trabalha junto ao P.O para assegurar que o mesmo esteja alinhado a
cada sprint.
> Também é responsável por verificar se todos os membros do time
estão felizes e realizados.

20. Scrum Master
> Atua como facilitador do daily scrum e é o responsável por remover
quaisquer obstáculos que sejam levantados pela equipe durante as
daylies.
> Geralmente é exercido por um gerente de projeto ou um líder técnico
mas em princípio pode ser qualquer pessoa da equipe.

21. Planning
> Reunião na qual estão presentes o P.O, o S.M e todo o time, bem como
qualquer pessoa interessada que esteja representando a gerência ou o
cliente.
> O P.O descreve as funcionalidades de maior prioridade para a equipe.
> A equipe faz perguntas durante a reunião de modo que seja capaz de
quebrar as funcionalidades em tarefas técnicas, após a reunião.

22. Planning
> A equipe se dissipa do S.M e P.O para conversar e decidir
quanto ela pode se comprometer a fazer no sprint que será
iniciado.
> Ela sempre será responsável em determinar o quanto será
capaz de fazer.

23. Planning Poker

24. Planning Poker
> Discute-se e estima-se sobre as histories selecionadas.
> Cada membro da equipe é responsável por jogar tanto para
complexidade quanto para estimar o tempo que julga gastar
em cada tarefa.

25. Code Hard!
Organize your self.
Execute it!

26. Daily Scrum
O que fez ontem? O que fará hoje?
Há algum impedimento no caminho?

27. Daily Scrum
> Reunião diária que tem o objetivo de apresentar o que foi feito no dia anterior
> Um ótimo ponto para identificar impedimentos e priorizar o trabalho a ser
realizado no dia que se inicia.
> São geralmente realizadas em um mesmo horário – geralmente pelas manhãs.
> Não deve ser utilizada como uma reunião para solucionar problemas.
> Não é uma reunião de status report na qual um chefe fica coletando informações
sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da
equipe assumem compromissos perante os demais.

28. Burndown Chart.

29. Review
> Feita ao final de cadas Sprint.
> Demonstração das novas funcionalidades
> O P.O, o S.M, clientes ou engenheiros de outros projetos
também participam.
> O projeto é avaliado em relação aos objetivos do sprint,
determinados durante o planning.

30. Retrospectiva

31. Retrospectiva
> O que foi bom e o que foi ruim durante a sprint?
> Nem sempre é necessario reportar o que está diretamente
envolvido com a sprint, mas qualquer coisa que tenha te
desagradado ou entusiasmado.
> O S.M apresenta o balanço da retrospectiva aos outros
colaboradores através de um quadro, com a finalidade de
colaborar para uma melhor qualidade de vida dentro do
empreendimento.

32. Obrigado =)
Gil Gomes > gil.gomes@giran.com.br
Uriel Juliatti > uriel.juliatti@giran.com.br
Giran Soluções e Ecommerce
http://www.giran.com.br