1) O documento introduz os conceitos e origens do framework Scrum, utilizado para gestão de projetos ágeis; 2) Scrum surgiu a partir da observação de equipes de rugby e prega a importância da interação, feedback constante e adaptação; 3) O framework define papéis como Product Owner, Scrum Master e time Scrum, além de eventos como Sprints e cerimônias para entrega contínua de valor.

1. +
Introdução ao Scrum
Tiago Machado
tiago@synapses.com.br

2. + 2
Introdução ao Scrum

3. + 3
Origem do termo
 O scrum é uma situação freqüente no Rugby, geralmente
usada após uma jogada irregular ou em alguma penalização.
Os jogadores das duas equipes se agrupam e se colocam uns
contra os outros.
 O jogador da equipe que não cometeu a infração insere a bola
no meio do "túnel" formado pelas duas primeiras linhas de
cada equipe com a finalidade de que os jogadores da sua
equipe consigam ganhar a bola.
“Na abordagem no estilo de rugby, o desenvolvimento surge a partir de
constante interação, onde um grupo disciplinado trabalha junto do início ao
fim.”
Nonaka e Takeuchi – The New New Product Development Game - 1986

4. + 4
O que é o Scrum?
 É um framework de processo leve para gestão de projetos,
seguindo os valores e princípios ágeis;
 É um esqueleto de processo que estabelece um conjunto de
práticas e papéis;
 Foco na entrega de maior valor de negócio no menor tempo;
 Suas ênfases estão em: comunicação, trabalho em equipe e
flexibilidade;
 Não descreve o que fazer em cada situação. É usado para
trabalhos complexos nos quais é impossível predizer tudo o
que irá ocorrer.

5. + 5
Teoria da Complexidade
A = Sistemas simples
B = Sistemas complicados
C = Sistemas complexos
Desconhecidos
D = Sistemas caóticos
D
No patterns
Requisitos C
Emergent Practices (Scrum)
B
Best / Good Practices (PMBOK)
Conhecidos A
Definida Tecnologia Indefinida

6. + 6
Teoria do Scrum
 O Scrum é fundamentado na teoria de controle de processos
ricos e emprega uma abordagem iterativa e incremental para
otimizar a previsibilidade e controlar riscos.
Processo Definido x Processo Empírico:
 Processo Definido: baseado em leis fundamentais, busca a cada
execução conquistar o mesmo resultado, utilizando um processo
conhecido que transforma um conjunto de variáveis conhecidas. Basta
repetir a fórmula correta, e o sucesso é garantido.
 Exemplo de aplicação: Engenharia Civil (PMBOK)
 Processo Empírico: nem todas as variáveis são conhecidas, o sistema
está começando a ser compreendido, é complexo, as necessidades
ainda não foram totalmente identificadas e com o tempo pode ser
alterado.
 Exemplo de aplicação: Desenvolvimento de Software (Scrum)

7. + 7
Modelo tradicional em cascata
Determinismo
Um processo de
desenvolvimento
previamente conhecido por
gerar determinados
resultados com base nas
especificações, gerará
resultados semelhantes
sempre que suas regras
forem rigidamente
seguidas.
Problema: baseia-se em premissas que
não se aplicam ao trabalho de
desenvolvimento de software.

8. + 8
Tipos de profissionais
 Trabalhador manual
 Trabalhador do conhecimento
Para atividades que envolvem trabalhadores manuais, erros podem e
devem sempre ser evitados, e os processos rígidos e determinísticos
ajudam a alcançar este objetivo.
Já para atividades que envolvem trabalhadores do conhecimento, erros
devem ser encarados como coisas naturais, saudáveis e até inevitáveis.
“Tentar sistematizar ou impor metodologias rígidas ao processo de
desenvolvimento, visando o determinismo, no máximo torna as
pessoas defensivas e pouco criativas."
Ken Schwaber

9. + 9
Resultados do desenvolvimento
tradicional
Bem sucedidos – O projeto é
finalizado no prazo, dentro do
orçamento e contendo todas as
funcionalidades especificadas.
Comprometidos – O projeto é
finalizado e um software
operacional é entregue, porém o
orçamento e o prazo ultrapassam
os limites estipulados, e, além
disso, o software entregue possui
menos funcionalidades do que o
especificado.
Standish Group International
Chaos Research 2002 Fracassados – O projeto é
cancelado em algum momento
durante o desenvolvimento.

10. + 10
História
• Takeuchi e Nonaka conceberam o Scrum como uma a alternativa de gerenciamento de projetos
em empresas de fabricação de automóveis e produtos de consumo. Eles notaram que projetos
usando equipes pequenas e multidisciplinares produziram os melhores resultados, e associaram
1986 estas equipes altamente eficazes à formação Scrum do Rugby.
• Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e
implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation
1993
• Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo no desenvolvimento de
softwares em todo o mundo
1995
• Manifesto Ágil
2001

11. + 11
Manifesto Ágil
 “Nós estamos descobrindo novas maneiras de desenvolver
software fazendo e ajudando outros a fazê-lo. Através deste
trabalho nós valorizamos:
 Indivíduos e interações mais que processos e ferramentas;
 Software funcionando mais que documentação compreensiva;
 Colaboração do cliente mais que negociação de contrato;
 Responder à mudança mais que seguir um plano;
 Isto é, muito embora valorizemos os itens da direita,
valorizamos mais os da esquerda!”
 http://www.agilemanifesto.org/

12. + 12
Influenciar pessoas por valores e
princípios e não por regras

13. + 13
Tipos de Projeto
Projeto Urgente Projeto Crítico Projeto sem orçamento
Escopo Escopo Escopo
Custo Prazo Custo Prazo Custo Prazo

14. + 14
Projetos Arriscados
Urgente e Crítico Crítico e Sem Orçamento Urgente e Sem Orçamento
Escopo Escopo Escopo
Custo Prazo Custo Prazo Custo Prazo

15. + 15
“Marcha para a morte”
 Urgente
Escopo
 Crítico
 Sem Orçamento
Custo Prazo

16. + 16
O mais comum em projetos Scrum
Escopo
Custo Prazo
Viagem de férias
Prazo: 7 dias
Custo: R$ 10.000,00
Escopo flexível

17. + 17
Pilares do Scrum
 Transparência: garante que aspectos do processo que
afetam o resultado devem ser veis para aqueles que
gerenciam os resultados.
 Inspeção: Os diversos aspectos do processo devem ser
inspecionados com uma frequência suficiente para que
es veis no processo possam ser detectadas. A
frequência da o deve levar em o que
qualquer processo modificado pelo prio ato da o.
 Adaptação: a partir da o, se um ou mais aspectos
do processo o fora dos limites veis e que o produto
resultante vel, devemos ajustar o processo
omais pido vel para minimizar desvios posteriores.

18. + 18
Papéis no Scrum
 Product Owner = PO
 Scrum Master = SM
 Scrum Team = ST
 Stakeholders
 Usuários
Não há mapeamento direto entre papéis tradicionais para os papéis do Scrum.
Não confundir papéis do Scrum com cargo.

19. + 19
Product Owner
 É o especialista do negócio e representa o cliente e os
stakeholders;
 Estabelece e comunica a visão do produto;
 Administra fundos e recursos do projeto;
 Decide quando serão liberadas as versões do produto;
 É responsável por compreender as necessidades do negócio e
apoiar o Scrum Team para sanar dúvidas sobre os requisitos do
projeto;
 É responsável por controlar o escopo e priorizar o que será feito
primeiro, com objetivo de assegurar a entrega dos requisitos mais
valiosos;
 Responsável pelo macro-gerenciamento do projeto.
 Pode ser visto como o “Gerente do Produto”.

20. + 20
Scrum Master
 É responsável por liderar o time ao sucesso, removendo
obstáculos e impedimentos;
 É o guardião do processo, assegurando que as práticas
do Scrum sejam utilizadas com a disciplina necessária;
 Organiza e conduz as cerimônias do Scrum;
 Faz um papel do tipo “coach” atuando ao lado dos
membros do Scrum Team e do PO;
 Ajuda o Time Scrum a entender e usar
autogerenciamento e interdisciplinaridade;
 É um agente de mudança, mobilizando e conscientizando
todos os envolvidos sobre o Scrum.
 Pode ser visto como “Gerente do Processo”.

21. + 21
Scrum Team
 Equipe multi-funcional que reune todas as especializações
necessárias para implementação do projeto;
 Estima o esforço necessário para implementar itens do Product
Backlog selecionados para o próximo sprint;
 Expande os itens do sprint backlog em atividades e gerencia seu
próprio trabalho até completar todo o sprint;
 Realiza a reunião diária para garantir a comunicação plena do time e
sincronismo de tarefas;
 Identifica pendências e impedimentos e comunica ao Scrum Master.
 Inspeciona e cobra de si mesmo o comprometimento necessário
para atingir as metas acordadas.
 Responsável pelo micro-gerenciamento do projeto.

22. + 22
Stakeholders
 São todos os interessados no software em desenvolvimento, a
começar por clientes (internos ou externos), usuários finais,
equipe de marketing e vendas, etc.
 São representados pelo Product Owner, que deve conhecer o
interesse e coletar idéias de todos para constituir o Product
Backlog e priorizá-lo constantemente.

23. + 23

24. + 24
E o gerente de projeto?

25. + 25
Comprometimento x Envolvimento
• Porcos – Time!
• Galinhas – Qualquer outra pessoa (PO, SM, Stakeholders).
“Galinhas” o podem dizer aos “porcos” como eles devem fazer seu trabalho.

26. + 26
Conceito: Time-box
 O Scrum é baseado em eventos de duração fixa;
 Garante que não iremos gastar mais esforço do que o
necessário;
 Se as cerimônicas e eventos não tivessem hora para terminar,
ninguém manteria o foco.
 Aumenta produtividade e efetividade.

27. + 27
Conceito: Sprint
 É o período dentro do qual um conjunto de atividades deve
ser executado para que seja possível entregar ao cliente uma
parcela de software útil (funcionando).
 Duração de 2 a 4 semanas. Depois de definida para o projeto,
não deve mudar;
 Sprint padrão na Synapses: 10 dias úteis;
 Não deve ter seu escopo modificado após seu início;

28. + 28
Sprint Goal – Meta do sprint
 É um objetivo proposto pelo aceito pelo time;
 O sprint goal é a meta que irá nortear e motivar o time;
Exemplos:
 Colocar uma versão beta do produto no ar para permitir
avaliação e demonstração do produto;
 Automatizar a funcionalidade de o de conta de
clientes s de um middleware seguro capaz de recuperar
es.

29. + 29
Fases do Desenvolvimento
Sprint Sprint
1 2
Pré-game Game Pós-game
Sprint Sprint
4 3

30. + 30
Pré-Game
 Análise e levantamento de requisitos
 Análise de viabilidade do projeto
 Criação do Documento de Visão do Projeto (DV)
 Público-alvo
 Definição do problema
 Benefícios
 Macro-funcionalidades
 Diferenciais competitivos
 Restrições de prazo e custo
 Riscos
 Papéis
 Configurações do Scrum
 Criação do Product Backlog inicial (priorizado);
 Montagem do Scrum Team / Scrum Master;
 Realização de Treinamentos Necessários
 Plano de Projeto Leve ou Release Plan (duração dos sprints, estimativa inicial,
velocidade, número de sprints, entregas).

31. + 31
Game
 A fase de game é onde o projeto será desenvolvido propriamente
dito.
 O desenvolvimento é dividido em sprints, conforme o tamanho e
complexidade do projeto.
 Cada sprint de 10 dias deve seguir a seguinte estrutura:
 Sprint planning 1 (4h)
 Sprint planning 2 (4h)
 Desenvolvimento + Daily Meeting (8 dias)
 Sprint Review (4h)
 Sprint Retrospective (2h)

32. + 32
Configurações do Scrum
 Tamanho do sprint
 Tamanho da equipe
 Definição de Ready = forma de garantir para o time que as
estórias estão prontas para serem desenvolvidas.
 Definição de Done = forma de garantir para o PO que as
estórias estarão concluídas e prontas ao término de um sprint.
 Scrum but
 Scrum and

33. + 33
Scrum típico na Synapes
 Tamanho do sprint: 10 dias úteis (começando na segunda)
 Equipe típica:
 PO
 SM
 Scrum Team = 2 desenvolvedores
 Definição de Ready:
 Estória priorizada no product backlog
 Escopo da estória definido e compreendido pelo PO
 Testes de aceitação elaborados pelo PO
 Definição de Done:
 Estória implementada conforme padrão de condificação Synapses
 Código-fonte revisado e auditado;
 Scripts de banco de dados revisados e auditados;
 Testes automatizados implementados;
 Deploy em ambiente de teste realizado;

34. + 34
Game – Fluxo de trabalho

35. + 35
Sprint Típico
S T Q Q S S T Q Q S
Planning 1 Desenvolvimento Review
Planning 2 Testes
Daily Scrum Retrospectiva

36. + 36
Cerimônias do Scrum
 Daily Scrum
 Sprint Planning 1
 Sprint Review
 Sprint Planning 2
 Sprint Retrospective

37. + 37
Sprint Planning 1 – O que?
 Reunião realizada todo início de sprint,
com duração de 4 horas (time boxed);
 Participação do Product Owner (PO),
Scrum Master (SM) e Scrum Team.
 Passagem do entendimento sobre o
backlog “pré-selecionado”, do PO para
o Scrum Team;
 O PO propõe a meta do sprint.
 O Scrum Team realiza a estimativa
inicial de tamanho para ver se é
possível cumprir a meta.

38. + 38
Sprint Planning 2 – Como?
 Reunião realizada após o Sprint Planning 1, com duração
estimada de 4 horas (time boxed).
 Planejamento do Scrum Team para seu próprio trabalho: ele refina
a análise do itens priorizados pelo PO no Product Backlog,
criando a lista de Sprint Backlog;
 O Product Owner pode estar presente para esclarecer o Backlog
do Produto e para ajudar a efetuar trocas.
 Se o Time concluir que ele tem trabalho demais ou de menos, ele
pode renegociar o Backlog do Produto escolhido com o Product
Owner.
 O time finaliza a estimativa iniciada no Sprint Planning 1,
reportando ao PO o resultado para confirmação ou pequenos
ajustes.
 Ao sair dessa reunião, o time deve ter quebrado cada estória em
tarefas. Cada tarefa deve ter duração máxima de 8h (ou 1 dia de
trabalho).

39. + 39
Daily Scrum
 Reunião realizada diariamente, sempre no mesmo lugar e
no mesmo horário, de preferência em pé.
 Duração estimada de 15 minutos;
 Participação do Scrum Team e Scrum Master; Demais
Stakeholders podem ser convidados como “galinha”;
 Cada participante responde 3 perguntas:
 O que você fez hoje?
 O que o atrapalhou?
 O que você fará amanhã?

40. + 40
Sprint Review
 Reunião realizada após cada Sprint, com duração máxima de
4 horas e participação do PO.
 O Scrum Team demonstra o trabalho realizado no Sprint.
 A demonstração deve ser “de produto funcionando” (nada de
powerpoint) e deve comprovar que os itens do Sprint Backlog
prioritários foram de fato desenvolvidos.
 O PO avalia o time com relação ao Sprint Goal.

41. + 41
Retrospective Meeting
 Reunião realizada após o Sprint Review, com duração máxima
de 2 horas, com a participação de todos os envolvidos;
 Alinhamento em grupo do que ocorreu no Sprint;
 Todos respondem 2 perguntas:
 “O que foi bem?” (WWW-What Went Well?)
 “O que pode ser melhorado?” (WCBI – What Can Be Improved?)
 Definição da responsabilidade sobre os itens WCBI para futura
avaliação.

42. + 42
Sprint Burndown Chart
 É o gráfico que indica o trabalho restante dentro de um Sprint,
baseado na pilha de Sprint Backlog (tarefas);
 É atualizado diariamente pelo time, após o Daily Scrum, para
refletir o progresso do Scrum Team naquele dia.

43. + 43
Scrum Board – Gestão a vista!
 Também conhecido como Task Board ou Agile Radiator;
 Exibe o progresso de cada atividade do Sprint Backlog;
 É atualizado diariamente, pelos membros da equipe;
 Deve ficar visível a todos.

44. + 44
Pontos de Atenção
 A equipe deve estar sempre comprometida e motivada. Ela é
quem deve fazer as estimativas, caso contrário, o time não se
compromete;
 A equipe deve ser multifuncional (não quer dizer que não podem
existir especialistas);
 O Product Owner deve ter disponibilidade e presença constante;
 As práticas de engenharia devem ser aplicadas (exemplo: XP);
 Não fique mudando os membros do time;
 Mantenha fixo o tamanho do Sprint ao longo do projeto;
 Não mude os requisitos de um Sprint durante sua execução.
 Nunca chegue à reunião de Sprint Planning com uma lista
inadequada de Product Backlog.

45. + 45
Scrum Smells
 Perda de ritmo
Sintoma: Sprints não possuem sempre o mesmo tamanho.
 “Galinhas falantes”
Sintoma: Galinhas fazem perguntas ou observações durante o
Daily Scrum.
 “Porcos faltantes”
Sintoma: Nem todos os porcos participam do Daily Scrum.
 Scrum Master atribui trabalho
Sintoma: As atividades são atribuídas pelo Scrum Master.
 Daily Scrum é para o Scrum Master
Sintoma: O Daily Scrum parece um status report para o Scrum
Master.
 Papéis especializados
Sintoma: O Scrum Team tem papéis muito especializados.

46. + 46
FAQ - Perguntas freqüentes
 Scrum pode ser utilizado apenas para projetos pequenos?
Não. Scrum é escalável por meio de “Scrum of Scrums”.
 O que acontece se não for possível finalizar todos os itens
previstos para o Sprint?
O tamanho do Sprint não pode mudar. Portanto, os itens que não
serão finalizados devem ser removidos do Sprint Backlog.
 O que acontece se todos os itens previstos para o Sprint
forem finalizados antes do fim do Sprint?
O tamanho do Sprint não pode mudar. Portanto, novos itens do
Product Backlog devem ser solicitados para o Product Owner.
 O que aconteceu com o Gerente de Projetos?
Não existe esse papel no Scrum. Os gerentes que gostam mais
da parte administrativa podem se tornar Product Owners. Aqueles
mais técnicos, Scrum Masters.

47. + 47
Perguntas?