Técnicas de estimativa ágil: uma estimativa verdadeira em um projeto ágil

agile estimation techniques

Estimativas verdadeiras em um projeto ágil: uma visão completa com exemplos de estimativas ágil

É muito importante fazer a estimativa ágil em diferentes níveis. Isso é feito para um planejamento adequado, gerenciamento e estimativa dos esforços totais que vamos usar para implementar, testar e entregar o produto desejado aos Clientes em termos de tempo dentro dos prazos especificados.

Com a falta de Estimativas no Projeto Ágil, pode não haver planejamento e gerenciamento adequados, o que pode resultar na entrega do produto indesejado e, assim, deixar o cliente insatisfeito.

Estimativas de pontos da história são feitas em projetos Agile usando diferentes técnicas, como Planning Poker, Bucket System, Affinity Mapping, etc. Diferentes modelos de estimativa em diferentes níveis são usados ​​para este propósito, como Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template , Modelo de história de usuário etc.

O que você aprenderá:

• Introdução
• Estimativas de pontos da história no Agile
• Ferramenta recomendada
• Diferentes técnicas de estimativa ágil
  • # 1) Planning Poker
  • # 2) Tamanhos de camisetas
  • # 3) Votação por pontos
  • # 4) O sistema de balde
  • # 5) Grande / Incerto / Pequeno
  • # 6) Mapeamento de afinidade
  • # 7) Método de pedido
• Cálculo do orçamento no Agile
• Modelos de estimativa em projeto de desenvolvimento ágil
  • 1) Modelo de plano de projeto ágil:
  • 2) Modelo de plano de lançamento ágil:
  • 3) Modelo de backlog do produto Agile:
  • 4) Modelo de backlog do Agile Sprint:
  • 5) Modelo de plano de teste ágil:
  • 6) Modelo de história de usuário Agile:
  • 7) Modelo de roteiro ágil:
• Estágios de estimativa em projeto ágil
  • # 1) Proposta ou estimativa do nível do projeto
  • # 2) Estimativa do nível de liberação
  • # 3) Estimativa de nível de sprint
• Conclusão
• Leitura recomendada

Introdução

Abaixo estão os 3 níveis principais de Estimativa Ágil.

# 1) Nível de projeto ou proposta é aquele que utiliza a Análise Rápida de Pontos de Função durante as fases iniciais de desenvolvimento do Projeto.

# 2) Nível de liberação inclui a atribuição de pontos de história às histórias de usuário que podem ajudar a definir a ordem das histórias de usuário com base na prioridade e também pode ajudar a decidir quais histórias podem ser obtidas na versão atual e quais podem ser tomadas posteriormente.

# 3) Nível de Sprint é aquele em que as histórias de usuário são divididas nas tarefas e as horas estimadas são atribuídas às tarefas de acordo com sua complexidade. Aqui, também definimos a pessoa responsável pela tarefa, juntamente com o status das tarefas.

Essas informações podem ser usadas posteriormente para calcular o orçamento para o projeto Agile. O cálculo do orçamento é crucial para garantir que o projeto não ultrapasse o orçamento devido às tarefas de pré e pós-iteração ou alguns outros motivos.

Estimativas de pontos da história no Agile

As estimativas de Story Points são uma análise comparativa para estimar aproximadamente os itens do backlog do produto com o tamanho relativo. Os membros da equipe para estimar histórias de usuário incluem: Product Owner, Scrum Master, Developers, Testers e Stakeholders.

Abaixo estão algumas etapas para chegar à decisão final sobre o dimensionamento relativo:

# 1) Analise todas as histórias de usuários e identifique a história base ou de referência. É importante para fazer o dimensionamento relativo. Esta história pode ser escolhida a partir do backlog do produto atual ou daquele que fizemos anteriormente. Esta história deve ser escolhida como história de referência mediante acordo de todos os membros.

#dois) Escolha outra história do Backlog do produto atual e os membros da equipe serão livres para discutir quaisquer questões ou dúvidas com o Product Owner, enquanto entendem os requisitos da história. O Product Owner é responsável por esclarecer todas as suas dúvidas e dúvidas.

# 3) Faça uma lista das coisas a serem cuidadas durante a implementação da história do usuário. Isso pode ser feito escrevendo notas na seção de notas da ferramenta ou adicionando marcadores no cartão de história. Isso é feito principalmente pelo Scrum Master.

# 4) A seguir, algumas perguntas comuns entre os participantes:

• Projeto: Quais são os conhecimentos prévios e obrigatórios que devemos ter antes de começar a trabalhar nisso?
• Codificação: Quanta codificação é necessária para implementar esta história de usuário. Já encontramos alguma história de usuário semelhante anteriormente?
• Teste de Unidade: Existem objetos simulados necessários para fazer o teste de unidade para esta história de usuário?
• Teste de integração: Essa história afeta as outras funcionalidades do mesmo módulo e também de outros módulos?
• Teste de aceitação: Quais são os pontos a serem atendidos para entregar o produto desejado conforme desejado pelos Clientes?
• Perícia: Algum dos participantes fez uma história semelhante antes e é um especialista nisso?

# 5) Faça o dimensionamento relativo para a história selecionada. Se exigir a mesma quantidade de trabalho e esforço, atribua-lhe o mesmo não. de pontos, conforme atribuído à história de referência. Se isso exigir mais esforço, atribua a ele algum valor mais alto. Se exigir menos esforço, atribua a ele algum valor inferior.

# 6) Chegue a um consenso com todos os participantes para finalizar o tamanho relativo da história do usuário selecionada de acordo com a definição de pronto.

como gerar números aleatórios em c ++ entre 0 e 100

# 7) Após o dimensionamento relativo de todos os itens do backlog do produto, certifique-se de que, se todas as histórias de usuário com o mesmo nº. de pontos atribuídos a eles, requerem o mesmo esforço e tamanho para serem consistentes.

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).

Diferentes técnicas de estimativa ágil

Existem muitas técnicas para fazer estimativas em um projeto ágil. Os princípios básicos para fazer estimativas incluem a Estimativa Relativa, discussões para obter mais informações dos itens cujas estimativas precisam ser feitas e garantir o comprometimento de toda a equipe com as tarefas que lhes são atribuídas.

Existem principalmente 7 técnicas de estimativa de projetos ágeis:

# 1) Planning Poker

• Nesta técnica de Estimativa, todas as pessoas que deveriam fazer as estimativas sentam-se em um círculo redondo para a sessão de Planning Poker.
• Cada estimador tem um conjunto de valores de Planning Poker Cards: 0,1,2,3,5,8,13,20,40 e 100. Estes valores representam pontos de história ou medidas em que a equipe estima.
• No início da sessão, o proprietário do produto ou cliente lê a história do usuário, descrevendo todos os seus recursos e requisitos.
• Depois que a história é lida, as discussões entre os avaliadores e com o product owner / cliente acontecem. Os estimadores podem fazer perguntas ou esclarecer suas dúvidas com o product owner.
• Após as discussões, todos os avaliadores são solicitados a selecionar um cartão para estimar uma história de usuário. Se todos os estimadores derem o mesmo valor, então essa será a estimativa final.
• Se os valores forem diferentes, os estimadores que fornecem os valores mais altos e mais baixos explicam suas opiniões e por que escolheram esse valor, até que um consenso seja alcançado.
• Uma boa técnica quando pequena não. de itens deve ser estimado em uma pequena equipe.

=> Leituras mais detalhadas sobre Técnica de estimativa de poker de planejamento .

# 2) Tamanhos de camisetas

• Assim como no caso das camisetas, vemos os tamanhos: XS (Extra Pequeno), S (Pequeno), M (Médio), L (Grande), XL (Extra Grande). Uma abordagem semelhante é seguida aqui. Os itens são estimados em tamanhos de camiseta.
• Esta é uma técnica perfeita para dar uma estimativa aproximada do grande acúmulo de itens.
• Útil quando uma estimativa rápida e aproximada precisa ser feita. Mais tarde, esses tamanhos podem ser convertidos em nãos de acordo com o requisito.
• Um tamanho relativo (principalmente Médio) é decidido após discussão mútua e acordo dos membros da equipe ou estimadores. Então, os nãos são atribuídos aos itens de acordo com o tamanho relativo que é atribuído ao tamanho Médio.
• Desvantagem: O que parece L para alguém pode parecer XL para alguém.
• Todos os estimadores atribuem seus próprios tamanhos aos itens. Após discussões e resolução das incompatibilidades, chega-se a um consenso para obter a estimativa final.

# 3) Votação por pontos

• Este é basicamente um método de classificação para decidir a ordem do Backlog do produto das histórias de prioridade mais alta para as histórias de prioridade mais baixa. Isso é feito para selecionar as histórias mais importantes que devem ser levadas adiante.
• Para começar, poste todas as histórias de usuário junto com sua descrição na parede ou quadro usando adesivos amarelos ou de uma forma que os diferencie para receber os votos.
• Todos os participantes recebem de 4 a 5 pontos (principalmente na forma de adesivos, canetas ou marcadores também podem ser usados ​​para fazer pontos).
• Todas as partes interessadas são solicitadas a dar seus votos nas histórias de usuário de sua preferência.
• O Product Owner ordena os itens da lista de pendências do produto do mais preferido (um com a maioria dos pontos) para o menos preferido (um com o menor número de pontos).
• Pode ser o caso, onde poucos interessados ​​estão insatisfeitos com a ordem decidida. Nesse caso, as histórias de usuário são divididas em 3 grupos após as discussões: alta prioridade, baixa prioridade e média prioridade. Histórias de usuários de alta prioridade são postadas no mural para receber os votos. Isso é feito até que o pedido final seja alcançado com o acordo de todas as partes interessadas.

# 4) O sistema de balde

• É uma boa técnica quando um grande não. de itens devem ser estimados em grande número de participantes. É mais rápido e mais razoável do que o Planning Poker.
• Depósitos diferentes são criados com os valores: 0,1,2,3,4,5,8,13,20,30,50,100, 200. Isso pode ser estendido, se necessário. Esses baldes nada mais são do que cartas que representam valores organizados sequencialmente em uma mesa.
• As histórias precisam ser colocadas dentro deles, onde o avaliador as considere adequadas. Todos os itens a serem estimados estão escritos nos cartões.
• Escolha um item aleatoriamente e coloque-o no balde 8. Isso é usado apenas para referência. Escolha outra história ao acaso, discuta todas as suas características e requisitos com o grupo e, em consenso, coloque-a no balde apropriado. Da mesma forma, o terceiro item é coletado e colocado em um balde apropriado.
• A sequência do balde também pode ser alterada, caso o grupo sinta que o primeiro item escolhido deve pertencer ao balde 1 em vez do balde 8.
• A abordagem de dividir e conquistar é seguida. Todos os itens restantes são divididos entre todos os participantes. Todos os participantes podem colocar o item sem a aprovação de outros participantes.
• Os itens devem ser colocados corretamente. Nenhum item pode ser colocado entre os baldes.
• Se um participante não entender o item do backlog do produto ou se os outros participantes terminaram de colocar suas histórias de usuário, as histórias de usuário podem ser transferidas para os outros participantes.
• Por fim, a verificação de sanidade é realizada por todos os participantes. Se algum participante encontrar um balde errado atribuído a um item, ele pode levá-lo ao conhecimento de outros participantes e discutir com eles. Isso é feito até que um consenso para todo o backlog do produto seja alcançado.
• O facilitador deve verificar se ninguém move os itens, a menos que a verificação de sanidade seja feita.
• Isso também é feito para atingir a ordem de prioridade dos itens do backlog do produto.

# 5) Grande / Incerto / Pequeno

• Esta é uma versão aproximada e é a simplificação do sistema de caçamba onde existem apenas três tamanhos: Grande, Pequeno e Incerto.
• Os participantes ou estimadores são solicitados a colocar os itens em uma das categorias. Primeiro, as histórias de usuário simples são escolhidas e colocadas nas categorias grandes e pequenas. Em seguida, os itens complexos são retomados.
• É uma boa técnica quando há itens comparáveis ​​no Backlog do produto.

# 6) Mapeamento de afinidade

• Uma boa técnica quando a equipe é pequena e não. de itens do backlog é menor.
• A primeira etapa é o dimensionamento relativo silencioso: Em uma parede, um cartão com 'Menor' escrito nele, é colocado no lado esquerdo e o cartão com 'Maior' escrito nele é colocado no lado direito. O Product Owner fornece um subconjunto de itens a todos os participantes. Todos os participantes são solicitados a dimensionar cada item em relação aos tamanhos nos cartões na parede, considerando o esforço necessário para implementá-los. É uma decisão individual do participante, sem qualquer discussão com os outros membros da equipe. O Product Owner ou stakeholder está presente para esclarecer as dúvidas do participante. Os itens do Backlog do produto que são muito ambíguos para serem compreendidos pelos membros da equipe para estimativa são colocados separadamente. Demora 5-20 minutos.
• Edição de parede: Os membros da equipe podem alterar a localização dos itens na parede. Eles podem discutir os requisitos de design e implementação com os outros membros da equipe. Esta atividade pode ser encerrada quando pouca mudança estiver acontecendo na parede. Demora cerca de 20-60 minutos .
• Colocando itens em locais corretos: Após as discussões, a equipe coloca os itens do backlog do produto em suas posições relativas e apropriadas. Podemos usar tamanhos de camisetas, séries Fibonacci etc. aqui para estimar relativamente o tamanho dos itens.
• Desafio do proprietário do produto: O Product Owner pode encontrar alguma discrepância nas estimativas feitas pela equipe e precisar discutir mais recursos ou requisitos para um item com a equipe. Após discussões, as estimativas finais são feitas.
• Exportar para a ferramenta de gerenciamento do backlog do projeto: Para garantir que as informações sobre as estimativas finais não sejam perdidas, exporte-as para uma ferramenta de gerenciamento de backlog do produto.

# 7) Método de pedido

• Uma boa técnica quando grande não. de itens e pequeno não. de pessoas estão lá.
• Ele fornece tamanhos relativos precisos para os itens da carteira de produtos.
• Uma escala é preparada variando de baixo a alto. Todos os itens são colocados aleatoriamente nele. Cada participante é solicitado a mover qualquer item da escala de uma vez. O movimento pode ser um para cima, um para baixo ou passar a vez para outro membro.
• Isso continua até que todos os participantes estejam satisfeitos e não queiram mover nenhum item da balança.
• Isso também fornece a ordem de prioridade dos itens do Backlog do produto.

Cálculo do orçamento no Agile

Calcular orçamentos desempenha um papel importante em projetos Agile. Isso é feito para ter certeza de qual é o orçamento real fornecido, que mais orçamento é necessário e como vamos dividir o orçamento para os diferentes itens do backlog do produto.

Ele usa os dados coletados dos projetos anteriores e usa a fórmula matemática para obter o orçamento estimado para o projeto atual.

Abaixo está a sequência de etapas para calcular o orçamento em um projeto Agile:

# 1) Liste todos os requisitos do projeto e faça o estimativas para eles usando Planning Poker, Bucket System, série Fibonacci, etc. Todos os membros da equipe devem concordar com as estimativas feitas para os requisitos listados após uma análise clara e compreensão das histórias de usuário. As estimativas são feitas com base nos recursos a serem implementados em uma história de usuário.

#dois) Determine a duração das iterações chamadas Sprints e itens do backlog do produto atribuídos a ela. Geralmente dura de 2 a 3 semanas. As histórias de usuário são selecionadas em uma sequência, começando com a história de usuário de prioridade máxima, passando para a prioridade menor e com a história de usuário de menor prioridade no final. Isso ajuda a decidir quais histórias de usuário devem ser escolhidas no primeiro Sprint e quais histórias podem ser retomadas posteriormente.

# 3) Prepare o gráfico queimado para dar uma imagem clara de quanto trabalho resta a ser feito em comparação com quanto tempo resta para implementação. Basicamente, dá a taxa de progresso de uma equipe ágil. Ele dá uma imagem clara de como a equipe está se comportando e como se espera que se comporte.

O progresso da equipe é medido em termos de tarefas concluídas, esforço remanescente, burndown ideal e tarefas restantes, conforme mostrado abaixo:

# 4) Adicione custos adicionais como compra de equipamentos, ferramentas, suporte de infraestrutura, obtenção de licenças para as ferramentas de software a serem usadas, ferramentas de gerenciamento de projetos, instalação de antivírus e atualizações.

# 5) Adicione orçamentos de pré e pós-iteração. Todos os membros do Agile devem ser multifuncionais, mas há limites para isso. Qualquer coisa feita por um membro da equipe fora de sua especialidade é considerado trabalho de pré-iteração ou pós-iteração. Esses trabalhos de pré e pós-iteração requerem um orçamento adicional para implementação.

# 6) Ficar de olho nos riscos ocultos. Os riscos no projeto Agile incluem: Risco de o projeto ultrapassar o orçamento, Ausência de membros da equipe, Membros não têm um conhecimento claro ou completo, Membros não têm as habilidades necessárias, prazos foram ultrapassados, etc.

Modelos de estimativa em projeto de desenvolvimento ágil

Existem muitos modelos de estimativa que são preparados em diferentes níveis no projeto de desenvolvimento Agile. O único objetivo é estabelecer claramente as estimativas necessárias para a implementação de um requisito ou item e rastrear seu progresso.

Os principais modelos são mencionados abaixo:

1) Modelo de plano de projeto ágil:

Ele fornece uma visão de alto nível de quanto tempo é necessário para entregar os recursos dos requisitos e qual é o seu status. Também menciona a pessoa responsável por uma tarefa específica.

(Nota: Clique em qualquer imagem para uma visão ampliada)

2) Modelo de plano de lançamento ágil:

Ele fornece detalhes de liberação das tarefas correspondentes aos requisitos, junto com seu status e Sprint em que eles precisam ser executados.

3) Modelo de backlog do produto Agile:

Ele descreve o backlog completo do produto definido para o projeto. Ele fornece detalhes das tarefas dos Sprints junto com status, prioridade, pontos da história e se eles são atribuídos a um Sprint ou se há alguma tarefa adicional como defeitos, etc.

4) Modelo de backlog do Agile Sprint:

Ele fornece uma descrição das histórias de usuário mencionadas no backlog de um determinado Sprint. Ele fornece os pontos de história totais atribuídos a uma história de usuário e como eles são divididos em tarefas diferentes. Ele também dá o status das tarefas correspondentes e qual é o trabalho realizado diariamente para as tarefas correspondentes.

5) Modelo de plano de teste ágil:

Ele divide todo o cenário de teste em sub-cenários. Ele fornece detalhes dos sub-cenários como data de implementação, resultado esperado, resultado real, status, etc.

Ele também menciona o nome do projeto, navegador compatível, versão do aplicativo em teste, ID do caso de teste para um cenário selecionado, escrito por, testado por, descrição, etc.

6) Modelo de história de usuário Agile:

Ele fornece os detalhes específicos para a análise da história do usuário, como quais são as funções necessárias para que uma funcionalidade específica seja testada, qual é o pré-requisito (configuração do ambiente e links habilitados) e qual é o resultado esperado?

7) Modelo de roteiro ágil:

Ela dá um direcionamento ao projeto na empresa, no curto e no longo prazo. Ajuda a definir expectativas dentro da empresa. E a visão geral de para onde o projeto está indo.

Estágios de estimativa em projeto ágil

Em um projeto ágil, as estimativas são feitas em 3 níveis, conforme mencionado abaixo:

• Nível de projeto / proposta: O tamanho funcional total de todo o aplicativo é estimado usando o método Quick Function Point Analysis (QFPA) quando apenas os requisitos de alto nível estão disponíveis.
• Nível de liberação: Os pontos da história são atribuídos às histórias do usuário, o que ajuda a determinar o não. de lançamentos planejados dentro de um projeto e o não. de histórias de usuário a serem obtidas em um release e sprint.
• Nível de Sprint: As horas estimadas são atribuídas às tarefas das histórias de usuário em uma sprint. Isso é feito para garantir o compromisso do desenvolvimento de entregar histórias de usuário em um sprint.

S1, S2, S3, S4, S5, S6 são sprints.

# 1) Proposta ou estimativa do nível do projeto

É uma estimativa de alto nível para o projeto. Ele se concentra no número total de requisitos no item Backlog do produto. Os Pontos de Função são usados ​​para estimar o tamanho do software / projeto antes que uma descrição detalhada dos requisitos funcionais seja documentada.

Os pontos de função são a forma universalmente aceita de calcular o tamanho do software. Tem como foco as funcionalidades encontradas nos projetos de software. Um ponto de função é uma métrica que converte os requisitos ou histórias de usuário em um número.

Durante os estágios iniciais do projeto, é recomendado adotar o método Quick Function Point Analysis (QFPA).

O método Quick Function Point Analysis é uma abordagem única para estimar FP quando apenas os requisitos de alto nível estão disponíveis.

Como calcular o tamanho funcional total?

• Compreenda todas as funcionalidades de um aplicativo com a ajuda de especialistas no domínio.
• Identifique e liste todas as funcionalidades possíveis de um aplicativo.
• As funções de armazenamento de dados são classificadas em Arquivos de lógica interna (dados armazenados internamente no aplicativo) e Arquivos de interface externa (dados usados ​​apenas para referência).
• As funções de transação são classificadas em Entradas Externas (dados provenientes de fontes externas para o aplicativo), Saídas Externas (os dados derivados vão do aplicativo para o exterior) e Consultas Externas (dados recuperados de uma ou mais Entradas Externas e Saídas Externas).
• Calcule o tamanho do FP para cada função calculando sua complexidade média.
• Resuma o tamanho do FP de todas as funções, para obter o Tamanho Funcional Total do aplicativo.
• Pelo menos duas pessoas com experiência em análise de PF devem calcular de forma independente, combinar os resultados e resolver as diferenças.

o que é função de amigo em c ++

Exemplo para estimativa em nível de projeto:

Abaixo está a lista de requisitos para um projeto, como no Backlog do produto:

• Um usuário deve ser capaz de acessar o site fornecendo o nome de usuário e a senha.
• Após o login com sucesso, o usuário deve ser levado à página principal com os painéis direito e esquerdo definidos.
• O usuário deve ter a opção de fazer logout do aplicativo.
• Um usuário válido tem a opção de alterar a senha fornecendo credenciais atuais.

A equipe usa uma estimativa Quick FP para estimar o tamanho do projeto.

A seguir está a análise feita:

• A função de armazenamento de dados aqui é armazenar as credenciais do usuário para fazer o login e alterar a senha.
• Como as credenciais são armazenadas dentro do limite do aplicativo, elas são armazenadas em ILFs (Arquivos Lógicos Internos).
• As funções de transação incluem:
  • Login do usuário e exibição da página principal.
  • Logout do usuário e exibição da tela de logout.
  • Capacidade de alterar a senha.

Abaixo estão as etapas executadas para estimar o tamanho do projeto usando a análise rápida de ponto de função:

ETAPA # 1: Listar todas as funções de dados

UFP (Unadjusted Function Point) é obtido da Tabela Caper Jones.

ETAPA # 2: Listar todas as funções de transação

UFP (Unadjusted Function Point) é obtido da Tabela Caper Jones.

ETAPA # 3: Derivando o tamanho estimado do projeto em Pontos de Função

UFP = Dados FP + Transação FP

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (Assumindo VFP (fator de ajuste de valor = 1)

Produtividade = 16 FP / mês (Padrão Normal)

Esforço = FP / Produtividade = 22/16 pessoa / mês = 1,37 pessoa / mês

# 2) Estimativa do nível de liberação

As estimativas de nível de liberação são feitas durante o planejamento da liberação. É a próxima atividade após a estimativa do nível do projeto. Os requisitos priorizados são retirados do Backlog do produto, que está na forma de User Stories.

As histórias do usuário são estimadas em termos de pontos da história durante o planejamento da versão, que se concentra em estimar o tamanho do software a ser entregue para essa versão. Desta forma, nenhum lançamento e nenhum total de pontos da história em cada lançamento é planejado.

Um ponto da história basicamente representa o esforço relativo necessário para implementar um recurso ou funcionalidade, quando comparado com os outros recursos. É basicamente para dimensionar os itens do Backlog do produto.

A estimativa do ponto da história é feita com base em:

• A complexidade do recurso a ser implementado.
• Experiência e habilidade técnica de todos os membros.

S1, S2, S3, S4, S5 são sprints.

Etapas para atribuir pontos de história a uma história de usuário:

• Todos os membros da equipe se reúnem em torno de uma mesa, analisando as histórias de usuário presentes no Sprint Backlog.
• O significado de um ponto da história e o esforço correspondente são decididos.
• Um dos membros da equipe lê uma história de usuário e, em seguida, pede aos membros da equipe que atribuam os pontos de história relativos.
• Se houver uma diferença significativa entre os pontos da história atribuídos pelos membros da equipe, eles explicam os pontos da história que atribuíram, chegando a um consenso no final.
• O processo é repetido 3-4 vezes até que não haja grande diferença entre as estimativas fornecidas pelos membros da equipe.
• O dimensionamento das histórias ajuda a determinar quantas histórias serão tiradas em um sprint e lançamento.

Exemplo para estimativa de nível de liberação:

Isso envolve a criação de uma lista priorizada de Estórias de Usuário chamada Backlog do Produto. O Product Owner cria o Product Backlog e fornece valor comercial para cada um dos itens listados nele.

Podemos usar os métodos abaixo para estimativas de pontos de história:

• Dimensionamento numérico: 1 a 10
• Tamanho da camiseta: Cada requisito é classificado como Extra Pequeno (XS), Pequeno (S), Médio (M), Grande (L), Extra Grande (XL).
• Série Fibonacci: Estimativa feita através da Sequência de Fibonacci (1,2,3,5,8,13,21,34,….)

Estimativa das histórias de usuário acima por meio da sequência de Fibonacci:

# 3) Estimativa de nível de sprint

As estimativas de nível do Sprint são feitas durante o Planejamento do Sprint. Os itens de lista de pendências de produtos de mais alta prioridade são pegos e divididos em diferentes tarefas, como Detalhamento, Projeto, Análise, Desenvolvimento, Criar Casos de Teste, Executar Casos de Teste, Teste de Aceitação do Usuário, etc.

As tarefas são estimadas em termos de horas estimadas, ou seja, o tempo necessário para concluir essa tarefa para uma história de usuário correspondente. A Abordagem Bottom-Up é usada para estimativas de Tarefa onde os requisitos de negócios são divididos em atividades de baixo nível e cada atividade recebe horas estimadas atribuídas.

O objetivo das estimativas é saber quantas histórias de usuário a equipe de desenvolvimento pode comprometer em um Sprint. O desenvolvimento deve estar confortável com o compromisso e os Donos do Produto devem estar confiantes de que a equipe cumprirá o compromisso.

S dicas para atribuir horas estimadas às tarefas:

• Os membros da equipe coletam as histórias de usuário. Em seguida, eles são solicitados a estimar o esforço real, em termos de horas ou dias, para as tarefas correspondentes à história de usuário.
• Se houver desacordo nessas estimativas entre os membros da equipe, eles discutem e chegam a um consenso.
• Se qualquer tarefa durar mais de seis horas, ela será dividida em tarefas menores.
• Se houver duas ou mais tarefas com horas estimadas de menos de duas, elas serão combinadas para formar uma nova tarefa.

Exemplo para estimativa de nível de sprint:

Existem duas partes na reunião de planejamento do Sprint:

• Primeira parte: O foco está em esclarecer os requisitos para as Estórias de Usuário, selecionadas do Backlog do Produto.
• Segunda parte: O foco está em dividir os requisitos em tarefas e estimar as horas necessárias para concluí-los. Todas as tarefas necessárias para tornar o item do Backlog do Produto entregável devem ser incluídas. As tarefas devem ser pequenas. Idealmente, um esforço de tarefa não deve ser superior a seis horas.

Conclusão

As estimativas em projetos Agile desempenham um papel importante para garantir a direção, planejamento e gerenciamento adequados. Ele fornece etapas sobre como assumir o projeto no futuro.

As técnicas para estimar os pontos da história, como Planning poker, Bucket System, etc., fazem uso de cartas ou pontos com valores ou números impressos neles e, em seguida, atribuem esses n ° s. às histórias de usuário para estimativa de tamanho relativo.

O único propósito é definir os itens em uma ordem priorizada da prioridade máxima para a prioridade mínima. Os tamanhos relativos estimados para os itens do backlog do produto ajudam a estimar ou calcular o orçamento necessário para o projeto.

Espero que você tenha obtido uma grande visão sobre as estimativas de projetos ágeis. Sinta-se à vontade para expressar suas idéias sobre este tutorial na seção de comentários abaixo.

Leitura recomendada

• Como tornar o processo de estimativa ágil fácil com o Planning Poker
• Agile Vs Waterfall: Qual a melhor metodologia para seu projeto?
• Técnicas de estimativa de teste de software (guia completo de estimativa de esforço de teste)
• Tutorial VersionOne: Guia da Ferramenta de Gerenciamento de Projetos Ágil Tudo-em-um
• Jira Portfolio Tutorial: Agile Project Portfolio Management Plug-in para JIRA (revisão)
• TOP 10 melhores ferramentas de gerenciamento de projetos ágeis em 2021
• Base para uma jornada ágil de sucesso: como escolher o método, as ferramentas e as técnicas corretas
• 4 etapas para desenvolver a mentalidade de teste ágil para uma transição bem-sucedida para o processo ágil