Gestão Ágil de Projetos através do Scrum

Transcrição

1 Gestão Ágil de Projetos através do Scrum Caxias do Sul, 16 de Agosto 2012 Gustavo Casarotto

2 Agenda O Scrum Product Backlog Planejamento do Projeto Planejamento da Sprint Execução da Sprint Retrospectiva Conclusão 2

3 O Scrum 3

4 Origem Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby 4

5 Origem Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo. 5

6 Qual problema o Scrum resolve? O gerenciamento de projetos com requisitos instáveis, sem condições adequadas de previsibilidade. Percebe-se que abordagens prescritivas têm deficiências em projetos dessa natureza. 6

7 Como ele resolve esses problemas? Reduzindo o esforço de planejamento ao mínimo necessário. Como os requisitos são instáveis e o projeto vai mudar, não há porque dedicar um grande esforço ao planejamento. Entregas frequentes e feedback constante. O prazo é fixo e determina o escopo. Em métodos prescritivos, o escopo determina o prazo. 7

8 Como funciona? 8

9 Papéis do Scrum Product Owner (Dono do Produto): É o representante do cliente perante a equipe. Executa a função de Tradutor Escreve, adiciona e prioriza os requisitos no Product Backlog. Fica a disposição da equipe para esclarecimentos de qualquer natureza. 9

10 Papéis do Scrum Equipe Responsável pela entrega do produto. Pessoas com habilidades multifuncionais que executam o trabalho real. 10

11 Papéis do Scrum Scrum Master É o Líder. Remove os obstáculos da equipe, orienta e mantém todos focados nos objetivos da Sprint. Assegura que todos estão executando as práticas do Scrum. 11

12 Construindo um Product Backlog Vamos dividir a turma em grupos de 3 pessoas. O grupo seleciona um Scrum Master. A seguir estão os requisitos levantados pelo Product Owner. Escreva cada um desses requisitos em um post-it. Encher 10 balões azuis Encher 10 balões brancos Encher 10 balões rosas Pintar 5 desenhos Montar 15 aviões de papel Resolver 3 palavras cruzadas 12

13 Construindo um Product Backlog Em seguida, o Product Owner priorizou o Product Backlog com o que é mais relevante na visão do cliente. Ordene os post-its conforme as prioridades a seguir. 1. Encher 10 balões azuis 2. Montar 15 aviões de papel 3. Encher 10 balões brancos 4. Resolver 3 palavras cruzadas 5. Pintar 5 desenhos 6. Encher 10 balões rosas 13

14 Estimando o Tamanho do Product Backlog Em métodos ágeis estimamos em Pontos. Ponto é uma medida relativa de complexidade. É o tamanho de uma entrega. 14

15 Estimando o Tamanho do Product Backlog Imagine um Ponto como um container. 15

16 Estimando o Tamanho do Product Backlog Quando estimamos o tamanho de um requisito, estamos dizendo que ele equivale a X containers empilhados. 16

17 Estimando o Tamanho do Product Backlog Dependendo do talento de cada equipe, pode-se demorar mais ou menos para empilhar esses containers dentro de determinado prazo de tempo. A equipe A, por exemplo, pode empilhar 10 containers em uma hora enquanto que a equipe B pode empilhar 15 containers em uma hora. 17

18 Estimando o Tamanho do Product Backlog O primeiro passo, portanto, é achar uma medida relativa de ponto, ou seja, o que significa para nós 1 container. Normalmente, utilizamos como referência o requisito mais simples como 1 ponto. Por prática, utilizamos o Planning Poker (Fibonacci do Paraguai) para estimar os demais requisitos, privilegiando a comunicação e colaboração mais que processos e ferramentas (princípio ágil). 18

19 Estimando o Tamanho do Product Backlog Agora, vamos estimar os requisitos a seguir em pontos utilizando um dos números a seguir: 1, 2, 3, 5, 8, 13, 20, 40 ou 100. Escreva a estimativa em cada post-it. 1. Encher 10 balões azuis 2. Montar 15 aviões de papel 3. Encher 10 balões brancos 4. Resolver 3 palavras cruzadas 5. Pintar 5 desenhos 6. Encher 10 balões rosas 19

20 Estimando o Tamanho do Product Backlog O resultado deve ficar mais ou menos assim: 1. Encher 10 balões azuis Montar 15 aviões de papel Encher 10 balões brancos Resolver 3 palavras cruzadas Pintar 5 desenhos Encher 10 balões rosas

21 Determinando a Duração da Sprint Precisamos agora definir a duração da Sprint. Essa duração permite fazer uma relação se os containers estão adequados ao tamanho do barco. 21

22 Determinando a Duração da Sprint O Scrum trabalha por padrão com Sprints de 2 a 4 semanas. No entanto, isso pode ser modificado conforme a natureza do projeto. No nosso caso, como faríamos o planejamento se a duração da Sprint fosse: 1 minuto? 10 minutos? 1 hora? 1 dia? 22

23 Determinando a Capacidade da Equipe Supondo que a duração da Sprint será de 10 minutos, temos que enquadrar os requisitos estimados dentro desse intervalo. Precisamos, então, antes de tudo, definir qual a capacidade da equipe, ou seja, quantos pontos a equipe é capaz de entregar por Sprint. Melhor ainda, quantos containers conseguimos empilhar em 10 minutos. Normalmente, utilizamos como referência a última Sprint realizada. Como não realizamos nada ainda, utilizaremos o primeiro requisito como referência através da seguinte pergunta: Quantos balões a nossa equipe consegue encher em 10 minutos? 23

24 Determinando a Capacidade da Equipe Uma pessoa enche um balão em 20 segundos. Uma pessoa enche 3 balões por minuto. Uma pessoa enche 30 balões em 10 minutos. 10 balões = 1 ponto 30 balões = 3 pontos Equipe = 3 pessoas Capacidade = 3 pessoas x 3 pontos/pessoa = 9 pontos 24

25 Construindo o Projeto Agora que conseguimos determinar a capacidade da Equipe, temos que organizar os requisitos em Sprints para poder determinar quantas Sprints serão necessárias para entregar o projeto como um todo: 1. Encher 10 balões azuis 1 Sprint 1 2. Montar 15 aviões de papel 2 Sprint 1 3. Encher 10 balões brancos 1 Sprint 1 4. Resolver 3 palavras cruzadas 8 E agora? 5. Pintar 5 desenhos Encher 10 balões rosas

26 Construindo o Projeto Não existe a possibilidade de enquadrar requisitos maiores que capacidade restante da Sprint dentro dela. Quando isso acontece, precisamos quebrar o requisito em itens menores, ocasionando entregas menores. Nesse caso, poderíamos quebrar o requisito nos itens a seguir e realizar a estimativa novamente: Resolver uma palavra cruzada Resolver uma palavra cruzada Resolver uma palavra cruzada 26

27 Construindo o Projeto O nosso Product Backlog agora deverá ficar da seguinte forma: 1. Encher 10 balões azuis 1 Sprint 1 2. Montar 15 aviões de papel 2 Sprint 1 3. Encher 10 balões brancos 1 Sprint 1 4. Resolver uma palavra cruzada 3 Sprint 1 5. Resolver uma palavra cruzada 3 Sprint 2 6. Resolver uma palavra cruzada 3 Sprint 2 7. Pintar 5 desenhos 5 Vamos dividir novamente 8. Encher 10 balões rosas 1 27

28 Construindo o Projeto Agora, organize os post-its em colunas de forma que cada coluna represente uma Sprint, respeitando a capacidade da equipe: 9 pontos. Sempre que necessário, divida os requisitos em partes menores de forma a distribuí-los uniformemente entre as Sprints. A estimativa em pontos serve para SABER QUANDO PARAR 28

29 Construindo o Projeto O nosso Product Backlog deverá ficar da seguinte forma: 1. Encher 10 balões azuis 1 Sprint 1 2. Montar 15 aviões de papel 2 Sprint 1 3. Encher 10 balões brancos 1 Sprint 1 4. Resolver uma palavra cruzada 3 Sprint 1 5. Resolver uma palavra cruzada 3 Sprint 2 6. Resolver uma palavra cruzada 3 Sprint 2 7. Pintar 3 desenhos 3 Sprint 2 8. Pintar 2 desenhos 2 Sprint 3 9. Encher 10 balões rosas 1 Sprint 3 29

30 Construindo o Projeto Descobrimos, portanto, que para entregar os requisitos solicitados pelo Product Owner precisamos de 3 Sprints de 10 minutos com uma equipe de 3 pessoas. Temos condições de avançar para o planejamento da Sprint 1, a qual passa a ser a nossa meta agora. 30

31 Planejamento da Sprint 1 O planejamento da Sprint consiste em quebrar os requisitos em tarefas, as quais serão designadas aos integrantes da equipe e estimadas em horas pelos mesmos, criando o Sprint Backlog. Antes de sair dividindo os requisitos em tarefas, precisamos saber como o projeto terá o seu andamento monitorado. O Scrum sugere o uso da reunião diária ou Daily Scrum. Isso significa que as tarefas devem ter uma granularidade pequena, em torno de 3 dias no máximo, para que possam ser monitoradas com maior assertividade. 31

32 Planejamento da Sprint 1 Como o nosso Sprint é de 10 minutos, as tarefas não podem ultrapassar 3 minutos e cada membro da equipe possui somente 10 minutos disponíveis. Divida todos os requisitos da Sprint 1 em tarefas e escreva cada tarefa em um post-it. Deixe-as ordenadas conforme a prioridade estabelecida no Product Backlog. Ofereça as tarefas em ordem aos membros da equipe. As pessoas devem se voluntariar. Assim que a tarefa for designada, o responsável deverá fazer uma estimativa entre 1 e 3 minutos. Escreva a estimativa e o responsável no post-it. 32

33 Planejamento da Sprint 1 Os Requisitos da Sprint 1 são: 1. Encher 10 balões azuis 1 2. Montar 15 aviões de papel 2 3. Encher 10 balões brancos 1 4. Resolver uma palavra cruzada 3 33

34 Planejamento da Sprint 1 Alguns exemplos de tarefas poderiam ser: Encher 10 balões azuis 1 Encher 3 balões azuis 1 minuto Marcelo Moreno Encher 3 balões azuis 1 minuto Kleber Gladiador Encher 3 balões azuis 1 minuto Marcelo Moreno Resolver uma palavra cruzada 3 Resolver 10 palavras 3 minutos Luxa Resolver 10 palavras 3 minutos Luxa Resolver 10 palavras 3 minutos Luxa 34

35 Planejamento da Sprint 1 Antes de sair executando, devemos selecionar os requisitos que são a Meta da Sprint e os desejáveis, pois sempre existe o risco do planejado não ocorrer conforme o esperado. Poderíamos colocar itens do Sprint 2 como desejáveis também ou simplesmente fazer como a seguir. Coloque uma estrela nos post-its que são Meta da Sprint para identificá-los visualmente. 1. Encher 10 balões azuis Meta 2. Montar 15 aviões de papel Meta 3. Encher 10 balões brancos Meta 4. Resolver uma palavra cruzada Desejável 35

36 Executando a Sprint 1 Agora vamos ao trabalho. Para fazer o acompanhamento utilizaremos uma ferramenta chamada Burndown, a qual será atualizada a cada reunião diária. No nosso caso, a cada dois minutos. 36

37 Executando a Sprint 1 O eixo vertical se refere a quantidade total de tempo apontado nas tarefas. O eixo horizontal se refere ao tempo de duração da Sprint. A linha pontilhada se refere ao caminho ideal, enquanto que a linha sólida se refere ao real. Agora, desenhe um gráfico contendo o total de minutos das tarefas no eixo vertical, 10 (minutos da Sprint) no eixo horizontal e trace uma linha pontilhada conforme a imagem ao lado. 37

38 Executando a Sprint 1 Todas as tarefas devem ser organizadas em três colunas distintas: Não iniciadas, Em andamento e Terminadas. Assim que for disparado o cronometro de 2 minutos, cada pessoa pegará o post-it correspondente a tarefa que está realizando e o colocará na coluna Em andamento. Quando terminar a tarefa, deverá colocá-lo na coluna Terminadas. Quando o cronometro parar, todos devem parar imediatamente o que estão fazendo para que possamos executar a Reunião Diária e apontar o progresso no Burndown. 38

39 Reunião Diária da Sprint 1 Cada pessoa deve informar qual foi o progresso obtido em suas tarefas desde a última reunião diária. Se alguma tarefa está em andamento, verifique qual o tempo restante necessário a sua finalização e atualize a estimativa no post-it se houver alguma modificação. Some o tempo restante de todas as tarefas não concluídas e faça uma linha ligando a última soma à soma atual, indicando o quanto foi queimado e o quanto falta. 39

40 A ideia é que ao final dessa reunião todos tenham respondido a três questões: O que eu fiz ontem? O que eu vou fazer hoje? Reunião Diária da Sprint 1 Tem algum impedimento que impeça o bom andamento do meu trabalho? Se houver algum impedimento, escreva em um post-it e coloque na seção de impedimentos. Isso significa que o projeto tem um problema e é tarefa do Scrum Master remover esses obstáculos imediatamente. 40

41 O cronometro vai rodar novamente. A cada rodada: Aponta-se o progresso. Atualizam-se as estimativas de trabalho restante, quando necessário. Responde-se as perguntas: O que eu fiz ontem? O que eu vou fazer hoje? Executando a Sprint 1 Tem algum impedimento que impeça o bom andamento do meu trabalho? Registram-se os impedimentos e o Scrum Master busca resolvê-los. 41

42 Executando a Sprint 1 Mais ao final da Sprint, pode ser que ocorra algum atraso. Como o prazo é fixo, algo terá que ser removido do escopo e negociado com o Product Owner. Pode ser também que ocorra algum adiantamento. Nesse caso, podese incluir mais requisitos desejáveis e adiantar o trabalho de outras Sprints. 42

43 Agora que a Sprint 1 terminou, vamos fazer uma retrospectiva, analisando o que ocorreu. Retrospectiva da Sprint 1 Em primeiro lugar, o Scrum Master deve obter as seguintes medições: Pontos Estimados Pontos Entregues (analise os requisitos) Horas por Ponto Estimada (no nosso caso minutos por ponto) Horas por Ponto Realizada Meta alcançada? 43

44 Retrospectiva da Sprint 1 Devemos apresentar ao Product Owner e ao Cliente as entregas realizadas, possibilitando um feedback imediato, possibilitando o ajuste da direção do projeto rapidamente se necessário. Agora, como exercício, vamos supor que o Cliente analisou as entregas da Sprint 1 e não gostou do tamanho dos balões azuis, solicitando balões menores para a próxima Sprint. Como vocês fariam esse ajuste? 44

45 Retrospectiva da Sprint 1 Com todas essas informações em mãos, para realmente finalizar a Sprint, a equipe deve responder duas perguntas: O que devemos continuar fazendo? O que devemos melhorar para a próxima Sprint? E também com base nessas informações, antes de fazer o planejamento da Sprint 2, a equipe pode decidir pela atualização da sua capacidade conforme os pontos entregues na Sprint 1 ou pode decidir pelo ajuste de estimativas já realizadas no Product Backlog. 45

46 Conclusão O Scrum é uma ferramenta fantástica para: Projetos com alto grau de incerteza quanto aos requisitos ou às entregas desejadas pelo cliente ou com alto grau de inovação. Projetos com requisitos instáveis, que podem mudar totalmente devido às entregas realizadas. Trazer o cliente para dentro do projeto, através de entregas e feedbacks frequentes. Aumentar a maturidade da equipe com relação a sua própria capacidade de entrega e à complexidade das tarefas que executa. 46

47 Obrigado! CONTATO Gustavo Casarotto Diretor de Produto e Inovação Metadados gustavo@metadados.com.br 47