ScrumGestão ágil de projetos          Autores:    Fábio Abrantes Diniz    Íthalo Bruno de Moura    Thiago Reis da Silva   ...
ScrumGestão ágil de projetos      Apresentadores:    Fábio Abrantes Diniz    Íthalo Bruno de Moura
31% são   cancelados53% custam o   dobro do estimadoApenas    16% são completados noprazo e custo estimados               ...
Mas por que?
Falta de envolvimento   do usuárioRequisitos e especificações incompletas      Falta de suporte   da direção     Falta de ...
Falhar é uma maneira muitoforte de aprendizado, mas é   preciso parar de apontar culpados
Olá,           Scrum!Por que o nome Scrum?O nome é proveninente de uma jogada do Rugby, ondeé demostrada a força de trabal...
Scrum é também um meio de        evidenciar os           problemas
Mas Scrum não            é bala de        prata*                     * Não mata vampiros & afins       * Exige trabalho du...
PDCAPlan, Do, Check, Act
Planejamento
Execução
Checagem
Exatamente oque Scrum faz!
Quem usa o Scrum•   Microsoft•   Yahoo•   Google•   Lockheed Martin•   Philips•   Siemens•   Nokia•   BBC
Scrum tem sido usado para•   Software comercial•   Desenvolvimento interno (empresa)•   Desenvolvimento contratado (tercei...
Características do Scrum• As equipes se auto-organizam• O produto evolui em uma série de “Sprints”  mensais• Os requerimen...
Papeis no scrum
Product Owner• O representante do cliente
Scrum Master• O Scrum Master lidera o time de  desenvolvimento
Scrum Team• Scrum Team São os membros que  formam o time de desenvolvedores,  designers, consiste de 5 a 9 pessoas.
Papéis e Responsabilidades                       ► Define as funcionalidades do produto assim como conteúdo e             ...
Ciclo de Vida       Ciclo de vida do ScrumFonte: Adaptado de Improve It (2008)
Ciclo de Vida       Ciclo de vida do ScrumFonte: Adaptado de Improve It (2008)
Ciclo de Vida       Ciclo de vida do ScrumFonte: Adaptado de Improve It (2008)
O Product Backlog é uma lista de  todas as funcionalidades desejadas noproduto, estimadas pelo time e priorizadas         ...
Exemplo de   Product Backlog
O Product Backlog       Emergente      Priorizado e estimado Maior prioridade, mais detalhes    Priorização é tarefa do PO...
O Product Backlog           EmergentePriorizado e estimado Maior prioridade, mais detalhes    Priorização é tarefa do PO A...
O Product Backlog                Emergente          Priorizado e estimadoMaior prioridade, mais detalhes         Priorizaç...
O Product Backlog             Emergente       Priorizado e estimado   Maior prioridade, mais detalhesPriorização é tarefa ...
O Product Backlog               Emergente         Priorizado e estimado     Maior prioridade, mais detalhes      Qualquer ...
Sprints• Representa um Time Box (uma iteração), dentro do  qual um conjunto de atividades deve ser executado• Ocorre em um...
Sprints          - Sprint Planning Meeting -• É uma reunião de planejamento na qual:   o O Product Owner prioriza os itens...
Sprints                 - Sprint Backlog -• É uma lista de tarefas que o Scrum Team se  compromete a fazer em um Sprint• S...
Sprints                   - Daily Scrum -– É uma reúnião diária da equipe dentro do Sprint, que  tem por objetivo:   o Dis...
Sprints                 - Daily Scrum -• Três Questões para todos:  • O que fizeste ontem?  • O que vais fazer Hoje?  • Há...
Sprints       - Sprint Review Meeting -O ScrumTeam e o SCRUM Masterapresentam ao Product Owner os resultadosalcançados dur...
Sprints         - Sprint Retrospective -O Sprint Retrospective ocorre ao finalde um Sprint e serve para identificar oque f...
Sprints           - Sprint Retrospective -Em uma das maneiras de se conduzirum Sprint Retrospective, a equipediscute o que...
Estudo de Caso: O Projeto XMPM (1)Características do Projeto  • Software desktop destinado a usuários finais de celulares ...
Estudo de Caso: O Projeto XMPM (2)Características do Produto → Suporte a 9 (nove) diferentes idiomas; → Possui instalador ...
Estudo de Caso: O Projeto XMPM (3)Práticas adaptadas para o contexto do projeto  Sprint:  - No projeto XMPM foram usados 5...
Estudo de Caso: O Projeto XMPM (4)Práticas adaptadas para o contexto do projeto Planejamento do Sprint:  - Duas reuniões s...
Estudo de Caso: O Projeto XMPM (5)Práticas adaptadas para o contexto do projeto Revisão do Sprint:    - A equipe apresenta...
Estudo de Caso: O Projeto XMPM (6) Reunião de Retrospectiva: - O Scrum master e a  equipe participam desta  reunião.- O qu...
Estudo de Caso: O Projeto XMPM (7)Práticas adaptadas para o contexto do projeto Reuniões Diárias do Scrum:  - As reuniões ...
Estudo de Caso: O Projeto XMPM (8)Práticas adaptadas para o contexto do projeto  Builds Diários:  - Builds diários no bran...
Estudo de Caso: O Projeto XMPM (9)Práticas sendo adaptadas para o contexto do projeto  Teste antes do desenvolvimento: - E...
Resumo e PerspectivaResumo • O fator terceirização adiciona mais complexidade ao uso do Scrum.  • As práticas melhoram a v...
ConclusãoScrum é uma metodologia de gerenciamento de projetos que está setornando cada vez mais comum na industria de soft...
?
• http://br.groups.yahoo.com/group/scrum-brasil/• http://blogdoabu.blogspot.com/2008/11/planning-poker.html• http://planni...
Planning Poker  An agile estimatingtechnique for agile and     Scrum teams    Gestão ágil de projetos           Apresentad...
31% são   cancelados53% custam o   dobro do estimadoApenas    16% são completados noprazo e custo estimados               ...
Mas por que?
Falta de envolvimento   do usuárioRequisitos e especificações incompletas      Falta de suporte   da direção     Falta de ...
É difícil estimar tempos              de execução
Time*        *Tudo eu! Tudo eu!
2±97
Responsabilidades:     • Estimar itens do backlog• Se comprometer a entregar um incrementofuncional de software• Gerenciar...
As cerimônias do SCRUM
Reunião de Estimativa:• Preparação para o Sprint Planning• Estimar baseado no tamanho, nuncaem tempo• Atualizar Product Ba...
O Product Backlog           EmergentePriorizado e estimado Maior prioridade, mais detalhes  Qualquer um pode contribuir   ...
Scrum foca emtamanho enão em duração
Estimar em tamanhorelativo é mais simples
Planning Poker• É um método eficiente que estima o  tamanho dos requisitos em times que  adotam métodos ágeis (SCRUM, XP)....
Planning Poker• As estimativas acontecem em reuniões:  – Geralmente 4 ou 8 horas.  – Paticipantes:    • Todos os membros d...
O Processo1. Cada membro do time recebe um deck   de cartas:   0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e   “pausa”.      ...
O Processo2. Os itens a serem estimados são lidos pelo   PO ou SM    A equipe decide qual o menor item de backlog     dis...
O Processo3. Após a estimativa inicial, esse item é   marcado como “2” pontos        Serve para definir uma referência de...
O Processo4. Para cada estória o SM ou PO lê a   descrição e os critérios da aceitação da   mesma.   São    respondidos  ...
O Processo5. Cada desenvolvedor escolhe em silêncio   a carta que representa sua estimativa.   O moderador pede para todo...
O Processo6. Se todas as estimativas convergirem, a   estimativa está feita e o processo volta   ao início, para um novo i...
Dinâmica• Grupo•   São Paulo•   Rio Grande do Norte•   Paraíba•   Goiás•   Amazonas•   Sergipe•   Paraná
Conclusões• O Planning Poker é uma prática eficiente de  estimação de requisitos• Por ser uma técnica bastante flexível, s...
?
Referências• http://br.groups.yahoo.com/group/scrum-brasil/• http://blogdoabu.blogspot.com/2008/11/planning-poker.html• ht...
Minicurso SCRUM
Minicurso SCRUM
Minicurso SCRUM
Minicurso SCRUM
Minicurso SCRUM
Próximos SlideShares
Carregando em…5
×

Minicurso SCRUM

489 visualizações

Publicada em

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
489
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
16
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Minicurso SCRUM

  1. 1. ScrumGestão ágil de projetos Autores: Fábio Abrantes Diniz Íthalo Bruno de Moura Thiago Reis da Silva Diego Grosmanniz
  2. 2. ScrumGestão ágil de projetos Apresentadores: Fábio Abrantes Diniz Íthalo Bruno de Moura
  3. 3. 31% são cancelados53% custam o dobro do estimadoApenas 16% são completados noprazo e custo estimados * dados do CHAOS report
  4. 4. Mas por que?
  5. 5. Falta de envolvimento do usuárioRequisitos e especificações incompletas Falta de suporte da direção Falta de Pessoas e Recursos Falta de ESTIMATIVAS!!!
  6. 6. Falhar é uma maneira muitoforte de aprendizado, mas é preciso parar de apontar culpados
  7. 7. Olá, Scrum!Por que o nome Scrum?O nome é proveninente de uma jogada do Rugby, ondeé demostrada a força de trabalho em equipe.O Scrum do Rugby é formado por até 8 pessoas decada equipe.O objetivo do Scrum no Rugby é avançar a bola oval nocampo adversário o máximo possível. Para isso énecessário um ótimo trabalho em equipe.
  8. 8. Scrum é também um meio de evidenciar os problemas
  9. 9. Mas Scrum não é bala de prata* * Não mata vampiros & afins * Exige trabalho duro e comprometimento
  10. 10. PDCAPlan, Do, Check, Act
  11. 11. Planejamento
  12. 12. Execução
  13. 13. Checagem
  14. 14. Exatamente oque Scrum faz!
  15. 15. Quem usa o Scrum• Microsoft• Yahoo• Google• Lockheed Martin• Philips• Siemens• Nokia• BBC
  16. 16. Scrum tem sido usado para• Software comercial• Desenvolvimento interno (empresa)• Desenvolvimento contratado (terceirização)• Aplicações financeiras• Sistemas embarcados• Jogos• Sistemas para controle de satélites• Websites• Telefones celulares
  17. 17. Características do Scrum• As equipes se auto-organizam• O produto evolui em uma série de “Sprints” mensais• Os requerimentos são listados em um “Product Backlog”• Não há prática de engenharia prescrita (o Scrum adequa-se a todas)• É uma das “metodologias ágeis”
  18. 18. Papeis no scrum
  19. 19. Product Owner• O representante do cliente
  20. 20. Scrum Master• O Scrum Master lidera o time de desenvolvimento
  21. 21. Scrum Team• Scrum Team São os membros que formam o time de desenvolvedores, designers, consiste de 5 a 9 pessoas.
  22. 22. Papéis e Responsabilidades ► Define as funcionalidades do produto assim como conteúdo e data das liberações;Product Owner ► Responsável pela rentabilidade do produto; ► Prioriza as funcionalidades de acordo com o valor do mercado; ► Pode mudar as funcionalidades e priorizar a cada 30 dias; ► Aceita ou rejeita os resultados do trabalho. ► Garante que a equipe está completamente funcional e produtiva;Scrum Master ► Facilita comunicação entre papéis e remove impedimentos; ► Protege a equipe contra interferências externas; ► Assegura que o processo é seguido; ► Coordena os encontros diários, revisão e planejamento da iteração. ►Estimar itens do backlogTeam ► Tem o direito de realizar quaisquer atividades para alcançar o objetivo da iteração desde que respeite os guidelines do projeto; ► Auto organizados para entregar o que o PO quer. © 2006 BenQ Mobile 26
  23. 23. Ciclo de Vida Ciclo de vida do ScrumFonte: Adaptado de Improve It (2008)
  24. 24. Ciclo de Vida Ciclo de vida do ScrumFonte: Adaptado de Improve It (2008)
  25. 25. Ciclo de Vida Ciclo de vida do ScrumFonte: Adaptado de Improve It (2008)
  26. 26. O Product Backlog é uma lista de todas as funcionalidades desejadas noproduto, estimadas pelo time e priorizadas pelo Product Owner.
  27. 27. Exemplo de Product Backlog
  28. 28. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Priorização é tarefa do PO Alinhado ao plano de negócios
  29. 29. O Product Backlog EmergentePriorizado e estimado Maior prioridade, mais detalhes Priorização é tarefa do PO Alinhado ao plano de negócios
  30. 30. O Product Backlog Emergente Priorizado e estimadoMaior prioridade, mais detalhes Priorização é tarefa do PO Alinhado ao plano de negócios
  31. 31. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhesPriorização é tarefa do PO Alinhado ao plano de negócios
  32. 32. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do POAlinhado ao plano de negócios
  33. 33. Sprints• Representa um Time Box (uma iteração), dentro do qual um conjunto de atividades deve ser executado• Ocorre em um período de duas a quatro semanas• Baseia-se na idéia de que um período constante leva a um melhor “ritmo”• O produto é projetado, codificado e testado durante o Sprint• No início de cada Sprint, faz-se um Sprint Planning Meeting
  34. 34. Sprints - Sprint Planning Meeting -• É uma reunião de planejamento na qual: o O Product Owner prioriza os itens do Product Backlog o O Scrum Team determina que atividades será capaz de implementar durante o novo Sprint e cria o Sprint Backlog o O Scrum Team e o Product Owner definem um objetivo para o Sprint• O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint
  35. 35. Sprints - Sprint Backlog -• É uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint• Seus itens são extraídos do Product Backlog com base nas prioridades definidas pelo Product Owner • Uma estimativa do tempo necessário para a implementação das funcionalidades• O Scrum Master mantém o Sprint Backlog atualizado
  36. 36. Sprints - Daily Scrum -– É uma reúnião diária da equipe dentro do Sprint, que tem por objetivo: o Disseminar conhecimento sobre o que foi feito no dia anterior o Identificar impedimentos o Priorizar o trabalho a ser realizado no dia que se inicia– Os impedimentos identificados devem ser tratados pelo Scrum Master o mais rapidamente possívelObs: o Daily Scrum não deve ser usadocomo uma reunião para resolução deproblemas
  37. 37. Sprints - Daily Scrum -• Três Questões para todos: • O que fizeste ontem? • O que vais fazer Hoje? • Há Algum obstáculo?• Obs: As respostas não são um relatório para o Scrum Master. Elas são comprimissos dentro do Scrum Team.
  38. 38. Sprints - Sprint Review Meeting -O ScrumTeam e o SCRUM Masterapresentam ao Product Owner os resultadosalcançados durante o sprint.
  39. 39. Sprints - Sprint Retrospective -O Sprint Retrospective ocorre ao finalde um Sprint e serve para identificar oque funcionou bem, o que pode sermelhorado e que ações serão tomadaspara melhorar.Todos participam: –Scrum Master –Product Owner –Scrum Team
  40. 40. Sprints - Sprint Retrospective -Em uma das maneiras de se conduzirum Sprint Retrospective, a equipediscute o que gostaria de:– Iniciar a fazer– Parar de fazer– Continuar fazendo
  41. 41. Estudo de Caso: O Projeto XMPM (1)Características do Projeto • Software desktop destinado a usuários finais de celulares BenQ- Siemens • Projeto complexo com 300,000 LOC possuindo um ciclo de vida médio → Interação complexa com o ambiente físico (celular) → O software deve suportar diferentes modelos de celulares e rodar em diferentes distribuições do Linux → Uma série de versões intermediárias (builds) precisam ser desenvolvidas e testadas. → Desenvolvido por três parceiros situados fisicamente em localidades diferentes. → Necessidade de boa comunicação entre as equipes de desenvolvimento. → Definição clara de papéis e responsabilidades. © 2006 BenQ Mobile 45
  42. 42. Estudo de Caso: O Projeto XMPM (2)Características do Produto → Suporte a 9 (nove) diferentes idiomas; → Possui instalador gráfico para as seguintes distribuições (supporte oficial): - Suse 10 - Ubuntu 5.10 - Mandriva 2006 XMPM → Algumas das funcionalidades do XMPM incluem: - Sincromização de contatos, tarefas, notas e calendário entre o telefone celular BenQ-Siemens e KDE-Kontact. - Acesso à internet através de uma conexão GPRS. - Acessa ao sistema de arquivos e suporte a diferentes formatos de música. © 2006 BenQ Mobile 46
  43. 43. Estudo de Caso: O Projeto XMPM (3)Práticas adaptadas para o contexto do projeto Sprint: - No projeto XMPM foram usados 5 sprints e cada sprint com duração de aproximadamente 30 dias. - Sprints de 30 dias fornecem uma melhor visibilidade dos objetivos do pro e comprometimento da equipe. - Iterações mais curtas podem melhorar a visibilidade do projeto e permitir que riscos e incertezas sejam eliminados o mais rápido possível. © 2006 BenQ Mobile 47
  44. 44. Estudo de Caso: O Projeto XMPM (4)Práticas adaptadas para o contexto do projeto Planejamento do Sprint: - Duas reuniões são conduzidas no ínicio de cada iteração. - A primeira é realizada internamente com o product owner e visa refinar e priorizar o backlog do produto. - A segunda é realizada com os parceiros e visa criar o backlog do sprint de modo a atender os objetivos da iteração. © 2006 BenQ Mobile 48
  45. 45. Estudo de Caso: O Projeto XMPM (5)Práticas adaptadas para o contexto do projeto Revisão do Sprint: - A equipe apresenta no final de cada iteração os resultados obtidos (software funcionando) para o product owner e parceiros. - Esta prática impõe que a equipe trabalhe arduamente para alcançar os objetivos prometidos para a iteração. © 2006 BenQ Mobile 49
  46. 46. Estudo de Caso: O Projeto XMPM (6) Reunião de Retrospectiva: - O Scrum master e a equipe participam desta reunião.- O que deu certo durante o sprint e o que poderia ser melhorado. © 2006 BenQ Mobile 50
  47. 47. Estudo de Caso: O Projeto XMPM (7)Práticas adaptadas para o contexto do projeto Reuniões Diárias do Scrum: - As reuniões diárias ajudam a saber o quê cada membro da equipe está fazendo, compartilhar conhecimento e fornece uma boa visão para o Scrum Master. - O quê você fez desde o último report? - O quê você irá fazer até a próxima reunião? -Existe algum bloqueio para alcançar os objetivos da iteração? - Alguma lição aprendida ou decisão tomada? © 2006 BenQ Mobile 51
  48. 48. Estudo de Caso: O Projeto XMPM (8)Práticas adaptadas para o contexto do projeto Builds Diários: - Builds diários no branch de cada parceiro e um build semanal no ramo principal do projeto (uso de padrões de gerência de configuração). © 2006 BenQ Mobile 52
  49. 49. Estudo de Caso: O Projeto XMPM (9)Práticas sendo adaptadas para o contexto do projeto Teste antes do desenvolvimento: - Esta prática força o desenvolvedor pensar sobre o que o código deveria fazer antes de realmente implementá-lo. - Caso o desenvolvedor não seja capaz de escrever o caso de teste para o código então provavelmente existem problemas de projeto. - Depois de criar e executar o teste unitário, o mesmo torna-se apenas uma instância de testes de regressão. - Esta prática é simples em conceito, mas requer intensa preparação técnica. © 2006 BenQ Mobile 53
  50. 50. Resumo e PerspectivaResumo • O fator terceirização adiciona mais complexidade ao uso do Scrum. • As práticas melhoram a visibilidade do projeto e reduzem riscos e incertezas no início do ciclo de desenvolvimento. • A prática “revisão do sprint” exige que a equipe se esforce para cumprir com os objetivos prometidos da iteração. • A prática “teste antes do desenvolvimento” evita a criação de classes complexas e assegura a qualidade do código.Perspectiva • Adaptação dos métodos ágeis para desenvolvimento de sistemas embarcados.© 2006 BenQ Mobile 54
  51. 51. ConclusãoScrum é uma metodologia de gerenciamento de projetos que está setornando cada vez mais comum na industria de software. É bastanteeficiente quando utilizado por equipes pequenas, mas podetranquilamente ser usado em projetos com grandes equipes.O Scrum tem como vantagens a velocidade, um bom controle docronograma, diminuição dos riscos e incertezas e a visibilidade -graças às constantes reuniões.Por outro lado, a grande desvantagem do Scrum é a sensação deinformalidade, devida a falta de documentação formal dosoftware.
  52. 52. ?
  53. 53. • http://br.groups.yahoo.com/group/scrum-brasil/• http://blogdoabu.blogspot.com/2008/11/planning-poker.html• http://planningpoker.com/• http://netfeijao.blogspot.com/2008/10/estimativas-geis- planning-poker.html• Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft Press 2004• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta, Juhani. Agile Software Development Method, Review and Analysis. Espoo 2002. VTT Publications 478. 107p• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed. Enterprise Software Development Community, 2007.
  54. 54. Planning Poker An agile estimatingtechnique for agile and Scrum teams Gestão ágil de projetos Apresentadores: Fábio Abrantes Diniz Íthalo Bruno de Moura
  55. 55. 31% são cancelados53% custam o dobro do estimadoApenas 16% são completados noprazo e custo estimados * dados do CHAOS report
  56. 56. Mas por que?
  57. 57. Falta de envolvimento do usuárioRequisitos e especificações incompletas Falta de suporte da direção Falta de Pessoas e Recursos Falta de ESTIMATIVAS!!!
  58. 58. É difícil estimar tempos de execução
  59. 59. Time* *Tudo eu! Tudo eu!
  60. 60. 2±97
  61. 61. Responsabilidades: • Estimar itens do backlog• Se comprometer a entregar um incrementofuncional de software• Gerenciar o próprio progresso• Auto organizados para entregar o que o PO quer
  62. 62. As cerimônias do SCRUM
  63. 63. Reunião de Estimativa:• Preparação para o Sprint Planning• Estimar baseado no tamanho, nuncaem tempo• Atualizar Product Backlog com asestimativas• Importante para o PO criar o releaseplan
  64. 64. O Product Backlog EmergentePriorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios
  65. 65. Scrum foca emtamanho enão em duração
  66. 66. Estimar em tamanhorelativo é mais simples
  67. 67. Planning Poker• É um método eficiente que estima o tamanho dos requisitos em times que adotam métodos ágeis (SCRUM, XP).1• O método foi primeiramente descrito por James Grenning em 2002 e, mais tarde popularizado por Mike Cohn no livro Agile Estimating and Planning. 1 – É uma variação do método de estimativa Wideband Delphi (1940)
  68. 68. Planning Poker• As estimativas acontecem em reuniões: – Geralmente 4 ou 8 horas. – Paticipantes: • Todos os membros do time do Scrum; • O PO somente esclarece os requisitos e não estima junto a equipe; • O Scrum Master registra os resultados, não interferindo nas estimativas do time; • A equipe não deve ser superior a dez pessoas.
  69. 69. O Processo1. Cada membro do time recebe um deck de cartas:  0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e “pausa”. http://en.wikipedia.org/wiki/Planning_poker
  70. 70. O Processo2. Os itens a serem estimados são lidos pelo PO ou SM  A equipe decide qual o menor item de backlog disponível. http://blogdoabu.blogspot.com/2008/11/planning-poker.html
  71. 71. O Processo3. Após a estimativa inicial, esse item é marcado como “2” pontos  Serve para definir uma referência de tamanho e complexidade para ser usada nas demais estimativas.  E deve ficar registrado para uso nas futuras reuniões.  Em casos excepcionais o time pode decidir mudar esta estória de referência por uma outra.
  72. 72. O Processo4. Para cada estória o SM ou PO lê a descrição e os critérios da aceitação da mesma.  São respondidos questionamentos a respeito da estória;  Manter a discussão em alto nível, não entrar em detalhes.  Tempo prefixado (timebox) nesta etapa.
  73. 73. O Processo5. Cada desenvolvedor escolhe em silêncio a carta que representa sua estimativa.  O moderador pede para todos mostrarem as cartas. http://blogdoabu.blogspot.com/2008/11/planning-poker.html
  74. 74. O Processo6. Se todas as estimativas convergirem, a estimativa está feita e o processo volta ao início, para um novo item.  Se houver uma grande variação na estimativa, aqueles que apresentaram o(s) maior(es) e o(s) menor(es) valor(es) se justificam.  O processo se repete até todas as estimativas convergirem.
  75. 75. Dinâmica• Grupo• São Paulo• Rio Grande do Norte• Paraíba• Goiás• Amazonas• Sergipe• Paraná
  76. 76. Conclusões• O Planning Poker é uma prática eficiente de estimação de requisitos• Por ser uma técnica bastante flexível, se enquadra• É uma prática que envolve todo o time – Ajuda times novos a se conhecerem• Realmente funciona!!!
  77. 77. ?
  78. 78. Referências• http://br.groups.yahoo.com/group/scrum-brasil/• http://blogdoabu.blogspot.com/2008/11/planning-poker.html• http://planningpoker.com/• http://netfeijao.blogspot.com/2008/10/estimativas-geis-planning- poker.html• Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft Press 2004• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta, Juhani. Agile Software Development Method, Review and Analysis. Espoo 2002. VTT Publications 478. 107p• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed. Enterprise Software Development Community, 2007.

×