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 em 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 em uma 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,
é 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,
em que ela já aproveita toda essa estrutura que nós construímos no anterior
e 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?
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 teriam 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, por que?
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?
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á.