Cumpra seus prazos: métodos que os desenvolvedores usam para estimar o esforço

Olá pessoal! Há uma quantidade colossal de teoria que você precisa saber para começar no desenvolvimento de software. Alguns especialistas (por exemplo, desenvolvedores de back-end que usam Java e outras linguagens) sabem mais sobre isso, enquanto outros (por exemplo, desenvolvedores de front-end que usam JavaScript e React Native) podem saber um pouco menos. Dito isto, ambos os grupos devem possuir um grande corpo de conhecimento não apenas técnico, mas também "organizacional". Esse conhecimento "organizacional" é uma área de sobreposição para desenvolvedores de front-end e back-end. Hoje quero falar sobre um aspecto desse conhecimento organizacional não técnico. Hoje vamos falar sobre estimativa de esforço . Porque só tenho experiência com a metodologia Agile(que é considerado o mais popular), mais especificamente o framework Scrum, vou considerar a estimativa de esforço no contexto do Scrum . Logo de início, devo dizer que a estimativa de esforço é difícil. Para mim, é um dos aspectos mais desafiadores/desagradáveis ​​do meu trabalho como desenvolvedor. Há muitos fatores diferentes a serem considerados que podem afetar sua estimativa do esforço necessário para uma tarefa. Além disso, os planos de desenvolvimento futuro serão baseados em suas estimativas.

E se você fornecer uma estimativa ruim?

Se um desenvolvedor estimar muito mais horas para uma tarefa do que as eventualmente gastas na tarefa, sua experiência pode ser questionada, pois a estimativa foi muito imprecisa. Em outras palavras, foi um palpite selvagem. Ao mesmo tempo, se um desenvolvedor não terminar o trabalho no tempo previsto, ele compromete os planos do cliente de lançar o produto ou novo recurso. Isso é negócio, e negócio é dinheiro. Poucos clientes ficarão satisfeitos com tal deslize. Na verdade, é por isso que não gosto de estimativas - porque às vezes é muito complicado determinar com precisão o tempo necessário para concluir uma tarefa.

Como fazer uma estimativa de tempo

Como regra, as estimativas são feitas em horas ou pontos de história. Minha preferência pessoal é fazer o processo de estimativa usando pontos de história . É difícil se enganar sobre objetos físicos concretos, mas os pontos da história são um pouco mais abstratos. As equipes de desenvolvimento de software normalmente fornecem estimativas como períodos de tempo: horas, dias, semanas, meses. Essas estimativas de tempo são baseadas principalmente em experiência pessoal, suposições e/ou intuição. Nesse caso, os desenvolvedores simplesmente olham para a tarefa e expressam sua suposição sobre quanto tempo levará. Como resultado, essas estimativas raramente são precisas, porque há muitos fatores que podem afetar a duração do trabalho. É por isso que muitas equipes que usam a metodologia Agile também usam pontos de história. Vamos mergulhar!

O que são pontos de história?

Um ponto de história é uma unidade de medida para expressar uma estimativa do esforço total necessário para implementar uma determinada parte da funcionalidade totalmente. Ou seja, estamos falando de relativocomplexidade. As equipes atribuem uma estimativa em pontos de história com base na complexidade do trabalho, no volume de trabalho e no risco ou incerteza. Esses valores geralmente são atribuídos para dividir o trabalho com mais eficiência em partes menores, eliminando assim a ambigüidade. Com o tempo, isso ajuda as equipes a entender o que podem realizar em um determinado período de tempo e as ajuda a planejar com mais precisão as partes subsequentes do trabalho. Isso pode parecer totalmente contra-intuitivo para você, mas essa abstração é realmente útil: ela leva a equipe a tomar decisões difíceis sobre a complexidade do trabalho. Vamos dar uma olhada em algumas das razões para usar pontos de história ao planejar:

• Você pode evitar estimativas de tempo imprecisas.
• Ao contrário das estimativas feitas em unidades de tempo, os pontos de história permitem contabilizar os custos indiretos: comunicações entre os membros da equipe e o cliente, várias discussões da equipe e atividades de planejamento, bem como situações imprevistas.
• Cada equipe estimará seu trabalho usando escalas diferentes, o que significa que sua capacidade (medida em pontos) será diferente.
• Ao definir uma escala para atribuir cada ponto da história, você pode alocar pontos rapidamente sem muita controvérsia.

Como NÃO usar pontos de história

Infelizmente, os pontos da história são frequentemente mal utilizados. Os pontos da história podem ser enganosos quando são usados ​​para avaliar pessoas, definir prazos e recursos detalhados e quando são confundidos com uma medida de desempenho. Em vez disso, as equipes devem usá-los para entender o escopo/complexidade de cada tarefa e definir prioridades. Talvez as partes consideradas mais difíceis devam ser trabalhadas primeiro, para que possam ser feitas antes do final do sprint , possivelmente deixando as tarefas mais fáceis para depois. Deixe-me lembrá-lo do que é um sprint no contexto da metodologia Scrum : A duração desse período de tempo é determinada quando o desenvolvimento começa e é acordada entre a equipe e o cliente. Isso pode ser um período de duas semanas ou um mês, ou qualquer outro período. Via de regra, as estimativas de esforço são feitas no início de cada sprint para planejar o trabalho que pode ser concluído até o final do sprint, quando o trabalho concluído é entregue ao cliente. A demonstração ajuda você a ver seu progresso no desenvolvimento do produto, receber feedback do cliente e ajustar a trajetória do projeto de acordo com a visão do cliente. Mas divagamos um pouco. Voltemos às estimativas. Seria muito subjetivo ter apenas um desenvolvedor fornecendo estimativas para todas as tarefas. Portanto, esse processo geralmente é um esforço de equipe. Existem algumas técnicas que as equipes podem usar para gerar estimativas. Hoje veremos a técnica mais popular: scrum poker . Esta técnica requer um gerente que atuará como moderador do scrum poker . Pode ser alguém que seja um scrum master ou possivelmente um PM .

O que é Scrum Poker?

Scrum poker , ou planning poker, é uma técnica de estimativa baseada na obtenção de um acordo. É usado principalmente para estimar a complexidade do trabalho à frente ou o tamanho relativo das tarefas de desenvolvimento de software. Eu direi imediatamente que scrum pokeré uma prática comum de desenvolvimento de software e você precisa saber do que se trata. Geralmente envolve um aplicativo ou site para facilitar a criação colaborativa de uma equipe de uma estimativa para uma tarefa específica. Como isso acontece? A equipe pega algo do backlog (uma nova tarefa, alguma funcionalidade) e discute brevemente possíveis armadilhas e outras nuances associadas a ela. Em seguida, cada participante escolhe um cartão com um número que reflete sua estimativa de complexidade. Ah, mais uma coisa, ao fazer essas estimativas, usamos números na sequência de Fibonacci em vez de números comuns. Os números de Fibonacci são populares no scrum poker, pois há um vão cada vez maior entre eles (lembrando os níveis de uma pirâmide). Algumas tarefas serão altamente complexas e não conseguiremos escapar com um pequeno número de pontos de história. Existem algumas cartas incomuns que têm os seguintes significados:

Número desconhecido de endpoints

Tarefa infinitamente longa

Preciso de um descanso

Métodos de estimativa menos comuns usam:

• Tamanhos de camiseta — S, M, L, XL
• Raças de cães — chihuahua, pug, dachshund, bulldog e assim por diante (pessoalmente, acho que essa é a unidade de medida mais estranha para estimativa de esforço =D)

A equipe então compara as estimativas fornecidas por diferentes desenvolvedores para a mesma tarefa. Se eles concordarem, ótimo! Caso contrário, as razões (argumentos) para as diferentes estimativas precisam ser discutidas. Depois disso, a equipe trabalha em conjunto para formar uma única estimativa que todos aceitem, mais ou menos. Então, por que o poker é usado para planejar projetos de software sérios? Você tem que admitir que isso é estranho. O fato é que esse tipo de gamificação estimula os membros da equipe a pensar de forma independente, convidando-os a revelar suas estimativas ao mesmo tempo que seus companheiros de equipe. Isso, por sua vez, evita criar uma situação em que alguns membros da equipe dependam da opinião de outros. Se não fosse feito dessa maneira, os desenvolvedores menos experientes analisariam e se concentrariam nas estimativas fornecidas pelos membros mais experientes da equipe, e isso tornaria suas próprias estimativas menos úteis. Mas mostrar simultaneamente as estimativas torna isso essencialmente impossível. ofertas Atlassianum aplicativo scrum poker para usar no processo de planejamento.

Exemplo de estimativa de esforço

Suponha que sua equipe tenha estabelecido a seguinte escala para atribuir pontos de história a estimativas: O Scrum poker é jogado para cada tarefa e você fornece uma estimativa da seguinte forma:

• Você nunca implementou uma funcionalidade semelhante antes: +3
• A funcionalidade é de tamanho médio: +2
• A implementação será altamente complexa: +3
• Escrever testes para a funcionalidade será altamente complexo: +3

Somando cada componente, você obtém um total de 11 pontos de história, mas não existe tal cartão, então você sugere 13. Um colega de trabalho apresenta a seguinte estimativa para a tarefa:

• Ele já trabalhou com uma tarefa semelhante antes: +1
• A funcionalidade é de tamanho médio: +2
• A implementação será de complexidade média: +2
• Escrever testes para a funcionalidade será de complexidade média: +2

Seu resultado intermediário é 7 story points, mas esse número não existe na série Fibonacci, então ele envia o cartão com o número mais aproximado — 8. Outros membros da equipe também fazem suas estimativas com base em suas visões subjetivas. Em seguida, todos mostram seus cartões e você descobre que quase todos os seus colegas de trabalho deram uma estimativa de 13, exceto o desenvolvedor que sugeriu um 8. Nesse caso, ele pode falar com os motivos de sua estimativa mais baixa. Suponha que ele ofereça esta justificativa: ele trabalhou anteriormente na mesma tarefa e não é tão difícil quanto pode parecer. No final das contas, ele convence o restante da equipe a mudar de ideia de 13 para 8 pontos de história, dizendo que ajudará quem acabar assumindo essa tarefa. Ou talvez ele mesmo o faça. Em todo caso, não Não importa se os outros aceitam seus argumentos ou não, porque de uma forma ou de outra uma estimativa será atribuída à tarefa, e a equipe passará a considerar a próxima. Inicialmente, as estimativas serão imprecisas, assim como as estimativas da quantidade de trabalho que você planeja realizar no próximo período de tempo (sprint). Afinal, essas estimativas feitas usando estimativas. Depois de algum tempo, talvez três meses depois, a equipe começará a estimar o tempo necessário para as tarefas com mais precisão, e a quantidade média de trabalho que a equipe é capaz de realizar em um sprint ficará aparente. Mas este é um processo para fazer um plano geral para o escopo do trabalho. Ele se concentra principalmente no tempo, mas neste caso pode haver muitos fatores relevantes diferentes. Por exemplo, suponha que um desenvolvedor saiu de férias por duas semanas. Você precisará cortar uma certa quantidade de trabalho planejado (funcionalidade planejada). Ou suponha que um novo desenvolvedor se juntou à equipe, mas ainda não está totalmente atualizado, então você precisa permitir que ele se familiarize com o projeto por meio de umprocesso de integração . Isso pode levar duas semanas, mais ou menos uma semana, dependendo da complexidade do projeto. Isso é tudo por hoje! Espero ter melhorado um pouco seu conhecimento sobre estimativa de esforço, um aspecto não técnico necessário do desenvolvimento de software. Se você quiser se aprofundar neste tópico e nos detalhes do scrum, recomendo fortemente que você leia o livro "SCRUM" de Jeff Sutherland. Não posso prometer as consequências, porque depois de ler você vai ter uma vontade chata de se tornar um scrum master =D