1

2

3

4

•  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

•  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

•  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

•  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

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

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

•  É 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

•  É 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

•  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

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

19

20

21

22

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

•  Story points são relativos •  Determinar Velocidade

24

25

26

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

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

30

31

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

34

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

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

39  39