Todos times deveriam ter um momento de prática. Um momento para desligar e viver situações diferentes. Treinar programação. Compartilhar pensamentos que não apareceriam no dia a dia de projeto.

Um Dojo é o lugar do caminho, é a casa dos praticantes de artes marciais. Desenvolvimento de Software além de ser uma atividade criativa, é uma arte. E como tal, deve ser estudada, praticada, e melhorada de forma constante.

A troca de experiências que ocorre em uma sessão de treinamento, entre pessoas com mais experiência e iniciantes é algo  único, uma oportunidade de aprender e de ensinar. De colaborar e ajudar na formação de melhores desenvolvedores.

É um ambiente de colaboração. Competição não possui lugar. É um ambiente de treinamento, onde práticas do eXtreme Programming como Desenvolvimento Orientado a Testes (TDD), Design Simples, Programação em Pares e Posse Coletiva podem ser compartilhadas. As ideias devem ser provadas com código. E todo novo código precisa aparecer evoluindo dentro do ciclo do TDD (Red-Green-Refactor). Explico: primeiro se faz a criação de um teste falhando um determinado cenário em foco, depois criar o mínimo necessário de código para fazer o teste passar e por fim aplicar técnicas de refatoração para melhorar a estrutura do código fonte, deixando ele mais simples. Ciclos curtos fazendo isto até fazer o que precisa ser feito.

Normalmente para se fazer um dojo se precisa de:

1. Um problema a ser resolvido. É normalmente um problema de lógica, onde através de técnicas de design, evolução constante do código através da criação de testes e pequenos passos, este problema vai sendo trabalhado e evoluído. Eventualmente se pode chegar na solução do problema, mas o propósito do Dojo é estudar situações e oportunidades de projetar e resolver um determinado problema.
2. Datashow ou forma de compartilhar o que está ocorrendo com os participantes.
3. Uma estratégia para tocar o Dojo. Existem algumas, como o (a) Prepared Kata, onde um especialista resolve o problema do início ao fim. O que mais uso, o (b) Randori Kata, possui um timer tocando a cada 5-7 minutos, indicando uma nova rotação a ser feita. Temos apenas um computador sendo usado nesta abordagem, assim como é com o Prepared Kata. A cada rotação o desenvolvedor que ficou na máquina tem a tarefa de passar o conhecimento e situar quem está chegando. Aqui estão as oportunidades perfeitas para parear pessoas com grande diferença de conhecimento. Assim o aprendizado funciona muito melhor. Ainda temos o conceito de (c) Kake Kata, onde pequenos grupos se formam e resolvem o mesmo problena. As rotações ocorrem dentro do grupo e entre grupos. O desafio neste caso comparado com o Randori, é que a cada ciclo, estaremos visualizando código diferente e que não foi tocado anteriormente pelo time. Então o processo de aprendizado tem mais desafios.
4. Pessoas. Pelo menos 1 pessoa. Se pode fazer um Prepared Kata e gravar para publicar online.  🙂
5. E o tempo? Uma hora pode ser o suficiente para passar a mensagem e fazer o time trabalhar junto. Gosto de usar 60-80mins de tempo de trabalho.

E quer saber qual a parte mais legal? Esta estrutura de pareamento e colaboração pode ser usada para diversas abordagens! Desenvolvimento de um Business Canvas, escrita de requisitos em um dojo de análise de negócios, e por aí vai.

Extras:

• Fotos sobre CodingDojo no Flickr.
• CodingDojo.org com a explicação do que é um CodingDojo (em inglês).
• Diferentes Katas a serem usados nos exercícios.

Dúvida para o seu primeiro Dojo? Pegue um problema simples como o FizzBuzz, escolha uma linguagem, um framework de teste e mande ver!