Quando?
29/07/2010, das 10 as 12h
Onde?
Serpro, Sala de Treinamento 06, 1o andar
Como foi a agenda?
10'
- Visão geral sobre Dojo
5' - Apresentação do desafio
60' - Programação em pares, rodízio a cada 5 minutos, comentários só com teste passando
30' - Retrospectiva
Quem participou?
Serge, Márcio, Thiago, Cleverson, Marlon, Gustavo, Luis Apodi, Cleiton, Rogério, Luis Gustavo (Serpro), Otávio (Área 1), e o Fernando, Fabrício, Leandro e Tiano (Avansys).
Qual foi o desafio?O Jogo Batalha Naval
.
Em qual linguagem?JavaScript com JSUnit, usando editor de textos Gedit e Firefox para rodar os testes unitários.
O que aprendemos?
Pontos positivos :-)
- Mudar foco do trabalho;
- Programação em pares;
- Presença de novas pessoas;
- Outras pessoas continuaram vindo;
- Compartilhamento de conhecimentos;
- Entendimento prático de acertos e erros;
- Aplicação prática de tecnologia;
- Garantia de implementação com redução de falhas;
- Adaptação a uma nova linguagem;
- Interação entre os programadores;
- Aprendizado;
- Trabalho em equipe;
- Motivação para solucionar o problema;
- Conhecimento novo na linguagem;
- Trabalho em equipe;
- Dividir a solução com várias pessoas para alcançar o resultado;
- Conhecer novas ferramentas xUnit;
- Maior participação externa;
- O desconhecimento da linguagem estimulou a criatividade;
- Rodízio de linguagens com padronização de testes com xUnit;
- Desperta o interesse em trabalha em equipe;
- Desperta o interesse em novas linguagens;
Pontos de melhoria :-(
- O tempo deveria ser de 10 minutos;
- Custo de desenvolvimento elevado;
- É interessante a elaboração de um roteiro: minimizar gaps;
- Melhorar o apoio dos participantes na resolução dos problemas;
- Muito copy and paste;
- Problema poderia ser simplificado;
- Sintaxe javascript;
- Os pilotos e copilotis ficaram muito isolados, sem comunicação com as outras pessoas;
- Falta de conhecimento da linguagem;
- Tentar não se repetir nos testes - Testar coisas diferentes como a jogada de cada um;
- Um script poucos tinham domínio;
- O desconhecimento da linguagem atrapalhou em um momento;
- Só com a prática constante é possível ter um conhecimento duradouro;
- Dimensionar melhor o problema;
- Conhecer o problema proposto;
- Evitar copiar e colar por parte dos pares;
- Perdeu um pouco o foco no objetivo: TDD.
Teve slides?
Sim, os mesmos dos Dojo 1 e 2, só que desta vez apresentados por Cleverson, para explicar os conceitos gerais sobre Coding-Dojo. Veja e ouça o SlideCast abaixo ou então
baixe o PDF.
E fotos?
Então, mostre-me o o código!Veja aqui o código que conseguimos produzir.
Você quer comentar (edita/salva e coloca também seu nome)
?Esse Dojo foi muito legal, principalmente pelas lições aprendidas. Por não simplificarmos o problema, do meio pro fim o Dojo virou muito "copy & paste" para preencher tabuleiros com os vários tipos de objeto (encouraçado, cruzador, destroyer) e nas várias posições (pra cima, pra baixo, pra direita, pra esquerda). Resultado
: refatoramos muito pouco código e não testamos uma "jogada completa", ou seja, se fosse um caso real não teríamos entregue valor real para o cliente. Algo a se pensar...
Serge Rehem
Reforço a visão de Serge. Valeu muito pelas lições aprendidas. Deveríamos ter simplificado o problema para facilitar. Contudo, as pessoas pensaram pouco no TDD e na refatoração, se preocupando mais em codificar alguma coisa, para não passar em branco na sua vez. Talvez a ideia passada no início, durante a apresentação sobre o que é o Dojo, não tenha sido bem fixada: Dojo não é competição ou exibicionismo. Estamos lá para errar e acertar. Este problema também pode ter originado da falta de cultura na prática de TDD, o que leva as pessoas a não conseguirem imaginar os testes possíveis e ficam presas às ideias de primeiro codificar a funcionalidade. Neste caso, o copy + paste pode ter sido um sintoma deste problema.
