Estimativas Ágeis: Planning Poker

1. Estimativas Ágeis: Planning Poker • Disciplina: Métricas em Projetos de Software • Professor: SÉRGIO SOARES • Equipe: • Cristina Luzia Carvalho Rodrigues • Fabiano Augusto • Marília Litwak Neves • Data: 08/08/2009

2. Agenda • Planejamento – Falhas, Motivação... • Planejamento Ágil • Metotologias Ágeis – SCRUM • Cebola do Planejamento Ágil • Planejamento Release • Planejamento Iteração • Planejamento do Dia • Estimativas: Tamanho X Tempo • Medidas de Tamanho • Técnicas • Planning Poker • Tempo a partir do Tamanho • Vantagens do Planejamento/ Estimativas Ágeis

3. Planejamento Planejar não é fácil!

4. Planejamento • Dados de 1995, usando como base 8.380 projetos: • Apenas 16,2% dos projetos foram entregues respeitando os prazos e os custos e com todas as funcionalidades especificadas; • Aproximadamente 31% dos projetos foram cancelados antes de estarem completos; • 52,7% foram entregues, porém com prazos maiores, custos maiores ou com menos funcionalidades do que especificado no início do projeto. • Dentre os projetos que não foram finalizados de acordo com os prazos e custos especificados, a média de atrasos foi de 222% a mais do que o previsto. Considerando todos os projetos que foram entregues além do prazo e com custo maior, na média, apenas 61% das funcionalidades originais foram incluídas.

5. Planejamento: Principais falhas • Atrasos são passados para frente do cronograma • Atividades não terminam mais cedo. Lei de Parkinson (1993) • Não se leva em consideração a lista de prioridades das funcionalidades • A incerteza é ignorada, os requisitos mudam! Estimativas se tornam compromissos! • Tarefas em paralelo diminuem a produtividade

6. Planejamento Ágil Planning is everything. Plans are nothing.

7. Planejamento Ágil • Conceitos chaves Manifesto Ágil: • Indivíduos e Interações são mais importantes do que processos e • Ferramentas • Software funcionando é mais importante do que documentação • detalhada • Colaboração com o cliente é mais importante do que negociação de • contratos • Adaptação à mudanças é mais importante do que seguir o plano inicial.

8. Equipe Ágil • Iterações curtas • Analisa e se adpata • Trabalho em função das prioridades de negócio • Existe UM Time

9. Metodologias Ágeis

10. Metodologias Ágeis • SCRUM

11. Metodologias Ágeis: SCRUM • Metodologia ágil para gestão e planejamento de projetos de software; • No SCRUM, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints; • O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado.

12. Metodologias Ágeis: SCRUM

13. Características do SCRUM • Cada sprint é uma interação e entrega incremento de software pronto. • Um backlog é conjunto de requisitos, priorizado pelo Product Owner (cliente); • Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando • Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos; • Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

14. Cebola do Planejamento Ágil Planejamento em Níveis: Dia, Iteração e Release

15. Planejando Release • Listar “Estórias” que serão desenvolvidas • Selecionar as que serão da release que está sendo planejada • Estimar essas “Estórias” (Planning Poker ??!!! )

16. Planejando Release Estórias: Descrições breves que relatam as necessidades do Cliente. Como se tentasse explicar o que está fazendo ao Cliente. Não explicam detalhes de implementação. Épicos São histórias do usuários que falam de recursos ou de funcionalidades em um nível superior

17. Planejando Release Modelo últil par escrever estórias: Como <uma função>, o meu objetivo é obter <o valor de negócio>

18. Planejando Iteração • Participação de todos os envolvidos: clientes, programadores, arquitetos etc.. • Identificar tarefas de cada Estória • Estimar as tarefas • Definir tamanho da iteração. Fatores que influenciam: • Tamanho da release • Quantidade de incerteza • Durabilidade das prioridades

19. Planejando Dia • Stand up meeting ou Scrum Daily • Poucos minutos de duração • Receber e repassar novidades

20. Estimativas • Estimar é prever, portanto toda estimativa tem um grau de incerteza.

21. Benefícios das Estimativas • Reduz: • RISCO • INCERTEZA • Auxilia na tomada de decisões • Transmite informações • Aumenta confiança

22. Estimativas: Tamanho x Tempo

23. Medidas de Tamanho • Por Pontos de Estória: • Mais abstrato • Estimativa relativa • Medida pura de tamanho • Discussões são dirigidas a funcionalidades • É mais rápido • A estimativa não perde a validade • Evita conversões precipitadas em horas de trabalho

24. Pontos de Estória A idéia por trás do método de estimativas por Story Pointsé que o cliente e o time sejam parte fundamental das estimativas, na qual o primeiro considera o valor que cada item do Product Backlog agrega para o seu negócio, e o segundo dimensiona a complexidade de implementação de cada item baseado no contexto atual do projeto. Uma vez que todo o Product Backlog tenha sido valorado de acordo com o valor de negócio de cada item, a equipe do projeto estima a complexidade de cada um destes itens em Story Points. Para isto, podem utilizar a técnica Planning Poker

25. Medidas de Tamanho • Por dias Ideais: • mais fácil para iniciantes • Dias Ideias x Dias Reais • – Correção de erros – Reuniões • – Demonstrações – Treinamentos • – Revisões – Entrevistas • – Troca de Tarefas – Telefonemas • – E-mails – Assuntos Pessoais • – Doenças

26. Para estimar • Técnicas: • Opinião de um especialista • Rápido, mas raramente em times ágeis possuem especialistas. • Analogia • Valores relativos, comparação com algo já construído... • Desagregação • Dividir para conquistar. Dividir Estórias maiores em menores.

27. Para estimar • Alternativa: • Planning Poker: Técnica (método) de atribuição de estimativas colaborativo • Combina as três técnicas de estimativas • Os estimadores justificam suas estimativas • Considera uma média das estimativas • Estimativas são feitas pelo TIME

28. Planning Poker Método foi descrito inicialmente por James Grenning em 2002 e depois popularizado por Mike Cohn no seu livro Agile Estimating and Planning, essa técnica é muito conhecido em XP e SCRUM.

29. Planning Poker • Se preparando para jogar.... • Participantes: todos do TIME (programadores, analistas, designers etc.. ) e o Product Owner!

30. Planning Poker • Se preparando para jogar.... • Defina a medida que será utilizada: pontos de Estória ou dias ideias? Pontos de Estória!! • Identifique o que será estimado: Estória, tarefa? Estória! • Descrever as “Estórias” em cartões

31. Planning Poker • Se preparando para jogar.... • Definir escala • Sequência de Fibonacci: 1,2,3,5,8,13,21,34,55,89,…refletem o aumento da incerteza relacionados a maiores unidades de trabalho. Fica mais fácil você ter uma noção de separação de complexidade.

32. Planning Poker • Ampulheta • Um conjunto de cartas para cada participante com a escala definida e as cartas especiais:

33. Planning Poker – Regras do jogo • Estórias são apresentadas pelo Product Owner. • Inicialmente, o time identifica o item de backlog mais simples (para este item é atribuído o valor 1) que passa a ser o item de referência na estimativa dos demais. • Após uma breve discussão, o participante escolhe de suas cartas qual deve representar sua estimativa - para quanto trabalho envolve aquela estória em relação a referência pré-definida.. • Todos devem apresentar sua estimativa em um mesmo momento.

34. Planning Poker – regras do jogo • . • Após apresentação das cartas, novas discussões iniciam. • O product owner deve esclarecer quaisquer dúvidas que surjam quanto a estória ou requisito apresentado para estimativa. • Caso haja muitas divergências, o maior e o menor estimador devem apresentar as suas premissas. • Novas rodadas de estimativas devem ocorrer até que exista um consenso. Normalmente três rodadas são suficiente para um consenso.

35. Planning Poker Ao fazer o planning poker, estamos discutindo requisitos funcionais e não funcionais, que visam a realização de um desejo do cliente, e geralmente, durate o planning poker está o Product Owner, para tirar todas as dúvidas em relação ao negócio e verificar se está sendo feito o que foi acordado.

36. Planning Poker • Prática... Simulação do jogo com o estudo de caso “HealthWatcher”.

37. Planning Poker Site idealizado por Mike Cohn, e propõe uma ferramenta para que time distribuídos façam a estimativa em conjunto: "http://www.planningpoker.com/“

38. Estimando tempo A estimativa do esforço necessária para desenvolver o projeto é derivada a partir do tamanho estimado em Story Points considerando-se a capacidade ou VELOCIDADE de produção do time.

39. Estimando tempo • Definir a VELOCIDADE!!! • Medida de trabalho feito • Não precisa ser estimada • Baseado no histórico • Após realizar 1 iteração

40. Estimando tempo • VELOCIDADE

41. Estimando tempo • VELOCIDADE • Para ganhar os pontos designados para uma Estória, a equipe deverá concluir todas as tarefas para essa Estória dentro da iteração. • O número médio de pontos de Estória por iteração é 33. • A velocidade atual da equipe é 35 pontos de Estória. • A média das três iterações mais lentas é 30 pontos de Estória.

42. Consideração sobre 1o planejamento Se a equipe não conseguiu cumprir todos os pontos da primeira iteração, o problema pode estar na VELOCIDADE !!

43. Vantagens do Planejamento Ágil / Estimativas Ágeis • Replanejamentos acontecem constantemente • As prioridades são atualizadas constantemente • Estimativas podem ser refinadas • Estimativas de tamanho e duração são separadas • Planos são feitos em vários níveis • Planos são feitos baseados em funcionalidades, não em tarefas • Assumimos a incerteza e nos preparamos para ela

44. Estimativas Ágeis: Planning Poker • Disciplina: Métricas em Projetos de Software • Professor: SÉRGIO SOARES • Equipe: • Cristina Luzia Carvalho Rodrigues • Fabiano Augusto • Marília Litwak Neves • FIM