Gestão de Projetos com Métodos Ágeis - Avançado

Transcrição

1 Gestão de Projetos com Métodos Ágeis - Avançado Caxias do Sul, 16 de Agosto 2013 Gustavo Casarotto

2 Agenda O Scrum Planejamento da Sprint 1 Execução da Sprint 1 Revisão da Sprint 1 Retrospectiva da Sprint 1 Planejamento da Sprint 2 Conclusões 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. A mudança é algo esperado e não indesejado. O prazo é fixo e determina o escopo. Em métodos prescritivos, o escopo determina o prazo. 7

8 Papéis do Scrum 8

9 Product Owner Analista de Negócio É 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 Scrum Master Gerente de Projetos É 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. 10

11 Time Responsável pela entrega do produto. Pessoas com habilidades multifuncionais que executam o trabalho real. 11

12 12

13 Escopo deste Treinamento 13

14 14

15 Planejamento da Sprint Nos projetos Scrum esta etapa é conduzida em duas partes. Na primeira, o Time de Projeto, juntamente com o Product Owner, seleciona os requisitos que serão trabalhados na Sprint. Para tanto, consideram uma série de fatores e restrições, como a prioridade e tamanho dos itens, dependências, duração da Sprint, capacidade de empacotamento do incremento de produto, velocidade do Time etc. Uma vez selecionados, os requisitos determinam o Backlog e a Meta da Sprint. 15

16 Planejamento da Sprint Na segunda parte do planejamento, o Time define a melhor forma de transformar os requisitos selecionados em produto, avaliando aspectos técnicos, sequenciamento das tarefas necessárias, organização dos componentes do Time etc. Para apoiar o processo de execução da Sprint e garantir a disponibilidade permanente de todas as informações relacionadas, o Time elabora o Taskboard e o Sprint Burndown. 16

17 Nosso Product Backlog já Priorizado Completar 10 Flows 7x7 Encher 8 balões Pintar 5 Desenhos Montar 10 Chapéus de Papel Agora vamos estimar esse backlog em pontos. 17

18 O que é ponto? Ponto é uma medida relativa de complexidade. É o tamanho de uma entrega. Imagine um Ponto como o trabalho para empilhar um container 18

19 O que é ponto? Quando estimamos o tamanho de um item do Product Backlog, estamos dizendo que ele equivale ao esforço para empilhar X containers. 19

20 O que é ponto? Ponto NÃO é tempo. 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. 20

21 O que é ponto? O primeiro passo, portanto, é achar uma medida relativa de ponto, ou seja, o que significa para nós empilhar 1 container. Normalmente, utilizamos como referência o item mais simples do Product Backlog como 1 ponto e, a partir de comparações, estimamos os seguintes. 21

22 Poker Planning 22

23 Estimando o Product Backlog Quais seriam as estimativas dos demais itens? Completar 10 Flows 7x7 Encher 8 balões 1 ponto (esse é o mais simples) Pintar 5 Desenhos Montar 10 Chapéus de Papel 23

24 O Spike Na vida real, algumas vezes somos solicitados a desenvolver algo que nunca trabalhamos antes na vida, ou seja, algo desconhecido, novo. O que não é conhecido, não pode ser estimado. Precisa ser investigado. Para investigar, podemos criar um item de Product Backlog e estimar um esforço assim como em qualquer outro item do Backlog. Só que nesse caso, o esforço é decidido pelo time como o suficiente para entender o tamanho do item investigado. 24

25 O Spike Nós vamos criar, então, um item chamado Spike Tamanho do Flow 7x7, com a estimativa de 1 ponto e adicionar ao backlog como o primeiro da lista, pois quanto antes eliminarmos a incerteza, melhor. Não podemos, por essa razão, deixar o item Completar 10 Flows 7x7 sem estimativa. Nesse caso, atribuiremos por enquanto 3 pontos (nosso achometro), mas sabendo que pode mudar em função do Spike. Eu costumo colocar um? no postit para identificar visualmente a dúvida quanto à estimativa. 25

26 O Nosso Backlog Estimado Spike Tamanho do Flow 7x7 1 ponto Completar 10 Flows 7x7-3 pontos? Encher 8 balões 1 ponto Pintar 5 Desenhos 2 pontos Montar 10 Chapéus de Papel 2 pontos 26

27 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. Como dinâmica, vamos trabalhar com duração de 5 minutos. 27

28 Velocidade do Time Agora, temos que enquadrar o Product Backlog estimado dentro desse intervalo de 5 minutos. Por isso, precisamos primeiro definir qual a velocidade do time, ou seja, quantos pontos o time é capaz de entregar por Sprint. Melhor ainda, quantos containers conseguimos empilhar em 5 minutos. 28

29 Velocidade do Time Normalmente, utiliza-se como referência a última Sprint realizada. Como não realizamos nada ainda, utilizaremos o item mais simples do Product Backlog como referência através da seguinte pergunta: Quantos balões o nosso time consegue encher em 5 minutos? 29

30 Velocidade do Time Uma pessoa enche um balão em 20 segundos. Uma pessoa enche 3 balões por minuto. Uma pessoa enche 15 balões em 5 minutos. 8 balões = 1 ponto 16 balões = 2 pontos Time = 3 pessoas Velocidade = 3 pessoas x 2 pontos/pessoa = 6 pontos. 30

31 Montando o Backlog da Sprint Temos, então, que distribuir esses 6 pontos em ordem: Spike Tamanho do Flow 7x7 1 ponto Sobram 5 Completar 10 Flows 7x7 3 pontos? (incerteza) 31

32 Montando o Backlog da Sprint Quando temos um Spike dentro de uma Sprint, o ideal é que não tenhamos nenhum item relacionado ao Spike dentro dessa mesma Sprint, pois se trata de uma incerteza. A Sprint deve representar a estabilidade dentro do caos. Algumas vezes, puxamos itens de menor relevância para o projeto para Sprints anteriores com o intuito também de poder fechá-la, ou seja, nem sempre o que é mais relevante é necessariamente executado primeiro. 32

33 Montando o Backlog da Sprint Temos, então, que distribuir esses 6 pontos em ordem: Spike Tamanho do Flow 7x7 1 ponto Sobram 5 Encher 8 balões 1 ponto Sobram 4 Pintar 5 Desenhos 2 pontos Sobra 2 Montar 10 Chapéus de Papel 2 pontos Sobra 0 Completar 10 Flows 7x7 3 pontos? Próxima Sprint 33

34 Montando o Backlog da Sprint Estabelecendo a Meta da Sprint: Spike Tamanho do Flow 7x7 1 ponto Encher 8 balões 1 ponto Pintar 5 Desenhos 2 pontos Lembre-se que algo sempre pode dar errado, mas isso não é justificativa para não obter um comprometimento mínimo da equipe com relação à entrega. Coloque um * nos post-its correspondentes à Meta para identifica-los visualmente. 34

35 Criando o Sprint Backlog O planejamento da Sprint consiste em quebrar os requisitos em tarefas, os quais serão designados aos integrantes do time e estimadas em horas pelos mesmos, criando o Sprint Backlog. Antes de sair dividindo os requisitos em tarefas, precisamos saber como o projeto será 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 (recomendado), para que possam ser monitoradas com maior assertividade. 35

36 O Taskboard Antes de iniciarmos efetivamente a execução da Sprint, precisamos montar o nosso cockpit de trabalho, conforme a imagem a seguir: 36

37 Criando o Sprint Backlog Como o nosso Sprint é de 5 minutos, as tarefas não podem ultrapassar 3 minutos e cada membro do time possui somente 5 minutos disponíveis para trabalhar dentro da Sprint. Agora, vamos dividir todos os requisitos da Sprint 1 em tarefas e escrever cada tarefa em um post-it. Vamos deixá-las ordenadas conforme a prioridade estabelecida no Product Backlog. As tarefas serão oferecidas em ordem aos membros da equipe de forma voluntária. 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. 37

38 Na Prática Demonstração do Planejamento da Sprint 1 38

39 39

40 Executando a Sprint 1 Agora, precisamos de 3 voluntários: Pessoa 1, Pessoa 2 e Pessoa 3. Assim que for disparado o cronometro de 1 minuto, 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 antes de iniciar a próxima. 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. 40

41 Reunião Diária da Sprint 1 Cada pessoa deve atualizar qual foi o progresso obtido em suas tarefas desde a última reunião diária informando quais foram as tarefas terminadas e quais ainda estão em andamento. Se alguma tarefa está em andamento, precisamos verificar qual o tempo restante necessário a sua finalização e atualizar a estimativa no post-it se houver alguma modificação. Precisamos atualizar o burndown com o tempo restante de todas as tarefas ainda não concluídas (novas e em andamento). 41

42 Reunião Diária da Sprint 1 O burndown nos mostra se o projeto está adiantado ou atrasado com relação ao planejado, conforme a imagem a seguir: 42

43 Reunião Diária da Sprint 1 Se o projeto estiver adiantado, o time pode decidir por: Continuar do jeito que está e ver o que vai acontecer amanhã. Adicionar mais itens à Sprint 1 puxando trabalho da Sprint 2. Se o projeto estiver atrasado, o time pode decidir por: Continuar do jeito que está e ver o que vai acontecer amanhã. Remover itens da Sprint 1 passando para a Sprint 2. 43

44 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? 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. Reunião Diária da Sprint 1 44

45 Impedimento Falta de balões 45

46 Impedimento Falta de balões Faltaram balões. Isso acontece também na vida real. Às vezes, nos deparamos com questões que impedem a execução do nosso trabalho e de difícil previsibilidade. O responsável pela tarefa, então, deve pegar um post-it, escrever o impedimento, colocar o mesmo na seção de impedimentos do Cockpit e avisar o Scrum Master. Pode-se escrever Impedimento junto ao post-it para identifica-lo como tal. 46

47 Impedimento Falta de balões Para efeito de conceito, impedimento é todo problema que afeta o ritmo de trabalho do Time, podendo comprometer o alcance da meta estabelecida para a Sprint e/ou seu prazo de execução. Agora entra em ação o Scrum Master. O que será que ele pode fazer? Quais seriam as suas alternativas? 47

48 Impedimento Falta de balões Algumas alternativas: Negociar com o Product Owner uma entrega menor, somente com os balões disponíveis. Negociar uma entrega particionada, ou seja, alguns balões agora e outros na próxima Sprint. Negociar a retirada dos balões do Backlog da Sprint e passá-la para a próxima Sprint. 48

49 Impedimento Falta de balões Para o exercício vamos considerar que o Product Owner aceitou a entrega de 7 balões. Temos, então, que ajustar o projeto, executando os seguintes passos: Risque o número 8 no post-it e coloque o número 7 no lugar dele tanto no Backlog quanto na tarefa. Coloque os post-its nas colunas adequadas no taskboard. Remova o impedimento da seção de impedimentos e coloque na coluna Terminados. Na vida real, a execução dessa ação ocorreria dentro do minuto da Sprint e não durante a reunião diária. 49

50 O cronometro vai rodar novamente. A cada rodada: Aponta-se o progresso. Continuando a Execução da Sprint 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? Tem algum impedimento que impeça o bom andamento do meu trabalho? Registram-se os impedimentos e o Scrum Master busca resolvê-los. 50

51 Solicitação de alteração de escopo Itens não Planejados 51

52 Solicitação de alteração de escopo Itens não Planejados O cliente solicitou, com urgência, a entrega de 7 aviões de papel. E agora? A primeira ação é escrever em um post-it "Montar 7 aviões de papel" e inserir na seção de itens não planejados para que o Scrum Master e o time tenham visibilidade do que está acontecendo. Coloque NP no post-it para identifica-lo como não planejado. Novamente o Scrum Master deve entrar em ação. O que ele deve fazer? Quais seriam as suas alternativas? 52

53 Solicitação de alteração de escopo Itens não Planejados Para conceitualizar, itens não planejados são todas aquelas coisas que descobrimos a medida que o projeto avança, como um requisito que não foi incluído no Backlog do Produto, itens que surgem em função de mudanças ambientais/de mercado (que exigem a mudança do produto final) ou até mesmo necessidades identificadas pelo cliente, depois de escorregar durante o banho e bater com a cabeça na parede (também conhecido como efeito Eureka!). 53

54 Solicitação de alteração de escopo Itens não Planejados Para itens não planejados, que realmente devem ser feitos, temos basicamente duas alternativas: Inserimos no Backlog da Sprint Inserimos no Backlog do Produto para fazer em Sprints futuras Para efeito didático, o cliente exige que seja feito imediatamente, ou seja, precisa ser incluído no Backlog da Sprint. O que o Scrum Master deve fazer então? 54

55 Solicitação de alteração de escopo Itens não Planejados No Scrum, sempre quando algo entra, algo tem que sair. Lembre-se que o projeto ágil não atrasa porque o prazo é fixo. Nesse caso, o Scrum Master convoca o time para: Estimar o novo item. Neste caso, 1 ponto Remover da Sprint os itens que não poderão mais ser realizados Atualizar o Backlog caso seja necessário quebrar algum item em mais de uma entrega e estima-los novamente. Ex. Dividir Montar 10 chapéus de papel em Montar 5 chapéus de papel e Montar 5 chapéus de papel. Atualizar o Backlog da Sprint com a alteração solicitada Criar as novas tarefas e dividir entre os integrantes do time. 55

56 O cronometro vai rodar novamente. A cada rodada: Aponta-se o progresso. Continuando a Execução da Sprint 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? Tem algum impedimento que impeça o bom andamento do meu trabalho? Registram-se os impedimentos e o Scrum Master busca resolvê-los. 56

57 57

58 Revisão da Sprint Encerrado o ciclo de execução, o incremento de produto gerado na Sprint deve ser inspecionado pelo Product Owner. Costumo chamar essa etapa de hora da verdade. Neste evento, com foco exclusivo nas funcionalidades do produto, o Time apresenta o incremento gerado para aprovação pelo Product Owner e demais usuários-chave envolvidos com o projeto. Os requisitos que integram o incremento podem ser aprovados totalmente, aprovados parcialmente, ou recusados. 58

59 Revisão da Sprint Porque esta etapa é uma das mais importantes? O Pensamento Ágil é baseado em Feedback Constante (comunicação). Como comentado no início do treinamento, os métodos ágeis se encaixam melhor em projetos onde os requisitos são instáveis ou desconhecidos ou onde os projetos possuem certo grau de inovação. Em projetos dessa natureza, o projeto é construído de forma incremental e possibilita uma análise dos resultados intermediários e correções de rumo antes da entrega final do projeto, ou seja, a mudança é bem vinda e aceita como parte normal do processo de criação e entrega. 59

60 Revisão da Sprint Vamos analisar a qualidade da entrega da Sprint através dos desenhos. Como Product Owner, você aceitariam integralmente, aceitariam parcialmente ou rejeitariam os desenhos? Supondo que 3 desenhos foram rejeitados, o que o Scrum Master deveria fazer? 60

61 Revisão da Sprint Ele deve criar mais um item no Product Backlog chamado Pintar 3 desenhos" e, em seguida, deve negociar com o Product Owner a prioridade dessa entrega dentro do planejamento da próxima Sprint. Para o exercício, vamos considerar que esse deve ser o primeiro item da próxima Sprint. 61

62 62

63 Retrospectiva da Sprint Trata-se do evento Kaizen do Scrum, onde os componentes do Time refletem sobre os resultados alcançados com a execução da Sprint (Kaizen é a prática Lean direcionada a Melhoria Contínua). Nesta etapa, o foco é a análise do processo de entrega, visando à identificação de oportunidades de melhoria, para assegurar o alcance dos resultados esperados com as próximas Sprints. 63

64 Retrospectiva da Sprint Para que a reflexão ocorra de uma forma não somente qualitativa, mas quantitativa também, o Srum Master pode obter os seguintes indicadores: Pontos estimados (velocidade estimada) Pontos entregues (nossa velocidade) Horas/ponto estimadas (no nosso caso minutos/ponto) Horas/ponto entregues Número de impedimentos Horas trabalhadas em itens não planejados Meta atingida? 64

65 Retrospectiva da Sprint Com todas essas informações em mãos, para finalizar a Sprint, a equipe deve responder duas perguntas: O que devemos continuar fazendo? O que devemos melhorar para a próxima Sprint? Se o Scrum Master desejar, pode escrever cada resposta em um postit e colocar ao lado do Taskboard para que possa ser visualizado durante a execução da próxima Sprint. 65

66 Planejamento da Sprint 2 66

67 Planejamento da Sprint 2 Qual seria a velocidade do time utilizada para o Sprint 2? As estimativas do Product Backlog estão atualizadas? Completar 10 Flows 7x7 3 pontos? Requisitos novos foram priorizados e estimados? Montar 5 chapéus de papel Pintar 3 desenhos Existem incertezas que impedem o planejamento da Sprint 2? (Spikes) 67

68 Conclusões 68

69 Conclusões 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, obrigando o mesmo a se comprometer com o projeto. Aumentar a maturidade da equipe com relação a sua própria capacidade de entrega e à complexidade das tarefas que executa. 69

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