sábado, 25 de outubro de 2008

Dojo 02 - Campo Minado

Data: 25/10/2008
Participantes: Diego, Hugo, Vanderson, Rodrigo, Gustavo e Lucas
Randori: Problema do Campo Minado
Linguagem: Python

A sessão sofreu uma mudança de local e horário devido à impossibilidade de se entrar no CEFET - Campos, por que as urnas eletrônicas ficam lá. Logo, ninguém poderia entrar.

Assim sendo, o dojo foi marcado para começar às 10:00hs na Universidade Cândido Mendes(UCAM), porém, como temos um sério problema com pontualidade, começamos às 11:00, utilizando a modalidade RandoriKata.

No início, houve uma discussão excessiva sobre como seria o Design da implementação(Big design up front), o que atrasou um bocado o início da implementação real.

Quando os "rounds" começaram, algumas pessoas tiveram problemas em escrever os testes primeiro, pois nem todos utilizavam TDD. Houve também uma divergência no design, quando tivemos dois testes que levariam a implementações completamente diferentes.

Passado isto, o ritmo prosseguiu normalmente, até que de repente, chegamos às 13:30hs. Sim, o dojo levou 2:30hs!! Todos acharam muito legal e engraçado, principalmente a parte de ficar quieto enquanto o teste estiver no vermelho.

Coisas Ruins:
  • Mais conversa que código
  • Pouco entendimento de TDD / Baby Steps
  • "Tagarelice" da platéia
  • Falta de confiança
  • Correr para resolver o problema.
Coisas boas:
  • Maior assimilação dos princípios do coding dojo
  • Todos participantes habituados com testes unitários
  • Bom entendimento do problema.
  • Foco no problema principal

terça-feira, 21 de outubro de 2008

Dojo 01 - Carga pesada

Data: 11/10/2008
Participantes: Diego, Hugo, Wallace, Ewerton, Juliana e Tiago
Randori: Problema da Carga Pesada
Linguagem: Python

Começamos o evento muito mais tarde do que o esperado(4h e 30min). Primeiro, eu e o Hugo explicamos(ou tentamos...) sobre as premissas do coding dojo e como funciona a processo colaborativo do RandoriKata. Depois, disto mostramos os três problemas selecionados para avaliação de todos. Ficou no empate e achei melhor deixar no acaso(nada como um "cara e coroa" para resolver o impasse). O Problema da Carga Pesada foi o selecionado. O problema era muito simples, o que foi bom pois assim o pessoal poderia obter foco no processo e não tanto no problema. O pior é que o processo foi realmente o empecilho. A primeira dupla ficou perdida no inicio para escrever o primeiro teste. O teste acabou saindo com a ajuda externa ao pair programming. Depois disto ficou uma dúvida no ar sobre o que testar. Levantou-se a idéia de testar a validação da entrada. Passaram alguns rodízios e todos perceberam que era um teste inútil para o momento, e que existia outras coisas mais importantes para serem testadas. Depois disto a ficha caiu, o ritmo começou a aumentar, mas de repente 6h!!!! Chegou o final do dojo . Então fizemos uma retrospectiva do que cada um gostou e não gostou. Não irei citar nomes porque na verdade isto não é importante.

Pontos Legais

A idéia de testar primeiro foi algo que ficou como primordialidade no processo (TDD). NInguém dava propostas de código sem ter feito testes primeiro. Pro-atividade do pessoal para participar programando.

Pontos Ruins

Durante a troca do co-piloto para piloto e a chegada de um novo piloto, o pessoal comentava muito, sendo que os testes não tinham passado, o que é uma premissa do dojo. Faltou foco no problema, sendo que o problema foi discutido e todos o compreenderam. Na hora o foco foi em testes supérfluos. Relataram que a falta de uma cópia pessoal do problema atrapalhou o processo de compreensão do problema. Durante o dojo algumas pessoas sentiram fome e tiveram a grande idéia de sugerir aperitivos durante o dojo para a platéia. A técnica de testes não foi perfeitamente utilizada, deixando vestígios de teste na implementação!!!!! A técnica de baby-steps foi utilizada incoerentemente, tornando algumas implementações desnecessárias para o tratamento de um cenário simples, aumentando o tempo de resposta de convergência do teste.


Relato escrito pelo Diego