🎩 🍼 🚵🏽 Avaliação de tarefas em pontos da história 🦇 🍇 ⏭️

Quase todas as pessoas que se depararam com o desenvolvimento de software sabem o que é a avaliação da tarefa Story Points (SP); no entanto, ocasionalmente digo a colegas de outros departamentos ou recém-chegados à equipe que nunca encontraram essa abordagem, por que usamos o SP e por que é conveniente para a equipe e eficaz para a empresa.

O objetivo deste texto é descrever o que é SP, como usá-los para avaliar problemas e por que essa técnica se tornou tão difundida.

Problema

Calcular o tempo necessário para concluir uma tarefa é uma tarefa muito simples e muito arriscada que as equipes de desenvolvimento enfrentam.

Uma avaliação incorreta se torna um dos primeiros motivos para a quebra de cronogramas ou até a falha do projeto.
O problema é que a empresa vê avaliações como passivos. Os desenvolvedores veem as classificações como premissas.

Para ilustrar, citarei um exemplo de um diálogo ficcional do livro de Robert Martin, O Programador Ideal.

Mike (Gerente): Qual é a probabilidade de você gerenciar em três dias?

Peter (Desenvolvedor): Eu posso lidar com isso.

Mike: Você pode citar um número?

Pedro: cinquenta ou sessenta por cento.

Mike: Então há uma probabilidade muito alta de que você precisará de quatro dias?

Pedro: Sim. até cinco ou seis podem ser necessários, embora eu duvide.

Mike: Até que ponto você duvida?

Peter: Ah, não sei ... tenho 95% de certeza de que o trabalho será realizado em menos de seis dias.

Mike: Então, talvez sete?

Pedro:Bem, se tudo der errado ... Droga, se TUDO der errado, talvez dez ou até onze dias. Mas a probabilidade de tal coincidência é muito pequena, certo?

Eu acho que o diálogo acima parece bastante familiar para qualquer desenvolvedor ou gerente de projeto.

Infelizmente, problemas com notas não param por aí. Outras armadilhas também devem ser consideradas:

Correlação de Grau e Grau

A classificação fornecida é válida apenas se o autor da classificação implementar a tarefa. Afinal, é óbvio que o tempo gasto na tarefa pelo desenvolvedor sênior e pelo estagiário será diferente.

Uma avaliação ideal em um mundo imperfeito

Reuniões urgentes, cartas de trabalho, mensageiros e um gerente de tarefas interrompido complicam ainda mais o já complexo processo de desenvolvimento, que torna as horas ideais que imaginamos ao avaliar pouco úteis para um gerente de projeto que tenta montar um gráfico de Gantt que envelhece rapidamente.

A seguir, consideraremos a abordagem para avaliar tarefas no SP e como ela aborda todas as dificuldades descritas acima.

Soluções alternativas

Naturalmente, a abordagem usando SP não é a primeira tentativa de resolver os problemas expressos, embora seja provavelmente a mais popular.

Neste bloco, falarei sobre outro programa que inclui um esquema de avaliação de tarefas. O programa é chamado PERT e não é necessário familiarizar-se com o objetivo dos textos, para que você possa prosseguir com segurança para o próximo bloco.

Avaliação do Programa e Técnica de Revisão

PERT Program Evaluation and Review Technique 50- XX .

:

O: . .

N: .

P: , , .

:

μ = \frac{O + 4 N + P}{6}

$\mu= \cfrac {O+4N+P} {6}$

, :

σ = \frac{P - O}{6}

$\sigma=\cfrac{P−O}{6}$

, :

\frac{1 + 12 + 12}{6} \pm \frac{12 - 1}{6}

$\cfrac{1+12+12}{6} ± \cfrac{12-1}{6}$

, . , , .

Pontos da história

O que são os Story Points e como eles ajudam a avaliar as tarefas? Mike Cohn, evangelista ágil e CEO da Mountain Goat Software, fala sobre essa técnica de maneira muito breve e clara.

E se, em vez de avaliar o tempo necessário para concluir uma tarefa, avaliaremos o esforço necessário para resolver esse problema? Para fazer isso, vamos pegar a escala de classificação e executar tarefas que exigem avaliação.

Ao mesmo tempo, todos os fatores que podem afetá-lo devem ser incluídos na avaliação dos esforços:

A quantidade de trabalho necessária;
A complexidade técnica da tarefa;
Possíveis riscos e incertezas nos requisitos;

Não parece fácil, mas lembre-se de que não precisamos atribuir uma classificação clara a cada tarefa, precisamos apenas encontrar seu lugar na escala de classificação entre outras tarefas a serem avaliadas.

Quero enfatizar dois aspectos importantes do método Story Points que permitem solucionar os problemas que discutimos na página anterior:

Avaliação relativa

As tarefas são avaliadas uma em relação à outra, assim surge uma escala de classificação universal que não depende da experiência do avaliador. Mesmo que a tarefa seja substituída pela responsável - sua avaliação permanecerá inalterada, avalie tarefas relativamente novas em relação a essa escala.

Substituindo relógios por pontos abstratos

Portanto, removemos do avaliador a necessidade de avaliar a tarefa em horas. Em vez disso, ele avalia em pontos, por isso removemos as contradições na percepção da avaliação pelo desenvolvedor e gerente. Além disso, agora distrações e circunstâncias de força maior não afetarão a avaliação de forma alguma, porque elas não alteram os esforços necessários para resolver o problema!

Números de Fibonacci, camisetas e cães

Sim, sim, camisetas e cachorros. Você pode usar qualquer escala para avaliar tarefas. Os mais comuns são os números de Fibonacci, esses são valores numéricos claros e também com um bom bônus: os elementos dessa sequência refletem bem o crescimento da incerteza que surge com a complexidade do problema estimado.

No entanto, algumas equipes usam uma escala de classificação alternativa. O mais comum é uma avaliação em camisetas e cães, quando a complexidade da tarefa é indicada no tamanho da camiseta (S, M, L, XL) ou na raça do cachorro (Chihuahua, Pug, Cachorro). Assim, as equipes são ainda mais abstraídas da representação numérica da avaliação, o que, em alguns casos, compromete a transferência para uma avaliação temporária.

Pontuação da equipe

Qual é a diferença entre avaliação de equipe e avaliação individual?
Por que é importante envolver toda a equipe na classificação?

Um dos maiores erros que podem ser cometidos ao avaliar tarefas é cometer erros e não pedir a opinião dos membros da equipe. Talvez eles tenham uma opinião sobre isso? Deseja adicionar novo suporte ao navegador? O que o QA pensa sobre isso?

As pessoas são o recurso de avaliação mais importante. Eles podem ver o que você não vê.

Mas como conduzir uma avaliação da equipe? Apenas gritar notas não é muito eficaz; além disso, depois de ouvir sua nota, outro membro da equipe pode mudar de idéia e não expressar a sua.

Planejamento de pôquer

Em 2002, James Granning descreveu um método que mais tarde se tornou tão popular que agora você pode até comprar baralhos de cartas reais para o planejamento do pôquer. Ou use um dos serviços online para a sessão;

A essência do método é a seguinte: todos os participantes da equipe recebem cartões com números da escala de classificação. Em seguida, uma tarefa é selecionada e seus requisitos são discutidos. Após a discussão, o moderador pede a todos os membros da equipe que escolham um cartão e o coloque de cabeça para baixo. Então o moderador emite um sinal para mostrar os cartões.

Se as classificações dos participantes são consistentes, a classificação é fixa; caso contrário, as cartas são devolvidas à mão e os membros da equipe continuam a discutir o problema. É uma boa ideia perguntar a quem tem notas diferentes: "Que dificuldades você vê nesta tarefa?" ou "Por que você acha que durante a implementação não haverá problemas?".

Vale ressaltar que o consentimento não deve ser absoluto. Você pode concordar que um conjunto de classificações vizinhas também é considerado um consentimento.

Alternativas

Como o próprio método de avaliação, o planejamento do pôquer tem alternativas. Vou falar brevemente sobre um deles.

Você pode pular este bloco e ir diretamente para a próxima página.

Classificação afim

« . , . , . — . , , , .

, . , . .

, , .

, „“ .

Planejamento do projeto

Quantas horas existem no Story Point'e e como faço para criar um gráfico de Gantt?

Por isso, apreciamos nossa lista de tarefas, mas você não pode criar um plano de projeto no Story Point'ah. Muitas vezes, o gerente de projeto tem uma pergunta: "Como converter SP em horas?"

A resposta curta para essa pergunta é: "De jeito nenhum".

Obviamente, você pode seguir os desenvolvedores com um cronômetro e registrar o tempo que levou para resolver o problema e exibir essas informações em um gráfico. Então você obtém o clássico "sino", como no exemplo no bloco abaixo. Como vimos na primeira figura, algumas tarefas levam um pouco mais de tempo, outras um pouco menos, mas, em geral, todo o valor corresponde a alguma distribuição normal.

O mesmo vale para tarefas em 2 SP e isso é mostrado na segunda figura. Você notou que as "caudas" dos gráficos se cruzam? Sim, algumas tarefas classificadas em 1 SP podem exigir mais esforço do que as tarefas mais simples classificadas em 2 SP. No final, nenhuma equipe ainda aprendeu a avaliar perfeitamente. Além disso, ao traduzir o SP em horas, voltamos ao rake antigo, quanto tempo o desenvolvedor precisará para resolver um problema específico depende muito do desenvolvedor.

Mas o que fazer, não podemos abandonar completamente o planejamento. Felizmente, para isso, não precisamos traduzir cada ponto da história em horas. O que realmente importa é quanto SP a equipe de desenvolvimento pode "fechar" para o sprint (iteração, release).

Ao coletar dados sobre a velocidade da equipe, você pode obter dados suficientemente precisos para o planejamento de projetos a longo prazo. Além disso, não se esqueça da lei dos grandes números, os erros de estimativa são compensados mutuamente, isso se aplica tanto às tarefas quanto às iterações. Vale ressaltar que isso é um pouco otimista, porque imprecisões são geralmente associadas a subestimação e não a reavaliação. Mas nada é perfeito.

Speed (ou Velocity) é uma poderosa ferramenta de planejamento e a principal métrica da equipe de desenvolvimento. A equipe deve trabalhar na melhoria contínua para aumentar sua velocidade. Não esqueça que a velocidade é uma derivada de SP e, portanto, também relativa. Você não pode comparar duas equipes uma com a outra, a equipe compete consigo mesma.

imagem

Prática

Quais nuances você precisa saber?
Que erros podem ser evitados?

Concluindo, quero coletar algumas dicas para quem, pela primeira vez, decidiu experimentar as técnicas descritas em seu trabalho.

Por onde começar

Este é seu primeiro planejamento de poker e a equipe não entende o que avaliar novas tarefas. Colete algumas tarefas já concluídas, idealmente bem familiares ou típicas, e avalie sua complexidade em relação uma à outra. Use essas tarefas para avaliar novas.

Você tem um novo projeto e nenhuma tarefa concluída? Tente usar a classificação afim descrita acima e atribua tarefas à escala de classificação.

Não classificações médias

Às vezes, quando dois membros da equipe avaliam a tarefa de maneira diferente, é tentador atribuir a pontuação média à tarefa e seguir em frente. Não ceda a essa tentação, a discussão é um elemento importante de avaliação, durante o qual a equipe pode revelar características anteriormente desconhecidas na implementação da tarefa.

Mas, como mencionado acima, você sempre pode concordar que estimativas próximas umas das outras não serão motivo para discussões adicionais.

Não altere as classificações:

mesmo que durante a implementação você tenha percebido que cometeu um erro durante o planejamento, deixe a classificação inalterada. Você se enganará no futuro e em ambas as direções. Deixe esses erros compensarem um ao outro, não interfira no processo.

Classificação de bug

Me deparei com diferentes abordagens para avaliar bugs. Algumas equipes avaliam todos os erros, exceto aqueles que surgiram durante a implementação de novas tarefas na iteração. Alguns não avaliam erros, justificando isso pelo fato de que a velocidade da equipe deve mostrar um novo valor que é adicionado ao produto, e a correção de erros não deve afetar o crescimento desse indicador.

Seja qual for a abordagem escolhida, mantenha-se consistente. As informações sobre a velocidade histórica da equipe não devem ser afetadas pelo uso de diferentes abordagens para a avaliação.

Zero ratings

Outra pergunta que não tem uma resposta clara. Alguém acredita que não há tarefas que não exijam esforço. Outros respondem que atribuir pontos a tarefas simples leva a um aumento irracional no gráfico de velocidade da equipe.

Você pode inserir uma pontuação de 1/2 pontos para essas tarefas e monitorar retrospectivamente se a proporção dessas tarefas excede os limites razoáveis. Mas o conselho principal é o mesmo, mantenha a consistência nas suas decisões.

Reavaliando tarefas inacabadas entre iterações

Nem sempre é possível concluir uma tarefa em uma iteração, mesmo que ela tenha sido planejada originalmente. No entanto, você não deve alterar sua avaliação ao planejar a próxima iteração com base na quantidade de trabalho restante. Lembre-se disso ao planejar, mas deixe a estimativa inalterada para a história.

Avaliações retrospectivas

Se você ainda não está realizando retrospectivas, é hora de começar! Essa é uma ótima ferramenta de equipe para aumentar a velocidade e a coerência da equipe. No entanto, esse é um problema separado.

No curso de suas retrospectivas, examine as estimativas feitas durante o planejamento da iteração e discuta se houve grandes desvios entre as expectativas e a realidade.

Você também pode obter vários problemas da história com as mesmas classificações e discutir se todas essas histórias realmente exigiram a mesma quantidade de esforço.

Grave tudo:

se o seu sistema de gerenciamento de tarefas não suportar classificações e não calcular automaticamente a velocidade da equipe, será necessário fazê-lo manualmente. Como você provavelmente já adivinhou, os dados históricos são uma ferramenta importante para melhorar suas notas.

Avaliação de tarefas em pontos da história