Slides utilizado no treinamento de Scrum

1. Scrum
Eric Cavalcanti
ecavalcanti@gmail.com
@ericoc

2. O Problema
Chaos Report
18%
2004 53%
29%
19%
2006 46% Fracassados
35%
Comprometidos
Bem sucedidos
24%
2009 44%
32%
!"#$%&'(")&*%+,-."/0$12""

3. Principais fatores de
insucesso
requisitos incompletos
falta de envolvimento
de usuários
mudanças de
requisitos e especificações
falta de apoio de negócios
falta de recursos

4. Como resolver?

5. Abordagem Tradicional

6. BDUF
Big Design Up Front

7. Analista de Requisitos, Analista de Negócios,
Engenheiro de Requisitos, Engenheiro de Qualidade,
Gerente de Configuração, Líder de Projeto...
Programadores

8. Processo!!

9. Ainda assim...

10. Ainda mais...
Código Complexo.
Manutenção difícil.
Baixa produtividade.
Cronograma sempre atrasado.
Insatisfação de todos.
Design degradado.
Documentação defasada, excessiva e ilegível.
Fracasso em grande parte dos projetos.

11. Por quê?

12. Previsibilidade

13. O desenvolvimento de software depende
muito mais das pessoas e da comunicação

14. “Ao contrário do cenário numa linha de
produção em massa, o software não é algo
previsível ou imune a mudanças”
Larman

15. “Desenvolver software é como
desenvolver novos produtos”
Larman

16. “Desenvolver é como criar uma receita,
enquanto produzir é seguir a receita”
Poppendieck

17. “O desenvolvimento é um processo de
aprendizado, que envolve tentativa e erros”
Larman

18. “Como a manufatura previsível, não pode ser comparada ao
software, dificilmente as práticas e valores enraizados nesse
paradigma trazem algum benefício” Larman

19. 64% das funcionalidades
desenvolvidas nos softwares
não são utilizadas
Standish Group

20. A Lei de Pareto, também
conhecido como princípio 80/20

21. 20% do esforço do desenvolvimento
80% dos benefícios

22. 20% dos custos
80% dos problemas

23. Muitas vezes, pelo fato do cliente
só poder pedir uma vez, ele
acaba pedindo coisas que não
tem certeza que precisa

24. Essas funcionalidades
fazem parte dos
64% que ele nem
repara que estão lá,
quando o software é
entregue

25. 70% dos usuários utilizam as
funcionalidades básicas de um software.
20% utilizam as funcionalidades
intermediárias.
10% utilizam as funcionalidades avançadas.
Microsoft

26. Cone da Incerteza

27. É natural que os
usuários tenham novas
idéias e suas opiniões
mudem quando vêem
as primeiras versões
do software

28. Os softwares mais famosos
e utilizados no mundo são
os mais simples

32. “Menos é Mais”
A cabeça de Steve Jobs (Inside Steve’s Brain) - Agir 2008

34. Abordagem Ágil

35. Final da década de 90
eXtreme Programming
Feature Driven Development
Scrum
Adaptive Development
Crystal Clear
Dynamic Systems Development Method

36. Mas o que é ser ágil?

37. Kent Beck Ron Jeffries
Mike Beedle Jon Kern
Arie van Brian Marick
Bennekum Robert C. Martin
Alistair Cockburn Steve Mellor
Ward Cunningham Ken Schwaber
Martin Fowler Jeff Sutherland
James Grenning
Manifesto Ágil
Dave Thomas
Jim Highsmith
Andrew Hunt

38. Indivíduos e interação entre eles
mais que processos e ferramentas

39. Software em funcionamento
mais que documentação abrangente

40. Colaboração com o cliente
mais que negociação de contratos

41. Responder a mudanças mais
que seguir um plano

42. Princípios por trás do
manifesto ágil

43. Nossa maior prioridade é
satisfazer o cliente, através
da entrega adiantada e
contínua de software de
valor

44. Aceitar mudanças de requisitos,
mesmo no fim do desenvolvimento

45. Processos ágeis se adequam a
mudanças, para que o cliente
possa tirar vantagens
competitivas

46. Entregar software
funcionando com
frequencia, na escala de
semanas até meses, com
preferência aos
períodos mais curtos

47. Pessoas relacionadas à negócios e desenvolvedores
devem trabalhar em conjunto e diariamente,
durante todo o curso do projeto

48. Construir projetos ao redor de
indivíduos motivados. Dando a eles o
ambiente e suporte necessário, e confiar
que farão seu trabalho.

49. O método mais eficiente e eficaz de
transmitir informações é através de uma
conversa cara a cara.

50. Software
funcional é a
medida primária
de progresso.

51. Processos ágeis promovem um ambiente
sustentável. Os patrocinadores, desenvolvedores
e usuários, devem ser capazes de manter
indefinidamente, passos constantes.

52. Contínua atenção à excelência
técnica e bom design, aumenta
a agilidade.

53. Simplicidade: a arte de
maximizar a quantidade de
trabalho que não precisou
ser feito

54. As melhores arquiteturas,
requisitos e designs emergem
de times auto-organizáveis

55. Em intervalos regulares, o time reflete em como
ficar mais efetivo, então, se ajustam e otimizam
seu comportamento de acordo

56. Por que adotar
abordagens ágeis?

57. STATE OF
AGILE SURVEY
2010
4.770 participantes
91 países
VersionOne

58. STATE OF
AGILE SURVEY
2010
68% conhecem moderadamente
ou extremamente
90%
trabalham em
organizações que usam
práticas de
desenvolvimento ágil
em um certo grau
VersionOne

59. STATE OF
AGILE SURVEY
2010
40% utilizam abordagem
ágil a mais de 2 anos
VersionOne

60. STATE OF
AGILE SURVEY
2010
Scrum e variantes de Scrum
são de longe os mais utilizados
VersionOne

61. STATE OF
AGILE SURVEY
2010
As razões mais comuns para a adoção ágil gira em torno de
aumento produtividade e tempo de aceleração para
o mercado
VersionOne

62. STATE OF
AGILE SURVEY
2010
83% consideram que projetos ágeis foram mais rápidos
ou a mesma coisa que projetos não ágeis
VersionOne

63. STATE OF
AGILE SURVEY
2010
87% melhoria significante no
gerenciamento de prioridades
VersionOne

64. O Scrum

65. A origem
1995
Jeff Sutherland
Ken Schwaber
1986

66. “O Scrum não vai dizer exatamente o que fazer,
não irá resolver todos os seus problemas, mas
com certeza os problemas serão mais
facilmente identificados”
Ken Schwaber

67. Se destaca dos demais métodos ágeis pela
ênfase dada ao gerenciamento do projeto

68. Práticas de Engenharia
de d
c lu
t in
No

69. Papéis
do Scrum

70. Product
Product Owner Determina a visão do produto
Owner Define as funcionalidades
Escolhe as datas de release
Dá o feedback
Gerencia os stakeholders
Aceita ou rejeita os resultados
Prioriza de acordo com o ROI

71. Pequenos (5 a 9 pessoas)
Desenvolve as funcionalidades
Auto-organizável
Auto-gerenciável
Multifuncional
Estima o esforço
Defina as tarefas
O Time Responsável pela qualidade

72. Scrum Master
Líder Servidor
Protege o time
Remove impedimentos
Guia do Scrum

73. Porcos e Galinhas
Product Owner Usuários
Scrum Master Gerentes
Time Marketing

74. Como funciona?

75. Visão do Produto
Uma visão é uma imagem clara que evoca uma
atração emocional
O Product Owner cria a visão do produto
Ele compartilha a visão com o time
Ele refina a visão com o time

76. Product Box
http://innovationgames.com/product-box/

77. Elevator Statement
Para
(público
alvo)
Que
estão
insa6sfeito
com
(as
atuais
alterna6vas
de
mercado)
Nosso
produto
é
um
(nova
categoria
do
produto)
Que
(problema
chave
que
ele
resolve)
Diferente
(o
produto
alterna6vo)
Nós
fornecemos
(funcionalidades
chaves)

78. Vamos criar a visão!

79. Product Backlog
Contém valor
Retardar decisões

80. Product Backlog
Uma lista de coisas que
queremos que sejam
entregues

81. As funcionalidades são
geralmente escritas em
estórias de usuários.

82. Como um <perfil>,
quero <funcionalidade>,
para <valor de negócio>
Como um agente de viagens, quero reservar lugar,
para facilitar o atendimento dos clientes
corporativos

83. Vamos contar estórias!!

84. O time estima o trabalho
associado a cada estória.

85. Problemas com estimativas
Pessoal, qual a
estimativa para essa
estória?

86. Planning Poker
Opinião de Especialistas
Analogia
Desagregação
Baseado em Fibonacci
1, 2, 3, 5, 8, 13, 20, 40, 100

87. Estimando com Planning Poker
Pessoal, qual a
estimativa para essa
estória?

88. Vamos jogar poker!

89. As estórias são rankeadas em ordem
de importância pelo product owner.

90. Business Value Game
Novos negócios
Venda
Retenção
Eficiência Operacional
100, 200, 300, 500, 800, 1200, 2000, 3000

91. O product owner é o dono do
backlog do produto.

92. Roadmap do Produto
Mês 1 Mês 2 Mês 3
Release 1 Release 2

93. Plano de Releases
Release 1 Release 2 Release 3

94. Planejando uma release

95. Priorização
Business Value / Story Points
BV SP BV/SP
US3 400 5 80
US1 200 5 40
US2 200 20 10

96. Product Backlog

97. Sprint Planning
capacidade do time, backlog do produto,
produto atual, condições de negócio, tecnologia +
Objetivo da Sprint
=
Planning 1
priorizar/selecionar os itens de backlog, discutir os critérios de aceitação,
verificar o entendimento
Planning 2
+
quebrar os items de backlog em tarefas, opcionalmente estimar as tarefas
Backlog da Sprint
=

98. Vamos produzir aviões

99. Team Velocity

100. Calculando o velocity em uma Sprint
BV SP BV/SP
US3 400 5 80
US1 200 5 40
US2 200 20 10

101. Calculando o velocity em uma Sprint
BV SP BV/SP
US3 400 5 80
US1 200 5 40
US2 200 20 10
Team Velocity = 10

102. Team Velocity
90
80
70 70 70
60
40
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7

103. Aplicando o velocity no backlog
Sprint 1
Sprint 2
Sprint N
Itens de risco

104. Quebrando os itens de
backlog em tarefas
Como cliente, gostaria
de poder mudar a data
da minha reserva Criar as
tarefas

105. Sprint Backlog

106. Executando a Sprint
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Análise Código Testa
Análise Código Testa
Análise Código Testa
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Análise Análise Análise
Código Código Código
Testa Testa Testa

107. Daily Scrum Meeting
• O que você fez ontem?
• O que você fará de hoje
para amanhã?
• Há algum impedimento
em seu caminho?
15
minutos

108. Taskboard

109. Acompanhamento

110. Sprint Burndown

111. Product Burndown
160
Story Points
120
100
80
1 2 3 4
Sprint

112. Sprint Review

113. Scrum Retrospective

114. Revisando...

115. Scrum of Scrums

116. Perguntas?
Eric Cavalcanti
ecavalcanti@gmail.com
@ericoc