-
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.
-
Essa Lara Gurgel, essa rede,
a experiência do cliente, nossa face
-
e também professora da FIAP.
-
E assim como o André, vou descobrir
que diabos seria rede em qualquer.
-
Eu sou João Mazzei, eu sou desenvolvedora
back end e instrutora de programação.
-
E aí eu vou ajudar a esclarecer
o que é o pleno e pra que ele é usado.
-
Eu acho que a gente pode partir daí,
vocês contarem pra gente o que que é.
-
Espere um pouco
e por que a gente tá com monte de carta
-
na mão
e principalmente, pra que ele serve?
-
Legal.
-
Bom, antes de tudo,
é importante a gente entender
-
a dinâmica de estimativas, o que ela
segue, 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, eles tinham um padrão
tabelas que muitas vezes não respeitavam
-
a produtividade real de cada personagem
do time com player em poker.
-
Isso mudou um pouco e isso respeita muito
mais, inclusive estimado
-
pelo próprio time que vai construir
o produto ou playing poker.
-
Assim como está na mesa ele é.
-
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 a gente vê numa escala
-
crescente, um, dois, três 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.
-
Há uma ponta muito importante disso
tudo é esse baralho.
-
Ele vai ser utilizado
por todas as pessoas do time
-
e a cada tarefa que a gente for estimar
para definir o quanto de trabalho
-
vai caber no nosso sprint,
não mais no modelo anterior,
-
quando definir o quanto de tempo
a gente demoraria para cada tarefa.
-
Aqui a gente vai discutir sobre os itens,
-
a gente vai apresentar ao mesmo tempo
as cartas e isso vai ser o norte para
-
a gente definir o tamanho de cada tarefa,
o tamanho de cada história,
-
o tamanho da complexidade de cada tarefa.
-
Um ponto muito importante por que isso
tem sido cada vez mais adotado?
-
E 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 oito ou cinco
-
em comparação
a outra, que teria a pontuação um ou dois.
-
É impressão minha ou a gente
está numa vibe meio jogo de tabuleiro,
-
onde a gente aprende melhor
jogando do que lendo as regras?
-
É exatamente isso, André.
-
É exatamente isso que a gente vai fazer
agora.
-
Bom, para começar a nossa simulação,
é muito importante
-
a gente entender 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 é
outra 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 pior,
ele definiu qual que é o escopo
-
do projeto, o que a gente vai fazer,
quais são as prioridades
-
e o que que a gente vai atacar primeiro
e essas tarefas que são as prioridades
-
e o que a gente vai estimar aqui,
-
pensando no que a gente vai fazer
no próximo sprint, começando aqui.
-
Então,
repassando o nosso exemplo de escopo,
-
a gente tem aqui
um sistema de locação de veículos.
-
Nesse sistema de locação de veículos
a gente tem alguns módulos chaves,
-
a gente tem o cadastro de carros
para você vincular os carros, a 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, seja relatórios
para o acompanhamento gerencial
-
e dentro desse escopo
foi priorizado pelo nosso cliente
-
para que a gente primeiro
fizesse toda a parte
-
para já fazer a locação do carro,
porque a parte cadastral
-
pra ele já começar a utilizar alguma coisa
já começou a operacionalizar.
-
A gente vai 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.
-
Tá dentro desse primeiro grupo?
-
Então 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 a gente tem 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
a gente tem o cancelamento dessa reserva.
-
Depois a gente tem a locação
e a baixa do retorno da locação
-
e a gente tem as atividades de pagamentos.
-
E para fechar, o que seria o MVP?
-
O mínimo que ele precisa para colocar para
rodar a partir do relatório de vendas.
-
Então, com isso a gente tem um mínimo
para começar a operação.
-
E aí nos outros sprints
a gente vai trabalhando
-
mais funcionalidades
que vão ser atualizadas nesse sistema,
-
cada vez dando mais autonomia
para o nosso cliente.
-
Bom, a
-
primeira coisa que a gente precisa
fazer numa rodada,
-
lembrando
que a gente está usando o Planning Poker
-
e com
frequentemente a gente vai buscar aqui
-
comparação de complexidade
entre as tarefas.
-
A primeira coisa a gente precisa 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?