Treinamento Scrum prático-lúdico para desenvolvimento de equipes de TI e Negócios. Ideal para equipes que necessitam de um setup ágil e bem definido para tornar o processo de gestão de projetos mais eficaz e com a formalidade necessária para manter o controle sobre o desenvolvimento. Baseado nos princípios do Manifesto Ágil e da Organização Scrum.Org (www.scrum.org).

1. 1

2. 2

3. 3

4. 4

5. • Processos fornecem direcionamento e suporte, e ferramentas produtividade, mas
sem as pessoas certas, que possuam satisfatório conhecimento técnico e habilidades
para formar uma equipe altamente eficaz, todos os processos e ferramentas do
mundo irão falhar;
• Bons processos devem mais auxiliar o time que ditar as ações que seus membros
devem tomar;
• Processos devem se adaptar ao time, e não o inverso;
• Processos e ferramentas são úteis, mas quando decisões tiverem que ser tomadas,
estas serão feitas de acordo com a capacidade e conhecimento de seu time.
5

6. • Troque a entrega de documentação e artefatos por versões iterativas de um produto
real que será útil para o cliente;
• Documentos não funcionam, produtos sim;
• No entanto, produtos funcionando não excluem a necessidade de documentação.
Documentos auxiliam a comunicação e colaboração, facilitam a transferência de
conhecimento e preservam informações históricas. Não estamos dizendo que
documentação não é importante, mas apenas que é menos importante que produto
funcionando;
• Documentação não deve substituir a interação.
6

7. • Em projetos ágeis, clientes e gerentes de produto são os guias;
• A meta de um time em projetos ágeis é entregar valor para o cliente;
• Clientes definem o que é valor. Os stakeholders definem as restrições. Quando
fazemos confusão entre clientes e stakeholders nosso projeto está tomando o rumo
errado.
• A fórmula para o sucesso é simples: entregue hoje, adapte amanhã!
7

8. • Todos os projetos são conhecidos e desconhecidos, certos e incertos, e portanto
todos eles precisam ter um balanceamento entre planejamento e mudanças;
• Evite a “Síndrome de Nostradamus”. Adaptação ao invés de antecipação;
• Projetos baseados na exploração são caracterizados por um processo com ênfase em
formar uma “antevisão” e então explorá-la dentro de uma visão, e não de um plano
detalhado. Isso não significa que isto seja “a única verdade”, mas sim que é o
melhor a ser feito em muitos tipos de projeto;
• Rob Austin e Lee Diven citam em Artful Making que o lema “Planeje o trabalho, e
trabalhe o plano” os levou ao fracasso em um projeto de TI que envolveu mais de U
$ 125 milhões.
8

9. 9

10. De ->Para
Iteração – Sprint
Reunião de Planejamento – Planning Meeting
Reunião de Retrospectiva – Retrospective Meeting
Reunião Diária – Daily Meeting
Reunião de Revisão – Review Meeting
Analista de Negócio – Product Owner
Líder de Sistemas – Scrum Master
Lista de Funcionalidades - Product Backlog
Lista de Funcionalidades da Iteração – Sprint Backlog
10

11. 11

12. Todo projeto inicia com a “visão do produto”. E é através desta visão que montamos a
Lista de Funcionalidades. Durante o desenvolvimento do produto, o conteúdo dessa
Lista de Funcionalidades pode mudar – entretanto, a “Visão do Produto” deve sempre
permanecer a mesma.
Uma vez criado a Lista de Funcionalidades (priorizado pelo Analista de Negócio), o
Time se reúne com o Analista de Negócio para esclarecimentos sobre os itens e os
estima, para que possam definir quais itens farão parte da Iteração. A esta reunião
damos o nome de Reunião de Planejamento, que é dividida em duas partes.
Na segunda parte do Reunião de Planejamento, o time decompõe os itens selecionados
em tarefas técnicas e as estima em horas (ou dias).
Durante a execução da Iteração , temos diariamente uma reunião de no máximo 15
minutos chamada Reunião Diária, onde os membros do time respondem a três
perguntas: 1) O que fiz desde o último Reunião Diária ?; 2) O que pretendo fazer até a
próxima Reunião Diária ? e 3) Estou com algum impedimento?.
Ao término da Iteração, o Time apresenta o que foi produzido na Iteração em uma
cerimônia chamada Reunião de Revisão. Esta apresentação é feita no formato de
demonstração (sem slides) e é feita pelo Time.
Finalmente, após apresentar o que foi produzido, o Time se reúne para uma cerimônia
chamada Reunião de Retrospectiva, onde analisam o que funcionou na Iteração e o que
deve ser melhorado para a próxima. Esta cerimônia é de extrema importância, pois é
através dela que o Time consegue melhorar seu processo de desenvolvimento, além de
atitudes e comportamento individuais.
12

13. • É quem tem o conhecimento das necessidades do(s) cliente(s) ou é o próprio
cliente;
• Responsável por garantir o retorno do investimento (ROI);
• Está em constante contato com o Time;
• Ele é o responsável pelo levantamento de requisitos, a chamada Lista de
Funcionalidades;
• Monitora o projeto através das metas;
• Gerencia a entrega do produto (Releases) .
13

14. • É quem tem a característica de ser um líder “facilitador” / líder “servidor”;
• Permite que o Time seja auto-gerenciável / auto-organizado;
• Responsável por remover os impedimentos do Time;
• Garantir que sempre estejam abertos os caminhos de comunicação entre o Time /
Analista de Negócio / Líder de CDS;
• Garantir que as práticas do Scrum sejam executadas;
• Facilitar todas as reuniões (Planejamento, Diária, Revisão e Retrospectiva);
• Proteger o time das interferências externas, assim a produtividade do Time não é
afetada;
• Responsável por gerenciar o processo.
• Combate o comando-controle
14

15. • Seleciona e desenvolve as funcionalidades de maior prioridade na Lista de
Funcionalidades;
• Cria a Lista de Funcionalidades da Iteração;
• Definem junto ao Analista de Negócio a “meta” da Iteração;
• Comprometido com o trabalho e com qualidade;
• Participar das reuniões diárias;
• Manifestar impedimentos;
• Gerenciar seu próprio trabalho;
• Colaborar com outros membros do Time e ajudá-los a serem auto-gerenciáveis.
15

16. 16

17. Quando formamos Times em Scrum, procuramos mesclar profissionais com diferentes
níveis de conhecimento com o objetivo de nivelar o conhecimento entre os diversos
membros. Mas além disso, Times Scrum possuem outras características:
• Times multifuncionais - Um Time Scrum deve incluir pessoas com todas as
habilidades e conhecimentos necessários para atingirem a “meta” da Iteração.
Scrum evita Times verticais de analistas, designers, controle de qualidade e
engenheiros de código. Um Time Scrum se auto-organiza de forma que todos
contribuam com o resultado. Cada membro do Time Scrum aplica seu expertise em
todos os problemas. Por exemplo, a sinergia resultante de um tester ajudando um
designer a escrever código melhora a qualidade do código e aumenta a
produtividade.
• Auto-gerenciamento – Em Scrum não existem títulos para membros do time. Os
times se auto-organizam para transformar os requisitos e tecnologia em
funcionalidades do produto. Todos se doam e fazem o seu melhor, fazendo ou
aprendendo o que for necessário. Sem descrições de funções. Sem títulos, sem
exceções. Por exemplo, pessoas que se recusam a codificar por serem arquitetos de
sistema ou designers não podem fazer parte de um Time Scrum.
17

18. 18

19. 19

20. 20

21. 21

22. 22

23. Ao iniciar uma Iteração, devemos planejar o que será produzido nela. E isto é feito em
uma reunião chamada “Planejamento”.
A Reunião de Planejamento é realizada em duas partes, onde na primeira o Analista de
Negócio explica ao Time o que significa “cada um” dos itens (ou User Story) da Lista
de Funcionalidades. O Líder do CDS participa geralmente como um facilitador.
Após discutir os detalhes de um item, o Time estima o tamanho (ou Story Point) do
item para, de acordo com a velocidade do time, determinar se será possível incluí-lo na
Iteração ou não.
23

24. • Story points são relativos
• Determinar Velocidade
24

25. 25

26. 26

27. Com os itens (ou User Stories) selecionados para a Iteração, o time juntamente com o
Analista de Negócios definem uma meta para a mesma.
Esta meta é criada com o objetivo de manter o Time focado no valor do que será
produzido para o cliente. Por isso ela deve ser criada em termos de negócios.
27

28. A segunda parte da Reunião de Planejamento é onde o time decompõe os itens
selecionados em tarefas técnicas. Ela é feita logo depois da primeira parte da reunião.
Cada uma destas tarefas é estimada em “tempo” – horas ou dias, de acordo com a
preferência – e geralmente é estimada pela pessoa que se habilitar a executá-la.
28

29. 29

30. 30

31. 31

32. Todo Time se reúne diariamente por 15 minutos para atualização do status da Iteração.
A estas reuniões damos o nome de Reunião Diária ou Daily Scrum.
Nestas reuniões, os membros do time respondem a três perguntas:
1. O que fiz desde a última Reunião Diária
2. O que pretendo fazer até a próxima Reunião Diária
3. Quais impedimentos estou encontrando
As Reunião Diária melhoram a comunicação, eliminam outras reuniões, identificam e
removem impedimentos ao desenvolvimento, promove tomadas rápidas de decisões e
aumenta o nível de conhecimento do projeto entre os membros.
O Líder do CDS toma as providências para que a reunião aconteça, sempre no mesmo
horário e local, enquanto que os membros são os responsáveis pela condução da
mesma. Isso significa que as perguntas devem ser respondidas ao time e não ao Líder
do CDS .
32

33. 33

34. 34

35. Ao final da Iteração, uma reunião é feita, chamada de Revisão. Durante esta reunião, o
time apresenta o que foi feito na Iteração e o Analista de Negócios valida os itens de
acordo com o que foi combinado na Reunião de Planejamento.
Esta é uma reunião informal onde o time, Analista de Negócio e stakeholders podem
discutir os próximos passos no projeto de acordo com o que foi apresentado até o
momento e o que ainda deve ser feito. Isto pode influenciar no conteúdo da Lista de
Funcionalidades para as próximas Iterações.
35

36. 36

37. Após a Reunião de Revisão e antes da próxima Reunião de Planejamento da Iteração
seguinte, o Time tem uma reunião chamada Retrospectiva. Nesta reunião, o Líder do
CDS encoraja o time a revisar, dentro do processo e práticas de Scrum, seu próprio
processo de desenvolvimento para torná-lo mais eficiente e divertido para a próxima
Iteração.
O propósito da Reunião de Retrospectiva é inspecionar como foi a última Iteração em
relação às pessoas, relacionamentos, processos e ferramentas. A inspeção deve
identificar e priorizar os principais itens que funcionaram bem e aqueles que se fossem
feitos de forma diferente poderiam tornar as coisas melhores. Isto inclui a composição
do time, arranjos para as reuniões, ferramentas, definição de “pronto” (“done”),
métodos de comunicação, etc.
Ao final da reunião, o Time deve ter identificado medidas a serem tomadas que devem
ser implementadas para melhorar a próxima Iteração.
37

38. 38

39. 39
39