Estimativa Ágil em Scrum? Ponto de história e pôquer de planejamento

Para o proprietário do projeto ou produto, esta é uma informação muito importante para sua medição dos recursos e prazos do projeto, mas a prática tem causado muitos problemas.

Muitos desenvolvedores sempre sentem que o PM está usando o prazo para avançar e retroceder. Eles não se importam se o recurso pode ser finalizado com qualidade.

“Faça primeiro, depois busque melhor” circula na indústria de software há muito tempo.

Muitos PMs sempre sentem que os desenvolvedores tendem a “exagerar” quando estimam seu trabalho. Parece que todos eles usam o método típico de estimativa de trabalho: “Estime três vezes o tempo real como buffer” “

De fato, as horas de trabalho não podem ser estimadas como “absolutamente precisas”, mas existem algumas maneiras de estimar “relativamente objetivas”. Devido à complexidade das horas de trabalho e requisitos, muitas vezes há uma correlação positiva. Portanto, este artigo explicará primeiro os problemas comuns em resposta à complexidade dos requisitos, proporá uma solução proposta e explicará o propósito de muitos projetos na solução.

Problemas

Mina do desenvolvedor

“É muito simples. Não deve demorar muito para fazer isso?”
PM disse a você hoje: “Eu tenho que entregá-lo antes de amanhã. “Faça antes de buscar qualidade”
PM lhe disse depois de amanhã: “Por que a qualidade do programa é tão ruim?”
Quando está atrasado, outros colegas: “Como você precisa passar tanto tempo? Este tem um código pronto para referência. Isso tem uma boa camada inferior para usar. Por que você não me perguntou?”
Outros colegas: “Só preciso de um dia, por que você passou tantos dias?”
“Isso é bom senso! Se não mencionarmos o requisito, você deve saber o que fazer.”

Mina de PM/PO

“Por que é tão simples? Demora tanto?”
“Por que você vê que está visitando o Facebook, mas não tem tempo para isso?”
“Por que a qualidade das coisas que são feitas é tão ruim?”
“Por que ele conseguiu da última vez, quantos dias você tem que fazer?”
Como as especificações ou requisitos não estão claramente escritos, o desenvolvedor é descrito como uma mudança de requisito.

Resultado

Hostilidade de papéis: A unidade de demanda e a unidade de desenvolvimento não são mais para entregar um produto que pode trazer benefícios para o usuário, mas para atacar um ao outro para seus próprios propósitos, a fim de evitar ter que arcar com responsabilidades adicionais. Portanto, a situação em que a unidade de demanda e a unidade de desenvolvimento não são uma única equipe.
Responsabilidade: A equipe pensa que “não estou errado, então o atraso não é minha responsabilidade”, ao invés de priorizar as necessidades do usuário.
Congelamento de demanda: Os desenvolvedores são forçados a alterar seus requisitos por causa da pressão do prazo, caso contrário, eles serão atrasados e a responsabilidade será contada no desenvolvedor. Conseqüentemente, seja necessário trabalhar horas extras para produzir algo que esconda muitos bugs, ou para fazer algum tipo de recurso que não atenda às necessidades dos usuários; e ambos reduzirão a satisfação do usuário.
Baixa qualidade: O status do PM geralmente é mais alto do que o dos desenvolvedores. Portanto, para cumprir o prazo do contrato ou para evitar penalidades, etc., a equipe será solicitada a “Fazer primeiro, depois buscar melhor”, mas finalmente é muitas vezes “primeiro, não há tempo para buscar o bom .” O acúmulo de dívida técnica está aumentando e o resultado é o modelo de cadeia de responsabilidade do mundo real, que tem a maior responsabilidade e custo no final da cadeia. Portanto, a equipe é como uma pilha, os desenvolvedores não podem sustentar um por um, o que é um dos fatores pelos quais os engenheiros da empresa de projetos geralmente têm altas taxas de rotatividade.
Aumentando o peso do código: Para otimizar a eficiência, a posição da pessoa mais familiar é sempre usada para estimar as horas de trabalho, de modo que a pessoa mais familiarizada com o módulo e o processo estará sempre preocupada com os requisitos relevantes . No final, apenas essas pessoas podem manter seu próprio código, é como uma caixa de Pandora, você nunca sabe quais vacas e fantasmas vão acabar depois de abrir. Porque a caixa preta costuma ser suja, mas a empresa não tinha ideia de como resolver esse problema. Você também espera que ele não vá embora, caso contrário, parte do código não será entendido.

Soluções

A solução proposta aqui é uma forma comum de estimar a complexidade dos requisitos em Scrum, mas mesmo que não seja uma equipe Scrum, é recomendável que os leitores consigam identificar a melhor forma de estimar sua equipe com base nos princípios e objetivos do projeto .

Lembre-se de que, sem uma bala de prata, a prática recomendada de outra pessoa não se aplica necessariamente à sua equipe, portanto, primeiro entenda qual é o problema que sua equipe está enfrentando no momento e, em seguida, descubra o que é certo para você resolver o problema a partir da prática de outra pessoa , desde que não dê origem a novos problemas ou o risco de custo de um novo problema seja aceitável.

A unidade usada aqui para estimar a complexidade dos requisitos é o ponto da história (unidade relativa), não as horas de trabalho (unidades absolutas).

A unidade usada para estimar a complexidade da demanda aqui é o ponto da história (unidade relativa), não o tempo de trabalho (unidade absoluta). Existem várias razões para fazer isso:

1. As comparações não variam de pessoa para lugar: a complexidade do requisito geralmente não varia de pessoa para pessoa, e o tempo necessário para a prática varia de pessoa para pessoa.

2. “Relativo” é mais fácil de avaliar do que “Absoluto”: Se você observar as horas de trabalho, precisará estimar o número absoluto e precisará pensar nos detalhes de implementação no processo de estimativa. Para usar o story point para estimar a complexidade, você só precisa comparar o tamanho com outros requisitos.

Por exemplo, é difícil dizer com clareza que “Uma Torre tem alguns metros de altura”, mas é mais fácil apontar que “Esta Torre é cerca de 2 vezes mais alta que aquele prédio”.

3. A pressão para estimar o ponto da história de uma história de usuário é menor do que a estimativa de seu tempo de trabalho: concentre-se no requisito em si, sem se preocupar com seus próprios recursos e recursos do projeto, simplesmente avalie a complexidade do requisito. Durante o processo de estimativa, os membros da equipe ficam menos estressados e participam do desenvolvimento de software como um jogo.

Embora a complexidade da demanda muitas vezes esteja positivamente relacionada à jornada de trabalho, devido às diferentes condições de implementação, ainda é possível ter um recurso com um ponto de história alto, e a demanda por jornada de trabalho é menor que o ponto de história. Mas no Scrum, você pode usar o sprint de iteração para avaliar quanta complexidade cada equipe de sprint pode digerir. Para PO/PM, em vez de estimar um curso de tempo malsucedido, é melhor estimar um curso de tempo mais preciso e objetivo para que eles possam entender na primeira vez, quão longe do curso de tempo esperado do projeto. Se os recursos são limitados, como priorizar os requisitos ou buscar outro suporte.

Em seguida, explique os vários aspectos da solução.

Quando

Faça uma avaliação antes de decidir quem precisa fazer isso: O benefício de fazer isso é minimizar os fatores pessoais do desenvolvedor. Como você não sabe quem vai fazer isso, não há necessidade de superestimar a adição de buffer devido à sua própria tarefa ou prazo.

Who

Somente as pessoas que fazem coisas para avaliar em conjunto: dois pontos principais:

Somente as pessoas que fazem coisas podem ser estimadas. O tempo ou complexidade estimado pela unidade de requisito não é objetivo, pois não é a pessoa real que faz o trabalho, e não há poder para influenciar a estimativa da equipe de desenvolvimento com base na avaliação do custo do trabalho. Isso também torna mais fácil evitar a avaliação da complexidade dos requisitos a partir do prazo.
Pessoas que fazem coisas juntas estimam. Como você não sabe quem vai fazer isso, os números que cada pessoa estima em conjunto são fáceis de chegar a um consenso após discussão e reavaliação. Todos têm a participação, eles terão um senso de participação, e porque todos têm a participação, o resultado da estimativa é decidido por todos, então quem vai fazer no futuro não vai reclamar.

O que

Use o Planning Poker para estimar o ponto da história.

Carta de pôquer e sequência de Fibonacci

A série Fischer tem uma característica interessante, e cada número são os dois primeiros números adicionados. Por outro lado, quanto maior a diferença entre o número e o próximo, maior a diferença.

Como mostrado acima, a diferença entre 8 e 13 é 5, e a diferença entre 13 e 20 é 7. No entanto, como isso se relaciona com a estimativa da complexidade da demanda? Não estamos na aula de matemática.

Características da Estimativa Relacionada à Sequência de Fibonacci

As estimativas também têm uma característica, ou seja, quanto maior quanto mais precisa, maior a demanda ou tarefa é cortada para uma granularidade mais fina, muitas vezes é estimada como mais precisa. Assim como se um grande pedaço de pedra irregular for instalado em um copo, haverá mais lacunas no meio, que é a parte que está desalinhada ou desperdiçada. Se você instalar uma pedra com um tamanho mais fino e a mesma irregularidade, a lacuna será relativamente pequena e é fácil de ajustar e pode preencher a lacuna de maneira mais conveniente.

Mesmo que a diferença nos números anteriores seja relativamente pequena, não importa porque o número é pequeno, o que significa que o movimento é flexível e o risco é baixo. Se a estimativa de tempo for imprecisa devido a certos fatores, a tarefa do pequeno número na frente é de cerca de 20 minutos de horas extras. Em vez de trabalhar horas extras por 2 ou 5 dias.

Como o grande gap digital é grande (a razão de diferença dos dois valores dianteiros e traseiros da série Fermi é próxima de 1,618), é possível evitar a estimativa de “se essa complexidade é 20 ou 21”. “Se você quer 13, você quer 20, você quer 40.

Tal lacuna pode evidenciar a diferença nas estimativas do mesmo requisito, pois quase todas são mais de 1,5 vezes piores. Essa proporção é bastante fácil para os humanos julgarem o tamanho relativo e, portanto, pode reduzir muitas nuances e custos desnecessários do processo Re-estimar.

Números Especiais no Cartão de Poker

Além disso, a imagem acima pode ser vista com alguns números especiais, que são 0, infinito e ponto de interrogação.

0 pode significar que esse requisito não precisa ser feito ou já foi concluído.
Infinito significa que a demanda é clara, mas aquela que excede o número máximo indica que a demanda precisa ser subdividida em vários requisitos de menor porte.
O ponto de interrogação indica que a demanda não está clara e precisa de PO/PM para explicar ou esclarecer.

Quão

1. Primeiro defina a unidade de complexidade 1 , como a função de uma consulta abrangente de uma única tabela. Como nosso processo de estimativa é baseado no tamanho relativo, primeiro definimos a unidade de referência de comparação e há uma base para comparação após as estimativas da equipe.

2. O anfitrião fala em voz alta os requisitos (como o User Story Card) para garantir que todos entendam os requisitos e que cada pessoa apresente sua própria complexidade estimada. A razão para usar o planning poker é porque os números que você avalia podem ser apresentados ao mesmo tempo, em vez de girar os números que você avaliou. É fácil virar os números e fazer com que os resultados das pessoas por trás deles sejam afetados pelos números anteriores.

3. Se houver estimativas diferentes na equipe, estima-se que as duas sejam a menor e a maior, e eles avaliarão por que são complicadas ou simples. No exemplo acima, no processo de estimativa, se uma pessoa estima que o story point é 13, a maioria das pessoas estima 20 e outra pessoa estima 40. 13 e 40 são quase 3 vezes piores, então basicamente deve haver alguma informação importante que tenha não foi sincronizado.

Por exemplo, as pessoas que estimam 13 acham que essa demanda é quase igual a uma exigência do passado, e essa exigência não é tão complicada quanto se imaginava. A pessoa que estima 40 pode se sentir relativamente complicada porque não está familiarizada o suficiente com esse requisito ou processo.

4. Os valores mínimos e máximos são preenchidos os motivos da avaliação e procede-se a nova votação. Se ainda houver números diferentes de votos, e a grande maioria das pessoas tiver um consenso, e não houver consenso de que a complexidade estimada está a apenas um nível da complexidade do consenso, você pode perguntar aos membros que estimam os diferentes números se eles pode aceitar os números que você avaliou.

5. Se o número ainda tiver uma lacuna acima de um nível, ou se o consenso não puder ser obtido, repita as etapas de 3 a 5 até que o consenso seja alcançado.

Novamente, apenas aqueles que realmente executam tarefas ou completam os requisitos podem participar do processo de votação, e o PO/PM não pode interferir.

Por que

Existem várias vantagens nesta forma de estimar:

A pessoa que está trabalhando em conjunto decide um resultado de estimativa razoável e objetivo, tem senso de participação e não tem reclamações.
O resultado da decisão é o consenso entre PO e Equipe, o que reduzirá a ocorrência de situações de confronto no futuro.
Todos podem entender o requisito. No futuro, todos podem agir como a pessoa para cumprir o requisito. Quando o requisito de apoio é necessário, as pessoas também podem ajudar ou apoiar umas às outras.
Antes de fazer isso, você pode esclarecer a parte do requisito que não está clara e a parte que tem dúvidas.
Antes que você possa fazer isso, você pode encontrar a melhor e mais eficiente maneira de trabalhar em equipe.
A menos que toda a equipe seja uma pessoa não confiável, esse número reflete o fato de que a estimativa é compartilhada pela equipe e o PO pode entender a lacuna entre demanda e avaliação.
Ao comparar o tamanho relativo da complexidade entre os requisitos, o futuro PO poderá prometer quanto trabalho pode ser realizado em uma iteração e haverá uma base para comparação.

Conclusão

Através do processo de estimativa acima, tal decisão é aberta, transparente, objetiva e consensual. Para dois papéis:

Para PO/PM:

Não se preocupe em superestimar uma tarefa para um buffer por certos membros.
Compreender a dificuldade subjacente de implementação de requisitos ou tarefas no processo de avaliação.
Entenda se há alguma parte do requisito que precisa ser claramente declarada ou mal compreendida.

Para equipe:

As pessoas que não estão mais fazendo as coisas recebem um prazo irracional de acordo com o prazo.
Troca de conhecimento entre os desenvolvedores antes de começarem a trabalhar na tarefa. Independentemente de aumentar ou diminuir o número estimado, a demanda é mais clara e a estimativa é mais objetiva.
Como você ainda não sabe quem está reivindicando essa tarefa, para que o processo de estimativa possa ser alcançado de forma objetiva e com o consenso da equipe, você sabe quem está familiarizado com essa tarefa ao longo do processo. Quando você realmente faz isso, você pode programar em par ou saber a quem pedir ajuda.

A solução proposta neste artigo é uma solução comum. O foco não está na forma, mas no propósito de design de cada link no processo de estimativa ágil, a fim de resolver que tipo de problema.