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 que 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 à 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 arquitetado,

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, no primeiro sprint,
você estimar mais e entregar menos,

depois estimar menos, porque
está inseguro, e entregar mais.

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

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

Boa!

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,

nós vamos 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 1.

Por favor.

Nós começamos
jogando para baixo?

Primeiro escondam as suas
cartas, isso é muito importante,

nós apresentamos 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 para nós buscarmos,
cada vez mais, esse time se sincronizar.

Então, exercitando nós vamos cada
vez mais entendendo a pontuação

e a complexidade para o time, e não
uma complexidade apenas para mim, está bom?

Então, eu vou contar "3, 2, 1",
ao final, todos apresentam a carta

que selecionaram de pontuação
para essa história.

- Estou nervosa.
- Todos prontos?

Eu quero ver aqui se vocês estão
indo comigo, vamos lá em.

- Todos prontos?
- Pronto.

3... 2... 1!

Então vamos lá, temos um 13,
um 5, um 8, um outro 13, legal.

Neste momento nós temos
uma divergência natural,

especialmente quando nós
estamos nos 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í, nós repassamos todo esse
entendimento e votamos novamente.

Tudo bem?

Então vamos lá.

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

Olha, eu coloquei um 8, porque eu entendi
que é uma tarefa relativamente complexa,

que eu vou demorar um tempo nela,
por mais que nós tenhamos a nossa base

que não seja o tempo, seja esforço,
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 8.

Legal.

Bom, eu escolhi o 5 porque
acho que é um sistema

que nós talvez já consigamos aproveitar
de outros projetos anteriores

por conta de, apesar da simplicidade e, vamos
dizer assim, da novidade de juntar isso tudo,

talvez sejam funcionalidades que já
tenham sido desenvolvidas antes.

Legal, quer defender o 13?

É, eu vou defender o 13, porque, apesar
de nós conseguirmos sempre aproveitar

coisas anteriores,
de projetos anteriores,

eu julgo, pelos requisitos que nós
precisamos desenvolver,

que esse projeto tem
muitas especificidades

e essas especificidades podem
acabar tomando muito mais trabalho

do que nós, inicialmente, imaginamos,
então eu vou defender o 13,

e, também, pelo estágio
que nós estamos do projeto.

Então, lá para frente, talvez,
pudesse estimar um pouco menos,

mas, nesse estágio do projeto e nesse
estágio do time, eu julgo 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

para nós fazermos aqui, então acho
que isso pode criar mais risco

para nós do que nós,
de fato, criarmos do zero

e , além da complexidade das tarefas
que nós temos para fazer,

nesse primeiro momento, nós já temos
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 8,

a Laura colocou o 5 dela e vocês,
Ju e Pantolfi, colocaram 13?

Como que nós chegamos
em um consenso?

- Nós saímos da pista.
- Vamos embora!

Eles querem 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, nós vamos
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 é
nós casarmos os entendimentos

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

Então, dado esse cenário em que nós
já percorremos todos os argumentos,

agora nós voltamos novamente para ver se todo
mundo chegou na mesma conclusão ou não.

Ah, nós não vamos brigar, combinar aqui
em aberto, nós vamos ter que votar de novo.

- Nós votamos novamente.
- Eu tenho uma pergunta antes.

Pois não?

Essas conversas de discussão, algumas
metodologias ágeis sempre pregam

que você precisa ter um tempo
pré-estabelecido, 5, 10.

Essa discussão que nós tivemos aqui,
ela não tem o tempo determinado?

Eu acho que essa é a parte
muito interessante.

Pensando em tempo para essa dinâmica,
ela estaria dentro da planning,

então a planning hoje, segundo
o manual, tem um percentual ali,

pensando em um sprint
de duas semanas,

o percentual dela seria equivalente
a uma reunião de 4 horas.

Então, essas 4 horas seriam desde o momento
em que o PO apresentou para nós as prioridades,

a regra de negócio e tudo o que vai ser feito,
até nós, de fato, fazermos as estimativas.

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

vai entendendo 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 vai exercitando.

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 3, 2, 1, nós mostramos
todos ao mesmo tempo.

- Todos prontos?
- Todos prontos.

3... 2... 1...

Agora temos uma unanimidade.

- Fui convencida.
- Perfeito!

Olha, eu confesso que, na hora
que vocês mostraram 13,

eu fiquei meio pressionado
a concordar,

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

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

e fez mais sentido ir para o 13 do que
para o que 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 nós estabelecemos como a história
de menor complexidade, pontuação 1.

Agora, vamos
para uma outra história,

que é justamente a história de dar
baixa no retorno de uma locação

do carro devolvido
pelo cliente.

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 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?
- Prontíssimo.

3... 2... 1...

Então, temos um 2,
um 3, um 8 e um 5.

Vamos lá, começamos
pelo mais alto.

Mais uma vez já estamos
discordando aqui, não é?

Eu considerei um 8 porque eu julgo que é
uma tarefa de menor complexidade

do que aquela que nós
acabamos de votar,

eu acho que tem uma boa complexidade
envolvida, aí dá um trabalho,

são várias tabelas, vários dados para cruzar,
então eu estou confortável com o meu 8.

Você acha que está
confuso ainda, talvez,

- tudo o que precisa fazer para dar baixa?
- Eu acho que são muitas etapas,

parece que é uma tarefa que está
escondendo várias por trás dela.

Está bom.

Eu acho, eu coloquei o 5,
eu mostrei o 5,

porque eu entendo que se
nós temos uma tarefa 1

que é, por exemplo, um cancelamento,
como o que nós definimos,

essa talvez seja
um pouco mais complexa,

na medida em que nós
vamos incluir algumas coisas,

mas não é tão complexa que uma equipe
um pouco mais experiente não consiga executar.

Legal, boa.

- Temos um 3.
- Uhum.

É, como vocês já adiantaram, ela envolve
algumas coisas que nós já definimos como 1,

que é o cancelamento, e eu acho que,
se nós estamos pensando em MVP,

então nós vamos 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 nós conseguimos colocar,
por exemplo, de 1 ou 3 vezes isso,

eu acho que o 3
aqui cabe bem.

Seguindo aquela mesma lógica
do que nós fizemos na de 1,

de ir lá e só trocar o que precisa de estado
para dizer que a pessoa devolveu.

Isso, nós vamos acrescentar
algumas coisas,

mas eu, nesse momento,
olhando os requisitos,

julgo que, os adicionais, nós conseguimos
manter em um grau 3, por exemplo.

Bom, interessante o argumento
de vocês, porque, de fato,

a estrutura principal que nós
precisamos para poder dar baixa

é o que nós já vamos ter
construído na parte de reserva.

E até por isso que eu acabei escolhendo
o 2, 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,

e 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 votar novamente?

Bom, é a regra
do jogo, vamos lá.

Dado esses novos argumentos,
o nosso novo entendimento,

por favor, cada um selecione a sua carta
de pontuação, deixando ela escondida.

Todos prontos?

Prontíssimo, agora
mais do que nunca.

3... 2... 1....

Boa, temos uma unanimidade,
então, todo mundo votou 3.

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

mas vocês estão trazendo argumentos
que me convencem, o que eu posso fazer?

-Ah, que bom.
- Eu não quero aqui, não é?

Que bom.

Bom, a próxima história que nós
temos aqui para estimar

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

Nesse caso, nós já vamos ter toda
a estrutura que gera o pedido de pagamento,

que é toda a devolução da reserva.

O que nós estamos fazendo aqui é 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 com cartão de crédito

ou outras opções.

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

o que nós fazemos é essa integração,
vinculando com a nossa estrutura de pedidos.

É um parceiro com qual
nós já trabalhamos antes?

Nós temos esse detalhe,
essa informação,

se nós já trabalhamos com esse
tipo de pagamento?

Nós já trabalhamos,
só que, mais do que isso,

são parceiros que seguem todos
o mesmo padrão no mercado.

Então, toda a especificação nós
conseguimos compartilhar aqui,

para nós já termos uma ideia de como vai
ser a integração e assim por diante.

Está bom.

Então, relembrando, estamos aqui estimando
a tarefa de processar o pagamento da locação.

Por favor, selecionem a carta que representa
a pontuação que vocês escolheram.

- Todos prontos?
- Estou nervosa.

- Continuo nervosa.
- Vamos lá em.

3... 2... 1...

Golaço.

- Olha que beleza!
- Temos nossa primeira unanimidade.

- Acertei!
- Já podemos ir para casa.

É assim que se encerra uma reunião,
quando está todo mundo concordando.

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

que nós estamos
trabalhando com padrões

e, diante das tarefas todas
que nós temos que fazer,

acho que ela fica meio que no meio do caminho
das outras coisas que nós estimamos.

Acho que o entendimento vai
aprofundando e fica mais fácil.

Sim, e o que eu acho importante
aqui é parceiro e pagamento,

são duas palavras importantes para nós
nos atentarmos nessa tarefa.

Primeiro, porque nós vamos ter
que fazer integrações externas,

por mais que já tenha trabalhado,
cada caso é sempre um caso,

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

Acho 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 nós estamos colocando

representam até agora, porque, tudo bem,
nós estimamos lá o esforço de cada tarefa,

mas eu não me perguntei no começo
se nós tínhamos um limite, um teto,

como que funciona
essa pontuação?

Muito bom, André.

Então, para nós exemplificarmos
um pouco melhor,

o que nós vamos ter no final aqui,
a cada rodada que nós estamos fazendo,

nós estamos associando uma pontuação
para cada uma das nossas tarefas.

No final, nós temos uma lista,
cada um com uma pontuação,

que vai ter uma somatória
e gera uma pontuação final.

Considerando tudo
o que nós estimamos,

até o nosso MVP, nós temos
aqui cerca de 41 pontos,

mas nós definimos o que nós
entendemos desse grupo

o que cabe nós trabalharmos
dentro do nosso sprint.

Assumindo que o nosso
sprint tem duas semanas,

nós definimos aqui uma quantidade
de pontos que, nesse primeiro momento,

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

e nós vamos entender, ao longo do caminho,
se esses 20 pontos se confirmam ou não.

Então, em uma simulação que nós até fizemos
aqui diretamente com essa pontuação,

nós tivemos ali um primeiro sprint
em que nós estimamos 20 pontos,

e nós entregamos
o total de 22 pontos,

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

Pô, legal, então nós temos capacidade
de entregar mais do que os 20, enfim.

Ah, vamos nos planejar no segundo
sprint para 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, nós não
entregamos aqueles mesmos 22 pontos,

entregamos 19, porque alguma tarefa foi
mais complexa, nós tivemos mais dificuldade,

então nós, nesse segundo sprint,
planejamos 25 e entregamos só 19.

Opa, então talvez o 25 foi muito agressivo,
vamos puxar novamente para 20.

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

as estruturas estão melhor pré-estabelecidas
e nós entregamos 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 está, de fato, entre
20 e 25 pontos, em um momento seguro,

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

conforme a maturidade aumenta
e, aí, mais três sprints, dois sprints,

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 nisso?

Como nós reforçamos
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 me obriga
a fazer duas perguntas separadas,

principalmente para vocês dois
que estão aí na ponta da mesa.

A primeira é: existem outros baralhos
desse que eu possa comprar?

Porque eu já quero comprar,
sleevar, guardar, usar de montão.

Não pode ver uma carta.

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

a Ju, por exemplo, que é
desenvolvedora, trabalha remoto

e muita gente está começando já a ingressar
na carreira trabalhando remoto.

Vou mandar por correio
para a galera, o que dá para fazer?

Eu como jogadora de Magic vejo
muitas possibilidades em cartinhas,

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

Esse baralho tem a sequência
que nós mostramos,

ele vai até 3 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, complexa, aí nós
pedimos o cafezinho.

Tem, se você tem, por exemplo,
alguma dúvida em 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",
coloco o infinito ali e nós vamos discutir.

E existem os baralhos fixos,
porém, como você mesmo disse,

muita gente, hoje em dia, trabalha remoto,
então existem vários apps e vários sites

que as equipes remotas normalmente usam
para fazer essa votação de forma remota,

tudo em um 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.

E a carta de cafezinho.

É isso que eu quero principalmente, mas
antes de nós irmos para o nosso cafezinho

e encerrar esse vídeo, conta para nós 
a história desse baralho aqui.

Eu consigo um igual a esse?
Que história é essa?

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

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

então não tinha o cafezinho,
não tinha o meio, não tinha a dúvida,

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

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

"ah, isso aqui é 2,5, isso aqui é 4", não,
cara, ou está para cima ou está para baixo.

Na dúvida, conservadorismo,
está para 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, reforçando, muito
mais do que só definir pontos,

é o quanto esse time está
aprendendo a mesma coisa juntos.

E, muitas vezes, mesmo uma pessoa
mais sênior que, eventualmente,

traz uma explicação muito clara
sobre uma funcionalidade,

às vezes ela 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 para a mesa.

Ju, Pantolfi, Laura e eu
vamos tomar um cafezinho

e depois nós voltamos
para continuar planejando.

- Que tal?
- Fechadíssimo.

Vamos lá.