INOV CAP08 2024 VIDEOCAST PLANNING POKER

Você conhece o planning poker?

Pois é, é exatamente disso
que nós vamos falar.

Eu sou o Robson Pantolfi, head de tecnologia
e produtos, e também professor na FIAP.

E temos aqui um time de ponta
para simular esse cenário com vocês.

Por falar de time de ponta,
eu estou aqui na ponta da mesa.

Sou o André David,
professor, desenvolvedor

e, junto com você, eu quero descobrir
que história é essa de planning poker

e onde nós vamos levar ele.

Eu sou a Laura Gurgel, sou head
de experiência do cliente na _____

e também professora da FIAP,

e, assim como o André, vou descobrir
que diabos seria planning poker.

Eu sou a Ju Amoasei, eu sou desenvolvedora
back-end e instrutora de programação.

E aí, eu vou ajudar a esclarecer o que é
o planning poker e para quê ele é usado.

Eu acho que nós podemos partir daí, vocês
contarem para nós o que é esse planning poker,

por que nós estamos com monte de carta
na mão e, principalmente, para que ele serve.

Legal.

Bom, antes de tudo, é importante nós
entendermos a dinâmica de estimativas

o que ela segue e como que é
o contexto histórico.

Historicamente, existiam
várias metodologias,

a mais famosa, especialmente
em projetos de sistemas,

era justamente a análise
de ponto de função.

Mas, diferente do que é
o nosso modelo ágil,

outros modelos tinham um padrão,
tabelas que, muitas vezes,

não respeitavam a produtividade
real de cada personagem do time.

Com o planning poker, isso mudou
um pouco e isso respeita muito mais,

inclusive é estimado pelo próprio
time que vai construir o produto.

O planning poker, assim
como está na mesa,

ele reflete diretamente
a filosofia de Fibonacci,

que é uma regra matemática,
uma sequência

que indica que o próximo número
representa a soma dos dois anteriores.

Então, aqui, nós vemos em uma escala
crescente, 1, 2, 3 e, consequentemente,

números que representam
a soma dos dois anteriores.

É muito comum
no planning poker,

a partir do 20, você não ter mais
exatamente essa regra a risca,

como o 21, mas sim você ter escalas
maiores que representam os épicos.

Uma ponta muito importante disso tudo
é que esse baralho vai ser utilizado

por todas as pessoas do time e,
a cada tarefa que nós formos estimar

para definir o quanto de trabalho
vai caber no nosso sprint,

não mais no modelo anterior,

quando nós definíamos o quanto de tempo
nós demoraríamos para cada tarefa,

aqui, nós vamos discutir sobre os itens,
nós vamos apresentar ao mesmo tempo as cartas

e isso vai ser um norte para nós
definirmos o tamanho de cada tarefa,

o tamanho de cada história, o tamanho
da complexidade de cada tarefa.

Um ponto muito importante do porquê
que isso tem sido cada vez mais adotado

é porque, muitas vezes, no modelo
anterior, você tinha muita discordância,

uma pessoa mais sênior,
uma pessoa mais júnior

ou alguém que tinha mais
experiência naquele projeto,

entre outras pessoas
com menos experiência.

Aqui, independente de quem vai demorar
mais ou menos para compreender

e executar uma tarefa, ambos vão concordar
que uma tarefa é mais complexa que a outra.

Consequentemente, uma pode
ter uma pontuação 8 ou 5

em comparação a outra,
que teria a pontuação 1 ou 2.

É impressão minha ou nós estamos
em uma vibe meio jogo de tabuleiro,

onde nós aprendemos melhor
jogando do que lendo as regras?

É exatamente isso, André, e é exatamente
isso que nós vamos fazer agora.

Bom, para começar a nossa simulação,
é muito importante nós entendermos

o que aconteceu antes
de começar essa dinâmica

e quais são os papéis
que nós estamos simulando.

Aqui, somos o time que vai participar
da construção desse produto,

o time de desenvolvimento, se não
é desenvolvimento de sistemas,

porque o seu produto é
outro, é de documentação,

são as pessoas que vão escrever
a documentação, enfim,

são as pessoas que fazem parte
do time que está construindo.

Antes disso,
o que aconteceu na prática?

O nosso product owner, ou PO,
definiu qual é o escopo do projeto,

o que nós vamos fazer,
quais são as prioridades

e o que que nós vamos atacar primeiro,
e essas tarefas que são as prioridades

é o que nós vamos estimar aqui, pensando
no que nós vamos fazer no próximo sprint.

começando aqui, então, repassando
o nosso exemplo de escopo,

nós temos, aqui, um sistema
de locação de veículos.

Nesse sistema de locação de veículos
nós temos alguns módulos-chaves,

nós temos o cadastro de carros
para você vincular os carros à agência,

você tem o cadastro
de clientes que vão locar,

você tem toda a parte
de pedidos, atendimentos,

que é justamente para fazer
a reserva do carro, alugar o carro,

devolver e assim por diante, e você
tem outras funcionalidades internas,

sejam para processar o pagamento, sejam
para colocar o carro para manutenção,

sejam relatórios
para o acompanhamento gerencial.

E, dentro desse escopo, foi
priorizado pelo nosso cliente

que nós primeiro fizéssemos toda
a parte para já fazer a locação do carro,

porque a parte cadastral, para ele
já começar a utilizar alguma coisa,

já começar a operacionalizar, nós vamos
cadastrar diretamente no banco de dados

e ele já consegue ali fazer uma reserva
com aqueles clientes já pré-cadastrados

e os carros também
já cadastrados.

Dentro desse primeiro grupo, então,
eu gostaria de repassar com vocês aqui

quais são as histórias
que foram mais prioritárias.

Bom, o primeiro grupo, aqui, está
diretamente como eu mencionei,

ligado à operação
de locação de carro.

Então, nós temos
como primeira história aqui:

como atendimento, desejo reservar um carro
para locação, então só fiz a reserva,

depois eu vou retirá-lo e, na sequência,
nós temos o cancelamento dessa reserva.

Depois nós temos a locação
e a baixa do retorno da locação,

e nós temos as atividades de pagamentos
e, para fechar, o que seria o MVP,

o mínimo que ele precisa para colocar
para rodar a parte do relatório de vendas.

Então, com isso, nós temos
um mínimo para começar a operação

e aí, nos outros sprints, nós vamos
trabalhando mais funcionalidades

que vão ser atualizadas
nesse sistema,

cada vez dando mais autonomia
para o nosso cliente.

Bom, a primeira coisa que nós
precisamos fazer numa rodada,

lembrando que nós estamos
usando o planning poker

e consequentemente nós vamos buscar aqui
comparação de complexidade entre as tarefas,

a primeira coisa,
nós precisamos definir,

encontrar o que seria um item de menor
complexidade dentre essas funções.

Pantolfi, quando nós estamos
falando de complexidade,

nós estamos falando do quê?

Do tempo que nós demoramos a fazer
uma tarefa, do trabalho que vai me dar,

quanta dor de cabeça eu
vou ter para resolver aquilo?

O que nós estamos
buscando definir?

Essa é uma ótima pergunta, André,
porque existe uma confusão natural

pela forma como, historicamente,
nós sempre estimamos tarefas.

Então, nós sempre nos preocupamos
em quanto tempo eu gasto em uma tarefa.

Aqui, o tempo você já
tem pré-estabelecido,

você tem 2 semanas, que é o padrão,
mas você pode usar de 1 a 4 semanas,

mas você tem o tempo do seu sprint,
que é aquele tempo fixo que vai se repetir.

O que nós vamos buscar agora é o quanto
de pontos nós conseguimos fazer

dentro dessas duas semanas.

Então, isso praticamente
vai ser um exercício,

nós vamos primeiro estimar,
comparando essas complexidades,

nós tomamos muito como referência
listar todas as atividades

que nós temos para fazer,
se abdicando de tempo, por quê?

Se você tem uma referência
de gastar em uma tarefa duas horas

e, de repente, outra pessoa tem
a referência de gastar uma hora só,

nós não podemos ficar
encontrando o meio termo,

nós encontramos uma pontuação que caiba
para ambos e, juntos, a cada sprint,

nós vamos entendendo quantos
pontos estamos entregando

e, consequentemente, qual que é
o nosso índice de produtividade.

Legal.

E isso vai tornando mais fácil,
no segundo, terceiro, quarto sprint,

o que nós estimamos, nós já sabemos, de fato,
depois que estimou um grupo de tarefas,

quanto delas vão caber, de fato,
dentro do nosso sprint, legal?

Bom, a primeira tarefa,
aqui na nossa lista,

seria justamente a reserva
de um carro de locação,

e, nessa tarefa, para nós entregarmos
ela, por ela ser a primeira,

e onde nós vamos ter o trabalho
técnico de criar o projeto,

criar estrutura de banco de dados,
criar as primeiras telas,

fazer todas as comunicações
em todas as camadas.

Então, a primeira estruturação
é diretamente nessa função.

Na sequência, nós temos uma
que é o cancelamento da reserva,

e ela já aproveita toda essa estrutura
que nós construímos no anterior

e ela faz apenas a mudança de um estado,
que é, justamente, "carro reservado",

"carro sem reserva".

Podemos compreender,
neste momento,

que o "cancelar", para nós,
seria a nossa tarefa tamanho 1?

Acho que faz sentido, porque
não vai ter todo esse processo

de nós termos que pensar
no problema de novo.

Se aquilo que nós pensarmos
pela primeira vez na reserva

puder só ser invertido e desfeito,
estou dentro, pode ser o nosso 1.

Nós consideramos que, se o sistema
está bem arquiteturado,

você incluir funcionalidades
como cancelamento

não é uma tarefa trabalhosa, porque
trabalhoso é diferente de levar muito tempo,

então eu acho que nós
podemos considerar 1.

Legal, se nós, ao longo
da revisão das funcionalidades,

encontrarmos alguma que seja mais
simples, nós podemos, eventualmente,

trazer esse "cancelar reserva" para um 2
e trazer o 1 para outra funcionalidade

que seja mais simples.

E essa revisão acontece
com que frequência?

Na verdade, ao longo aqui da nossa reunião
de planejamento, nós vamos entender ela.

Pode ser que, nessa reunião,

nós descubramos que estimamos
alguma coisa com muito otimismo

- e outra com muito pessimismo.
- Acontece com muita frequência.

E normal e esse é
um ponto muito importante,

a estimativa não é um compromisso na pedra
que as pessoas devem morrer se não cumprirem.

Isso aqui é muito mais
um processo de aprendizado

em busca de uma velocidade de cruzeiro
do que propriamente um compromisso na pedra.

Eu costumo dizer, e é bem comum,
que os times demoram pelo menos 3 sprints

para entenderem, de fato,
a sua velocidade de cruzeiro,

quantos pontos, de fato,
cabem no sprint.

É muito comum o primeiro sprint
você estimar mais, entregar menos,

depois estimar menos que está inseguro,
entregar mais.

E aí vai encontrando aí o caminho conforme
você vai acumulando entregas.

Então vamos lá que eu estou louco
pra jogar esse negócio, voar.

Então,
voltando na nossa primeira história,

que é justamente reservar o carro
para locação,

então entendam que aqui eu estou criando
o projeto,

estou criando
a estrutura de banco de dados,

estou criando a primeira
estrutura de telas para fazer a reserva,

então vai ter lá
todas as informações do carro,

vai ter todo o vínculo diretamente
das informações do cliente,

tem o processamento
do pedido dessa reserva.

Então, essa primeira amarração,
essa primeira estruturação,

a gente vai ter que trabalhar para poder
entregar essa primeira história.

Então, dado esse cenário, dado essas
tarefas que nós temos para fazer,

vocês podem escolher uma

carta que vocês entendem, comparando aí
a complexidade com a tarefa de pontuação

número um.

Por favor.

A gente começa jogando para baixo.

Primeiro escondam as suas cartas.

Isso é muito importante.

A gente apresenta as cartas ao mesmo
tempo.

Por quê?

Para que uma opinião
não seja enviesada pela outra.

O mais importante é que o grupo
tenha o seu próprio entendimento.

Ah, mas tem uma pessoa que é mais júnior,
tem uma pessoa que é de fora

ou ela faz uma tarefa mais de negócio
ou uma tarefa mais separada.

Não tem problema.

O exercício é justamente pra gente buscar
cada vez mais esse time, sincronizar.

Então, exercitando a gente
vai cada vez mais entendendo

a pontuação e a complexidade para o time,
e não uma complexidade apenas para mim.

Tá bom.

Então eu vou contar três, dois,
um Ao final, todos apresentam a carta

que selecionou de pontuação
para essa história toda nervosa.

Todos prontos.

Eu quero ver quem vocês estão indo comigo.

Vamos lá.

Todos prontos. Pronto. Três, dois, um.

Então vamos lá.

Temos um 13, um cinco um oito um
um outro 13.

Legal!

Neste momento nós temos uma divergência
natural, especialmente quando a gente está

se acostumando e entendendo
como esse tipo de dinâmica funciona.

O ideal, nesse momento
é cada um colocar o seu entendimento.

Por que acha que de repente
tem uma pontuação menor ou maior

e a partir daí a gente repassa
todo esse entendimento e vota novamente.

Tudo bem?

Então vamos lá.

André, quer explicar
por que você entende que foi oito?

Olha, eu coloquei um oito,
porque eu entendi que é uma tarefa

relativamente complexa,
que eu vou demorar um tempo nela.

Por mais que a gente tenha a nossa base
e que não seja o tempo seja esforço,

que eu vou demorar um tempo nela,
Não acho que é o pior sistema que eu teria

que desenvolver em termos de dificuldade,
mas me daria um bom trabalho.

Por isso que eu escolhi o oito Legal.

Bom, eu escolhi

cinco porque acho que é um sistema
que a gente talvez já consiga aproveitar

de outros projetos anteriores
por conta de.

Apesar da simplicidade, ele nos dá
da novidade de juntar isso tudo.

Talvez sejam funcionalidades
que já tenham sido desenvolvidas antes.

Legal cada final.

13 Eu vou defender o 13
porque apesar da gente

conseguir sempre aproveitar
coisas anteriores de projetos anteriores,

eu julgo pelos requisitos que a gente
precisa desenvolver, que esse projeto

ele tem muitas especificidades
e essas especificidades podem acabar

tomando muito mais trabalho
do que a gente inicialmente imagina.

Então vou defender o 13 também
pelo estágio que nós estamos do projeto.

Então lá para frente
talvez pudesse chamar um pouco menos.

Mas nesse estágio do projeto,
nesse estágio do time,

eu jogo melhor o 13 legal.

E eu vou aproveitar
um pouco dos argumentos justamente

para entrar no mérito.

Sim, acho que teria muitas adaptações
dos projetos anteriores pra gente

fazer aqui,
então acho que isso pode criar mais risco

para a gente do que a gente de fato
criar do zero.

E além da complexidade das tarefas
que a gente tem para fazer

nesse primeiro momento, a gente
já tem que pensar um pouco na arquitetura.

Então, por esse elemento,
eu entrei também com o 13.

Mas o que acontece
agora que eu coloquei meu oito?

A Laura colocou cinco dela
e vocês plantou e colocaram 13.

Como que a gente chega num consenso?

Sempre sai da mesma forma.

Eu espero tomar conta do negócio aqui.

Percebam que mais do que simplesmente
votar e achar um número,

estamos sincronizando o entendimento
de cada pessoa

sobre o que precisa ser feito
para construir algo.

A ideia é independente
de quem seja a pessoa aqui nesse grupo

que vai trabalhar naquilo, todos tem
o mesmo entendimento do que deve ser feito

e junto com outras dinâmicas
a gente vai buscar

para que não tenha duas pessoas
fazendo a mesma coisa ao mesmo tempo

e que tudo que um faça complemente
o trabalho do outro e assim por diante.

Mas aqui o mais importante é a gente casar
os entendimentos

e cada vez mais
evoluir a percepção da complexidade.

Então, dado esse cenário que a gente
já percorreu todos os argumentos,

agora a gente volta novamente para ver
se todo mundo chegou na mesma conclusão.

A gente não vai obrigar a combinar
quem a gente vai.

Votar de volta, não vai.

Tem uma pergunta, pois não?

Essas conversas de discussão,
algumas metodologias ágeis

sempre pregam que você precisa
ter um tempo pré estabelecido.

Cinco, dez Essa discussão que a gente teve
aqui, ela não tem um tempo determinado.

Eu acho que essa parte muito interessante,
pensando em tempo para essa dinâmica,

se ela estaria dentro da planning,
então a plena em hoje, segundo o manual,

ela tem um percentual ali,
vai pensando num sprint de duas semanas,

o percentual dela
seria equivalente a uma reunião de 04h00.

Então essas 04h00 seria desde o momento

em que o pessoal apresentou pra gente
as prioridades, a regra de negócio

e tudo o que vai ser feito,
até a gente de fato fazer as estimativas.

Mas óbvio que cada time, no seu contexto,
na sua empresa, vai entendendo o

quanto tempo precisa.

E óbvio, no começo vai demorar
um pouco mais de tempo e depois

isso vai ficando cada vez mais natural
conforme vá exercitando.

Tá bom, então vou pedir para que vocês,
dado agora todos os argumentos,

separem novamente uma carta
que representa o valor que vocês imaginam.

E no três, dois, um
a gente mostra todos ao mesmo tempo,

todos prontos,
todos para um, três, dois, um.

Agora temos uma unanimidade.

Foi perfeito!

Olha, eu confesso

que na hora que vocês mostraram três
eu fiquei meio pressionado a concordar,

mas o fato depois da discussão,
depois da argumentação,

deu pra entender o que vocês estavam
trazendo de ponto de vista

e fez mais sentido ir para o 13 do que
porque eu tinha estimado antes.

Legal, Então já temos a primeira história,

que é a história de reservar o carro
para locação com a pontuação 13.

A segunda história,
que é o cancelamento da reserva

que a gente estabeleceu
a história de menor complexidade.

Pontuação um.

Agora vamos pra uma outra história,

que é justamente a história de dar baixa
no retorno

de uma locação do carro
devolvido pelo cliente, né?

Bom, nesse caso aqui, essa funcionalidade.

Basicamente quando o cliente traz o carro,
eu tenho que identificar

que ele está locado para aquele cliente
que está sendo devolvido

dentro do prazo estabelecido,
que está tudo certinho, processar

a devolução e dar

baixa para liberar esse carro
para uma nova locação.

Ele não necessariamente
ele envolve o processo de pagamento ainda.

Isso é uma outra funcionalidade,
mas aqui ele atualiza o status do carro

para liberar ele propriamente dito
para poder ser locado por outro cliente.

Tudo bem, até aqui tudo bem.

Bom, vamos lá pessoal,
Todos prontos para votar?

Então escondam suas cartas, Definam
então a carta que representa a pontuação

da história que nós estamos votando, que
é para dar baixa na devolução do carro.

Todos prontos. Prontos?

Íssimo três dois um.

Então temos um dois um, três,
um 08h01 cinco.

Vamos lá.

Começamos pelo mais.

Alto mais uma vez
e estamos discordando aqui.

Eu considerei o oito porque eu julgo

que é uma tarefa de menor complexidade
que aquela que a gente acabou de votar.

Eu acho que tem uma boa complexidade
envolvida.

Aí dá um trabalho.

São várias tabelas, várias,
vários dados para cruzar.

Então eu estou confortável com meu. Site,
que está confuso ainda.

Talvez tudo o que precisar fazer pra duas.

Pessoas,

muitas etapas, parece que é uma tarefa
que tá escondendo várias por trás dela.

Tá bom.

Eu acho.

Eu coloquei cinco, eu mostrei as cinco,
porque eu entendo que

se a gente tem uma tarefa
um que é, por exemplo, um cancelamento

como o que a gente definiu, essa
talvez seja um pouco mais complexa.

A medida em que a gente vai incluir
algumas coisas, mas não é tão complexa

que uma equipe um pouco mais experiente
não consiga executar.

Legal, boa.

Temos um três.

Como vocês já já adiantaram,
ela envolve algumas coisas que já

a gente já definiu como uma,
que é o cancelamento.

E eu acho que a gente está pensando
em MVP,

Então a gente vai definir apenas o que é
necessário, estritamente necessário

nesse momento
para se fazer o fluxo de devolução

do carro e de liberação
do carro e do cliente para pagamento.

Então acho que a gente consegue colocar,
por exemplo, de um ou três vezes isso, né?

Então acho que o três aqui cabe.

Bem, seguindo aquela mesma lógica
do que a gente fez lá de um de lá,

é só trocar o que precisa de estado
para dizer que a pessoa devolveu.

Isso.

A gente vai acrescentar algumas coisas,
mas eu nesse momento,

olhando os requisitos,

eu julgo que os adicionais
eles a gente consegue manter isso no

grau três, por exemplo.

Bom, interessante o argumento de vocês,

porque de fato, a estrutura principal
que a gente precisa para poder dar baixa

é o que a gente já vai ter construído
na parte de reserva.

É até por isso que eu acabei
escolhendo dois,

porque ao meu entendimento,
obviamente tem mais complexidade aqui

do que o cancelamento da reserva,
porque eu não estou atualizando um estado

apenas do carro.

Eu estou desbloqueando o carro
para ser locado novamente,

eu estou desbloqueando o cliente
para ele poder locar um outro carro.

Então de fato

eu entendo que dá para se preocupar,

talvez com alguma dor a mais aí,

mas eu entendo que talvez não.

Uma complexidade tão alta,
tão próxima do nosso 13.

Vamos voltar novamente. Com
a regra do jogo.

Vamos lá.

Dado esses novos argumentos
do nosso novo entendimento, por favor,

cada um selecione
a sua carta de pontuação,

deixando ela escondida e

todos prontos.

Prontíssima agora mais do que.

Nunca. Três.

Dois um

Boa, Temos uma unanimidade.

Então todo mundo votou.

Três Mais uma vez
fui obrigado a mudar a minha concepção,

mas vocês estão trazendo argumentos
que me convencem de que eu posso fazer.

Eu quero aqui

que vou.

Bom, a próxima história
que a gente tem aqui para estimar

é justamente que a história de processar
o pagamento da locação,

nesse caso,
a gente já vai ter toda a estrutura

que gera o pedido de pagamento,
que é toda a devolução da reserva.

O que a gente está fazendo aqui
e integrando

com todo o parceiro de pagamento
todo esse processo e disponibilizando ali

a parte do checkout para o cliente
eventualmente

decidir se ele quer pagar
por cartão de crédito ou outras opções.

Lembrando que essa estrutura de checkout
ela já vem do nosso parceiro de pagamento,

o que a gente faz?

Essa integração vinculando aí
com a nossa estrutura de pedidos?

É um parceiro
com qual a gente já trabalhou antes?

A gente tem esse detalhe, essa informação.

Se a gente já trabalhou
com esse tipo de pagamento.

E a gente já trabalhou,
só que mais do que isso, são parceiros

que seguem todos o mesmo padrão legal.

Então toda a especificação
a gente consegue compartilhar

aqui para a gente já ter uma ideia

como que vai ser a integração
e assim por diante. Tá bom?

Ok, Então, relembrando, estamos aqui

estimando a tarefa de processar
o pagamento da locação.

Por favor, selecionem as cartas,

a carta que representa
ou a pontuação que vocês escolheram.

Todos prontos.

Muito nervosa. Vamos lá em.

Três, dois, um.

Golaço.

Olha, temos nossa primeira unanimidade.

Podemos ir pra casa.

É assim que se encerra uma reunião.

Quando tá todo mundo concorda.

Eu acho que faz sentido
isso aqui, de acordo com que vocês falaram

que a gente está trabalhando com padrões
e diante das tarefas

todas que a gente tem que fazer,
acho que ela fica meio

que no meio do caminho,
das outras coisas que a gente estimou.

Eu acho que o entendimento vai
aprofundando, fica.

Mais fácil sim.

É o que eu acho importante aqui.

Parceiro e pagamento
são duas palavras importantes para a gente

se atentar nessa tarefa.

Primeiro que a gente vai ter que fazer

integrações externas,
por mais que já tenha trabalhado casa

cada casa sempre um caso e pagamento,
que é um ponto crítico na aplicação.

Agora, o que vale a pena ser conservadora
nesse caso?

Eu estou com a pulga atrás da orelha,

porque o que eu falei
eu estou descobrindo o Planning Poker

aqui com vocês e eu quero entender
o que esses pontos todos

que a gente está colocando
representam até agora,

porque tudo bem a gente
estimular o esforço de cada tarefa,

mas eu me perguntei no começo

a gente tinha um limite, um teto,
como funciona essa pontuação?

Muito bom, André.

Então,
para a gente exemplificar um pouco melhor

o que a gente vai ter no final aqui,
a cada rodada que a gente está fazendo,

a gente está associando uma pontuação
para cada uma das nossas tarefas.

No final,

a gente tem uma lista,
cada um com uma pontuação que vai ter

uma somatória e gera uma pontuação final,
considerando tudo o que a gente estimou,

até o nosso MVP,
a gente tem aqui cerca de 41 pontos,

mas a gente define o que a gente entende

desse grupo que cabe a gente
trabalhar dentro do nosso sprint.

Assumindo que o nosso sprint tem
duas semanas, a gente define aqui

uma quantidade de pontos
que nesse primeiro momento

é muito mais um norte,
uma percepção inicial.

E a gente vai entender ao longo do caminho
se esses 20 pontos se confirmam ou não.

Então, numa simulação
até que a gente fez aqui diretamente

com essa pontuação,
a gente teve ali um primeiro sprint,

que a gente estimou 20 pontos
e a gente entregou o total de 22 pontos,

ou seja, um conjunto de tarefas
que, somando a sua pontuação, chegou a 22.

Pô, legal.

Então a gente tem capacidade
de entregar mais do que os 20.

Enfim, a vamos nos planejar no segundo
sprint pra entregar 25 pontos.

Aí acontece essa dinâmica toda de novo.

Acontece essa dinâmica toda de novo.

Próximas funcionalidades
começa a construir.

No final do segundo sprint a gente
não entregou aqueles mesmos 22 pontos.

Entregamos 19
porque alguma tarefa foi mais complexa.

A gente teve mais dificuldade.

Então a gente, nesse segundo sprint,
planejamos 25, entregamos só 19.

Opa, então talvez o 25
foi muito agressivo.

Vamos puxar novamente pra 20.

E aí no terceiro sprint o time já evoluiu,
tudo já está mais natural,

as estruturas estão melhor
pré estabelecidas

e a gente entregou
um conjunto de 26 pontos.

Então você começa a entender ali
pelo seu histórico.

22, 19, 26,
que a sua tendência ali está de fato,

entre 20 e 25 pontos ali,
no momento seguro.

Mas nada impede, obviamente,
que a produtividade desse time cresça

conforme a maturidade aumenta.

E aí mais três sprints, dois Sprint.

Você já vai entendendo que de repente
o time já tem um índice de produtividade

de 25 pontos e assim, gradativamente.

E o que é muito interessante disso,
Como a gente reforçou desde o começo,

a ideia não é mais definir
quanto tempo para cada tarefa,

mas o quanto de tarefa cabe no nosso tempo
fixo, que é o nosso time box.

Eu gostei desse negócio,
eu acho que é uma ferramenta bem legal,

só que o nerd de dentro de mim

ele me obriga a fazer duas perguntas
separadas, principalmente para vocês dois.

Estão aí na ponta da mesa,
a primeira e existem outros baralhos,

desde que eu possa comprar, porque eu
já quero comprar isso, levar, guardar,

usar de montão.

Pode vir uma carta,

eu posso ver uma carta que eu já me animo
e outra coisa que está na minha cabeça,

a Ju, por exemplo, que a desenvolvedora
trabalha remoto e muita gente

está começando já a ingressar na carreira,
trabalhando remoto.

Vou mandar por correio pra galera
aqui que dá pra coisa.

Eu como jogadora de med, que eu
vejo muitas possibilidades pro cara,

mas depois

ele pode inclusive contar a história
desse baralho específico.

Esse baralho ele vai,
ele tem a sequência que a gente mostrou,

ele vai até três no Fibonacci,
depois 20, 40 e 100.

Existem outras

cartas, por exemplo, a carta do cafezinho,
porque dependendo do tamanho da Sprint,

a reunião de planning pode ficar grande,
extensa e complexa.

Aí a gente pede o cafezinho.

Bem, se você tem alguma, por exemplo,
alguma dúvida em alguma,

algum requisito
e está em dúvida na votação,

tem a carta da interrogação,
por exemplo, tem a carta do infinito.

Eu não faço ideia, eu coloco a referência
ali, a gente vai discutir.

E existem os baralhos fixos.

Porém, como você mesmo disse,
muita gente hoje em dia trabalha remoto.

Então existem vários, vários EPs
e vários sites que as equipes remotas

normalmente usam pra fazer essa votação
aí de forma a de forma remota.

Tudo num browser assim não faltam opções.

Mas o importante é entender a mecânica,

porque a mecânica vai ser sempre a mesma,
com carta de cafezinho ou não.

E agora eu já quero os dois,
eu quero o físico e quero esse virtual.

É aquela coisa de cafezinho,

é isso que eu quero, principalmente mais
antes da gente ir pro nosso cafezinho

encerrar esse vídeo, conta pra gente
a história desse baralho aqui.

Eu consigo igual a esse.

Que história é essa?

Não, na verdade não
tem exatamente uma história

que a brincadeira é justamente
porque esse foi o primeiro de todos, né?

Então não tinha o cafezinho, não tinha
um meio, não tinha dúvida, não tinha

porque a ideia era simplesmente trazer
uma referência matemática

para que as pessoas não ficassem
discutindo a vírgula.

Isso aqui é dois e-mail,
Isso aqui é quatro.

Não, cara, ou tá pra cima ou para baixo.

Na dúvida, ali.

Conservadorismo tá pra cima, mas são taxas
fixas que vão ajudando cada vez mais

no conceito comparativo e cada vez mais
a sincronizar entendimentos.

Perceba que muito mais reforçando,
é muito mais do que só definir pontos,

é o quanto esse time tá

aprendendo a mesma coisa juntos, né?

E muitas vezes mesmo a pessoa mais sênior
que eventualmente traz uma explicação

muito cara clara sobre uma funcionalidade,
às vezes ela não entende.

Não tinha na cabeça dela
o seu ponto de vista,

o seu ponto de vista, o seu.

E essa troca é que vai gerando a riqueza
do entendimento da estimativa do time.

Então eu trago aqui
um assunto novo pra mesa.

Ju, Pandolfi, Laura e eu

vamos tomar um cafezinho e depois a gente
volta pra continuar planejando.

O que acha disso?