Estimar é difícil. Para os desenvolvedores de software, é um dos aspectos mais difíceis — se não for o mais difícil — do trabalho. Ao fazer estimativas, é preciso considerar uma série de fatores que ajudam os proprietários de produtos a tomar decisões que afetam toda a equipe — e a empresa. Com tudo o que está em jogo, não é de admirar que todos, de desenvolvedores ao gerenciamento de alto nível, estão propensos a comprometer todo seu tempo com as estimativas. Mas é um erro. A estimativa ágil não passa disso: uma estimativa. Não um juramento de sangue.
Não há necessidade de trabalhar nos fins de semana para compensar quando uma parte do trabalho é subestimada. Dito isso, vejamos algumas maneiras de fazer as estimativas ágeis o mais precisas possível.
Colaboração com o proprietário do produto
No desenvolvimento ágil, o proprietário do produto tem como tarefa priorizar o backlog (a lista ordenada de trabalho que contém descrições breves de todos os recursos desejados e correções para o produto). Os proprietários do produto agrupam os requisitos da empresa, mas nem sempre entendem o que há por trás da implementação. Uma estimativa boa dá ao proprietário do produto uma visão nova em relação ao nível de esforço para cada item de trabalho que, então, embasa uma avaliação da prioridade relativa de cada item.
Quando a equipe de engenharia começa seu processo de estimativa, normalmente surgem perguntas sobre os requisitos e as histórias de usuários. E isso é bom: essas perguntas ajudam toda a equipe a entender melhor o trabalho completo. Os proprietários do produto, especificamente, podem dividir os itens de trabalho em partes menores e fazer estimativas por meio de pontos de histórias para ajudar a ordenar todas as áreas de trabalho, inclusive as que podem estar ocultas. E, assim que recebem as estimativas da equipe de desenvolvimento, não é incomum para um proprietário de produto reordenar os itens no backlog.
Os pontos da história do método ágil são um esporte coletivo
Envolver todos (desenvolvedores, designers, testadores, implementadores, etc.) na equipe é fundamental. Cada membro da equipe traz uma perspectiva diferente sobre o produto e o trabalho necessário para entregar uma história do usuário. Por exemplo, se o gerenciamento de produto quer fazer algo que pareça simples, como a compatibilidade com um navegador da Web novo, as equipes de desenvolvimento e assistência de qualidade precisam fazer o ponderamento, pois a experiência demonstra que problemas podem surgir a qualquer momento.
Da mesma forma, as alterações de design exigem não só comentários da equipe de design, mas também das equipes de desenvolvimento e assistência de qualidade. Deixar a maior parte da equipe de produtos fora do processo de estimativa cria estimativas de qualidade menores, reduz o incentivo, pois os principais colaboradores não se sentem incluídos, e compromete a qualidade do software.
Então, não deixe que sua equipe seja vítima de estimativas feitas a partir do nada. É um caminho rápido para o fracasso! Entenda o que significa estimativa e como isso pode ajudar seu time.
Quer testar os pontos da história? Primeiro, faça sua inscrição ou login no Jira
Pontos de história versus horas
Equipes de software tradicionais dão estimativas em um formato de tempo: dias, semanas, meses. Muitas equipes ágeis, contudo, fizeram a transição para pontos de história. Os story points, também chamados de pontos da história, são unidades de medida para expressar uma estimativa do esforço geral necessário para implementar por inteiro um backlog do produto ou qualquer outro trabalho. Equipes atribuem pontos de história em relação à complexidade de trabalho, à quantidade de trabalho e ao risco ou à incerteza. Valores são atribuídos para dividir o trabalho em partes menores com mais eficácia, para que eles possam tratar da incerteza. Com o tempo, isso ajuda equipes a entender quanto pode ser alcançado em um período de tempo e cria consenso e comprometimento com a solução. Pode parecer nada intuitivo, mas na realidade essa abstração é útil porque faz com que a equipe tome decisões mais difíceis em relação a uma dificuldade do trabalho. Aqui estão alguns motivos para usar pontos de história:
- Datas não levam em conta o trabalho não relacionado ao projeto que aparece inevitavelmente em nossos dias: e-mails, reuniões e entrevistas nas quais um membro da equipe pode estar envolvido.
- Datas têm um vínculo emocional com eles. A estimativa relativa elimina o vínculo emocional.
- Cada equipe estimará o trabalho em uma escala levemente diferente, o que significa que a velocidade (medida em pontos) será, naturalmente, diferente. Isso, por sua vez, torna impossível fazer política usando a velocidade como uma estratégia.
- Depois de concordar sobre o esforço relativo do valor de cada ponto da história, você pode atribuir pontos com rapidez e sem muita discussão.
- Como usar story points? Os pontos da história recompensam os membros da equipe por resolver problemas com base na dificuldade, não no tempo gasto. Isso mantém os membros da equipe focados em entregar valor, não em gastar tempo.
Infelizmente, os pontos de história são mal utilizados com frequência. Pontos da história dão errado quando forem usados para julgar pessoas, atribuir cronogramas e recursos detalhados e quando forem confundidos com uma medida de produtividade. Em vez disso, equipes deveriam usar pontos de história para entender o tamanho e a priorização do trabalho. Para uma discussão profunda sobre pontos de história e práticas de estimativa, consulte essa mesa redonda com parceiros da indústria e continue lendo para obter dicas de estimativas mais ágeis.
Pontos de história e Planning Poker
As equipes que estão começando a usar pontos da história praticam um exercício chamado "pôquer de planejamento". Na Atlassian, o pôquer de planejamento é uma prática comum em toda a empresa. A equipe vai pegar um item do backlog, ter uma discussão breve sobre ele, e cada membro vai formular mentalmente uma estimativa. Então todos levantam um cartão com o número que reflete sua estimativa. Se todos estiverem de acordo, ótimo! Se não, reserve algum tempo (mas não muito tempo — apenas alguns minutos) para entender a lógica por trás de estimativas diferentes. Não se esqueça: a estimativa é uma atividade a ser pensada em termos gerais. Se a equipe estiver muito envolvida em detalhes, respire e traga a discussão de volta para o geral.
Pronto para testar?
- Instale o aplicativo Planning Poker
- Saiba mais sobre o Planning Poker
Estime de um modo inteligente, não difícil
Nenhuma tarefa individual deve ter mais de 16 horas de trabalho. (Se estiver usando pontos de história, você poderá decidir que, digamos, 20 pontos é o limite superior.) É simplesmente muito difícil estimar itens de trabalho individuais maiores do que os com um alto grau de confiança. E essa confiança é especialmente importante para itens no topo da lista de pendências. Quando algo é estimado acima do limite de 16 horas (ou 20 pontos) de sua equipe, isso é um sinal para fazer uma divisão em partes menores e elaborar uma nova estimativa.
Para itens mais complicados na lista de pendências, dê uma estimativa aproximada. Quando que a equipe realmente começar a trabalhar nesses itens, os requisitos poderão mudar, e seu aplicativo certamente terá mudado. Então as estimativas anteriores não serão tão precisas. Não desperdice tempo estimando trabalho que provavelmente será alterado. Forneça ao proprietário do produto um número aproximado para que seja possível priorizar o roteiro do produto adequadamente.
Aprender com as últimas estimativas
As retrospectivas são o momento em que a equipe pode incorporar os insights coletados de iterações anteriores, como a precisão das estimativas. Várias ferramentas ágeis como o Jira monitoram pontos de história, o que ajuda você a refletir sobre as estimativas e fazer a recalibragem delas com muito mais facilidade. Por exemplo, verifique as cinco últimas histórias de usuário da sua equipe que alcançaram um ponto de história de valor 8. Reflita se cada um desses itens de trabalho exigiu o mesmo nível de esforço. Se não tiver exigido, discuta o motivo. Use esses insights nas próximas discussões de estimativa.
Como tudo no método ágil, a estimativa é questão de prática. Você vai melhorar com o tempo.
