JFJUG - Coding DOJO

Origem: JFJUG Wiki, a enciclopédia livre.

Coding Dojo - Juiz de Fora Java User Group

Apresentação sobre Coding Dojo. (a qualidade ficou ruim no upload do pdf, mas dá pra ver tranquilo).
Apresentação no SlideShare

1. Agenda

Local	Data	Hora	Problema	Retrospectiva
Universo	22/05/2010	14:00-16:00	Caixa Eletrônico(Randori)	Não Aconteceu
Universo	29/05/2010	14:00-16:00	Caixa Eletrônico(Randori)	Retrospectiva DOJO 2
Cancelado	05/06/2010	14:00-16:00	Cancelado
Cancelado	12/06/2010	14:00-16:00	Cancelado
Universo	19/06/2010	14:00-16:00	Não Sugerido

Outras instituições demonstraram interesse em participar deste projeto, porém ainda não liberaram infraestrutura oficialmente.

2. Objetivo

Treinar, aprender, ensinar, discutir sobre código e interagir. Programadores não possuem o hábito de treinar sua programação, basicamente trabalham dia após dia em uma empresa, solucionando problemas, mas em nenhum momento treinam a sua capacidade de codificar, resolver problemas e melhorar sua técnica. Além disto, é uma oportunidade de programadores interagirem entre si, aumentando o networking de cada pessoa, até mesmo, podendo gerar oportunidades de estágio/trabalho. E também, é possível, através dessa interação aprender e ensinar novas técnicas, ferramentas e linguagens de acordo com a sua utilização na realização de problemas.

3.Princípios

Aprendizado contínuo, ambiente seguro (não competitivo, colaborativo e inclusivo), tolerância a falhas e entendimento coletivo. O propósito básico e proporcionar o aprendizado contínuo dos participantes, através da resolução de problemas utilizando técnicas de programação como Passos de BebêAtacar o problema dando o menor passo possível, e não mais do que um de cada vez. e Test-Driven-Development - Metodologia de design de código onde primeiramente é criado um teste (que obviamente irá falhar), em seguida cria-se a implementação mais simples possível para passar no teste, e no momento que o teste estiver passando, efetua-se refatorações no código a fim de melhorá-lo. Torna-se isso um ciclo, e vai-se aumentando os testes a fim de atender todos os requisitos do problema. O ambiente do Dojo deve ser seguro, onde os participantes não compitam entre si, colaborativo, onde todos participem e inclusivo, pois permite a participação tanto de programadores experiêntes como iniciantes. A tolerância a falhas também é um princípio a ser considerado, pois nós programadores, no nosso dia-a-dia não temos o direito de falhar enquanto codificamos algo para a nossa empresa, em um ambiente de treinamento, falhar é permitido e até mesmo interessante, pois das falhas que se aumenta o aprendizado. Um último princípio, é o princípio de entendimento coletivo, ele se dá com um entendimento total de todas as pessoas que estiverem no evento. Se qualquer pessoa não entender alguma coisa, o Dojo não é bem sucedido.

4.Formato

4.1. Katá

Neste formato um participante prepara uma solução de um problema em casa e apresenta-o para o publico. Em seguida as pessoas tentam replicar a solução do mesmo problema.

• 1º Parte: É necessário um computador computador com um projetor e um ambiente que permita a presença de aproximadamente até 15 pessoas, para apresentação da técnica / solução.
• 2º Parte: É necessário um computador para cada par replicar o que foi apresentado pelo palestrante.

4.1.1. Processo

Uma sessão do Dojo tem a tendência a demorar aproximadamente 2 horas.

• 5 minutos iniciais - Definir o problema
• 30~40 minutos - Apresentar solução para o problema proposto e implementar.
• ~10 minutos - Pausa para comer algo, discutir sobre como está indo, "relaxar".
• 30~60 minutos - Cada time tenta replicar o problema.
• ~15 minutos - Retrospectiva. O que foi bom, o que foi ruim, o que melhorar. Lições aprendidas.

4.2. Randori

É necessário somente um computador com um projetor e um ambiente que permita a presença de aproximadamente até 15 pessoas. Sempre é feita a programação em pares no computador, onde a pessoa que está em posse do teclado é o piloto e a outra pessoa um co-piloto. É definido um "time-box" (normalmente de 7 minutos) que é o tempo onde haverá rotatividade entre os participantes. Passados os 7 minutos acontece:

• O piloto vai para a platéia assistir.
• O co-piloto vira o novo piloto.
• Uma pessoa da platéia assume o lugar de co-piloto.

Conforme explicado utiliza-se a técnica de TDD (Test Driven Development), inicialmente é escrito um teste que irá falhar (momentos de falha consideraremos em vermelho). Em seguida é implementado uma solução para fazer este teste passar (momentos de sucesso considerados em verde). No vermelho a platéia deve ficar em silêncio, e piloto e co-piloto interagirem para solucionar o problema. Nos momentos que os testes passarem, ou seja, no verde as pessoas da platéia ficam livres para criticar ou dar sugestões em relação a solução proposta. RefatoraçõesTecnica para reestruturar código existente, alterando sua estrutura interna (a fim de melhorar seu design), sem que o seu comportamento externo seja alterado. são feitas e propostas (por qualquer participante) no momento verde.

4.2.1. Processo

Uma sessão do Dojo tem a tendência a demorar aproximadamente 2 horas.

• 5 minutos iniciais - Definir o problema
• ~15 minutos - Discutir sobre o problema a ser resolvido. Propor abordagens de atacar o mesmo.
• 30~40 minutos - Codificação. (Em pares, conforme citado acima).
• ~10 minutos - Pausa para comer algo, discutir sobre como está indo, "relaxar"
• 30~40 minutos - Codificação novamente.
• ~15 minutos - Retrospectiva. O que foi bom, o que foi ruim, o que melhorar. Lições aprendidas

5. O que não é feito

Não utiliza-se problemas do dia-a-dia da empresa. Utiliza-se sempre problemas fictícios, de tal forma que não é necessário que a pessoa conheça o contexto de uma empresa por exemplo para poder participar. Não é permitido também fazer sessões contínuas. Sempre uma sessão deve iniciar do zero, para que pessoas que não estiverem presentes em sessões anteriores possam participar da sessão atual. Além disto, apesar de o Dojo se desenrolar através da tentativa de solucionar um problema, o objetivo em si não é ter o problema resolvido, e sim treinar, aprender e discutir diferentes e melhores formas de atacar um problema. Portanto, correr para se chegar na solução do problema também não é desejado. Não deve ser um ambiente competitivo, onde um participante tenta ser melhor que outro. E repetindo mais uma vez, não é permitido deixar uma pessoa sem entender sobre as abordagens propostas.

6. Sessões e Recursos necessários.

É proposto que seja todos os sábados, com uma duração de 2h e tendo início às 14horas. É esperado entre 5 a 15 pessoas para as sessões. Para ambas formas de sessões (Katá e/ou Randori) precisa-se de 1 computador ou 1 teclado + mouse USB (para se conectar a um notebook) e um projetor. Utilizar um notebook de um participante é melhor pois pode ser necessário a instalação de ferramentas (IDE, frameworks para testes, etc) e linguagens (Java, Ruby, Python, etc). E o ideal é que o ambiente já esteja preparado para utilizar a linguagem e as ferramentas escolhidas de ante-mão para não "roubar" tempo do evento. Além disto para que cada par possa replicar a solução de um problema (nas sessões de Katá invés de Randori) é necessária a utilização de um laboratório, para que as pessoas possam sentar-se em par e resolver também o problema. Um quadro também é interessante, mas não necessário, para que os participantes possam escrever as formas de abordar o problema e isto ficar disponível para todos. Não é necessário internet, mas tê-la seria muito bom para caso surja alguma dúvida que os participantes não consiga sanar diretamente entre si no momento.

7. Listagem de Problemas

• Problema A
• problema B

8. Custo

Não é cobrado nenhum valor para a participação, porem sugere-se que cada participante leve 1 kg de alimento não perecível que será doado para um instituição de caridade.

9. Outros tópicos

Para bom andamento do grupo de estudo, será disponibilizado no site do JFJUG (www.jfjug.org): Um repositório de códigos fonte SVN. Cada encontro vai gerar uma página no formado de wiki sobre o que aconteceu. Um fórum de discussão. Qualquer assunto relacionado ao Coding Dojo como opiniões, discussões e também avisos devem ser tratado na lista de discussão principal do JFJUG (users@jfjug.dev.java.net). ' '