Qual é o objetivo de planejar o poker em um sprint?

Nosso analista de negócios e líderes de projeto nos dizem a exigência do cliente como Histórias. Todo planejamento da Sprint, nós (desenvolvedores) somos convidados a jogar pôquer de planejamento.

Eles pediram a todos nós que considerássemos a 'complexidade' em vez de 'esforço'. Estamos realmente confusos e estamos perdendo tempo em nossas reuniões. Um desenvolvedor levantou uma questão: 'O que realmente devemos considerar? É sobre a alteração de código / DDL que precisamos fazer nesse requisito (estimativa de tempo) ou se entendemos ou não o requisito? '

Mas o que eles (analista de negócios e líderes de projeto) realmente querem dizer com 'entender o requisito' e 'levantar um cartão'?

Além disso, temos reuniões de divisão para equipes de scrum individuais, em que cada desenvolvedor fornece uma estimativa de tempo para determinada tarefa para cada equipe de scrum. Então, de que tipo de coisa eles realmente estão falando no Planning Poker?

Alguém pode explicar isso usando um exemplo? Tente diferenciar o que eles realmente estão falando quando dizem 'Complexidade' e 'Esforço'.

Considere o ponto de vista do gerente de projetos

Ao pedir complexidade, eles querem um número que possa ser comparado ao seu próximo sprint para encontrar sua velocidade como equipe. Eles também podem estar tentando usá-lo para adicionar o resultado com as estimativas de outras equipes para fornecer uma estimativa geral de quando todas as histórias serão concluídas.

O gerente de projeto está procurando uma estimativa de quando o projeto será concluído ou se eles são flexíveis em outros lados do triângulo tempo-função-custo, que outras saídas podem ser puxadas para ajustá-lo ao tempo restante. Isso não é irracional. As decisões de negócios precisarão ser tomadas com base nessa estimativa. O problema é que é realmente difícil estimar isso para o software. Planejar o pôquer é uma das maneiras de ajudar com esse problema. Em vez de vê-lo simplesmente agregando o número de pontos da história, pense nisso como uma função mais complexa de estimar o melhor possível, fazendo o trabalho, medindo quanto tempo demorou, iterando e extrapolando.

A discussão é mais importante que um número

Acho que a parte mais importante das reuniões que apontam histórias são as discussões que surgem. Se alguém da equipe não estiver confiante sugerindo um número, provavelmente não entenderá completamente a história e é necessário que haja mais discussões. Do Manifesto Ágil "Colaboração do cliente sobre negociação de contrato". Em vez de apenas especificar um contrato escrito como uma história de usuário e dizer que a equipe falhou se eles não fizerem exatamente o que você deseja, é sempre melhor conversar sobre o que o cliente realmente deseja até que você entenda.

Complexidade versus esforço

Para abordar sua pergunta específica sobre complexidade versus esforço, todos parecem ter uma opinião diferente sobre isso. Mountain Goat , que são as pessoas que fazem os cartões de pôquer de planejamento que têm cabras nas costas e cujo dono Mike Cohn é grande no mundo do Agile / Scrum, diz que deve ser um esforço e não uma complexidade.

Normalmente, não é visto como uma medida de tempo (veja um exemplo abaixo como exemplo), pois as pessoas são ruins em estimar o tempo, com outros fatores afetando o número que elas dão: por exemplo, pressão para manter o número baixo, para que você possa ajustar mais recursos pressão, para dar um número maior, para dar espaço a si mesmo, se você se deparar com um problema. Construir software é difícil. Quando você constrói sua 100ª casa, pode estimar quanto tempo levará, já que você construiu 99 casas antes disso. Se o software que você está construindo é o mesmo que os programas anteriores que você criou, você pode copiar e colar, qualquer valor enquanto o projeto de software é diferente e, portanto, terá problemas que você não previu no início.

Assim como as estimativas de tempo contendo pressões ocultas, uma medida de esforço também apresenta problemas. Se um desenvolvedor júnior estima uma alta complexidade, pode sentir que está se deixando aberto ao ataque por não ser bom o suficiente de outros que lhe dariam uma estimativa mais baixa. Isso não é apenas prejudicial para suas estimativas, mas para as pessoas da equipe.

Os números de planejamento do poker não são 'número de dias' ou outra medida de tempo; são uma medida relativa para poder comparar duas histórias de usuários. A primeira coisa que você precisa fazer em uma nova equipe é estabelecer uma linha de base. Escolha uma história de usuário que esteja no meio do intervalo de complexidade e concorde como equipe um número no meio do intervalo que você deseja atribuir. Agora todas as outras histórias de usuários podem ser numeradas em relação a esta. Eu descobri que isso facilita muito.

Razões pelas quais você não pode dar uma estimativa

Quando os gerentes de projeto perguntam quando um projeto será concluído, eles precisam entender a complexidade da pergunta que estão fazendo. Os programadores não são trabalhadores de fábrica, onde sua produtividade pode ser medida multiplicando a rapidez com que digitam e por quanto tempo trabalham. Eles estão descobrindo respostas para os problemas e isso é difícil. Ao jogar poker de planejamento, você primeiro identifica quem na equipe sente que não pode responder à pergunta de qual número atribuir e, em seguida, analisa por que eles não podem responder a essa pergunta. Eu acho que há pelo menos quatro razões:

1. A história é muito grande. Divida-o em histórias de usuário menores e mais específicas. Lembre-se de que cada história de usuário deve fornecer um pedaço de valor ao usuário; entrada - processo - saída = valor.
2. Eles não entendem o domínio do problema o suficiente para poder dizer quanto tempo levará ou até fazer todas as perguntas corretamente. Vá conversar com pessoas que sabem mais sobre o domínio / programação de partes interessadas desse tipo de aplicativo, independentemente do que você nunca viu antes. Se isso não for possível ou não o levar até lá, você poderá usar um pico de design. Vá e protótipo de uma solução, mas apenas por um período de tempo limitado e especificado . Defina quanto tempo a fase de prototipagem continuará, não muito, e depois volte a se reunir para compartilhar seu novo entendimento.
3. Seus stakeholders não estão sendo suficientemente específicos. "Construa uma nuvem para mim" não é uma história de usuário aceitável. "Construa para mim um sistema em que eu possa ativar VMs sob demanda" é melhor, pois é dividido ainda mais, mas ainda não está no nível em que você pode fornecer uma estimativa precisa de quanto tempo levará, já que haverá cem ocultos suposições contidas nessa declaração de que as partes interessadas têm que você não descobrirá até que mostre algo a elas.
4. Finalmente, mesmo se você puder fazer uma estimativa, provavelmente estará errado na primeira vez. A estimativa é um problema difícil e a melhor maneira que conheço para resolver problemas difíceis é usar o método científico. Colete dados sobre os números estimados por cada membro da equipe, em seguida, colete dados sobre quanto tempo realmente os levou ou quão "complexos" foram, embora isso seja mais difícil, e compare-os com o tempo. Eventualmente, você terá uma ideia de quem superestima e quem subestima e, em seguida, deve compartilhar isso com a equipe. As pessoas podem ajudar-se a melhorar na estimativa. Esses números também podem ser retornados à sua ferramenta de rastreamento para ajudar a prever melhor quanto tempo as histórias levarão.

Conclusão

Acredito que o ponto realmente deve ser a discussão, mas se você realmente precisar fornecer um número a alguém, tente torná-lo independente de qual membro da equipe trabalha e em que ordem as histórias são trabalhadas. O objetivo é obter um registro posterior que seja priorizado, para que você trabalhe neles na ordem e no tamanho corretos, para que o gerente de projeto possa ver mais ou menos quantos você pode caber antes do prazo. Você deve poder parar no final de qualquer iteração e enviar com todos os recursos concluídos que foram iniciados.

Atenção

Você pode estimar o tempo para concluir as tarefas dentro de sua equipe o quanto quiser, desde que mantenha os números para si mesmo. Depois que você permitir que qualquer número escape da equipe e seja visto por outras pessoas, eles farão coisas com o número que você não pretendia. Eles tentarão usá-lo por alguns dias para concluir as tarefas. Eles tentarão mantê-lo na classificação de complexidade relativa e perguntarão por que demorou mais para concluir uma história de usuário do que outra com o mesmo número de pontos. Eles adicionam seus números e os comparam aos números de outras equipes e perguntam por que a outra equipe está 'fazendo mais trabalho' à medida que completam mais histórias dentro de um período de tempo. Você pode'

a parte, de lado

O conjunto de números de planejamento do poker é normalmente distribuído de forma que as diferenças entre os números continuem aumentando. Acredito que isso tenha como objetivo desencorajar as pessoas a discutir se uma história de usuário é 16 ou 17, se for maior que 13, então faça 20.

Exemplo

Conheço pelo menos um time que usa apenas os números 1, 2, 3 e 4 para planejar o pôquer. Eles, por convenção e contrariamente à discussão acima, definem esses dias como dias de programação (na verdade parear dias de programação, ou seja, quantos dias levaria dois programadores trabalhando juntos na mesma máquina para completar a história do usuário). Se a equipe considerar que levaria mais de quatro dias para concluir uma história do usuário, ela não será informada e o proprietário do produto será solicitado a trabalhar com a equipe para detalhar mais a história ou especificá-la com mais precisão para que possa dentro desse intervalo para uma futura reunião de planejamento. Mas isso é ágil e avançado e provavelmente só deve ser usado por pessoas com experiência no uso de outras técnicas.

Acho que as respostas de Frank e Encaita praticamente cobrem isso, mas há algumas coisas adicionais a serem consideradas:

Por que usar pontos da história

O objetivo de estimar com pontos da história é fornecer a relativa complexidade do desenvolvimento de recursos para seu aplicativo. Uma maneira simples de pensar sobre isso é pegar uma história que você tem no próximo sprint, por exemplo, uma alteração de URL. Você sabe que isso é simples em termos de complexidade e tem critérios de aceitação claramente definidos, de modo que toda a equipe concorda que mesmo com o teste é 1 (usando a escala Fibo).

A próxima história a ser estimada é agregar um conjunto de dados do usuário e visualizá-lo no front end. Agora, como desenvolvedor, você sabe imediatamente que isso é muito mais complexo do que alterar um URL. Você discute a história e os critérios de aceitação e tem muitas perguntas e pode ver várias soluções em potencial para fazer isso. Os outros desenvolvedores e o controle de qualidade também concordam que é muito complexo. Então todos vocês concordam que é uma história de 34 pontos. Vale a pena notar que a escala Fibo também permite indicar quanta confiança você tem na estimativa - quanto maiores as diferenças entre os números, menor a confiança que você tem em sua estimativa

Nesse ponto, seu mestre do Scrum deve pular e dizer que essa é uma história única muito grande e precisa ser dividida em histórias menores e de menor complexidade. Você pode abordar isso fazendo o que é conhecido como SPIKES - esse é apenas um tempo reservado para investigar algo. Portanto, neste exemplo, você e os outros desenvolvedores concordam que deseja 4 horas para discutir e investigar as possíveis soluções técnicas.

Para resumir uma longa história, você divide essa grande história em quatro outras histórias de 5, 8, 8 e 13 pontos. Não se esqueça de que essas estimativas são relativas à complexidade relativa - elas não precisam ser somadas à estimativa original e você tem mais informações agora para fazer uma estimativa mais precisa.

Você concorda em equipe que, para este sprint, terá como objetivo concluir a história de 13 pontos, uma história de 8 pontos e a alteração de URL de 1 ponto que você já identificou. Então, um total de 22 pontos. No próximo sprint, você recebe 27 pontos; no seguinte, você recebe 18 pontos. Após três sprints, você pode começar a ter confiança em sua velocidade (velocidade é a quantidade de trabalho que sua equipe pode realizar em um sprint). Para obter a velocidade, calcule a média dos sprints anteriores. Portanto, neste exemplo, a média é (22 + 27 + 18) / 3 = 22,3, então arredonde-o para o mais próximo na escala Fibo, que é 21.

Agora, para o próximo sprint, apenas 21 pontos.

Não se preocupe em obter sua estimativa de ponto da história exatamente correta - não é uma ciência exata. Você sabe que uma alteração de URL é muito menos complexa do que a agregação de dados; portanto, apenas classifique-a de acordo.

Além disso, discutir essas coisas em equipe é bom. Examine suas estimativas durante a revisão do sprint e discuta se você ficou feliz com eles ou não e, em seguida, alimente isso na próxima sessão de planejamento do sprint.

Estimativa de toda a equipe

Toda a equipe deve concordar com uma única estimativa para cada história. Um recurso não é concluído até que esteja pronto para produção. Basta escrever o código de maneira alguma. Na minha experiência, as equipes Scrum têm sido muito mais eficazes quando trabalham em equipe. Tome um exemplo da equipe com a qual estou trabalhando agora. Quando entrei, eles estavam realizando todas as reuniões do sprint e planejando o pôquer, mas durante o sprint o processo foi 1. Os BAs / Product Owners definem os requisitos como histórias com critérios de aceitação e testes de aceitação 2. Eles entregam esses requisitos ao desenvolvedor que então escreve o código 3. O desenvolvedor mesclou o código no ramo de desenvolvimento para testar o controle de qualidade 4. O teste de controle de qualidade começa a fazer perguntas e os testes falham e, portanto, volta ao desenvolvimento.

O que falta aqui? Não há discussão suficiente no início e cada membro da equipe viu apenas sua própria tarefa. Agora o BA / PO, os desenvolvedores e o controle de qualidade se reúnem antes de escrever qualquer código para discutir os requisitos em detalhes e fazer perguntas antecipadamente, depois continue a discussão durante o sprint. Isso é muito mais eficiente e leva a soluções de melhor qualidade.

O planejamento do pôquer ajuda esse processo porque força a equipe a discutir o recurso e a concordar, como um time, quão complexa é a entrega desse recurso. No desenvolvimento tradicional de software, o gerente de projeto era responsável pela entrega do projeto, mas qualquer pessoa com experiência nessa abordagem sabe que não funciona porque, na maioria das vezes, as pessoas não se responsabilizam por sua parte na entrega do aplicativo. No Agile, você não precisa de gerentes de projeto, porque a equipe assume a responsabilidade como um todo pela entrega do aplicativo.

Estimativa pontual de tarefas

Minha visão de ter trabalhado com equipes que estimam tempo em tarefas e equipes que apenas calculam pontos de história é NÃO FAÇA ESTIMATIVAS DE TEMPO! Na verdade, são apenas uma perda de tempo. Eles não são tão precisos quanto os pontos da história, porque são específicos para indivíduos e não para a equipe, e cada indivíduo terá uma idéia diferente de estimativa de tempo (acenda a chama).

Os pontos da história aceitam que as coisas, ou seja, os requisitos, mudam o tempo todo, então você realmente precisa de um indicador do que a equipe pode concluir em um sprint.

Depois de entender a velocidade, você pode medir seus resultados a tempo, porque sabe o que pode ser feito em cada sprint. Por exemplo, a cada duas semanas, você sabe quais recursos podem ser entregues. O mestre do scrum e os proprietários do produto devem ter sessões de estimativa para prever futuros sprints, para que você possa obter um indicador de quanto trabalho será realizado nos próximos meses. Isso permite que os proprietários do produto tomem decisões de priorização sobre quais recursos incluir no aplicativo final.

Os desenvolvedores solicitaram que estimassemos o tempo das tarefas para planejar, mas eu realmente discordo dessa abordagem (na verdade, eu discordo totalmente dessa abordagem) porque ela não é precisa, por exemplo, o que isso me levará 4 horas realmente significa: um desenvolvedor pode incluir apenas o tempo da tarefa em si, alguém pode adicionar tempo para fazer xícaras de chá!

As estimativas de tempo são sempre entregues a outra pessoa para fins de geração de relatórios e também enfatizam demais os elementos individuais da entrega de um recurso em comparação com todo o esforço da equipe.

A estimativa não é o maior problema

Como um aparte, descobrir estimativas não é o maior problema que as equipes precisam resolver. O mais importante é trabalhar juntos como uma equipe para realizar as tarefas durante todo o sprint, para que você não entregue tudo para os testes no último dia. Você deseja ver uma série constante de recursos durante o sprint de duas semanas. A dinâmica da equipe que expliquei acima é uma grande parte disso. A estimativa do ponto da história o ajudará a planejar isso, porque você verá quais são as grandes histórias que precisam ser divididas em menores e que podem ser entregues regularmente em testes.

A Wikipedia explica muito bem o planejamento do pôquer . Deixe-me recapitular um pouco do estado lá com foco no seu caso:

Por que planejar poker?

Antes de tudo, todos devem estar cientes do motivo pelo qual estão planejando um pôquer, em oposição a uma estimativa "normal". O motivo é bem simples: todos nós demoramos muito para estimar o tempo de uma tarefa. Praticamente todos os estudos revelaram que o cérebro humano é simplesmente incapaz de estimar tarefas que levam uma quantidade razoável de tempo. (Também é uma razão pela qual os tickets que ultrapassam 2-3 dias em sua estimativa são praticamente inúteis em termos de estimativa.)

Por que complexidade e não esforço?

Isso anda de mãos dadas com o acima. Esforço geralmente significa tempo , e somos péssimos nisso. Em vez disso, é difícil quantificar objetivamente a complexidade , o que é uma coisa boa nesse caso. É o seu intestino que lhe diz que essa história será complexa. Para outra pessoa, pode ser menos complexo. Mas você não precisa quantificar exatamente o quão complexo é realmente. Você não precisa obter esse número Xde complexidade - em oposição a um esforço cronometrado, em que eventualmente precisa concordar que leva Xdias ou algo assim.

Por que esconder os cartões?

As cartas com sua complexidade convidada são jogadas escondidas e depois reveladas de uma só vez. Isso é feito para garantir que você não seja influenciado pelas opiniões de outras pessoas antes de fazer sua própria estimativa inicial. Se todo mundo tem o mesmo instinto em termos de complexidade, então está feito. Se houver números muito diferentes, você sabe que há algo a ser discutido escondido lá. Dessa forma, você pode lidar rapidamente com histórias para as quais todos têm a mesma idéia da complexidade / esforço exigidos.

Por que números de Fibonacci?

Os números em seus cartões são tipicamente números de Fibonacci ou algum outro tipo de sequência com muitas lacunas nos números. Isso é para forçá-lo a confiar plenamente no seu instinto. Se você tiver que escolher entre 8 e 13, é muito mais uma declaração do que optar por 9 ou 10. Além disso, como mencionado acima, as grandes diferenças são onde estão os problemas ocultos; portanto, ao aumentar as lacunas, você aumenta a chance de detectar esses problemas melhor.

Por que isso funciona?

Curiosamente, nas primeiras vezes em que você faz um planejamento de pôquer, não funciona. É simples assim. O que significa "3" ou "5"? Não há definição para o que cada número significa (de propósito!) E cabe a toda a equipe descobrir o significado real por trás de cada um desses números. Somente depois de aceitar a estimativa de suas histórias nesses números - e depois de perceber várias delas - você terá uma idéia melhor de quando deve aumentar um 5 e quando é um 8.

Depois de combinar isso com o conceito de velocidade e medir o progresso do sprint por meio desses pontos da história, você terá uma nova escala de eficiência que é mais ou menos independente das estimativas de tempo tradicionais.

No entanto, para mim, pessoalmente, o ponto mais benéfico do planejamento do poker é que, usando números de fibonacci em vez de estimativas de tempo, você tem um tempo muito mais fácil para detectar incertezas. Com as estimativas de tempo clássicas, você não é forçado a tomar essas decisões "extremas" (devido às diferenças de número); portanto, as estimativas podem estar bastante próximas e a equipe pode acreditar falsamente que entendeu bem a história.

Exemplo

Um exemplo simples do que normalmente acontece é que uma história é apresentada e a pessoa A apresenta uma objeção. É algo como "por favor, não esqueça que esse recurso afeta o X e isso pode significar que é mais caro do que pensávamos até agora". O principal problema é que sempre há essa pessoa A na mesa. Sempre há algo com que alguém está preocupado. Se você tem uma discussão aberta, você não tem idéia do quão grande é essa preocupação X.

Se você fizer estimativas ocultas com base no tempo, elas ficarão um pouco melhores. Mas, ainda assim, uma pessoa A com uma objeção válida pode ainda não estar claramente clara em sua estimativa. Por outro lado, ao planejar o pôquer, a pessoa A precisa pensar mais sobre o tamanho de um problema real X. Para dois problemas diferentes, você não pode distinguir adequadamente sua importância pelo "texto de objeção falado" acima. Mesmo com estimativas de tempo, é bastante difícil ver qual é mais um problema. A esperança de usar o planejamento do poker aqui é que você acaba com uma objeção sendo apenas 2-3 pontos diferente das estimativas dos outros, mas a outra objeção que terminou a 5 ou 8 pontos da mediana pode ser apenas a incerteza mais importante do seu planejamento de sprint.

Depois de dezenas de iterações na minha equipe, descobrimos que os pontos da história são principalmente sobre orientação de projeto a médio prazo. Eles permitem que o proprietário do produto projete 2 ou 3 sprints à frente e toma essencialmente decisões de negócios e escopo sobre uma liberação, com base em uma velocidade média.

Descobrimos que os pontos da história não são tão úteis no nível do sprint, porque não existem dois sprints semelhantes e é impossível prever quanto trabalho será feito. Conseqüentemente, decidimos que não devemos ficar obcecados com a parte da estimativa e apenas tomar o planejamento das sessões de pôquer como pretexto para conversar sobre recursos.

Isso concorda com um argumento de Mike Cohn aqui .

Como observação lateral, isso é verdade para uma equipe, mas não há regra sobre como os pontos da história o ajudarão. Eu recomendo que você se atenha primeiro à metodologia, mas tente descobrir rapidamente por si mesmo se e como elas são úteis. Retrospectivas ajudarão você a refletir sobre isso.

O problema fundamental aqui é que ele está quebrado. O PM quer usar o planejamento do pôquer para ter uma idéia da complexidade de cada história, com a intenção de saber aproximadamente quantas histórias podem ser encaixadas em um sprint (a velocidade da equipe).

Como resultado, é um "não baseado no tempo" que é "baseado no tempo". Não é de admirar que todos fiquem confusos.

Existem maneiras de fazer isso funcionar para você. Primeiro, esqueça o esforço e concentre-se na complexidade. Esqueça tudo quanto tempo pode levar para se desenvolver e se concentrar nas áreas que cada história afeta. Se você tem uma história que atualiza o banco de dados, o código do servidor, o código do cliente e a documentação do cliente, pode dizer que é uma história de quatro pontos. Se for apenas uma alteração no sql do banco de dados, será uma história de 1 ponto. Isso fornece uma maneira mais compreensível de descobrir a relativa complexidade entre as histórias. (Você precisará criar algumas métricas que façam sentido para suas circunstâncias, talvez para testar os requisitos de cobertura ou a complexidade da interface do usuário)

Em geral, minha opinião é que é um desperdício de tempo inútil que simplesmente incentiva o planejamento de sprints como se fossem mini projetos em cascata. Quem realmente se importa com quantos pontos da história você pode caber em um sprint? Se houver sobras de histórias no final de um sprint, basta fazê-las na próxima. Dado isso, você também pode fazer com que seu backlog fique do tamanho de todas as histórias pendentes que você tem e gradualmente reduzi-las ao longo do tempo. A entrega leva o tempo que for necessário (mas será mais rápido se você não se preocupar em desperdiçar 20% do seu tempo em reuniões de planejamento de pendências e sprint). No final do projeto, ninguém se importa com quantos pontos da história foram entregues. O que as pessoas se preocupam é com o projeto entregue.

Além disso, apontar a história do usuário dá à empresa um alerta em termos de se algo precisa ser renegociado. se você tiver um mês para concluir algum trabalho que você pontuou como 100, poderá estar com problemas. também oferece a chance de dividir uma história épica em algo menor que ainda tem valor e pode ser concluído em um sprint.