Solução? procurava me empenhar no conteúdo e deixava que outras pessoas apresentassem no meu lugar(isso quando o trabalho era em grupo) e ficava confortável com isso, mas sempre dava um “migué” caso fosse uma apresentação individual, ou seja, sempre que podia eu driblava esse incomodo.

Mas e ae, até quando tentaria me enganar?
Hoje o modo como penso mudou totalmente depois que conheci a Adaptworks, sempre ouvia pelos “corredores” para tentarmos enxergar “fora da caixa” e que “zona de conforto” era algo inaceitável. Pois bem, propus um desafio a mim mesmo e alguns meses atrás submeti uma proposta de palestra em um dos maiores eventos agile do país, o Agile Brazil.

Convidei meu parceiro @diogobaeder para dividir esse fardo comigo e enviamos a proposta; algumas semanas depois e somos informados que nossa palestra foi aceita e precisaríamos confirmar…ainda tinha uma última chance para desistir. Daí a importância do meu parceiro, se eu desistisse teria que inventar uma desculpa para ele e não seria legal, então aceitamos

Firme e confiante… estava cada vez mais decidido e animado com essa apresentação, porém, a medida que o dia se aproximava eu ficava com mais medo, meu nervosismo estava somado a importância do evento, a responsabilidade de criar um bom conteúdo e a repercussão após a palestra, meu medo que antes era apenas de me expor agora era algo gigantesco, pelo menos para minha cabeça.

O “dia d” estava cada vez mais perto, mas não tinha como desistir, eram muitos amigos me dando apoio e me desejando sorte, sem ao menos saber o quão desconfortável eu estava me sentindo, então my friends, não estava indo pra fortaleza apenas por mim, já estava levando vocês juntos comigo; se eu desistisse iria decepcionar muitas pessoas.

Enfim o dia chegou, graças a ótima organização do evento pudemos entrar 1 hora antes na sala e conseguimos até fazer um último ensaio slide por slide. A medida que o horário da apresentação se aproximava e as pessoas começavam a entrar eu me sentia mais calmo, os nossos ensaios anteriores me fez bem, e como a @brunaspontes mesmo me disse, falar sobre um assunto que temos mais conhecimento é sempre mais fácil. Em pouco menos de 50min e tinha vencido meu maior inimigo de anos, pelo menos 1 vez consegui vencê-lo.

Vou guardar esse crachá por um bom tempo

A ideia da palestra nós conseguimos transmitir muito bem, se apenas uma pessoa da platéia ja se interessou por algum assunto que abordamos na apresentação, todo esse esforço foi mais do que recompensado.

E você tem alguma vontade ou anseia por algo mas não encara por alguma dificuldade? reconhecer seus limites é o primeiro passo…

Nossa palestra
Quarta(29/07) era dia da minha palestra com meu parceiro Diogo Baeder, falamos sobre “A Importância dos Testes de Regressão” na trilha de engenharia. Antes da nossa apresentação estava bem nervoso, era muita responsabilidade apresentar um material com bom conteúdo, e não bastava o conteúdo ser bom se a apresentação fosse ruim, por isso passamos alguns dias ensaiando e no fim deu tudo certo, conseguimos apresentar todos os slides, não estouramos o tempo e ainda consegui falar sem gaguejar #win. Palestrar nunca foi meu forte, mas isso fica para outro post.

A sala tinha um tamanho bom, acho que 70% das cadeiras ficaram ocupadas, platéia maior do que tinha imaginado visto que eram mais outras 3 salas e o auditório principal com apresentações no mesmo horário, então fiquei feliz pra caramba!

No final, ainda deu tempo de responder algumas perguntas e durante todo o evento algumas pessoas ainda vieram conversar comigo para tirar algumas dúvidas e claro, para dar feedback da palestra. Essa exposição é muito boa, nos aproxima com profissionais de vários lugares do país e a troca de experiência é sem dúvida a melhor parte de tudo, sem contar que ao ouvirmos que nossa palestra foi boa, nos indica que conseguimos alcançar nosso objetivo que era disseminar conhecimento e mostrar o outro valor dos testes unitários.
Avaliem minha palestra e vamos melhorar juntos: http://fala-ai.heroku.com/palestras/54

O evento
Depois da nossa apresentação e passado meu nervosismo, pude aproveitar o evento. Assisti algumas palestras e fiquei boa parte dos 2 primeiros dias no stand da Adaptworks, aproveitava o intervalo do coffee break para conhecer e conversar com a galera; percebi que a maioria tem as mesmas queixas em relação ao trabalho, algumas inclusive iguais às que tenho hoje, então voltei munido de algumas soluções e práticas que talvez possa me ajudar

Fortaleza foi sem dúvida uma ótima escolha para sediar o #agilebrazil2011, cidade muito bonita e muito acolhedora, o espaço utilizado para o evento era bem amplo, bem organizado, o coffe break servido era excelente e as salas reservadas para as apresentações tinha um tamanho muito bom e eram bem estruturadas, todas com projetores e notebooks para os palestrantes usarem, ar-condicionado que era essencial e a rede wi-fi que estava com ótimo sinal. A organização sem dúvida foi nota 10.

O evento estava repleto de pessoas que se preocupam em melhorar, que não estão acomodadas, que querem aprender com o erro dos outros, que querem compartilhar o que sabem, só fico puto triste porque ainda tem palestrante que aproveita para fazer propaganda de sua empresa/produtos, oras, se quer fazer propaganda entra como patrocinador que você tem o direito de ter um stand, NÃO FAÇA ISSO NA SUA PALESTRA SEU FULEIRO!!!

Amigos
Tive a honra de conhecer muitas pessoas que antes só conhecia via twitter, com certeza voltei de fortaleza com algumas amizades a mais na bagagem. Me acolheram aqui de uma forma que parecia que conhecia a galera faz anos. Show de bola!

Fortaleza

FODA DEMAIS!!!

Enfim, o Agile Brazil 2011 foi muito bom! voltei com a sensação de que devo estudar mais, debater mais, ler mais…ou seja, não me esquecer da tal “zona de conforto”…agradeço em especial a galera de fortaleza, o pessoal da Adaptworks que nos deixou usar a sala de treinamento para fazer um de nossos ensaios, ao Jonas Abreu por ter nos ajudado muito com a palestra e por ter me aguentado no mesmo quarto do hotel.

Quase ia me esquecendo, no encerramento teve o show do humorista Zé Modesto…maldito me trollou! ahauhahauha foi muito hilário, chorei de rir com o show dele…outra vez surpreendido pela organização do evento.

O que leva um programador dizer aos demais que ele ganha mais do que os outros? – Sim, trabalhei com um mané que frequentemente fazia questão de deixar claro pra todo mundo que ele ganhava mais, pelo menos ele era de outra equipe (equipe mesmo, aquilo estava muito longe de ser um time). Resultado, devido ao seu comportamento ele foi demitido no meio de um projeto.
Já imaginou dividir a baia com o Charles Bronson? é amigão, eu tive esse “privilégio”, o cara era o “fodão” (pelo menos ele pensava que fosse), além de ser super auto-confiante não admitia erros, quando ele errava a equipe toda era culpada, mas quando alguma outra pessoa da equipe cometia um erro, a culpa era só dela. Uma vez passei a semana toda em uma task beeeem chata, mas que consegui finaliza-la na sexta e quando voltei na segunda ele tinha dito que tinha feito “coisas mirabolantes” e que tinha terminado o que eu tinha feito, wtf? com toda minha calma oriental falei que ja tinha feito exatamente aquilo que ele acabara de me falar, mas claro que o Charles Bronson não satisfeito fez questão de mostrar o código, que logo reconheci pois estava exatamente como deixei na sexta, dessa vez eu não satisfeito abri a versão passada do meu commit e mostrei “olha meu commit de sexta, eu ja tinha feito isso”. Resultado, ele saiu da empresa por conta própria, mas logo quis voltar e a empresa não o aceitou de volta.
Bugs são chatos, mas uma pessoa que só cria bugs é mais chato ainda. Bug é um jeito formal de falar em nossa área, mas em alguns casos é uma “cagada” mesmo, pense em ter uma pessoa da equipe que não aceita ajuda e só cria “bugs”, e o pior, depois ele não assume os erros e outras pessoas da equipe perde tempo consertando seus erros enquanto ele cria mais bugs…é inacreditável algumas coisas que lembro. Resultado, devido a pressão ele saiu \o/

Hoje com tudo que tenho apreendido sobre scrum, muitos desses problemas poderiam ser resolvidos muito mais rápido e talvez impedisse a perda de pessoas no meio do projeto, com a retrospectiva que é a tal hora de “lavar a roupa suja” todos esses problemas que enfrentei poderiam ser jogados na mesa, e talvez poderiamos saber as opiniões dos outros membros da equipe e quem sabe se todos tivessemos a mesma opinião conseguiriamos ajudar a pessoa, ou até mesmo, se eu fosse a única pessoa a ter notado esse problema…talvez eu fosse o empecilho e eu precisasse de ajuda, quem sabe eu era o único chatão…

E vocês, costumam “lavar a roupa suja” em suas retrospectivas?

edit: o comentário da Brena me fez lembrar que, lavar a roupa suja é diferente de “caça as bruxas”, não devemos levantar culpados e sim procurarmos resolver os problemas da melhor forma possível para o time.

Não lembro aonde li, mas me recordo de ter visto em algum livro ou post que dizia +- assim: “…com o andar do sprint, os pigs identificam um chicken no time, caso haja algum…”

1. vocês concordam com essa abordagem?
2. ja identificaram algum chicken no time?

Acho que a maior dúvida é, quais atitudes devemos tomar quando isso ocorrer!? discuti esse tema essa semana com meu amigo e o mesmo me disse que passou por uma situação parecida, e no caso deles, eles ajudaram o chicken a ser um pig novamente. Sem dúvidas essa me parece ser a melhor escolha (todo mundo sai ganhando), porém, o chicken muitas vezes não sabe que ele é um chicken e não aceita ajuda, dificultando mais ainda (já passei por tal situação, o rapaz não aceitava ajuda).
Qual o papel do scrum master nesse caso? será que os pigs devem informar aos SM sobre o provável chicken ou se o SM for participativo o suficiente ele teria percebido o mesmo que o restante do time? e se apenas você acha que um membro do time é um chicken? e se fora do trabalho o chicken é um grande amigo, como deixar de lado a amizade e pensar no lado profissional? quanto um chicken pode comprometer um sprint? muitas…muitas dúvidas! afinal, gostaria que contassem se ja passaram por situações parecidas e o que decidiram.

ps: vale lembrar que minha experiência com scrum é pequena, mas por favor, me corrijam se falei muita besteira
ps2: em nenhum momento criei esse post para crucificar alguém, apenas tenho real interesse na experiência de vocês, acredito que são temas como esse que nos enriquecem e nos deixam mais preparados para as situações do nosso cotidiano.

Aproveito o post para agradecer ao Paulo e a toda galera do IPTI, me acolheram tão bem que na primeira semana de trabalho parecia que trabalhavamos juntos há anos, peço desculpas por não cumprir meu contrato de 6 meses.

E é assim, cada empresa que passo ganho novos amigos, sou melhor em network do que em programar, desejem-me sucesso, pois sorte acho que estou tendo bastante

Pós e Contras
- Apresentamos tudo, nenhum história/tarefa sumiu (ponto positivo).
- Integração do Spring Web Flow + JSF em uma história que precisava de um “wizard” (ponto positivo).
- Surgiram alguns problemas com a versão do sistema que está em produção, e a pedido parte do time trabalhou em um domingo. As correções eram necessárias, não teria como deixar para o próximo sprint, só leva o ponto negativo porque essa semana ficou mais longa (ponto negativo).
- O “Harry” da Caelum entrou para o time (ponto positivo).
- Código que está funcionando pode melhorar! Temos que deixar de ser acomodados! (ponto negativo).
- Pontuação das histórias e horas estimadas de cada tarefa foram melhores estimadas (ponto positivo).
- O “espírito de porco” influenciado por algum problema pessoal, parece que está rondando um membro do time, isso pode comprometer nosso próximo sprint dependendo de quão podre está essa maçã (ponto negativo).
- Pensei que o time se preocuparia mais com refatoração e testes e não foi isso que percebi (ponto negativo).
- Criação de tags no SVN (ponto positivo).
- Integração com sistema de geração de boleto da Locaweb (ponto positivo).

Finalizando, a sensação de terminar outro sprint e apresentar tudo é excelente, novamente não ouvimos nada que pudesse originar algum desconforto, tudo dependia apenas do time. Sendo sincero, estou um pouco cansado após 2 sprints, gostaria muito que segunda-feira pudessemos esquecer um pouco das histórias do product backlog e termos nosso “lab day“(inspirado pelo Google, claro!) como dito no livro “Scrum and XP from the Trenches” escrito por Henrik Kniberg. Até a próxima!