1. O documento discute a história e o desenvolvimento de métodos ágeis como Scrum para gerenciamento de projetos de software. 2. Scrum é um framework leve para gerenciar projetos complexos de forma adaptável e entregar valor ao cliente. 3. Existem alguns desafios comuns na implementação de Scrum, como mudança cultural e resistência à mudança.

1. Desmistificando o Scrum
Alison Rodrigues de Souza

2. ABOUT ME!
Alison Rodrigues de Souza:
● Motociclista
● Programador JAVA
● Agilista
● Certificado Scrum Master.

3. CONTATOS
Site/Blog: alisonsouza.com.br
Twitter: @AlisonRSouza
GitHub: AlisonSouza

4. VAMOS FALAR UM POUCO
SOBRE HISTÓRIA...

5. VAMOS FALAR UM POUCO
SOBRE HISTÓRIA...

6. O caos predominava.
NOS ANOS 60...

7. NOS ANOS 60...
Não tinham a menor idéia de como fazer
um software.

8. NOS ANOS 60...
Mais da metade dos projetos falhavam.

9. NOS ANOS 60...
Eram superestimados.

10. NOS ANOS 60...
Não eram entregues e não se tinha
previsão de
quanto tempo
levaria para
desenvolver e
entregar

11. ENTÃO...
Caos

12. NOS ANOS 80...
Com base em todos as dificuldades
encontradas na construção de software,
surgiu a necessidade de mudar...

13. Com a “Crise do software” - o
Departamento da Defesa norte-
americano patrocinou a criação do SEI
- Software Engineering Institute, em
1984.
NOS ANOS 80...

14. O Departamento tinha como objetivo
alcançar o mesmo nível de repetibilidade
e controle dos setores industriais.
O SEI tinha como desafio criar condições
para a evolução da boas práticas da
engenharia de software.
NOS ANOS 80...

15. NOS ANOS 80...
O SEI selecionou profissionais das áreas
de gestão e engenharia para criar
um modelo de engenharia onde fosse
possível entregar software.

16. NOS ANOS 80...
Modelos de gestão definiam que para
gerir um projeto é preciso dividir a
equipe em:
* Profissionais do conhecimento;
* Profissionais de execução.

17. NOS ANOS 80...
Conhecimento:

18. NOS ANOS 80...
Execução:

19. NOS ANOS 80...

20. NOS ANOS 80...
Com base nas Engenharias Tradicionais
foi definido que para entregar projetos
no tempo planejado era
preciso de um processo bem
definido como linha de montagem ou
linha de produção.

21. NOS ANOS 80...
Linha de Montagem:

22. NOS ANOS 80...
Assim nasceu a Engenharia de
Software.

23. ENTÃO...
Caos Engenharia de Software

24. NOS ANOS 2000...
Desenvolvimento de Software se
parece com isso?

25. NOS ANOS 2000...
... ou isso?

26. NOS ANOS 2000...
Desenvolvimento de software é um
trabalho intelectual, onde ações
externas impactam na produtividade e
no resultado final.

27. NOS ANOS 2000...
Algo estava errado, precisávamos mudar!

28. NOS ANOS 2000...

29. Em 2001, um grupo de profissionais e
pensadores se reuniu para conversar
sobre metodologias e práticas que
vinham utilizando no gerenciamento
de projetos de software.
NOS ANOS 2000...

30. Esse grupo, de comum acordo, criou o
“The Agile Manifesto”, com 12
princípios que norteiam todos os
métodos ágeis.
Ainda hoje estes princípios servem como
parâmetro para testar novos métodos
ágeis e “agilistas” (praticantes de
métodos ágeis).
NOS ANOS 2000...

31. NOS ANOS 2000...
Assim nasceu o movimento
ágil!!!
O movimento ágil surgiu de uma
ruptura do modelo da engenharia
de software.

32. ENTÃO...
Caos Engenharia de Software Agile

34. AGILE

35. AGILE
Rápido:
"Que se move depressa, com muita
velocidade"
X
Ágil:
"Que se move ou age com muita
facilidade , destreza e rapidez"
Fonte: Dicionario Aulete / http://aulete.uol.com.br/

37. AGILE

38. OS 12 PRINCÍPIOS!!!
1. Satisfazer o cliente, através da
entrega adiantada e contínua de
software de valor.
2. Aceitar mudanças de requisitos,
mesmo no fim do desenvolvimento.

39. 3. Entregar software funcionando com
frequência, na escala de semanas até
meses, com preferência aos períodos
mais curtos.
OS 12 PRINCÍPIOS!!!

40. 4. Pessoas relacionadas à negócios e
desenvolvedores trabalharem em
conjunto e diariamente, durante todo
o curso do projeto.
5. Construir projetos ao redor de
indivíduos motivados.
OS 12 PRINCÍPIOS!!!

41. 6. Por mais conversa cara a cara.
7. Por mais Software funcional.
8. Processos ágeis promovem um
ambiente sustentável. Os
patrocinadores, desenvolvedores e
usuários, devem ser capazes de
manter indefinidamente, passos
constantes.
OS 12 PRINCÍPIOS!!!

42. 9. Simplicidade: a arte de maximizar a
quantidade de trabalho que não
precisou ser feito.
10. Contínua atenção à excelência
técnica e bom design, aumenta a
agilidade.
OS 12 PRINCÍPIOS!!!

43. 11. As melhores arquiteturas, requisitos e
designs emergem de times auto-
organizáveis.
12. O time refletir em como ficar mais
efetivo, então, se ajustam e
otimizam seu comportamento de
acordo.
OS 12 PRINCÍPIOS!!!

44. Mas o desenvolvimento de
software ainda apresentava
muitos problemas...

45. TEORIA DA COMPLEXIDADE

49. SCRUM

50. SCRUM

51. SCRUM
Framework com o qual as pessoas
podem resolver problemas
complexos e adaptáveis
enquanto entregam produtos de
forma produtiva e criativa com
maior valor possível.

52. SCRUM
...é leve, simples de entender,
mas difícil de aplicar.

54. Quais as principais dificuldades para colocar
scrum na prática?
● [ 51% ] Habilidade para mudar a cultura
organizacional
● [ 40% ] Resistência geral a mudança
● [ 40% ] Disponibilidades das pessoas com as
habilidades necessárias
● [ 34% ] Suporte da Gestão
● [ 31% ] Complexidade ou tamanho do
projeto
Fonte http://www.adaptworks.com.br/blog/2012/01/11/o-dilema-do-scrummaster/
SCRUM

55. ● [ 29% ] Colaboração do Cliente
● [ 21% ] Confiança na habilidade para escalar
Agile
● [ 19% ] Tempo percebido para transição
● [ 13% ] Restrições de orçamento
● [ 12% ] Nenhum
● [ 06% ] Outros
Fonte http://www.adaptworks.com.br/blog/2012/01/11/o-dilema-do-scrummaster/
SCRUM
Quais as principais dificuldades para colocar
scrum na prática?

56. SCRUM

57. SCRUM
Ken Schwaber Jeff Sutherland

58. SCRUM
● Transparência: todo processo visível
a todos que estão envolvidos na
criação do produto.
● Inspeção: o processo deve ser
inspecionado regularmente para
detectar problemas.
● Adaptação: Caso existam problemas,
adaptações devem ser feitas.

59. O Scrum pode ser analisado por um
conjunto de:
● Papeis
● Cerimonias/Eventos
● Artefatos
SCRUM

61. EVENTOS DO SCRUM

62. ● Sprint.
● Reunião de Planejamento da Sprint
(Sprint planning meeting).
● Scrum Diário.
● Revisão da Sprint.
● Retrospectiva da Sprint.
EVENTOS DO SCRUM

63. SPRINT

64. DAILY SCRUM

66. Eventos do Scrum

68. ARTEFATOS DO SCRUM

69. ● Backlog do produto.
● Backlog da sprint.
ARTEFATOS DO SCRUM

71. SPRINT BACKLOG

72. BURNDOWN

73. SCRUMBUT
Ken fala sobre o que significa adotar
"Scrum ... mas", ou ScrumBut:
● "(Nós usamos o Scrum, mas) (fazer
Daily Scrum é muito em cima), (por
isso só temos uma por semana)."

74. ● "(Nós usamos o Scrum, mas) (não
podemos construir um pedaço de
funcionalidade em um mês), (por
isso nossas Sprints são de 6 semanas
de duração)."
SCRUMBUT

75. ● "(Nós usamos o Scrum, mas)
(Retrospectivas são um desperdício
de tempo,) (de modo que não vamos
fazê-las.)"
SCRUMBUT

76. O QUE NÃO É SCRUM
● Scrum não é um método da
engenharia de software.

77. ● Scrum não é um método da
engenharia de software.
● Scrum não cuidará da qualidade do
seu projeto.
O QUE NÃO É SCRUM

78. ● Scrum não é um método da
engenharia de software.
● Scrum não cuidará da qualidade do
seu projeto.
● Scrum não fornece templates para
Gerenciar Tarefas, Relatórios,
Estimar ou para Coletar Requisitos.
O QUE NÃO É SCRUM

79. ● Jogam baralho durante o trabalho.
MITOS SOBRE AGILE E SCRUM

80. ● Não precisa planejar.
MITOS SOBRE AGILE E SCRUM

81. ● Se eu usar Agile não posso ter CMMI ou
outras certificações.
MITOS SOBRE AGILE E SCRUM

82. MITOS SOBRE AGILE E SCRUM

83. QUEM UTILIZA SCRUM?

84. MAIS INFORMAÇÕES

85. MAIS INFORMAÇÕES

86. PERGUNTAS?

87. Contatos:
Site/Blog: alisonsouza.com.br
Twitter: @AlisonRSouza
GitHub: AlisonSouza
OBRIGADO!