Este documento fornece uma introdução ao framework Scrum, descrevendo suas origens, pilares, papéis, artefatos e cerimônias. O documento também discute desafios comuns na adoção do Scrum e como lidar com eles.

1. Scrum
Tiago Silva da Silva
silvadasilva@unifesp.br
!
@tiagosdasilva
!
silvadasilva@gmail.com
!
tiago.silva.da.silva

2. Scrum
Tiago Silva da Silva
silvadasilva@unifesp.br
!
@tiagosdasilva
!
silvadasilva@gmail.com
!
tiago.silva.da.silva

3. Agenda
• Origens
• Pilares
• Framework Scrum
• Papéis
• Artefatos
• Cerimônias
• Desafios

4. Por que utilizar Métodos
Ágeis?

7. Origens

8. Origens
• Takeuchi, H; Nonaka, I. The new new product
development game. Harvard Business Review. P.
137-146, 1986.
• Conference on Object Oriented Programming
Systems, Languages and Applications, 1995., Austin.
Proceedings…Austin: OOPSLA, 1995.
• Schwaber, K. Agile project management with Scrum.
Redmond: Microsoft, 2004.
• Schwaber, K.; Sutherland, J. The Scrum Guide., 2013.

9. Origens
• Teorias empíricas de processo,
empirismo.
• Afirma que o conhecimento vem da
experiência e de tomada de decisões
baseadas no que é conhecido.
• Emprega uma abordagem iterativa e
incremental.

11. Pilares que apóiam o
Scrum
• Transparência
• Inspeção
• Adaptação

12. Transparência
• Aspectos significativos do processo
devem estar visíveis aos
responsáveis pelos resultados

13. Inspeção
• Os usuários Scrum devem,
frequentemente, inspecionar os
artefatos Scrum e o progresso em
direção ao objetivo, para detectar
indesejáveis variações.

14. Adaptação
• Se um inspetor determina que um ou
mais aspectos de um processo desviou
para fora dos limites aceitáveis, e que o
produto resultado será inaceitável, o
processo ou material sendo produzido
deve ser ajustado.
• O ajuste deve ser realizado o mais breve
possível para minimizar mais desvios.

15. Framework Scrum

16. Framework Scrum
• …para apoiar a resolução de problemas
complexos em ambientes de alta imprevisibilidade.
• Scrum não é o seu processo, mas o framework
sobre o qual você empiricamente construirá os
seus processos,
• você é bem mais habilitado para fazer isso do
que outros profissionais que não conhecem a
realidade de seu projeto e cultura da sua
empresa.

17. Scrum
• Papéis
• Artefatos
• Cerimônias

18. Scrum

19. Scrum
Sprint
Inspection and Adapttion
24 hours
Sprint Planning
Sprint Backlog Tasks
Product or
increment
Daily Scrum
Inspection and Adaption
Review
Retrospective
Adapted from Agile Software
Development with Scrum by Ken
Vision
Release
Planning
Product Backlog Schwaber and Mike Beedle

20. 24 hours
Sprint
Subset of
the PBL
Sprint
Backlog
Product or
increment
Daily Scrum
Product Backlog
Release
Planning
Sprint Planning
Inspection
Review
Retrospective
Inspection and Adaption
Review if necessary
Sprint Zero
• Contracting
• Team forming
• Proof of concepts
• Necessary requirements
gathering
• Necessary requirements
eliciting
Adapt in the
next Sprint

21. Papéis

22. Papéis
• Product Owner
• Team
• Scrum Master

23. Papéis
• Product Owner
• Team
• Scrum Master
!
• Auto-organizadas
• Multifuncionais

24. Product Owner

25. Product Owner
• Entende e compartilha a visão do produto
• Gerencia e maximiza o ROI
• Sabe como priorizar o Product Backlog
• Colabora constantemente com o Time e o
SM
• Planeja releases
• Gerencia e poda o Product Backlog

26. Team

27. Team
• Auto-organizado
• Multidisciplinar
• Responsável pela estimativa quanto ao tamanho dos itens do
Product Backlog
• Está em constante conflito
• Compreende o conceito de auto-gerenciamento dentro do
contexto técnico de uma Sprint
• Ninguém os orienta sobre como transformar o Product
Backlog em incrementos de funcionalidades de software
pronto.

28. Scrum Master

29. Scrum Master
• Remove impedimentos
• Verifica se o o Scrum está sendo implementado
adequadamente
• Facilita as cerimônias
• Melhora constantemente suas habilidades de liderança
• Líder na questão do processo
• Coach o Time e o PO
• Para o restante da organização, ele servirá como interface
e especialista em Scrum

30. Artefatos

31. Artefatos
• Product Backlog
• Sprint Backlog
• Incremento

32. Product Backlog

33. Product Backlog
• DEEP
• Detailed appropriately
• Estimable
• Emergent
• Prioritized

34. The Product Backlog
Dynamics

35. The Product Backlog
Dynamics
• Foco na Representação, não na
Documentação
• Entregável vs. Consumível

36. The Product Backlog
Dynamics
High priority
Low priority
At each iteration, the set of
higher priority (finer
granularity) is selected.
At any given moment,
items can go up or
down in the PBL
PBI’s down in the PBL
have coarse granularity
and must be worked as
the Sprints progresses

37. Product Backlog
Backlog do Produto: Twitter
Login de usuários já cadastrados
Cadastrar novo usuário
Tweetar
Visualizar tweets de quem sigo
Visualizar número de seguidores que possuo
Visualizar histórico de um tweet
Mostrar banner promocional
Remover tweet
Ver sugestões de usuários a seguir
Listar trends
Compor e alterar meu perfil de usuário
(…)

38. Sprint Backlog

39. Sprint Backlog
• US1: As a client, I need to
log into the system in order
to edit my data
└ T1: Model and design database
tables
└ T2: Design front-end interface
└ T3: Develop communication
middleware
└ T4: Develop login rules
• US2: As a seller, I want a
list of clients to be able to
contact them.
└ T1: blablabla
└ T2: blablabla
Sprint Planning
Ordered Product Backlog

40. Sprint Backlog
Meta da Sprint: usuários poderão estar no twitter
Login de usuários já
cadastrados
Ativar login com usuário
Gmail
Montar layout do box de
login
Montar plano de segurança Testar integrado
Estruturar log Revisar código
Criar comportamento de
login
Inserir hint explicativo
Atualizar documentação
técnica
(…)
Cadastrar novo usuário
Criar tabelas no banco de
dados
Estruturar persistência
Definição sobre uso de
templates
Quando validado, ativar
usuário
Escrever testes Definir padrões para
cadastros
Atualizar documentação
técnica
Validar email cadastrado
Testar integrado (…)

41. Incremento
• Resultado do que foi produzido durante a sprint
• Um dos principais conceitos do Scrum
• Vai ao encontro da sua natureza empírica, já que
permite ao PO perceber o valor do investimento
e também vislumbrar outras possibilidade
• Potentially Shippable - Potencialmente Entregável
• O cliente pode colocar imediatamente em
produção

42. DoD
• Definition of Done
• Uma funcionalidade somente é considerada pronta se
tiver passado por todas as etapas definidas pela Equipe
de Desenvolvimento.
• Uma funcionalidade que não esteja pronta ao final da
Sprint deve retornar ao Product Backlog para que seja
incluída em uma próxima Sprint.
• Conforme a Equipe amadurece, é esperado que esta
DoD se expanda para acomodar mais critérios visando
à melhora na qualidade.

43. Cerimônias

44. Cerimônias
• Eventos de duração fixa (time-boxed)
realizados em intervalos regulares.
• Cada um desses eventos é uma
oportunidade para Inspeção e Adaptação.

45. Sprint

46. Sprint
Sprint
24 hours
Sprint Backlog Tasks
Product or
increment
Daily Scrum
Inspection and Adaption
Review
Vision
Adapted from Agile Software
Development with Scrum by Ken
Product Backlog Schwaber and Mike Beedle
Release
Planning
Sprint Planning
Retrospective

47. Sprint
• Todo o desenvolvimento em Scrum é feito de
forma iterativa e incremental - ciclos completos
de desenvolvimento de duração fixa que, ao
final, resultem em incrementos potencialmente
entregáveis do produto.
• Duração de até um mês, o que permite
feedbacks constantes.
• Sprint Planing, Daily Scrum, Sprint Review e
Retrospective.

48. Sprint Planning
• O que será entregue no Incremento
resultante nesta Sprint?
• Como faremos para entregar o Incremento
nesta Sprint?

49. Release Planning
• Delineamento de entregas para o cliente
• Criação do Product Backlog
• Análise de Negócios

50. Sprint Planning vs.
Release Planning
• Sprint Planning acontece para planejar a iteração, logo:
• Trabalha com histórias de menor granularidade
• Tem um horizonte de planejamento curto
• Representa um alto nível de comprometimento
• Release Planning acontece para dar respostas ao cliente:
• Quando será entregue
• Maior granularidade: alto nível de abstração
• Grande quantidade de histórias
• Geralmente planeja-se 2-3 sprints antecipadamente

51. Daily Scrum
Sprint
24 hours
Sprint Backlog Tasks
Product or
increment
Daily Scrum
Product Backlog
Inspection and Adaption
Vision
Release
Planning
Sprint Planning
Review
Retrospective

52. Daily Scrum, Daily
Meeting
• O que fiz desde a última Daily?
• O que pretendo fazer até a próxima Daily?
• Existe algo me impedindo de concluir
alguma tarefa?

53. Sprint Review vs.
Retrospective
Sprint
24 hours
Sprint Backlog Tasks
Product or
increment
Daily Scrum
Product Backlog
Inspection and Adaption
Vision
Release
Planning
Sprint Planning
Review
Retrospective

54. Sprint Review
• Entrada é o Produto.
• Objetivo é inspecionar o que o Time produziu e
colher impressões dos presentes para, caso seja
necessário, adaptar o plano para a Sprint seguinte.
• PO valida ou não as entregas da Sprint, de acordo
com a meta acordada com o Time.
• Demonstração
• Time responde à perguntas

55. Sprint Retrospective
• Entrada é o Processo.
• Imediatamente após a Review.
• Objetivo é a melhoria do processo
• Interação entre os membros do Time
• Práticas e ferramentas utilizadas
• O que funcionou
• O que precisa ser melhorado
• Além de identificar problemas, deve-se identificar medidas a serem
tomadas para a melhoria do processo já na próxima Sprint.

56. Desafios

57. Desafios
• Framework que fornece visibilidade para a
equipe e um mecanismo que permite
realizar inspeções e adaptações constantes.
• Transparência - deixa visíveis os problemas
e impedimentos que impactam no PO e na
eficiência da equipe.
• Não resolve os problemas do
desenvolvimento, apenas os deixa visíveis.

58. Desafios
• Erro comum: quando se encontra uma prática
do framework difícil de aplicar, tenta mudado o
próprio Scrum, em vez de mudar a forma como
a equipe trabalha.
• Equipe com dificuldade de entregar o que foi
planejado durante uma Sprint tende a estender
seu prazo de duração.
• Negando a possibilidade de aprender a
melhor estimar e gerenciar seu tempo.

59. Perguntas

60. Perguntas
• Sua empresa concorda em mudar o ciclo de vida dos
projetos para timboxes de 1-4 semanas?
• Sua organização concorda sem problemas em juntar
divisões funcionais clássicas como analistas,
programadores, testers, arquitetos em um único time?
• Sua empresa concorda em abrir mão de hierarquias
rígidas tradicionais para uma estrutura mais horizontal?
• A liderança concorda em abrir mão do comando e
controle, empoderando essa equipe multi-disciplinar a
se auto-organizar e auto-gerenciar o trabalho?

61. Perguntas
• Escolher um líder-servidor para atuar como ScrumMaster é
algo fácil na sua organização ou vai gerar muita discussão?
• O papel de Product Owner é facilmente identificável na sua
organização? O cliente está “próximo”?
• Sua empresa está disposta a uma queda inicial de
produtividade devida a curva de aprendizado e a inspeção e
adaptação?
• Sua empresa está disposta a abrir mão dos atuais
mecanismos de controle (custos, prazo, escopo) para adotar
a forma ágil de controlar um projeto?

62. Problemas

63. Problemas
!
!
• Equipe não dedicada (comprometimento).
• Cliente ausente.
• Muita interrupção.

64. Problemas
• Como fica o planejamento e alinhamento
com negócios?
• Como a diretoria pode ver?
• Por que não precisa de coordenação?
• Como mostrar o andamento?

65. Desafios
SCRUM SCRUM+
SCRUM+
...mas essa é a forma do
Time B ser mais ágil.
SCRUMBUT

66. Scrum
Tiago Silva da Silva
silvadasilva@unifesp.br
!
@tiagosdasilva
!
silvadasilva@gmail.com
!
tiago.silva.da.silva

67. Conceitos e Técnicas
• User Stories
• Burndown chart
• Acceptance Tests
• Story Points

68. User Stories

69. User Stories
• Uma descrição informal das necessidades do
negócio
• São trabalhadas e amadurecem à medida que a
análise progride
• Uma história pode ser decomposta em duas ou mais
histórias
• Devem ser testadas e aprovadas
• São priorizadas pelo PO de acordo com as
necessidades do cliente

70. User Stories
Epic
blablablabla
blabla
blablablabla
blabla
blablablabla
blabla
Objective
Feature
Use Case/
User Story
Functional
requirements
Non-functional
requirements
The relationship
between use cases
and user stories

71. Burndown

72. Burndown

73. Acceptance Tests

74. Acceptance Tests
• Certificam que as stories implementadas
correspondem ao que o cliente necessita
• Devem ser automatizados, se possível

75. Story Points
• Usado para estimar o tamanho de uma Story
• Estimativa relativa; 2 story points requerem
mais esforço que um story point e, 13 story
points requerem muito mais esforço do que
um story point
• Por que a Sequencia de Fibonacci?
• 1 - 3 - 5 - 8 - 13

76. Story Points
• Empire State Building,
• Teatro Amazonas,
• sua casa,
• Cristo Redentor,
• Torre Eifel

77. Story Points
• Empire State Building,
• Teatro Amazonas,
• sua casa,
• Cristo Redentor,
• Torre Eifel
!
• Estime a altura dos edifícios:
• Escolha o menor
• Use-o como 1 story point
• Estime todos os outros de forma relativa ao primeiro escolhido

78. Referências
• Takeuchi, H; Nonaka, I. The new new product development game. Harvard
Business Review. P. 137-146, 1986.
• Conference on Object Oriented Programming Systems, Languages and
Applications, 1995., Austin. Proceedings…Austin: OOPSLA, 1995.
• Schwaber, K. Agile project management with Scrum. Redmond: Microsoft,
2004.
• Schwaber, K.; Sutherland, J. The Scrum Guide., 2013.
• Métodos Ágeis para Desenvolvimento de Software, Organizadores: Rafael
Prikladnicki, Renato Willi e Fabiano Milani. Porto Alegre : Bookman., 2014.
• Roriz, H. Certified Scrum Master Training (Apostila)., 2012.
• Magno, A.. O julgamento do Scrum. Palestra proferida no Agile Brazil 2013.

79. Scrum
Tiago Silva da Silva
silvadasilva@unifesp.br
!
@tiagosdasilva
!
silvadasilva@gmail.com
!
tiago.silva.da.silva
http://www.slideshare.net/silvadasilva
http://www.speakerdeck.com/silvadasilva