-
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 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á.