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. Quanto ao fundo, está falando de complexidade. A gente está falando do kit do tempo, que a gente demora fazer uma tarefa do trabalho que vai me dar. Quanta dor de cabeça eu vou ter para resolver aquilo que a gente está buscando definir? Essa é uma ótima pergunta, André, porque existe uma confusão natural pela forma como historicamente a gente sempre estimou tarefas. Então a gente sempre se preocupou em quanto tempo eu gasto numa tarefa. Aqui o tempo você já tem pré estabelecidos, você tem duas 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 a gente vai buscar agora é o quanto de pontos a gente consegue fazer dentro dessas duas semanas. Então isso praticamente vai ser um exercício. Nós vamos primeiro estimar, comparando essas complexidades, a gente toma muito como referência listar todas as atividades que a gente tem para fazer, se abdicando de tempo, Porque se você tem uma referência de gastar numa tarefa duas horas e de repente outra pessoa tem a referência de gastar 01h00 só, a gente não pode ficar encontrando meio termo. A gente encontra uma pontuação que caiba para ambos e juntos, a cada sprint, a gente vai 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 a gente estima a gente já sabe de fato, depois que estimar um grupo de tarefas, quanto delas vão caber de fato dentro do nosso esplêndido. Legal! Bom, a primeira tarefa aqui na nossa lista seria justamente a reserva de o carro de locação. E nessa tarefa para a gente entregar ela por ela ser a primeira e onde a gente vai ter o trabalho técnico de criar o projeto, criar estrutura de banco de dados, criar as primeiras telas, fazer todas as comunicações aí, em todas as camadas. Então, a primeira estruturação é diretamente nessa função. Na sequência, a gente tem uma, que é o cancelamento da reserva, que ela já aproveita. Toda essa estrutura que a gente construiu 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 a gente seria a nossa tarefa tamanho um. Acho que faz sentido, porque esse não vai ter todo esse processo de a gente tem que pensar no problema de novo. Se aquilo que a gente pensar pela primeira vez na reserva pudesse ser invertido e desfeito, tô dentro. Legal. A gente considera que se o sistema ele está bem, arquitetura de você Incluir funcionalidades como cancelamento não é uma tarefa trabalhosa, que é trabalhosa. Diferente de ele leva muito tempo. Então acho que a gente pode considerar. Legal se a gente, ao longo da revisão das funcionalidades, encontrarmos alguma que seja mais simples. A gente pode eventualmente trazer. Se cancelar reserva por um, dois e trazer o um para outra funcionalidade que seja mais sim, tá bom. E essa revisão acontece com frequência. Na verdade, ao longo aqui da nossa reunião de planejamento a gente vai entender ela. Pode ser que nessa reunião a gente descubra que estimamos alguma coisa com muito otimismo e outra com muito. Acontece com muita. Frequência. É normal. E esse é um ponto muito importante a estimativa. Ela não é um compromisso na pedra que as pessoas devem morrer. Se elas 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 -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?