Agile Story Points vs. Horas: Como fazer uma estimativa melhor do desenvolvimento de software
Publicados: 2021-10-05Pode ser difícil envolver sua mente em torno dos processos de desenvolvimento de software. Quando você tem uma ideia e aborda os desenvolvedores com ela, as duas primeiras coisas que você pergunta são quanto custará para implementar e quanto tempo levará para construir . A estimativa é uma das primeiras etapas no desenvolvimento de aplicativos.
Neste artigo, comparamos os dois modelos de estimativa mais populares no desenvolvimento de software moderno: Pontos de história Agile vs horas .
Continue lendo para aprender como estimar o tempo no Agile, obter a essência de ambos os modelos de estimativa, entender suas diferenças e ver por que os desenvolvedores podem escolher um em vez do outro.
Horas são muito fáceis de entender e têm sido o principal modelo de estimativa no desenvolvimento de software por muito tempo. Horas, também conhecidas como horas de trabalho ou horas de trabalho, são o número de horas que um desenvolvedor gasta no projeto.
Então, o que são pontos da história e por que eles surgiram se já temos um modelo de estimativa simples e direto?
Conteúdo:
- O que exatamente são pontos da história?
- Veja como os pontos da história são calculados no Agile
- Vantagens de estimar em pontos da história
- Desvantagens de estimar em pontos da história
- Vantagens de estimar em horas
- Desvantagens de estimar em horas
- Você pode converter pontos da história em horas?
- Pontos da história x horas: o que escolher para o desenvolvimento de software?
O que exatamente são pontos da história?
Os pontos da história são um modelo de estimativa relativo nativo para Agile e Scrum. Eles estimam o esforço para construir um produto abordando três aspectos do desenvolvimento:
a quantidade de trabalho que o produto requer
a complexidade dos recursos do produto
riscos e incertezas que podem afetar o desenvolvimento
No início da avaliação do projeto, os desenvolvedores escolhem a menor e mais simples história de usuário de um produto - por exemplo, uma história de usuário de inscrição - e a definem como uma história de usuário de 1 ponto. Essa é a história básica : uma história de usuário que será usada para comparações de complexidade. Todas as outras histórias de usuário receberão uma série de pontos de história com base na complexidade de seu desenvolvimento em comparação com a história base.
Parece bastante simples na superfície, mas quem decide o número de pontos da história em cada história?
Veja como os pontos da história são calculados no Agile
Assim como acontece com as horas, as pessoas que trabalharão no produto geralmente estimam os pontos da história para o desenvolvimento. No entanto, o processo de estimativa é ligeiramente diferente com os pontos da história.
Para atribuir pontos de história a uma história de usuário, vários desenvolvedores estão envolvidos. Deve haver pelo menos dois, mas a empresa pode pedir a todos os seus desenvolvedores que contribuam jogando o que a indústria chama de Planning Poker . Aqui estão as regras do jogo:
Cada desenvolvedor recebe um conjunto de cartas do Planning Poker.
Os desenvolvedores escolhem uma história de usuário e discutem sua complexidade e o esforço de desenvolvimento necessário.
Cada desenvolvedor apresenta um cartão correspondente ao número de pontos que eles atribuem à história.
Se as estimativas de pontuação da história forem iguais, o número estimado de pontos será atribuído à história.
Se os pontos da história sugeridos forem diferentes, os desenvolvedores discutem a história do usuário até chegarem a uma série de pontos aprovados pela maioria.
Os desenvolvedores escolhem a próxima história do usuário.
Repita as etapas 3 a 5.
Quando todas as nossas atividades ficaram remotas, esse processo foi modificado. Em vez de cartões e reuniões, os pontos da história são decididos em discussões online, durante as reuniões do Zoom ou em mensageiros.
É mais ou menos assim:
Isso não significa que todos os desenvolvedores envolvidos na estimativa de pontos da história trabalharão no projeto, é claro. Mas uma vantagem principal do sistema de pontos da história é que ele cria uma estrutura mais ou menos universal que pode ser usada não apenas no projeto em questão, mas também em projetos futuros com recursos semelhantes.
Existem duas opções freqüentemente usadas para estimar pontos da história. Você pode atribuir pontos:
usando quaisquer números inteiros (1, 2, 3 ... 13,14,15, etc.)
usando números na sequência de Fibonacci (1, 2, 3, 5, 8, 13 ... 55, 89, 144, etc.)
A sequência de Fibonacci é uma opção mais conveniente para estimar o desenvolvimento, pois deixa alguma margem de aproximação. O modelo de ordem numérica é um pouco preciso demais para comparações convenientes.
Durante o desenvolvimento e entre projetos, se a história do usuário acabar sendo mais ou menos complexa do que o estimado originalmente, os pontos da história atribuídos podem ser alterados.
Vantagens de estimar em pontos da história
Se o processo de atribuição de pontos da história parece um pouco complexo, não se deixe confundir. Existem vantagens no planejamento de capacidade com pontos da história.
1. Os pontos da história são independentes do desenvolvedor
Pontos de história para cada história são atribuídos por vários desenvolvedores em negociação , e a razão para isso é que o número é atribuído não apenas para um produto específico e um desenvolvedor específico, mas "em média". Por que isso é uma coisa boa?
Coisas acontecem. Às vezes, o desenvolvedor do seu projeto pode deixar seu projeto e ser substituído. Talvez adoeçam, decidam tirar licença parental ou um sabático, ou simplesmente deixem a empresa. Talvez eles acabem sendo subqualificados ou superqualificados para o projeto.
Quando eles são substituídos, um novo desenvolvedor pode ter uma velocidade de trabalho diferente , o que levará a uma nova estimativa das horas de trabalho necessárias para criar o produto.
Os pontos da história minimizam esse problema . Designados por vários desenvolvedores diferentes, eles fornecem uma visão geral de quão complexa é uma história de usuário específica. Os pontos da história funcionam para todo e qualquer desenvolvedor de uma determinada empresa. (No entanto, lembre-se de que as estimativas de pontos da história não serão corretas para empresas diferentes.)
2. Os pontos da história tornam mais fácil recalcular o tempo de desenvolvimento
Na estimativa de tempo ágil com pontos da história, as equipes usam o termo velocidade para se referir ao número de pontos da história liberados em um único sprint.
As equipes monitoram constantemente sua velocidade, e isso é bastante variável no início. Uma equipe pode lançar recursos que valem cinco pontos de história em uma semana e vinte pontos de história na próxima. Mas isso é apenas o começo. Conforme o projeto avança, o gráfico de velocidade se uniformiza .
Com as horas, se um membro da equipe muda, cada tarefa em que ele está envolvido precisará ser reavaliada para ajustar os prazos. Com os pontos da história, isso é desnecessário - a equipe pode ajustar o prazo do projeto após o próximo sprint sabendo da mudança na velocidade geral.
Os pontos da história avaliam o desempenho da equipe como um todo , eliminando a necessidade de uma nova estimativa por tarefa.
3. Os pontos da história são bons para monitorar o desempenho da equipe
Quando você tem equipes trabalhando em projetos e / ou tarefas semelhantes em momentos diferentes, a velocidade pode facilmente mostrar o progresso de cada equipe. Eles melhoraram e em quanto? Qual equipe ou desenvolvedor tem dificuldades e pode precisar de treinamento extra? Qual é a curva de aprendizado? Talvez uma equipe diferente tenha um desempenho melhor?
O Velocity é uma ótima ferramenta para avaliar o desempenho de suas equipes não apenas no local, mas continuamente.
4. A estimativa do tempo de lançamento com pontos da história é mais precisa
Ao rastrear a velocidade, a equipe sabe com alta precisão quantos pontos de história podem liberar em um sprint. Embora leve algum tempo para a equipe de desenvolvimento do aplicativo calcular sua velocidade, uma vez calculada, a data de lançamento estimada é fácil de prever .
Além disso, as mudanças nos membros da equipe, nos requisitos ou no número / complexidade dos recursos não causam muitos problemas com a reavaliação.
5. Você pode reutilizar os pontos da história para projetos futuros para acelerar a estimativa
Não é incomum para uma empresa ser bem versada em um nicho específico (ou vários) e construir mais de um produto com um conjunto semelhante de recursos. Depois de concluir até mesmo um projeto estimado em pontos da história, os desenvolvedores podem consultar essa estimativa para novos projetos . Isso encurtará o tempo para estimativa.
No entanto, é importante acompanhar a velocidade de cada projeto, pois as circunstâncias podem mudar.
6. Os pontos da história melhoram o trabalho em equipe
Tradicionalmente, as empresas de desenvolvimento têm várias equipes de desenvolvedores, cada uma trabalhando em projetos separados. Ao estimar em horas, é o desenvolvedor que trabalha no projeto que faz a estimativa. Isso é uma coisa boa, em geral, pois quem sabe melhor quanto tempo algo vai demorar do que a pessoa que o faz?
No entanto, estimar a complexidade em pontos de história oferece uma oportunidade para desenvolvedores no mesmo campo cooperarem - algo que raramente acontece de outra forma. Esse tipo de trabalho em equipe é uma ótima oportunidade para compartilhar experiências e motivar uns aos outros.
Desvantagens de estimar em pontos da história
Há sempre o outro lado do argumento, que é como grandes sistemas nascem. A estimativa baseada na complexidade também tem suas desvantagens , e cada equipe deve decidir por si mesma se supera as vantagens.
1. Os pontos da história devem ser atribuídos por mais de um desenvolvedor
O ponto de venda do modelo de pontos da história é sua objetividade e valor para estimativas futuras. Mas para que isso seja verdade, a estimativa deve ser feita por mais de um desenvolvedor . Para pequenas empresas com uma única equipe ou empresas onde há apenas um especialista em um campo (ou seja, apenas um designer ou desenvolvedor iOS), os pontos da história não trazem tantas vantagens. Essas pequenas empresas tradicionalmente escolhem as horas de trabalho como modelo de estimativa.
2. A estimativa nos pontos da história requer um acúmulo considerável
Para realizar todo o potencial dos pontos da história, sua equipe precisará despender uma quantidade considerável de tempo . Se você estiver trabalhando em um projeto com recursos nos quais a equipe nunca trabalhou anteriormente (ou não trabalhou em tempo integral), será difícil prever o desempenho dos primeiros dois a três sprints. Concedido, quanto mais itens de backlog suas equipes têm, mais precisas suas estimativas podem ser devido à abundância de dados estatísticos. Mas os pontos da história não são um sistema pronto para funcionar imediatamente.
3. Os pontos da história são mais complexos para o orçamento
Os pontos da história são ótimos para definir prazos e datas de lançamento precisos, o que pode ser importante para desenvolvedores e para o marketing do cliente. No entanto, quando se trata de estimar os custos de desenvolvimento de aplicativos, eles são menos convenientes .
O fato é que os desenvolvedores gastam tempo em um projeto não apenas escrevendo código (ou fazendo designs ou testando). Algum tempo é gasto em pesquisa, discussão - dentro da equipe e com o cliente - fazendo alterações, etc. O tempo gasto estimando os pontos da história também é tempo gasto no projeto, mas não está incluído nos pontos por história.
É possível fazer um orçamento ao estimar em pontos de história, mas geralmente é mais rápido e fácil equiparar o dinheiro ao tempo gasto no projeto.
4. A velocidade é calculada por equipe
O que isso significa é que, se as equipes se misturarem entre os projetos, você precisará calcular a velocidade de cada combinação de desenvolvedores separadamente. Portanto, a estimativa para uma equipe não será necessariamente verdadeira para uma equipe diferente, e até mesmo a alteração de um único membro da equipe pode invalidar as estimativas anteriores.
Por outro lado, você pode usar a estimativa de complexidade para encontrar as combinações de melhor desempenho. No entanto, isso levará algum tempo.
Vantagens de estimar em horas
Embora algumas equipes ágeis usem pontos de história, muitas ainda precisam mudar de horas de trabalho. Existem razões importantes para isso. Vamos cobri-los também.
1. Horas é um modelo familiar
A inovação é ótima, mas leva tempo. Os desenvolvedores e seus clientes são bem versados na estimativa de horas de trabalho. Para muitos, a ideia é “se não está quebrado, não conserte”. Contanto que o sistema ofereça estimativas viáveis, por que mudar para outra coisa?
A diferença na precisão das estimativas pode não ser grande o suficiente para que alguns desenvolvedores mudem a forma como fazem as coisas.
2. Os clientes geralmente pagam por horas
Isso precisa de pouca elaboração. Para clientes, a estimativa baseada na complexidade pode ser confusa . Além disso, se para o cliente o orçamento for mais importante do que a data de lançamento (o que geralmente é), os pontos da história não serão relevantes para eles.
3. Estimativa baseada em horas pode ser feita por um desenvolvedor
Para pequenas equipes ou freelancers, os pontos da história são amplamente inúteis, pois exigem vários pontos de vista. Sem qualquer referência, estimar em pontos da história é um aborrecimento desnecessário.
As horas, por outro lado, oferecem ao desenvolvedor que está trabalhando no projeto uma maneira de fazer ele mesmo estimativas bastante precisas .
O mesmo vale para a velocidade da equipe. Quando as equipes mudam toda vez, como acontece com freelancers ou terceirização parcial, monitorar a velocidade faz muito pouco sentido. A estimativa com base em horas é a melhor escolha aqui.
Desvantagens de estimar em horas
Aqui estão os motivos pelos quais as equipes podem decidir parar de usar as horas como modelo de estimativa.
1. Ser o único responsável pela estimativa exige muita pressão
Por outro lado, estimar suas próprias necessidades de tempo pode ser mais fácil, pois você só depende de si mesmo.
Por outro lado, se você não cumprir suas estimativas, será um grande golpe. Mais ainda se a equipe que está esperando para iniciar suas tarefas depende de você concluir as suas.
Além disso, o estresse causado pela pressão para cumprir o que você mesmo prometeu pode atrapalhar uma tarefa que, de outra forma, estava indo bem.
2. A estimativa de um desenvolvedor é sempre menos precisa do que a de uma equipe
As estimativas individuais são subjetivas e vinculadas às circunstâncias emocionais e psicológicas do estimador.
Alguns desenvolvedores tendem a se superestimar e definir prazos que mais tarde lutam para manter. Isso não apenas interrompe o desenvolvimento (e impõe custos extras à equipe se houver multas), mas também causa estresse e desgaste nos desenvolvedores .
Outros subestimam suas próprias habilidades , prolongando o desenvolvimento mais do que o objetivamente necessário. A insegurança e o hábito de pensar demais, verificar e reexaminar o trabalho geralmente fazem com que os prazos de desenvolvimento sejam definidos para datas posteriores - e as tarefas raramente são concluídas antes dos prazos . A entrada da equipe permite uma estimativa mais objetiva.
3. Quanto maior a tarefa, mais difícil é estimar em horas
Isso também se correlaciona com situações de não desenvolvimento. É fácil dizer quanto tempo levará para ler um livreto universitário de três páginas, mas é mais difícil estimar quanto tempo levará para terminar Guerra e paz .
O mesmo vale para o desenvolvimento. Pequenas tarefas são fáceis de estimar para desenvolvedores com alguma experiência. Quanto maior a tarefa, porém, mais coisas - acontecendo tanto dentro quanto fora do projeto - podem afetar o desenvolvimento. As estimativas com base em horas não oferecem as margens que os pontos da história têm, tornando as estimativas mais imprecisas.
4. Pouca flexibilidade
A estimativa com base em horas é baseada no desenvolvedor. Se um membro da equipe trabalhando no produto muda no meio do projeto, a equipe precisará recalcular cada história de usuário afetada ainda em desenvolvimento ou programada para sprints futuros. Isso pode ser muito trabalhoso, dependendo do estágio em que o projeto se encontra e da diferença de habilidades entre o desenvolvedor original e o novo. A estimativa de tempo com base em horas é bastante rígida.
Você pode converter pontos da história em horas?
Os clientes podem pedir a uma equipe que faz estimativas em pontos de história para converter o mapeamento de pontos de história Agile em horas . A maioria das pessoas que não estão familiarizadas com as últimas tendências de desenvolvimento de software não saberão o que fazer com os pontos da história.
No entanto, quando um cliente pergunta quantas horas é igual a um storypoint, é impossível responder definitivamente. Um dos principais componentes da estimativa baseada na complexidade é o esforço despendido para completar a história. Mas o esforço não se traduz diretamente em tempo gasto . As horas tratam da incerteza de uma forma mais vaga do que os pontos da história.
Quanto mais complexa a tarefa, mais incertezas e riscos existem. Converter pontos da história em horas de uma maneira direta e confiar apenas na velocidade não leva em conta muitos desses riscos, uma vez que a estimativa baseada em horas é mais aproximada do que pontos da história quando se trata de riscos e incertezas.
Até certo ponto, usar a sequência de Fibonacci na atribuição de pontos da história explicará a incerteza nos tempos de desenvolvimento, mas não permite exatamente uma conversão direta.
Aqui está um exemplo.
Uma história pontual de 1 história (história básica) leva, digamos, duas horas para ser concluída.
Uma história pontual de 13 andares pode levar 26 horas na melhor das hipóteses - se nada der errado ou atrapalhar. Por exemplo, se a API usada se encaixa perfeitamente, ponto final a ponto final. Mas se isso não acontecer, a história pode exigir algo entre, digamos, 30 e 50 horas - dependendo de quantas incompatibilidades existem. Ninguém pode dizer de antemão como será se o desenvolvedor ainda não trabalhou com a API em questão.
Portanto, ao traduzir os pontos da história em horas, é necessário que haja um multiplicador para o crescimento exponencial para lidar com a incerteza. E esse multiplicador será diferente de uma equipe para outra.
Pontos da história x horas: o que escolher para o desenvolvimento de software?
Como você pode ver, tanto os pontos da história quanto as horas são escolhas válidas para um desenvolvedor estimar projetos.
Em suma, diríamos que mais empresas de produtos escolhem os pontos da história, enquanto os terceirizados tendem a se inclinar para o horário.
As empresas que trabalham com um modelo de preço fixo geralmente optam pela estimativa baseada em horas. Equipes que preferem Scrum geralmente escolhem pontos de história, já que literalmente nasceram do Scrum e são nativos desta metodologia.
Em nossos anos de experiência, passamos a ver isso desta forma:
Se estimar com precisão a data de lançamento for mais importante do que ajustar o orçamento, vá para os pontos da história.
Se o orçamento for mais importante do que uma data de lançamento precisa, considere as horas.
Ou, o melhor de tudo, combine os dois.
Os pontos da história são altamente convenientes para equipes de desenvolvimento que trabalham em projetos longos, onde o monitoramento da velocidade fará a diferença.
O horário é importante para os clientes que se preocupam em fazer pouco do seu orçamento. Além disso, as horas fazem mais sentido para projetos de curto prazo.
O sistema baseado em complexidade ainda é bastante jovem, como o próprio Scrum, e ainda está em desenvolvimento. A combinação de ambos os modelos de estimativa e a elaboração de um sistema para alterar rapidamente cada ponto da história para horas fornece benefícios de ambos os modelos, ao mesmo tempo que minimiza as desvantagens.