how make agile estimation process easy with planning poker
Uma arte de estimar é conhecida de todos.
10 maiores empresas de pesquisa de mercado do mundo
Estimamos todos os dias de nossas vidas. A maioria de nós pode estimar o peso dos vegetais simplesmente segurando-os; também podemos avaliar a maturação de uma fruta por seu aroma.
No artigo de hoje, aprenderemos sobre o Planning Poker também conhecido como Scrum Poker Cards, uma estimativa ágil e técnica de planejamento, que é uma técnica muito popular, fácil e simples nos dias atuais.
Para um exemplo da vida real de estimativa, vamos pegar um cenário de 3 amigos:
Tim, Bob e John que desejam dirigir a uma Conferência Técnica depois do trabalho. O local fica a 60 km de distância e possui um terreno acidentado. Tim, Bob e John discutem o plano de viagem na hora do almoço.
Bob diz , “Também estive nesta conferência no ano passado. Eu conheço o caminho e demorarei 2 horas para chegar lá ”.
Tim diz , “Sou um novo piloto e nunca estive nessa área antes. Se eu dirigir, levarei 4 horas. ”
John diz , “Eu estou bem em dirigir em uma área montanhosa, mas nunca estive lá antes. Então, pode levar 3 horas para levar todos nós até lá ”
Parece uma conversa normal, mas esses amigos apenas estimaram quanto tempo levará para cada um deles dirigir até a Conferência Técnica com base em suas experiências anteriores, suas habilidades de direção e familiaridade com o terreno.
Da mesma forma, no desenvolvimento de software, oferecemos estimativas com base em nossas experiências anteriores semelhantes , habilidades técnicas e familiaridade / conhecimento de domínio dos aspectos técnicos da tarefa atribuída.
O que você aprenderá:
- Por que precisamos fazer uma estimativa?
- Compreendendo as unidades de estimativa
- O que é o Planning Poker ou o Scrum Poker?
- Ferramenta recomendada
- Quando é que o Planning Poker é concluído?
- Conduzindo sessão de planejamento de pôquer
- Resumo das etapas
- Algumas dicas úteis
- Conclusão
- Leitura recomendada
Por que precisamos fazer uma estimativa?
O cronograma de entrega do projeto de software é orientado pelas necessidades do negócio. Para que a equipe se comprometa com os prazos, é importante que ela se reúna e forneça uma estimativa realista.
No início do projeto, o requisito pode não estar bem definido, a metodologia de desenvolvimento detalhada pode não ser delineada, as dependências podem não ter sido identificadas, etc. Ainda assim, é importante estabelecer uma estimativa de alto nível para que o projeto possa ser planejado adequadamente.
Por exemplo, se a estimativa de alto nível for mais do que a equipe pode atingir em um determinado período, as decisões podem ser tomadas se um recurso adicional precisar ser adquirido, os prazos devem ser estendidos etc.
Portanto, a estimativa é uma etapa crucial no ciclo de vida de desenvolvimento de software.
Compreendendo as unidades de estimativa
As unidades de estimativa podem ser em horas, dias ou pontos da história. As estimativas em horas e dias são fáceis de entender e relacionar. O conceito de storypoints é mais abstrato.
Os pontos da história são usados como uma medida de complexidade e incógnitas associadas a uma tarefa. O valor da pontuação da história é calculado de acordo com uma linha de base calculada. Esta linha de base é estabelecida pela própria equipe com base no velocidade da equipe em projetos anteriores. Quanto maior o valor do storypoint, mais esforço é necessário para implementar uma tarefa específica.
No entanto, é importante entender que os pontos da história não equivalem a horas, portanto, é difícil comparar os pontos da história e a estimativa de esforço em horas. Portanto, 1 ponto de história? 1 hora.
O que é o Planning Poker ou o Scrum Poker?
Conforme definido em Wikipedia :
“Planning poker, também chamado Scrum poker, é uma técnica baseada em consenso e gamificada para estimar, usada principalmente para estimar o esforço ou tamanho relativo dos objetivos de desenvolvimento no desenvolvimento de software”
A palavra 'Pôquer' lembra a todos sobre o jogo de cartas de Pôquer e, nem é preciso dizer, essas técnicas de estimativa usam cartas para fornecer estimativas. Vamos discutir
Discutiremos mais sobre as cartas e como uma sessão de planejamento de pôquer é realizada nas seções subsequentes do artigo.
Ferramenta recomendada
# 1) Agile Poker
Agile Poker é um aplicativo conhecido para Jira para planejamento rápido e conveniente e estimativas para equipes remotas e co-localizadas.
Começar com o Agile Poker é simples e fácil, pois foi inspirado por três metodologias de estimativa padrão da indústria: Planning Poker®, Wideband Delphi e Magic Estimation (também conhecido como Silent Grouping, Affinity Estimation, Swimlanes Sizing ou Relative Estimation).
perguntas da entrevista python e respostas para testadores=> Baixe a ferramenta Agile Poker aqui
Quando é que o Planning Poker é concluído?
O Planning Poker é uma técnica de estimativa e, como todas as sessões de fornecimento de estimativa, deve ser realizada antes do iteração / sprint começa.
As histórias de usuário podem ser obtidas nas questões pendentes e pré-selecionadas antes da reunião de Planning Poker. Com base nas estimativas fornecidas para as histórias de usuário, a decisão pode ser tomada em relação às histórias a serem incluídas em cada iteração.
Por exemplo, com base na velocidade anterior e desempenho da equipe, o Gerente de Projeto está ciente de que a equipe é capaz de entregar 20 pontos de história em 2 semanas. Se durante a sessão de planejamento de pôquer, a estimativa total das histórias de usuário pré-selecionadas exceder 20 pontos de história, o Gerente de Projeto tomará decisões sobre quais histórias de usuário incluir e / ou omitir na próxima Iteração para que a equipe possa entregar o histórias de usuários comprometidas no prazo.
Conduzindo sessão de planejamento de pôquer
Deixe-nos conduzir uma sessão de planejamento de pôquer simulada para ter uma idéia melhor do processo.
Para conduzir a sessão de planejamento de pôquer, você precisaria de várias cópias do baralho de cartas de planejamento do scrum. Não é necessário ter cartões em papel. Existem vários aplicativos online como Scrum Poker (android) ou Scrum Poker planning (IOS), etc. que podem ser usados.
Os cartões terão estimativas comuns sobre eles, por exemplo, 0, 0,5,1, 2, 3, 5, 8, 13, 20 etc. Esta sequência parecerá familiar para a maioria dos leitores e é a série de Fibonacci.
Algumas outras cartas opcionais são:? - para indicar que o estimador é incerto, símbolo do Infinito - para indicar que a tarefa não pode ser completada e Cartão da xícara de café - para indicar que o estimador precisa fazer uma pausa.
A figura abaixo mostra um baralho de cartas de planejamento de pôquer:
Se desejar, você também pode usar um dispositivo de cronômetro para rastrear e limitar o tempo gasto em cada discussão
Para esta sessão de planejamento de pôquer, considere um aplicativo de registro universitário baseado na web. A seguir estão as histórias do backlog que devem ser implementadas em um próximo sprint:
História do usuário 1: Como usuário, não devo ser capaz de me registrar sem fornecer o número do telefone celular
Descrição: Tornar o campo telefone celular obrigatório. O usuário receberá a mensagem de erro “Número de telefone celular obrigatório” se o campo for deixado em branco. Deve haver um botão ‘Fechar’ nesta mensagem de erro pop-up. A IU da caixa de diálogo, o tamanho da fonte e o estilo do texto da mensagem de erro devem ser iguais às outras mensagens pop-up no formulário. Esta mensagem seria disparada quando um usuário tentasse salvar o aplicativo.
História do usuário 2: Como usuário, não devo ser capaz de me registrar sem fornecer o número do telefone celular no formato adequado
Descrição: Adicione validação para o número da célula (agora deve estar no formato 111-111-1111). O usuário obterá “O formato do número do telefone celular deve ser 111-111-1111” se o formato estiver incorreto. Deve haver um botão ‘Fechar’ nesta mensagem de erro pop-up. A IU de uma caixa de diálogo, o tamanho da fonte e o estilo do texto da mensagem de erro devem ser os mesmos de outras mensagens pop-up no formulário. Esta validação seria acionada quando o usuário tentasse salvar o aplicativo
Tarefa 3: Alterar o logotipo da universidade para um novo logotipo em todas as 75 páginas do aplicativo da web
Vamos supor que o facilitador seja a Tia, Analista de Produto do projeto. Os estimadores são Tony (Desenvolvedor), Maria (designer de UI) e Gavin (Testador). Jose, o Gerente de Projeto, também estará presente na reunião, mas não participará da estimativa.
Passo 1 : Tia programa uma sessão de planejamento de pôquer e divulga as histórias de usuários em potencial para serem incluídas no próximo sprint com a equipe.
Passo 2: Todos os participantes comparecem à reunião. Quando a reunião começa, Tia entrega o baralho de cartas para cada avaliador ou cada avaliador abre o aplicativo de cartas de pôquer de planejamento em seus smartphones.
perguntas e respostas da entrevista php pdf
Etapa 3 : Tia oferece uma visão geral da história do usuário 1. Os avaliadores pedem esclarecimentos, discutem brevemente as áreas de impacto, a metodologia de desenvolvimento, etc.
Passo 4: Quando questionado por Tia, todo avaliador liga para seu número. Maria, Tony e Gavin escolheram 2 pontos de história como estimativa.
Etapa 5: Uma vez que o consenso é alcançado, a equipe passa para o próximo requisito.
Etapa # 6: Tia fornece uma visão geral do Requisito 2. Todos escolheram 1 ponto da história como estimativa, o consenso é alcançado, a equipe segue para o próximo requisito.
Etapa # 7: Tia fornece uma visão geral da Tarefa 3. Maria e Tony escolheram 1 e Gavin escolheu 2 pontos de história como estimativa. Como o consenso não foi alcançado, Tony e Gavin são convidados a justificar sua escolha. Tony diz que, como o logotipo da Universidade é exibido em um único local em cada página da web, eles só precisam atualizar o logotipo naquele local e pensa que 1 ponto de história é uma estimativa suficiente para desenvolvimento e teste de ambos.
Gavin, por outro lado, argumenta que embora a localização do logotipo seja centralizada, todas as páginas da web usam folhas de estilo diferentes, o testador precisaria navegar para cada página da web e verificar se o logotipo é exibido corretamente (não deve aparecer cortado, não deve parecer esticado, etc.).
Além disso, o teste precisaria ser feito para vários navegadores. Portanto, de acordo com Gavin, 2 pontos de história é uma estimativa realista para desenvolvimento e teste.
Etapa # 8: Tia pede a reavaliação das estimativas. Agora, Maria, Tony e Gavin estão de acordo e escolheram 2 pontos da história como estimativa.
Todas as histórias de usuário agora são estimadas, com o valor total de pontos da história do próximo sprint como 2 + 1 + 2 = 5 pontos da história. O gerente de projeto / analista de projeto cria formalmente um novo sprint e agende a data de início e término do sprint.
Resumo das etapas
(Clique para prolongar imagem)
Ferramentas de planejamento de pôquer online:
Algumas dicas úteis
# 1. Os estimadores devem vir preparados e passar pelos requisitos de antemão. Isso pode ser feito em sessões de Backlog Grooming. Estar preparado é essencial porque as estimativas precisam ser fornecidas com base no entendimento dos requisitos.
Por exemplopara fornecer uma estimativa precisa, o desenvolvedor precisa ter clareza sobre a metodologia que seguirá para implementar os requisitos. Se houver algumas incógnitas ou a tarefa for de alta complexidade, o storypoint e uma estimativa anexada à tarefa serão maiores.
#dois. O planejamento de reuniões de pôquer é uma atividade com limite de tempo e seu objetivo é reunir-se como uma equipe e fornecer estimativas. O foco deve ser fornecer estimativas com base nos desempenhos anteriores das equipes (ou velocidade). Esta reunião não deve ser confundida com outras reuniões como Daily Scrum, Backlog Grooming ou Retrospectiva.
# 3. As estimativas devem ser fornecidas pelas pessoas que realmente trabalharão no projeto. Com equipes localizadas em locais geográficos diferentes, as pessoas reais que trabalham no projeto precisam colaborar e fornecer estimativas. A reunião pode ser realizada online para facilitar as equipes de todas as localizações globais.
# 4. Lembre-se de se divertir!
(imagem fonte )
Conclusão
- O Planning Poker Estimation funciona muito bem em metodologia ágil .
- Esta técnica é escalonável e as estimativas são baseadas na velocidade da equipe
- O Planning Poker também é muito bem-sucedido devido ao fato de que recebemos estimativas diretamente das pessoas que trabalharão na tarefa e, portanto, é mais realista.
- Se o Gerente de Projeto fornecer ele mesmo as estimativas, sem consultar a equipe ou finalizar os detalhes técnicos, isso pode essencialmente colocar o projeto em risco devido a suposições feitas, detalhes esquecidos etc.
- Mais e mais empresas estão migrando para o Agile e usando técnicas de estimativa não tradicionais.
A estimativa é uma parte essencial do Planejamento de projeto . A abordagem de estimativa deve ser consistente, flexível, escalonável e funcionar bem para tarefas menores e histórias de usuário semelhantes. Além disso, não deve consumir muito tempo e recursos da equipe.
A última coisa que você precisa é uma tarefa de estimativa para estimar!
Sobre a autor: Este artigo útil foi escrito por Neha B. Ela éatualmente trabalhando como Gerente de Garantia de Qualidade e se especializando em liderar e gerenciar equipes de QA internas e offshore.
Informe-nos se tiver alguma dúvida usando a técnica de pôquer do Planning para estimativa e planejamento Agile.
Leitura recomendada
- 4 etapas para desenvolver a mentalidade de teste ágil para uma transição bem-sucedida para o processo ágil
- Técnicas de estimativa ágil: uma estimativa verdadeira em um projeto ágil
- Como entregar recursos de software de alto valor em um curto período de tempo usando o processo Agile Scrum
- 6 razões mais comuns para adotar o Agile em sua organização (Parte 1)
- Tutorial do JIRA Agile: Como usar o JIRA com eficácia para gerenciar projetos Agile
- Manifesto Agile: Compreendendo os valores e princípios do Agile
- A mudança de mentalidade de um testador ágil: alinhando-se com o manifesto ágil
- Tutorial do SAFe Agile: O que é o Scaled Agile Framework