Este documento discute a importância de estar aberto a novas ideias. Ele sugere que algumas pessoas são resistentes a novas ideias, mas que aceitar novas ideias pode levar a grandes realizações, assim como Forrest Gump aceitou novas ideias e teve muito sucesso. Também discute as metodologias ágeis Scrum e XP e encoraja o leitor a não ter medo de novas ideias.

1. Não São apenas
Sapatos
Vinícius Silva de Andrade
facebook.com/ozirispc
twitter.com/ozirispc
ozirispc.blogspot.com
ozirispc@gmail.com

2. Quem gosta de programar
extremamente?

3. Quem gosta extremamente de
programar?

4. Quem não gosta de programar?

5. “A mamãe dizia que dá para saber muito sobre
alguém pelos seus sapatos.
Para onde ela vai, onde ela esteve.
Eu já usei muitos sapatos.”
Forrest Gump

6. Não Rir, não Lamentar e nem Amaldiçoar
Apenas Compreender

7. Pés que são incrivelmente
resistentes a novos
Sapatos.

8. Reflexão...

9. Agora Pense!
Você acha que
algumas Pessoas
são incrivelmente
resistentes a novas
Ideias?

10. Quantas coisas FANTÁSTICAS,
aconteceram com você,
quando disse
SIM
a novas ideias?

11. SIM

12. Dias Medíocres

13. Dias Glórias

14. Quantos dias Medíocres ele
teve?

15. Quantos dias Medíocres ele
teve?

16. Quantos dias Medíocres ele
teve?

17. Mas, e as
GLÓRIAS

18. Mas, e as
GLÓRIAS

19. Mas, e as
GLÓRIAS

20. Forreste Gump,
aceitou as Simples Ideias e
acabou sendo:
Astro de Futebol Campeão Mundical de
Ping-Pong
Capitão de um barco de Pesca
Herói de Guerra Contribuiu aos ideais
Corredor de Lennon
Dono da Apple Criador da dança de Elvis
Ainda, mostrou a bunda para Kennedy

21. Forreste Gump,
não teve RESISTÊNCIA a
novas ideias,
ou
várias novas IDEIAS...

22. Eu não sou o
Forreste Gump, mas gostaria
de fazer 4 coisas aqui
hoje...

23. 1º
Eu gostaria de contar uma
história

24. 2º
Eu quero muito falar sobre
SCRUM

25. 3º
Falar Sobre XP
(Extreming Programming)

26. 4º
Ajudar você a Ganhar o
BRIND

27. Na graduação, eu
Só via e ouvia:
Pragramação = C++
Analise de Sistemas = Praxis

28. Quem Programa?
Aluno de Curso Técnico
E Curso Superior?
É pra Analista!

29. Quem tá certo?
Usa PRAXIS
Quem tá errado?
não documenta e Usa XP

30. Em toda empresa que eu
passava...
Quem não tinha documentação!

31. TÁ ERRADO!
EU SOU FORMADO!
ONDE ESTÁ O PRAXIS?

32. Quem tá certo?
Quem tá errado?

33. O meu Sapato era mais
bonito que o de
todos os outros.

34. E então... Eu tive que trocar
de Sapatos...

35. Entre os sapatos, eu fui
conhecendo gente
Bem Esperta...

36. Eu disse
SIM
Mas, na hora, queria dizer:

37. SCRUM,
mas o que é
isso?

38. Vinícius, estamos precisando
de um
Cara, tipo um Lider
técnico!

39. Pelo visto você está
confundindo um pouco
os Papeis do SCRUM.
O que acha de
começar
a entender um pouco?

40. Manifesto Ágil
Valores e princípios da Aliança
Indivíduos e interações MAIS QUE processos e ferramentas.
Software operante MAIS QUE documentação abrangente.
Colaboração do cliente MAIS QUE negociações contratuais.
Responder as mudanças MAIS QUE seguir um plano.

41. Motivação Ágil
Experiência de anos usando práticas
prescritivas demonstra que:
Clientes ou Usuários não tem certeza do que querem.
Muitos Detalhes são expressados apenas na construção.
A medida que vêem o produto, eles mudam de ideia.
Forças Externas trazem mudanças ou melhorias aos
Requisitos.

42. Métodos Ágeis
SCRUM
XP
(Extreming Programming)

43. SCRUM

44. SCRUM
Rugby

45. SCRUM
Rugby

46. O que é SCRUM?
Framework de Processo Ágil
Método ágil para gestão
e planejamento de projetos.

47. O que não é SCRUM?
Não é um método que garantirá
você desenvolver produtos
Melhores.
Não é uma Bala de Prata
Não te dará todas as respostas!

48. SCRUM
Características

49. Quais são as Regras?
ARTEFATOS
• Product Backlog REUNIÕES
• Sprint Backlog • Release Planning
• Scrum Board • Sprint Planning
• Burndown Chart • Daily Meeting
• Sprint Review
PAPÉIS • Sprint Retrospective
• Product Owner
• Scrum Master
• Team

50. ARTEFATOS

51. Product Backlog
• Lista PRIORIZADA dos requisitos
para A VISÃO se tornar PRODUTO.
• Apenas 1 Backlog para toda a vida
do Projeto.
• Priorizado pelo PO, mas todos
contribuem com Itens (Estórias).
• Deve ser sempre devidamente
organizado pelo PO antes da
Reunião. Ele é responsavel por estar
pronto, mas o time pode ajudar.

52. Sprint Backlog
• São as atividades estimadas pelo Time
para execução em 1 sprint.
• Definida na reunião do Sprint Planning.
• Os itens do Sprint Backlog são estraidos
do Product Backlog.
• Priorizado pelo PO, mas estimada pelo
Time, só o que cabe (comprometido pelo
time), e é feito em 1 Sprint.

53. Scrum Board ou Kanban

54. Burndown Chart

55. PAPÉIS

56. Product Owner (PO)
• Quem tem a visão do cliente sobre o projeto.
• É quem priorisa as funcionalidades para agregar
valor ao cliente.
• Responsável por comunicar e Sincronizar as
informações.
• É quem sabe quando o produto pode ir para o
cliente, quando está realmente agregando valor.
Vanessa

57. SCRUM MASTER
• Remover impedimentos que atrapalhem a
produção do Time.
• Garantir que o Time nunca assuma mais que
pode.
• Garantir a aplicação das regras do Scrum
melhorando o dia-a-dia dos Membros.
• Facilitador que utiliza todos os artefatos
possíveis para melhorar a produtividade e auxiliar
Márcio o PO a maximizar o ROI

58. SCRUM TEAM
• Normalmente possui de 5 à 9 membros
auto-gerenciáveis.
• São membros responsáveis, focados e
comprometidos (PIG’s)
• Responsáveis por estimativa dos itens do
Backlog.
Saulo • Responsável por quebrar Histórias em
Eliana
Fernanda funcionalidades.

59. SCRUM TEAM
São membros Responsáveis, Focados e
Comprometidos.

60. REUNIÕES

61. Release Planning
Planejamento de uma VISÃO do
produto.
É a entrega do mundo real, diretamente do
mundo das ideias.
É o planejamento de uma
versão. É dividido em Sprints.

62. Sprint Planning
Reunião de Planejamento da Sprint quando
determina-se qual será o Sprint Backlog.
Definição do Foco durante a execução da sprint,
quando se alcança o compromisso do Time.
No final deste Plano se tem um Sprint Backlog,
um Burndown e atualiza o Kanban.

63. Daily Meeting
Inspeção e Adaptação do TIME.
É a sincronização do TIME!
Não é para reportar informações ao SM, é uma
reunião do TIME para o TIME, o SM pode
participar. Não é obrigado!
Geralmente 15 minutos, EM PÉ.
O que fez ontem? O que fará hoje?
Tem Impedimentos no caminho?

64. Sprint Review
Inspeção e Adaptação do processo realizado na
Sprint que se seguiu.
Apresentação do Publicado, nada de PPT.
Mostrar o Produto, entrega principal
do VALOR.
Todos da Empresa podem participar, porém, só
participar.

65. Sprint Retrospective
Todos tem condições de entregar esperiências. O
PAU QUEBRA!!!
Sair do lugar e lavar roupa suja é muito
importante neste momento.
o Scrum Master deve tirar das pessoas:
O que deu Certo? O que pode Melhorar?

66. SCRUM
(Resumo)

67. XP
(Extreme Programming)

68. Motivações
45% Nunca + 19% Raramente
64% de DESPERDÍCIO

69. Motivações
20% das funcionalidades são responsáveis
por 80% do Valor Agregado ao Cliente

70. Motivações
R$ 640.000,00
640 MIL REAIS PRO LIXO

71. Motivações
Documentação é
importante, mas as
vezes existe
documentação
D+ e valor agregado
D-

72. PORQUE?
Utilização de Métodos de Engenharia Civil?
Medo dos Riscos ou das Mudanças?
Mudanças são
problemas?
ou são
oportunidades?
Vinícius Teles

73. XP
(Extreme Programming)

74. XP
(Extreme Programming)
O Xp é um método ágil criado por
Kent Beck (1996) na Crysler.
Tem como objetivo pequenas equipes
onde os requisitos mudam rápido.
Defende a não especialização dos
Membros do time, todos participam de
todas atividades, em pares com rodízio de
duplas.

75. XP
(Extreme Programming)
É a arte de Maximizar
a quantidade de Software
que você não vai fazer!
Vinícius Teles

76. XP
Baseado em seus
VALORES + PRINCÍPIOS + PRÁTICAS

77. VALORES

78. Comunicação
O Cliente possui problemas, e também ideias
sobre funcionalidades que podem resolvê-los.
Desenvolvedores possuem conhecimentos
técnicos que possibilitam as ideias do cliente.
Face a Face é muito importante para eliminar
maus entendidos.

79. Coragem
Não existe uma solução mágica para eliminar
riscos.
Coragem para confiar nas práticas do XP,
acreditando que mudanças podem contribuir.
Coragem para não frear a criatividade do cliente
tentando evitar + riscos e + mudanças.

80. Feedback
Saber a realidade sobre a Satisfação, entendendo
que aceites contantes é bom.
Ter Clientes próximos dos desenvolvedores para
eliminar surpresas.
Valor que agrega, economiza e diminui inúmeros
riscos.

81. Simplicidade
A simplicidade, em inúmeros aspéctos para o XP,
mantem o foco no que fazer.
Evita 64% de desperdício das funcionalidades
existentes, pois, busca o ideal e nada mais.
O Simples proporciona o entendível, e o
entendido para todos os membros.
SEM PEDANTISMO... POR FAVOR!!!

82. Respeito
O valor que proporciona sustentação a todos os
demais.
O Membro da equipe só preocupa em comunicar
quando respeita seu próximo.
Saber OUVIR e Saber COMPREENDER é
RESPEITAR o ponto de vista dos OUTROS.

83. PRINCÍPIOS

84. Feedback rápido
Após obter o feedback, interprete e implemente o
mais rápido possível.
Quanto mais rápido implementar o feedback
melhor. Daqui 1 ano você já esqueceu.

85. Simplicidade Presumida
A equipe deve pressupor que todo problema
tem uma solução razoavelmente simples.
Com isso, pode poupar tempo e assim deve-
se prender em algo realmente complexo e
importante!
OU OU

86. Aceitação das Mudanças
Requisito muda rapidamente, os membros da
equipe devem aceitar isso.
Se está na mente coletiva da equipe que
mudanças são uma realidade, os membros se
mantem menos lamentando.

87. Auta Qualidade
Se não vai fazer algo bom, então não faça,
independente de cronograma e orçamento.
Todos gostam de qualidade, então demonstre
sua qualidade sobre seu trabalho.

88. Mudanças Incrementais
Grandes mudanças tem Grandes chances de
não dar certo!
Assim, faça mudanças menores para
resolver qualquer problema.

89. Práticas

90. Algumas das Práticas
Programação em Par: Todo o código desenvolvido é realizado
por programadores trabalhando em par.
TDD: Os programadores devem criar testes de unidade para todo
o código escrito durante o processo de desenvolvimento.
Integração Contínua: Integre e atualize as versões do sistema
várias vezes por dia, cada vez que uma tarefa for feita.
Jogo do Planejamento: Determinar escopo da próxima versão
(requisitos + importantes sejam contemplados antes) e a entrega
em prazo não muito longo.
Refatoração: os programadores deixão o código simplificado,
estruturado e removendo redundancia.

91. COMPARAÇÃO
SCRUM & XP

92. Semelhanças
SCRUM XP
Sprint Iteration
Sprint Planning Iteration Planning
Daily Meeting Stand Up Meeting
Sprint Retrospective Reflection

93. Quando o cliente fica
satisfeito?
XP: Quando tem o sistema
SCRUM: Finalizados os Itens do
Backlog

94. Quem define o escopo dos
requisitos?
XP: Cliente escreve os User Story.
SCRUM: PO define o product
backlog, mas todos podem participar.

95. XP e SCRUM
Existem muitas referências na internet
para mesclar as 2 metodologias.
Lembre-se sempre de checar se seus atos
estão respeitando o manifesto ágil.
Seja Focado, Comprometido em tudo que
fizer. Senão faça outra coisa.

96. 4º
Ajudar você a Ganhar o
BRIND

97. Mensagem
Não tenha medo de novas ideias,
os seus pés se acostumarão com elas.