Quais métodos os desenvolvedores usam para avaliar tarefas?

Olá a todos! A teoria necessária para iniciar o desenvolvimento é muito extensa. Alguns especialistas (desenvolvedores backend em Java e outras linguagens) têm mais, enquanto outros (por exemplo, desenvolvedores frontend em JavaScript - React Native) têm um pouco menos. Porém, ambos devem possuir um grande estoque de conhecimento não apenas técnico, mas também “organizacional”. Esse conhecimento “organizacional” é um dos pontos de intersecção para desenvolvedores frontend e backend. Hoje quero falar sobre um aspecto desse conhecimento organizacional não técnico - sobre avaliação de tarefas (estimativa). E como trabalhei apenas na metodologia Ágil (que aliás é considerada a mais popular), em sua subparte, Scrum , considerarei a avaliação de tarefas no contexto do Scrum . Direi desde já que a avaliação, também chamada de estimativa, é difícil. Para mim, pessoalmente, como desenvolvedor, este é um dos aspectos mais difíceis/indesejáveis ​​do trabalho. Existem muitos fatores diferentes a serem considerados que podem influenciar a avaliação de uma tarefa. Ao mesmo tempo, os planos para desenvolvimento futuro serão baseados em suas previsões.

E se você não acertar a classificação?

Se um desenvolvedor gasta muito mais horas em uma tarefa do que será gasto no final, pode parecer que ele não é o melhor especialista, pois a estimativa foi muito imprecisa. Por assim dizer, um dedo no céu. Ao mesmo tempo, se o desenvolvedor não investir no tempo previsto, ele compromete os planos do cliente de lançar o produto/nova funcionalidade. Este é um negócio, e negócios significam dinheiro, e poucos clientes gostarão de tal furo. Na verdade, é por isso que não gosto de estimativas, porque às vezes é muito difícil determinar o momento exato para concluir uma tarefa.

Como o tempo é avaliado?

Via de regra, a estimativa é realizada em horas ou pontos de história. Pessoalmente, estou muito mais próximo do processo de avaliação em story points . Se um relógio é algo físico, então algo que pode ser confundido, os pontos da história são um pouco sobre outra coisa, mais abstratos. Normalmente, as equipes de desenvolvimento de software fornecem estimativas em formato de tempo: horas, dias, semanas, meses. Essas estimativas de tempo baseiam-se principalmente na experiência pessoal, suposições ou intuição. Nesse caso, os desenvolvedores simplesmente analisam a tarefa e expressam uma estimativa de quanto tempo levariam. Como resultado, muito raramente são precisos, pois existem muitos fatores que podem afetar o prazo de conclusão do trabalho. Portanto, muitas equipes que trabalham de acordo com a metodologia Agile utilizam story points. Vamos descobrir.

O que são pontos da história

Um story point é uma unidade de medida que expressa uma avaliação do esforço total necessário para implementar plenamente uma determinada área de trabalho (funcionalidade). Ou seja, esta é uma complexidade relativa . As equipes atribuem pontos da história com base na complexidade do trabalho, no escopo do trabalho e no risco ou incerteza. Normalmente, esses valores são atribuídos para dividir o trabalho em partes menores de maneira mais eficiente, eliminando assim a incerteza. Com o tempo, isso ajuda as equipes a entender o que podem alcançar em um determinado período de tempo e a planejar as próximas áreas de trabalho com mais precisão. Isso pode parecer completamente contra-intuitivo para você, mas na verdade essa abstração é bastante útil: ela leva a equipe a tomar decisões mais difíceis sobre a complexidade do trabalho. Vejamos alguns motivos para usar story points no planejamento:

• a imprecisão da estimativa em intervalos de tempo pode ser evitada;
• Ao contrário da estimativa ao longo do tempo, os custos indiretos podem ser melhor levados em consideração: comunicações entre os membros da equipe e o cliente, diversas discussões e planejamentos da equipe, bem como situações imprevistas;
• Cada equipe avaliará o trabalho em uma escala diferente, o que significa que sua velocidade (medida em pontos) será diferente;
• Ao definir uma escala para atribuição de cada ponto da história, você pode distribuir pontos rapidamente sem muita controvérsia.

Como NÃO usar pontos da história

Infelizmente, os pontos da história são frequentemente usados ​​para outros fins. Os story points podem apresentar falhas quando são usados ​​para avaliar pessoas, definir prazos e recursos detalhados e quando são erroneamente tomados como uma medida de desempenho. Em vez disso, as equipes precisam usá-los para compreender o volume/complexidade do trabalho em cada tarefa e definir prioridades. É possível que as partes classificadas como mais difíceis sejam feitas primeiro para que possam ser concluídas antes do final do sprint , mas as mais fáceis podem ser adiadas para mais tarde. Deixe-me lembrá-lo do que é um sprint no contexto da metodologia Scrum : A duração desse período é determinada no início do desenvolvimento por acordo entre a equipe e o cliente. Este pode ser um período de duas semanas ou um mês, ou qualquer outro período. Via de regra, a estimativa de tarefas é realizada no início do sprint para planejar a possível quantidade de trabalho concluído até o final do sprint, quando o trabalho concluído é entregue ao cliente. Ajuda você a ver seu progresso no desenvolvimento do produto, receber feedback do cliente e ajustar o desenvolvimento do projeto de acordo com a visão do cliente. Mesmo assim, divagamos um pouco: voltemos à estimativa. Avaliar tarefas por apenas um desenvolvedor seria muito subjetivo. Portanto, via de regra, trata-se de um trabalho em equipe. Existem algumas técnicas para avaliação de equipe. Hoje veremos o mais utilizado deles - Scrum poker . Esta técnica requer um gestor que será alguém como o líder deste pôquer Scrum . Pode ser uma pessoa especializada em Scrum Master , ou PM .

O que é Scrum Poker

O Scrum Poker – ou Planning Poker – é uma técnica de avaliação que se baseia na obtenção de um acordo. Usado principalmente para avaliar a complexidade do trabalho a seguir ou o volume relativo de tarefas a serem resolvidas durante o desenvolvimento de software. Observo imediatamente que o pôquer Scrum é uma prática comum no desenvolvimento e você definitivamente precisa saber que tipo de fera é. Para este processo, normalmente utilizamos algum tipo de aplicativo ou site que nos permite organizar uma avaliação em equipe de uma determinada tarefa. Como isso acontece? A equipe pega um item do backlog (nova tarefa, funcionalidade), discute brevemente possíveis armadilhas e outras nuances associadas a ele. Cada participante então escolhe uma carta com um número que representa sua classificação de dificuldade. Ah, e ao estimar, não é a série usual que é usada, mas os números de Fibonacci . Os números de Fibonacci são tão populares no scrum poker porque a diferença entre eles aumenta com o tempo (uma reminiscência dos níveis da pirâmide). Existem tarefas que terão enorme complexidade e um pequeno número de pontos da história não pode ser alcançado. Explicação para cartas incomuns:

número desconhecido de endpoints

uma tarefa infinitamente longa

Preciso de um descanso

Métodos mais raros de estimativa:

• nos tamanhos de camisetas - S, M, L, XL
• ou em cães - chihuahua, pug, dachshund, bulldog e assim por diante (na minha opinião, esta é a unidade mais estranha para avaliar tarefas =D)

A equipe então compara as estimativas dadas para o mesmo problema por diferentes desenvolvedores e, se concordarem, ótimo! Caso contrário, é necessário discutir as razões das diferenças de avaliação (argumentos). Depois disso, podemos chegar em conjunto a uma estimativa única, com a qual todos, mais ou menos, concordarão. Bem, por que o pôquer é usado para planejar um projeto de software sério? Afinal, isso é um tanto estranho. Na verdade, essa gamificação incentiva os membros da equipe a pensar de forma independente, pedindo-lhes que mostrem os seus resultados ao mesmo tempo que os seus colegas de equipa. Isto, por sua vez, evita a dependência das opiniões de outros membros da equipe. Caso contrário, os desenvolvedores menos experientes irão olhar e confiar nas avaliações dos membros da equipe mais experientes, o que negará a utilidade da sua própria avaliação. Mas com a abertura simultânea dos resultados, isso é essencialmente impossível. Um exemplo de aplicativo de agendamento do Scrum Poker é da Atlassian .

Exemplo de avaliação de tarefa

Vamos imaginar que sua equipe identificou uma determinada escala para avaliação em story points: O Scrum Poker começa com uma tarefa e você a avalia assim:

• você nunca trabalhou com a implementação de funcionalidade semelhante antes - +3
• funcionalidade de uma tarefa de médio porte - +2
• a implementação da tarefa tem alta complexidade - +3
• alta complexidade de escrita de testes para esta funcionalidade - +3

Como resultado, você ganha 11 pontos de história, mas como esse cartão não existe, você oferece 13. Outro colega seu avalia a tarefa:

• trabalhei com um problema semelhante antes - +1
• funcionalidade de uma tarefa de médio porte - +2
• a implementação da tarefa tem complexidade média - +2
• complexidade média de escrever testes para esta funcionalidade - +2

Como resultado, ele obtém 7 pontos de história, mas isso não existe nos números de Fibonacci, e ele coloca um cartão com o número mais próximo possível - 8. Outros membros da equipe, portanto, dão estimativas com base em suas opiniões subjetivas. A seguir, você mostra seus resultados e descobre que quase todos os seus colegas deram a estimativa 13, exceto um desenvolvedor que deu 8. Nesse caso, ele recebe a palavra e justifica. E eles, por exemplo, são assim: ele trabalhou anteriormente com o mesmo problema, e não é tão difícil quanto pode parecer, e no final ele convence o restante da equipe a mudar a solução de 13 para 8 histórias pontos, dizendo que ele ajudará quem assumir essa tarefa a descobrir. Ou, no final, ele mesmo fará isso. E em geral, não importa se os outros ouvem ou não seus argumentos, porque de uma forma ou de outra, será atribuída uma classificação a esta tarefa, e a equipe passará a se familiarizar com a próxima. Nas primeiras vezes, as estimativas serão imprecisas, assim como as estimativas da quantidade de trabalho que você planeja realizar no próximo período (sprint). Afinal, essas estimativas são feitas justamente com base em estimativas. Depois de algum tempo, cerca de três meses, a equipe começará a estimar as tarefas com mais precisão, e a quantidade média de trabalho que a equipe pode concluir por sprint se tornará visível. Mas este é um planejamento geral do escopo do trabalho, é mais uma questão de tempo e, neste caso, podem haver muitos fatores diferentes que têm impacto. Por exemplo, um dos desenvolvedores saiu de férias por duas semanas. Ou seja, você precisa riscar uma certa quantidade de trabalho planejado (funcionalidade planejada). Ou chegou um novo desenvolvedor na equipe, mas você não precisa contar totalmente com ele, pois... é preciso levar em consideração o tempo necessário para adaptação ao projeto, chamado onboarding . Isso pode levar duas semanas, mais ou menos uma semana, dependendo da complexidade do projeto. Por hoje é tudo, espero ter melhorado um pouco o seu conhecimento em uma parte não técnica do conhecimento como a estimativa de problemas. Se você quiser se aprofundar neste tema, bem como nos detalhes do Scrum, aconselho fortemente a leitura do livro “SCRUM” de Jeff Sutherland. Não posso garantir as consequências, porque talvez depois disso você tenha uma vontade irritante de se tornar um Scrum Master =D