1. Scrum
Gestão ágil de projetos
Autores:
Fábio Abrantes Diniz
Íthalo Bruno de Moura
Thiago Reis da Silva
Diego Grosmanniz

2. Scrum
Gestão ágil de projetos
Apresentadores:
Fábio Abrantes Diniz
Íthalo Bruno de Moura

3. 31% são cancelados
53% custam o dobro do estimado
Apenas 16% são completados no
prazo e custo estimados
* dados do CHAOS report

4. Mas por que?

5. Falta de envolvimento do usuário
Requisitos e especificações incompletas
Falta de suporte da direção
Falta de Pessoas e Recursos
Falta de ESTIMATIVAS!!!

9. Falhar é uma maneira muito
forte de aprendizado, mas é
preciso parar de
apontar culpados

10. Olá, Scrum!
Por que o nome Scrum?
O nome é proveninente de uma jogada do Rugby, onde
é demostrada a força de trabalho em equipe.
O Scrum do Rugby é formado por até 8 pessoas de
cada equipe.
O objetivo do Scrum no Rugby é avançar a bola oval no
campo adversário o máximo possível. Para isso é
necessário um ótimo trabalho em equipe.

12. Scrum é também um meio de
evidenciar os
problemas

13. Mas Scrum não
é bala de
prata*
* Não mata vampiros & afins
* Exige trabalho duro e comprometimento

14. PDCA
Plan, Do, Check, Act

15. Planejamento

16. Execução

17. Checagem

18. Exatamente o
que Scrum faz!

19. Quem usa o Scrum
• Microsoft
• Yahoo
• Google
• Lockheed Martin
• Philips
• Siemens
• Nokia
• BBC

20. Scrum tem sido usado para
• Software comercial
• Desenvolvimento interno (empresa)
• Desenvolvimento contratado (terceirização)
• Aplicações financeiras
• Sistemas embarcados
• Jogos
• Sistemas para controle de satélites
• Websites
• Telefones celulares

21. Características do Scrum
• As equipes se auto-organizam
• O produto evolui em uma série de “Sprints”
mensais
• Os requerimentos são listados em um “Product
Backlog”
• Não há prática de engenharia prescrita (o Scrum
adequa-se a todas)
• É uma das “metodologias ágeis”

22. Papeis no
scrum

23. Product Owner
• O representante do cliente

24. Scrum Master
• O Scrum Master lidera o time de
desenvolvimento

25. Scrum Team
• Scrum Team São os membros que
formam o time de desenvolvedores,
designers, consiste de 5 a 9 pessoas.

26. Papéis e Responsabilidades
► Define as funcionalidades do produto assim como conteúdo e
data das liberações;
Product Owner
► Responsável pela rentabilidade do produto;
► Prioriza as funcionalidades de acordo com o valor do mercado;
► Pode mudar as funcionalidades e priorizar a cada 30 dias;
► Aceita ou rejeita os resultados do trabalho.
► Garante que a equipe está completamente funcional e produtiva;
Scrum Master ► Facilita comunicação entre papéis e remove impedimentos;
► Protege a equipe contra interferências externas;
► Assegura que o processo é seguido;
► Coordena os encontros diários, revisão e planejamento da
iteração.
►Estimar itens do backlog
Team ► Tem o direito de realizar quaisquer atividades para alcançar
o objetivo da iteração desde que respeite os guidelines do
projeto;
► Auto organizados para entregar o que o PO quer.
© 2006 BenQ Mobile 26

27. Ciclo de Vida
Ciclo de vida do Scrum
Fonte: Adaptado de Improve It (2008)

28. Ciclo de Vida
Ciclo de vida do Scrum
Fonte: Adaptado de Improve It (2008)

29. Ciclo de Vida
Ciclo de vida do Scrum
Fonte: Adaptado de Improve It (2008)

30. O Product Backlog é uma lista de
todas as funcionalidades desejadas no
produto, estimadas pelo time e priorizadas
pelo
Product Owner.

31. Exemplo de Product Backlog

32. O Product Backlog
Emergente
Priorizado e estimado
Maior prioridade, mais detalhes
Priorização é tarefa do PO
Alinhado ao plano de negócios

33. O Product Backlog
Emergente
Priorizado e estimado
Maior prioridade, mais detalhes
Priorização é tarefa do PO
Alinhado ao plano de negócios

34. O Product Backlog
Emergente
Priorizado e estimado
Maior prioridade, mais detalhes
Priorização é tarefa do PO
Alinhado ao plano de negócios

35. O Product Backlog
Emergente
Priorizado e estimado
Maior prioridade, mais detalhes
Priorização é tarefa do PO
Alinhado ao plano de negócios

36. O Product Backlog
Emergente
Priorizado e estimado
Maior prioridade, mais detalhes
Qualquer um pode contribuir
Priorização é tarefa do PO
Alinhado ao plano de negócios

37. Sprints
• Representa um Time Box (uma iteração), dentro do
qual um conjunto de atividades deve ser executado
• Ocorre em um período de duas a quatro semanas
• Baseia-se na idéia de que um período constante
leva a um melhor “ritmo”
• O produto é projetado, codificado e testado durante
o Sprint
• No início de cada Sprint, faz-se um Sprint
Planning Meeting

38. Sprints
- Sprint Planning Meeting -
• É uma reunião de planejamento na qual:
o O Product Owner prioriza os itens do Product
Backlog
o O Scrum Team determina que atividades será
capaz de implementar durante o novo Sprint e
cria o Sprint Backlog
o O Scrum Team e o Product Owner definem um
objetivo para o Sprint
• O sucesso do Sprint será avaliado mais adiante no
Sprint Review Meeting em relação ao objetivo
traçado para o Sprint

39. Sprints
- Sprint Backlog -
• É uma lista de tarefas que o Scrum Team se
compromete a fazer em um Sprint
• Seus itens são extraídos do Product Backlog com
base nas prioridades definidas pelo Product
Owner
• Uma estimativa do tempo necessário para a
implementação das funcionalidades
• O Scrum Master mantém o Sprint Backlog
atualizado

40. Sprints
- Daily Scrum -
– É uma reúnião diária da equipe dentro do Sprint, que
tem por objetivo:
o Disseminar conhecimento sobre o que foi feito no
dia anterior
o Identificar impedimentos
o Priorizar o trabalho a ser realizado no dia que se
inicia
– Os impedimentos identificados devem ser tratados
pelo Scrum Master o mais rapidamente possível
Obs: o Daily Scrum não deve ser usado
como uma reunião para resolução de
problemas

41. Sprints
- Daily Scrum -
• Três Questões para todos:
• O que fizeste ontem?
• O que vais fazer Hoje?
• Há Algum obstáculo?
• Obs: As respostas não são um
relatório para o Scrum Master. Elas
são comprimissos dentro do Scrum
Team.

42. Sprints
- Sprint Review Meeting -
O ScrumTeam e o SCRUM Master
apresentam ao Product Owner os resultados
alcançados durante o sprint.

43. Sprints
- Sprint Retrospective -
O Sprint Retrospective ocorre ao final
de um Sprint e serve para identificar o
que funcionou bem, o que pode ser
melhorado e que ações serão tomadas
para melhorar.
Todos participam:
–Scrum Master
–Product Owner
–Scrum Team

44. Sprints
- Sprint Retrospective -
Em uma das maneiras de se conduzir
um Sprint Retrospective, a equipe
discute o que gostaria de:
– Iniciar a fazer
– Parar de fazer
– Continuar fazendo

45. Estudo de Caso: O Projeto XMPM (1)
Características do Projeto
• Software desktop destinado a usuários finais de celulares BenQ-
Siemens
• Projeto complexo com 300,000 LOC possuindo um ciclo de vida
médio
→ Interação complexa com o ambiente físico (celular)
→ O software deve suportar diferentes modelos de celulares e rodar em
diferentes distribuições do Linux
→ Uma série de versões intermediárias (builds) precisam ser
desenvolvidas e testadas.
→ Desenvolvido por três parceiros situados fisicamente em localidades
diferentes.
→ Necessidade de boa comunicação entre as equipes de
desenvolvimento.
→ Definição clara de papéis e responsabilidades.
© 2006 BenQ Mobile 45

46. Estudo de Caso: O Projeto XMPM (2)
Características do Produto
→ Suporte a 9 (nove) diferentes idiomas;
→ Possui instalador gráfico para as seguintes
distribuições (supporte oficial):
- Suse 10
- Ubuntu 5.10
- Mandriva 2006
XMPM
→ Algumas das funcionalidades do XMPM incluem:
- Sincromização de contatos, tarefas, notas e calendário entre o
telefone celular BenQ-Siemens e KDE-Kontact.
- Acesso à internet através de uma conexão GPRS.
- Acessa ao sistema de arquivos e suporte a diferentes formatos de
música.
© 2006 BenQ Mobile 46

47. Estudo de Caso: O Projeto XMPM (3)
Práticas adaptadas para o contexto do projeto
Sprint:
- No projeto XMPM foram usados 5 sprints e cada sprint com duração
de aproximadamente 30 dias.
- Sprints de 30 dias fornecem uma melhor visibilidade dos objetivos do pro
e comprometimento da equipe.
- Iterações mais curtas podem melhorar a visibilidade do projeto
e permitir que riscos e incertezas sejam eliminados
o mais rápido possível.
© 2006 BenQ Mobile 47

48. Estudo de Caso: O Projeto XMPM (4)
Práticas adaptadas para o contexto do projeto
Planejamento do Sprint:
- Duas reuniões são conduzidas no ínicio de cada iteração.
- A primeira é realizada internamente com o product owner e visa refinar e
priorizar o backlog do produto.
- A segunda é realizada com os parceiros e visa criar o backlog do sprint
de modo a atender os objetivos da iteração.
© 2006 BenQ Mobile 48

49. Estudo de Caso: O Projeto XMPM (5)
Práticas adaptadas para o contexto do projeto
Revisão do Sprint:
- A equipe apresenta no final de cada iteração os resultados
obtidos (software funcionando) para o product owner e parceiros.
- Esta prática impõe que a equipe trabalhe arduamente para alcançar os
objetivos prometidos para a iteração.
© 2006 BenQ Mobile 49

50. Estudo de Caso: O Projeto XMPM (6)
Reunião de Retrospectiva:
- O Scrum master e a
equipe participam desta
reunião.
- O que deu certo durante
o sprint e o que poderia
ser melhorado.
© 2006 BenQ Mobile 50

51. Estudo de Caso: O Projeto XMPM (7)
Práticas adaptadas para o contexto do projeto
Reuniões Diárias do Scrum:
- As reuniões diárias ajudam a saber o quê cada membro da
equipe está fazendo, compartilhar conhecimento e fornece uma
boa visão para o Scrum Master.
- O quê você fez desde o último report?
- O quê você irá fazer até a próxima reunião?
-Existe algum bloqueio para alcançar os objetivos
da iteração?
- Alguma lição aprendida ou decisão tomada?
© 2006 BenQ Mobile 51

52. Estudo de Caso: O Projeto XMPM (8)
Práticas adaptadas para o contexto do projeto
Builds Diários:
- Builds diários no branch de cada parceiro e um build semanal
no ramo principal do projeto (uso de padrões de gerência de
configuração).
© 2006 BenQ Mobile 52

53. Estudo de Caso: O Projeto XMPM (9)
Práticas sendo adaptadas para o contexto do projeto
Teste antes do desenvolvimento:
- Esta prática força o desenvolvedor pensar
sobre o que o código deveria fazer antes de
realmente implementá-lo.
- Caso o desenvolvedor não seja capaz de
escrever o caso de teste para o código então
provavelmente existem problemas de projeto.
- Depois de criar e executar o teste unitário, o
mesmo torna-se apenas uma instância de testes
de regressão.
- Esta prática é simples em conceito, mas
requer intensa preparação técnica.
© 2006 BenQ Mobile 53

54. Resumo e Perspectiva
Resumo
• O fator terceirização adiciona mais complexidade ao uso do
Scrum.
• As práticas melhoram a visibilidade do projeto e reduzem riscos e
incertezas no início do ciclo de desenvolvimento.
• A prática “revisão do sprint” exige que a equipe se esforce para
cumprir com os objetivos prometidos da iteração.
• A prática “teste antes do desenvolvimento” evita a criação de
classes complexas e assegura a qualidade do código.
Perspectiva
• Adaptação dos métodos ágeis para desenvolvimento de
sistemas embarcados.
© 2006 BenQ Mobile 54

55. Conclusão
Scrum é uma metodologia de gerenciamento de projetos que está se
tornando cada vez mais comum na industria de software. É bastante
eficiente quando utilizado por equipes pequenas, mas pode
tranquilamente ser usado em projetos com grandes equipes.
O Scrum tem como vantagens a velocidade, um bom controle do
cronograma, diminuição dos riscos e incertezas e a visibilidade -
graças às constantes reuniões.
Por outro lado, a grande desvantagem do Scrum é a sensação de
informalidade, devida a falta de documentação formal do
software.

56. ?

57. • http://br.groups.yahoo.com/group/scrum-brasil/
• http://blogdoabu.blogspot.com/2008/11/planning-poker.html
• http://planningpoker.com/
• http://netfeijao.blogspot.com/2008/10/estimativas-geis-
planning-poker.html
• Ken Schwaber. Agile Project Management with Scrum. Ed.
Microsoft Press 2004
• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta,
Juhani. Agile Software Development Method, Review and
Analysis. Espoo 2002. VTT Publications 478. 107p
• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed.
Enterprise Software Development Community, 2007.

58. Planning Poker
An agile estimating
technique for agile and
Scrum teams
Gestão ágil de projetos
Apresentadores:
Fábio Abrantes Diniz
Íthalo Bruno de Moura

59. 31% são cancelados
53% custam o dobro do estimado
Apenas 16% são completados no
prazo e custo estimados
* dados do CHAOS report

60. Mas por que?

61. Falta de envolvimento do usuário
Requisitos e especificações incompletas
Falta de suporte da direção
Falta de Pessoas e Recursos
Falta de ESTIMATIVAS!!!

62. É difícil estimar tempos
de execução

63. Time*
*Tudo eu! Tudo eu!

64. 2±9
7

65. Responsabilidades:
• Estimar itens do backlog
• Se comprometer a entregar um incremento
funcional de software
• Gerenciar o próprio progresso
• Auto organizados para entregar o que o PO quer

66. As cerimônias
do SCRUM

68. Reunião de Estimativa:
• Preparação para o Sprint Planning
• Estimar baseado no tamanho, nunca
em tempo
• Atualizar Product Backlog com as
estimativas
• Importante para o PO criar o release
plan

69. O Product Backlog
Emergente
Priorizado e estimado
Maior prioridade, mais detalhes
Qualquer um pode contribuir
Priorização é tarefa do PO
Sempre visível
Alinhado ao plano de negócios

70. Scrum foca em
tamanho e
não em duração

71. Estimar em tamanho
relativo é mais simples

72. Planning Poker
• É um método eficiente que estima o
tamanho dos requisitos em times que
adotam métodos ágeis (SCRUM, XP).1
• O método foi primeiramente descrito por
James Grenning em 2002 e, mais tarde
popularizado por Mike Cohn no livro Agile
Estimating and Planning.
1 – É uma variação do método de estimativa Wideband Delphi (1940)

73. Planning Poker
• As estimativas acontecem em reuniões:
– Geralmente 4 ou 8 horas.
– Paticipantes:
• Todos os membros do time do Scrum;
• O PO somente esclarece os requisitos e não
estima junto a equipe;
• O Scrum Master registra os resultados, não
interferindo nas estimativas do time;
• A equipe não deve ser superior a dez pessoas.

74. O Processo
1. Cada membro do time recebe um deck
de cartas:
 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e
“pausa”.
http://en.wikipedia.org/wiki/Planning_poker

75. O Processo
2. Os itens a serem estimados são lidos pelo
PO ou SM
 A equipe decide qual o menor item de backlog
disponível.
http://blogdoabu.blogspot.com/2008/11/planning-poker.html

76. O Processo
3. Após a estimativa inicial, esse item é
marcado como “2” pontos
 Serve para definir uma referência de tamanho
e complexidade para ser usada nas demais
estimativas.
 E deve ficar registrado para uso nas futuras
reuniões.
 Em casos excepcionais o time pode decidir mudar
esta estória de referência por uma outra.

77. O Processo
4. Para cada estória o SM ou PO lê a
descrição e os critérios da aceitação da
mesma.
 São respondidos questionamentos a
respeito da estória;
 Manter a discussão em alto nível, não entrar em
detalhes.
 Tempo prefixado (timebox) nesta etapa.

78. O Processo
5. Cada desenvolvedor escolhe em silêncio
a carta que representa sua estimativa.
 O moderador pede para todos mostrarem
as cartas.
http://blogdoabu.blogspot.com/2008/11/planning-poker.html

79. O Processo
6. Se todas as estimativas convergirem, a
estimativa está feita e o processo volta
ao início, para um novo item.
 Se houver uma grande variação na
estimativa, aqueles que apresentaram o(s)
maior(es) e o(s) menor(es) valor(es) se
justificam.
 O processo se repete até todas as
estimativas convergirem.

80. Dinâmica
• Grupo
• São Paulo
• Rio Grande do Norte
• Paraíba
• Goiás
• Amazonas
• Sergipe
• Paraná

81. Conclusões
• O Planning Poker é uma prática eficiente de
estimação de requisitos
• Por ser uma técnica bastante flexível, se
enquadra
• É uma prática que envolve todo o time
– Ajuda times novos a se conhecerem
• Realmente funciona!!!

82. ?

83. Referências
• http://br.groups.yahoo.com/group/scrum-brasil/
• http://blogdoabu.blogspot.com/2008/11/planning-poker.html
• http://planningpoker.com/
• http://netfeijao.blogspot.com/2008/10/estimativas-geis-planning-
poker.html
• Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft
Press 2004
• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta, Juhani.
Agile Software Development Method, Review and Analysis. Espoo
2002. VTT Publications 478. 107p
• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed. Enterprise
Software Development Community, 2007.