O documento fornece uma introdução ao framework Scrum, descrevendo seus princípios, papéis, artefatos e eventos. Resume os principais conceitos do manifesto ágil e explica que Scrum é um framework ágil criado para gestão e desenvolvimento de software de forma iterativa.

1. Carlos Lucas Brandão
lucasbrandaobh@gmail.com
Introdução ao Scrum

2. Agenda
 O que é desenvolvimento Ágil
 Princípios do Manifesto Ágil
 O que é Scrum?
 Papeis
 Artefatos
 Eventos
 Documentação

3. O QUE É DESENVOLVIMENTO ÁGIL?
 O desenvolvimento ágil é um fruto da constatação feita, de forma
independente, por diversos profissionais renomados na área de engenharia
de software, de que, apesar de terem aprendido segundo a cartilha
tradicional, só conseguiam minimizar os riscos associados ao
desenvolvimento de software, pensando e agindo de forma muito diferente
do que tradicionalmente está nos livros.
 Assim foi criada a “Aliança Ágil”.

4. Manifesto Ágil
 O Manifesto Ágil criado em 2001 é um conjunto de práticas que tem como
principal objetivo nortear as ações das equipes ágeis, mantendo-as focadas
no que realmente agrega valor tanto para o projeto quanto para o cliente.
 Baseado em 12 princípios, ele se tornou uma espécie de guia que orienta as
ações dos times ágeis de projetos, maximizando os resultados.
 Um grupo composto de grandes nomes do mundo do software, tais como:
Kent Beck, Jim Highsmith, Alistair Cockburn, Martim Fowler, Ken Shwaber
e Jeff Sutherland.
Criaram o Manifesto Ágil.
http://agilemanifesto.org

5. Valores Manifesto Ágil
 Ou seja, mesmo havendo valor aos itens à direita, valorizamos
mais os itens à esquerda.
 “Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
trabalho, passamos a valorizar:”

6. O que é Scrum?

7.  Estratégia em um jogo de rugby onde jogadores colocam uma bola quase perdida novamente em
jogo através de trabalho em equipe.
 A participação de todos é essencial.
 A falta de comprometimento de um membro pode fazer a formação cair.
 Então a união e o foco no objetivo (mover a bola em direção ao gol) é primordial.
Scrum no Rugby:

8. O que é o Scrum?
 Criado por Jeff Sutherland e Ken Schwaber

9.  É um framework que tem como princípio o manifesto ágil .
 Atualmente é o framework mais utilizado no desenvolvimento e gestão de um de software ágil.
O que é Scrum?

10. O que é Scrum?
 Surgiu no inicio da década de 90.

11. O que é Scrum?
 Surgiu no inicio da década de 90.
 Método em Cascata, Complexidade em prever riscos

12. O modelo em cascata ou waterfall, conforme definido por Royce (1970)

13. O que é Scrum?
 Surgiu no inicio da década de 90.
 Método em Cascata, Complexidade em prever riscos
 2015 - Standish Group – Pesquisa Chaos Report

16. Principais Características do Scrum
 Trabalha de forma iterativa e incremental
 Equipes mutli-funcionais e auto-organizadas

17. Principais Características do Scrum
 Foco em prioridade: equipe sabe por onde começar e o que é mais prioritário para o
cliente.
 Objetividade: metas menores (por sprints) atingíveis e claras.

18. Principais Características do Scrum
 Visibilidade: clara visibilidade do que está completo e pendências o que reduz os riscos e as
incertezas associadas ao projeto.

19. Principais Características do Scrum
 Aumento do ROI(return on investment): entregando funcionalidades antes para a
validação do cliente.
 Maior flexibilidade a agilidade: permite rever o planejamento, mudar de direção ou
fazer adaptações para as próximas iterações.
 Não há prática de engenharia prescrita (o Scrum adequa-se a todas)

20. Visão Geral do Ciclo de Vida

21.  As pessoas que desempenham esses papeis são igualmente responsáveis e
responsabilizadas pelos resultados do trabalho e, assim, se comprometem com o
projeto.
Papéis: o Time de Scrum

22. Scrum Team

23. Quem é o Time de Desenvolvimento?
 Grupo multidisciplinar de pessoas
 O Time gera, em cada Sprint, um Incremento do Produto pronto.
 Suficientemente pequeno, de forma que se comuniquem efetivamente e se auto-
organizem;
 Desejável de 3 a 9 pessoas, existem times de 800 pessoas.

24. Product Owner

25. Quem e o Product Owner?
 Também chamado de P.O., pessoa responsável pela definição do produto.
 Garante e maximiza a partir do trabalho do Time, o ROI do projeto para os clientes.
 Insere, detalha, remove e priorizando itens de trabalho do produto no Product Backlog.

26. Scrum Master

27. Quem é o Scrum Master?
 Facilita o trabalho do Time de Scrum no dia a dia e nos eventos do Scrum.
 Faz com que a equipe viva os valores e práticas de Scrum.
 Remove Impedimentos.
 Dentro do Scrum não possui posição hierárquica acima do Time.

28. Artefatos do Scrum

29. Artefatos do Scrum
Product
Backlog
Sprint
Backlog
Burndown
charts

30. Product Backlog

31. O que é o Product Backlog?
 É uma lista ordenada ou priorizada de itens sobre os quais o Time de Desenvolvimento
trabalhara no decorrer do projeto.
 Gerenciado pelo Product Owner, contem o que será desenvolvido pelo Time de
Desenvolvimento para o produto.
 Pode também conter melhorias a serem realizadas, correções de problemas, questões
técnicas, pesquisas que forem necessárias etc.

32. Exemplo Product Backlog

33. Bug tracking?
 O Product Backlog e a única fonte de trabalho a ser
realizado no produto pelo Time de Desenvolvimento.
 Esse trabalho também inclui as correções de erros
(ou bugs) encontrados no sistema.
 Para o desenvolvimento de software, o uso de
ferramentas de bug tracking, portanto, se sobreporia
ao uso do Product Backlog. Logo, não é
recomendado.

34. Sprint Backlog

35. Visão Geral do Ciclo de Vida

36. O que é o Sprint Backlog?
 Lista de itens selecionados do topo do Product Backlog.
 Existe apenas no contexto de seu Sprint correspondente.
 Criado na reunião de Sprint Planning.
 Deixa de existir após as reuniões de Sprint Review e Sprint Retrospective.
 Pertence ao Time de Desenvolvimento.

37. Release Burndown

39. Eventos do Scrum
Daily Scrum Sprint Planning
Sprint RetrospectiveSprint Review

40. Daily Scrum

41. Daily Scrum
 Parâmetros
 Diário
 Máximo de 15 minutos
 Todos em pé!
 Não é para a solução de problemas
 Todo mundo é convidado
 Apenas os membros da equipe, ScrumMaster, P.O. podem falar
 Ajuda a evitar reuniões adicionais desnecessárias

42. Três questões, para todos
 1) O quê você fez ontem?
 2) O quê você vai fazer hoje?
 3) Quais os problemas encontrados?

43. Evita: Como um projeto atrasa um ano?
 Um dia por vez ...
 Qualquer deslize pode ser corrigido de imediato

44. Ajuda a manter as promessas!

45. Daily Scrum
 As respostas não são um “relatório” para o Scrum Master
 Elas são COMPROMISSOS perante os pares

47. Sprint Planning Meeting

48.  Objetivo: planejar o ciclo de desenvolvimento (Sprint) que se inicia
 Quando: no primeiro dia do Sprint, iniciando-o
Sprint Planning Meeting

49.  Duração: máxima proporcional a 8 horas para Sprints de 1 mês
 Participantes obrigatórios:
Sprint Planning Meeting

50.  Todos os membros do Time participam da reunião com igual poder de opinião e decisão,
quaisquer que sejam suas áreas de conhecimento ou de atuação.
Sprint Planning Meeting

51. Planning Poker

52. Objetivos dos quadros
O objetivos dos quadros é dar maior visibilidade no andamento das histórias.
O quadro padrão do Scrum possui 4 colunas, são elas:

53. Sprint Review Meeting

54. Sprint Review
 Objetivo: obter feedback sobre o Incremento do Produto desenvolvido no Sprint
(inspeção e adaptação do produto)
 Quando: no ultimo dia de cada Sprint, antes da reunião de Sprint Retrospective

55.  Duração: máxima proporcional a 4 horas para Sprints de 1 mês
 Participantes obrigatórios:
 Usuários e quaisquer outras partes interessadas que possam prover feedback
Sprint Review
stakeholders

56. Sprint Review
 Saidas esperadas:
 Feedback para o P.O. atualizar o Product Backlog.
 Visibilidade sobre o produto para clientes e demais partes interessadas.

57. Sprint Retrospective

58. Sprint Retrospective
 Objetivo: melhoria incremental continua na forma como o Time de Scrum faz o
seu trabalho (inspeção e adaptação)
 Quando: no ultimo dia de cada Sprint, após a reunião de Sprint Review

59.  Duração: máxima proporcional a 3 horas para Sprints de 1 mês
 Participantes obrigatórios:
Sprint Retrospective

60. Sprint Retrospective
 Saídas esperadas:
 Planos de ação para melhorias a serem realizados já no próximo Sprint.

61.  Não deve ser utilizada para se identificarem ações de melhoria no produto.
 O principal foco identificar do que precisa ser melhorado na forma de trabalho do
Time de Scrum.
Sprint Retrospective

62.  Não se deve apontar erros individuais.
 O foco dos participantes deve se manter no desejo objetivo de melhoria.
 Aprendendo-se com os erros cometidos.
Sprint Retrospective

63.  O trabalho de inspeção envolve a capacidade dos participantes de expor, em algum
grau, suas próprias limitações e pontos fracos.
Sprint Retrospective

64.  Buscar culpados para os problemas que aconteceram durante o Sprint ou
“lavar roupa suja” tem efeitos extremamente negativos sobre o andamento
da reunião e sobre seus resultados.
Sprint Retrospective

65. Documentação

66. Scrum não tem documentação?

67. Mito!
 Na verdade Scrum é um framework que define o processo de trabalho, boas práticas e
disciplinas de Engenharia de Software podem e devem ser inseridas conforme a
necessidade da sua organização.
 Scrum não determina como criar, por exemplo, algum artefato, ele se remete apenas
ao processo.
 Junto a Scrum, especificamos nosso software.
 Normalmente utilizamos UML.
Scrum não tem documentação?

68. Valores Manifesto Ágil
 Ou seja, mesmo havendo valor aos itens à direita, valorizamos
mais os itens à esquerda.
 “Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
trabalho, passamos a valorizar:”

69. Conclusões
 Benefícios com adoção do Scrum
 Respostas rápidas a mudanças;
 Maior qualidade;
 Aumento de produtividade;
 Maior assertividade e visibilidade;
 Cooperação e autonomia;

70. • Não adianta dizer que Scrum não funciona, se o processo está sendo executada de
forma errada.
• Scrum não resolve os problemas técnicos, como elaboração de documentação e de
requisitos complexos, mas colabora para isso.
• Projetos desenvolvidos em Scrum, não finalizam mais rápido, a diferença é a entrega
do produto de forma diferente.
• A chave do Scrum é a comunicação, como em qualquer outra metodologia de
desenvolvimento de software.
• Devido ao auto-gerenciamento do time, o mesmo é responsável pela a entrega, ou
seja, se o time falhar todos falham.
Considerações Finais

71. Quem usa o Scrum?

73. Referências
 http://agilemanifesto.org/iso/ptbr/manifesto.html
 http://www.knowledge21.com.br/
 https://www.scrumalliance.org/
 https://www.casadocodigo.com.br/products/livro-scrum

74. Obrigado!
74

75. Porco ou Galinha – Papeis no SCRUM

76.  Na fábula, o porco está altamente comprometido com o negócio, com “a própria
carne”. Já a galinha está comprometida apenas em fornecer os ovos.
 Neste sentido refletir um pouco melhor sobre isso irá nos ajudar a definir a nossa
postura e evitar aborrecimentos e frustrações em todas as partes envolvidas (quer em
um projeto, quer não).
 Existem situações em que devemos ser porcos e situações em que devemos ser
galinhas. Não se esconder quando você quer se comprometer apenas parcialmente. As
pessoas tendem a achar que isso pode soar negativamente mas, mais nestas situações
vale a pena jogar limpo. Será muito melhor do que simplesmente fingir que está
comprometido sem estar de verdade.
 Li em um blog esta frase e gostei… “Honesto você deve ser sempre. Comprometido
é uma opção sua de acordo com a situação.”.

77. Porco ou Galinha na prática
 Os Porcos são os que estão comprometidos com os objetivos do projeto todo. São o
Product Owner, o Scrum Master e a equipe. Estes definem o sucesso da implantação e
continuidade do Scrum em uma empresa. (São esses com “seu bacon na linha”)
 Já as galinhas são os envolvidos, que não estão necessariamente dispostos a“fazer
de tudo” pelo projeto. São todas as demais pessoas que não estão no dia-a-dia do
projeto, incluindo usuários, gerentes, em alguns casos infra, etc.