Vou tentar lembrar do máximo de casos possível. Descrever como a brincadeira foi apresentada, como executamos e qual era o "truque". Sim, sempre haviam truques e pegadinhas nas dinâmicas. Que apesar de serem esperadas, todos nós caíamos feito espectadores em um truque de mágica. Foram elas:
Uma coisa corriqueira e boba, de certo modo. A brincadeira era a seguinte: Todos deveriam se levantar e formar uma fila indiana na frente da sala. A fila deveria ser em ordem alfabética. Apesar de relutarmos um pouco, todos levantaram e após alguns minutos se perguntando o nome (afinal era primeira ou segunda aula, e ninguém sabia o nome de ninguém), formamos a fila. Resultado: muito tempo para formar uma simples fila em ordem alfabética.
Segundo passo foi remontar a fila em ordem alfabética pelo seu sobrenome. Fomos um pouco mais rápidos, pois alguém da sala resolveu gritar qual era a sua letra e se posicionar "mais ou menos" onde deveria ficar. Todos repetimos e foi bem mais rápido dessa vez.
Agora teríamos que remontar a fila pela ordem alfabética do nome do pai. Na terceira "iteração" foi quase instantâneo, pois já tínhamos a manha da brincadeira.
O que aprendemos sobre tudo isso? Que só vamos conseguir entrosamento da equipe com o tempo. Não adianta exigir rapidez logo de cara. Enquanto a equipe toda não se "organizar e conhecer", esbarraremos em alguns obstáculos.
- Trabalhando em Equipe
O professor tinha uma caixinha que ele guardava seus itens de atividade em sala. Lá tinha dados, lápis de cor, folhas, papeis coloridos, régua, trena, e mais um montão de coisa. Certo dia ele passou uma lista na projeção com umas dez tarefas a serem executadas e nos dividiu em quatro grupos. Falou que tudo o que iríamos precisar estavam na caixa, mas que não teria para todos. Nossa missão era cumprir pelo menos 4 tarefas até ele voltar. Ele saiu da sala e começou o pandemônio para pegar itens e fazer as tarefas mais simples.
Quando ele voltou ele perguntou o que cada um fez. E constatou que nenhum grupo conseguiu fazer todas as tarefas que se propôs a fazer. Ele chegou a perguntar da seguinte maneira: "Quem disse que era uma competição? Eu só separei vocês em grupos para facilitar a execução da tarefa. Além do mais, não tinha itens para todos fazerem tudo. Entendam melhor as tarefas, ou vão acabar trabalhando e competindo uns com os outros atoa."
Mais uma pequena tarefa que utilizaríamos a "caixa de atividades".
Essa ele separou novamente a turma em quatro grupos e disse que seria uma competição entre equipes. Menos mal. Dessa vez poderíamos fazer a tarefa sem o peso na consciência da tarefa anterior.
A tarefa dessa vez foi bem mais light, por assim dizer. Tínhamos outra lista de tarefas a executar, e precisávamos fazer a maior parte delas. O grupo que melhor executasse mais tarefas e melhor, iria ganhar.
As tarefas eram coias como "jogar o dado várias vezes até sair 3 vezes o número 6", "recortar quadrados de papel de cores diferentes", "fazer aviões de papel com cores específicas", "fazer barcos de papel". Essas tarefas envolviam basicamente dobraduras, recortes, pintura e dados.
Meu grupo escolheu as mais fáceis e começamos a procurar itens para realizar. Fizemos o que pudemos e o professor pediu para todos pararem que ele iria avaliar as tarefas.
Ele já chegou perguntando quais fizemos e segue as respostas dele:
"Uhm... vocês jogaram o dado quantas vezes? Filmaram? Como vocês vão me provar que fizeram isso? Esse avião não foi o que eu pedi. Queria um maior. E esse chapéu de papel? Não cabe na minha cabeça. E blá blá blá".
Ele arranjou um defeito ou erro na tarefa de todos. Qual a lição? Ninguém perguntou exatamente o que ele queria! Fizemos tudo com as mínimas informações que recebemos.
Ele queria um avião de cada cor, mas não sabíamos qual "modelo" de avião ou quais cores. Ele queria "chapéus de papel", mas não nos deu tamanho ou forma. A gente também não se deu o trabalho de perguntar. Já saímos fazendo. Para "acelerar" o processo, que acabou se voltando contra nós. Aprendemos que é muito importante ter o escopo do que fazer muito bem definido antes, do que sair atrás da correção e do prejuízo depois.
- Conceito de pronto
Após termos visto muitos conceitos da metodologia Scrum, os grupos tinham que eleger o "Scrum Master", enquanto o professor faria o papel do "Product Owner". A nossa tarefa era fazer a partir de uma folha de sulfite e canetas coloridas, um Folder para um Pet Shop imaginário. Cada grupo teria a liberdade de criar o nome, logo, e atrações. Algumas premissas nos foram dadas: "nome criativo", slogan, endereço, X atrações para cachorros. Y atrações para animais de ricos, e Z atrações para animais Argentinos. Enfim, coisas que nos manteriam ocupados pensando no que escrever. Esse foi a primeira parte.
A segunda parte seria montar um protótipo do Folder. Tivemos 15 minutos para organizar e entregar.
Lembram da tarefa anterior, onde deveríamos ter perguntado "o que era para ser feito e como"?
Então, cada grupo entregou novamente uma coisa diferente. Foi ai que ele nos fez aprender o "Conceito de Pronto".
O que é isso? Ele definiu que na primeira iteração da tarefa, o folder deveria possuir uma capa, uma imagem na capa do logo, nome, slogan e endereço. E dentro do folder, deveria ter as divisões para as atrações separadas por tipo. Isso é o que ele consideraria "PRONTO" para uma primeira parte da tarefa.
Agora com os 15 minutos novamente, conseguimos "acertar" o que foi pedido e acordado para entrega ao cliente. Aprendemos que é sempre bom ter o relacionamento bem estreito com o cliente, para além de deixar claro o que vai ser "entregue", também poder negociar ou combinar um prazo hábil para a entrega do produto, caso alguma interrupção ocorra ou troca de planos seja necessária.
- Nunca se esqueça do objetivo.
Guardei o que mais gostei para o final do texto. A tarefa mais divertida no conjunto da sua execução
Fomos novamente separados em grupos, e iríamos competir entre nós novamente.
A missão era fazer uma estimativa de custos para uma tarefa. A tarefa era ir do "Ponto A" da sala, até o "Ponto B" e pegar uma bolinha de tênis que estava sobre uma mesa no final do caminho. Durante o caminho existiriam obstáculos (cadeiras, mochilas) que deveriam ser contornados ou pulados.
Tínhamos tipos de passos que "custavam" pontos. Por exemplo:
- passo curto: 3 pontos
- passo longo: 5 pontos
- salto/pulo: 7 pontos
- virar 90 graus: 2 pontos
Era mais ou menos isso. Cada grupo deveria escolher um integrante para realizar o percurso, fazer um planejamento de passos para que completar o caminho e atingir o objetivo. O grupo seria escolhido pelo menor custo no percurso.
O grupo vencedor "cobrou" metade dos pontos que o meu grupo chutou. E depois da escolha, foi a vez deles executarem o plano. O escolhido foi para o ponto A e outro integrante foi para a frente da sala falar o passo a passo para cumprir o objetivo. "Passo curto, passo curto, passo longo, girar esquerda, passo curto, pular, passo curto, etc....".
Quando ele chegou ao ponto B, foi a uma grande alegria da sala toda. Dos que duvidaram que eles acertariam, e dos que estavam confiantes que conseguiriam.
Nessa hora o professor perguntou qual era mesmo o objetivo: Fazer o menor caminho entre o Ponto A e o Ponto B e pegar a bolinha.
Todos olhamos para o ponto B e a bolinha não estava ali. Estava em outro lugar da sala, levada pelo professor durante a execução da tarefa. Ninguém percebeu, e todos foram até o fim do plano sem questionar.
Qual a moral da história? Apesar de todo o nosso planejamento e empenho em cumprir a meta no prazo e custo combinado, temos que "sentir" e saber das mudanças que podem, e VÃO, ocorrer. Mudanças devem ser bem vistas, e antecipadas a tempo, para que não haja tanto custo para contornar as alterações e ainda assim cumprir o objetivo da Tarefa. Não adiantou chegar ao ponto B com menor custo, e a bolinha mudou de lugar e não valeu de nada todo o trabalho executado.
Esse foi o maior texto que escrevi para um blog. Acho que consegui finalmente escrever uma história que vira-e-mexe fico martelando na cabeça. E também vivo contando para os amigos sobre essas aventuras nas aulas de Scrum.
Fica a dica para quem trabalha na área, estudar um pouco da metodologia Scrum. Acho que não precisa ser 100% nela. Mas utilizar certos conceitos dela, ajudaria à muitas equipes de desenvolvedores.
Abraço! o/
Nenhum comentário:
Postar um comentário