AgileAndArt

No mês passado participamos de uma atividade promovida pela ThoghtWorks Brasil em Porto Alegre e organizada pelo Carlos Villela (CV). Eles aproveitaram a ocasião do FISL12 para organizar esse pequeno evento no confortável escritório que fica dentro do campus da PUC-RS. Foi pequeno em relação ao número de participantes (acho que éramos em uns 30), mas enorme em divertimento e aprendizado.

A brincadeira era uma espécie de Dojo, com regras um pouco exóticas. A ideia original foi do Nat Pryce e do Ivan Moore, e eles chamaram de Scrapheap Challenge, por causa do programa de TV, mas eu resolvi re-batizar para Dojo Ojod (um palíndromo de Dojo ao contrário), pois foi exatamente assim que o CV definiu (e que eu concordo muitíssimo): um Dojo ao contrário.

Vamos lembrar que o objetivo principal do Coding Dojo é aprender, num ambiente amistoso e divertido. Nesse quesito o Dojo Ojod é bem semelhante ao Dojo Randori (a mais tradicional modalidade de Dojo). O que muda é que no Dojo Randori temos que fazer TDD, seguir passos de bebê e escrever o melhor código possível, refatorando, deixando ele elegante. No Dojo Randori não temos o objetivo de resolver o problema proposto. Já no Dojo Ojod o objetivo principal é resolver o problema, só que de uma maneira não convencional. Na verdade, a regra é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código que pudermos. Vale usar qualquer coisa, desde scripts nojentos até ferramentas prontas na Web, planilha de Excel, tudo que tem de mais abominável em matéria de desenvolvimento de software. O importante é favorecer a reutilização.

Aqui vão as instruções de como organizar um Dojo Ojod você mesmo:

1. Exponha a lista de problemas (veja os exemplos de problemas abaixo). Normalmente é bem ter umas 5 opções.
2. Cada pessoa escolhe que problema quere fazer. Dessa forma todos se dividirão em alguns grupos.
3. O ideal são grupos de 4 a 6 pessoas. Tente fazer com que isso aconteça, re-arranjando as pessoas caso seja necessário.
4. Cada grupo irá trabalhar isoladamente por 2 horas (cada grupo pode se sub-dividir como preferir se achar melhor).
5. Durante o trabalho, lembrem-se de que o objetivo principal é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código.
6. Passadas 2 horas, cada grupo irá apresentar para os outros a solução encontrada (acreditem, isso será muito engraçado!).

Um dos requisitos mais difíceis para esse tipo de Dojo é justamente criar problemas interessantes de serem resolvidos nesse tempo (2 horas). Vou passar aqui a lista dos problemas que tivemos na ThoughWorks:

O grupo que eu participei resolveu o problema número 3 (a música mais sortuda da cidade). Para quem está curioso, veja a solução no meu github e ouça um trecho dessa música maravilhosa.

Essa dinâmica de Dojo nos faz perceber como existem infinitas maneiras de se resolver um problema e como podemos re-utilizar soluções prontas, agrupando-as da maneira adequada, sem a necessidade de escrevermos muito código.

Organize você um Dojo desses na sua comunidade e deixe o seu comentário aqui de como foi o resultado. Se conseguirem inventar novos problemas, por favor, me conte também

Não deixe de ler uma descrição mais detalhada do Scrapheap Challenge no site do Nat Pryce.

O modelo de Dojo que estamos acostumados é o Dojo Randori, aquele em que temos uma dupla programando (o piloto e o co-piloto) e um telão para mostrar para o resto da plateia o código que está sendo feito. A cada 5 ou 7 minutos o co-piloto ocupa o lugar do piloto e alguém da plateia ocupa o lugar do co-piloto. No Randori, todo desenvolvimento é sempre feito usando TDD.

O Dojo Kake é uma modalidade diferente de Coding Dojo. No Kake, nós temos sempre duas ou mais duplas trabalhando simultaneamente. As duplas podem resolver o mesmo problema em linguagens diferentes ou problemas diferentes. Os turnos continuam sendo de 7 minutos, porém a plateia NÃO PODE ficar olhando a dupla programar. A ideia é sentar para programar sem ter a menor noção do que estava acontecendo antes. É uma simulação da vida real: você chega para trabalhar num projeto que já começou, tem código legado. O seu par deve conseguir te explicar o que foi feito até então e vocês precisam avançar com o código. Depois de 7 minutos, o seu par sai e agora fica com você a responsabilidade de explicar para o próximo o que foi feito e continuar resolvendo o problema. Algumas regras do Kake Dojo:

• Dois ou mais computadores, dependendo da quantidade de participantes
• Turnos de 7 minutos
• TDD, baby steps, refatorações continuam sendo obrigatórios
• Divertir-se é obrigação: bater papo, contar piadas, cantar uma música, jogar video game, vale TUDO, menos olhar os outros programando
• Comida durante toda a sessão (pizza, sanduíche de metro ou jantar gourmet)
• No final fazemos uma retrospectiva usando a técnica dos 6 chapéus

Algumas cenas do último Dojo Kake que realizamos em 2009 podem ser vistas no vídeo:

Vamos fazer um Dojo Kake na próxima 3a. feira, dia 17 de agosto as 20h. Quem estiver interessado em participar, mande um e-mail para mim: danicuki arroba gmail ponto com.

Há um tempo tivemos na empresa um treinamento sobre Feedback. Uma das atividades da tarde foi criarmos encenações onde o líder deveria conversar com um subordinado e dar feedback sobre um determinado acontecimento (i.e. não cumprimento de meta, comportamento inadequado, etc.). Duas coisas estavam sendo trabalhadas: de um lado o “ator” no papel de líder estava simulando uma situação real e aprendendo a lidar com situações difíceis do dia-a-dia de forma lúdica. Do outro estava a platéia, que podia (se) observar de fora. Podemos considerar essa observação fundamental e valiosa para o aprendizado. Ao observar o outro (e suas reações) numa situação que já vivemos, podemos extrair novas saídas, novos comportamentos possíveis.

Na mesma semana do curso de feedback realizamos uma sessão de Dojo com os líderes de tecnologia. Dojo é um encontro de programadores que se reúnem para trabalhar em cima de um determinado desafio de programação. Eles estão lá para se divertir e melhorar suas habilidades através da prática “deliberada”. Existe uma diferença entre a experiência que ganhamos no cotidiano do trabalho e o aprendizado buscado por livre vontade. Esse exercício é uma grande oportunidade de aprender com os outros. É também uma oportunidade de Simplesmente Fazer. Só fazendo é que o programador tem a oportunidade de aprender. Podemos ler vários livros ou artigos sobre TDD, mas nunca saberemos o que o Desenvolvimento Orientado a Testes realmente significa se não o fizermos e praticarmos repetidas vezes.

No Dojo existem algumas regras rígidas a serem seguidas (e fundamentais para a eficácia do aprendizado). Seguindo essas regras, o grupo pode observar cada programador trabalhando e depois sugerir melhorias, num processo de feedback. É a prática contínua misturada com a observação que traz o aprendizado. Durante o exercício, dois programadores formam um par e trabalham em cima do código, enquanto a platéia observa em silêncio. Mesmo que a dupla esteja fazendo coisas muito erradas e absurdas, a regra é observar e só depois que os testes estiverem passando comentar. Além de tudo, é um grande exercício de disciplina (bons programadores só são bons porque têm muita disciplina). A cada 7 minutos troca-se uma pessoa da dupla, de forma de todos tenham a oportunidade de programar. No momento da troca fica claro como um código mal feito do passado pode atrapalhar um trabalho futuro. Outro fato evidente é ver os vários estilos de programação e como uma comunicação ineficiente dentro do time pode levar a resultados completamente improdutivos e muitas vezes desastrosos. Claro que a troca não é o principal fator que faz com que código ruim do passado seja difícil de manter no futuro. O código ruim em si é que é o problema. Um mesmo programador pode pegar um código seu do passado e não conseguir fazer nada com ele a não ser reescrever do zero, de tão calamitoso que estava o código. É interessante observar como é importante sempre fazer um código mínimo mas que ao mesmo tempo deixe espaço para evolução sem muito custo. Esse é o desafio. Muitas rodadas acabam focando mais nas discussões sobre qual seria o melhor código do que observar a dupla codificando

A vivência do Dojo pode ser encarada como uma experiência teatral. A princípio o termo “teatro” pode significar um lugar, um prédio onde acontecem representações teatrais. Mas teatro também pode ser apenas qualquer lugar onde coisas acontecem sob a vista de espectadores “paralisados”. Em Jogos para Atores e Não Atores, Augusto Boal diz que no sentido mais arcaico do termo, teatro é a capacidade dos seres humanos (ausente nos animais) de se observarem a si mesmos em ação. Todos os seres humanos são atores – porque atuam – e espectadores – porque observam. Somos todos “espect-atores”.

Existe uma forma de teatro criada por Augusto Boal e o grupo Teatro dos Oprimidos chamada Teatro Fórum. Essa forma foi muito difundida na Europa na década de 80 e consiste inicialmente num problema real que é apresentado como espetáculo teatral. Em seguida, os espectadores são convidados a entrar em cena, substituir o personagem “oprimido” na situação encenada (personagem que luta para transformar a sua realidade) e, através da improvisação, apresentar alternativas que mudem o rumo dos acontecimentos. O público, atravéz da observação, é então capaz de tirar conclusões que podem servir de gatilho para aprimoramentos em suas vidas individuais.

É claro que existe uma grande diferença entre a resolução de um problema humano e psicológico (razão pela qual o Teatro dos Oprimidos foi criado) e a resolução de problemas matemático-computacionais. Mas não podemos negar que, mesmo na solução de questões algorítmicas complexas, existem pessoas realizando um trabalho. Se o problema tiver que ser resolvido por várias pessoas, é preciso existir muita qualidade na comunicação. Ainda mais quando tiverem pessoas de diferentes níveis de maturidade. Cada um poderá resolver a questão de forma diferente, mas todos precisam aprender com o processo. Ver o outro errar ou acertar é uma forma de reconhecer as próprias limitações ou habilidades. Ao mesmo tempo em que o Teatro (=Dojo) nos expõe individualmente, ele traz a tona oportunidades de aperfeiçoar e ampliar nosso conhecimento.

Podemos encarar a dupla do Dojo como dois atores que estão representando personagens de programadores. Porque um programador também pode ser visto como um personagem. Ele pode ser nervoso, inquieto, ansioso, calmo, empolgado, rápido, egoísta, desanimado: todas características humanas e que podem mudar com o tempo (num dia o programador está ansioso, no outro ele está calmo). Como lidar com todas essas emoções no dia-a-dia de forma hábil?

A platéia numa sessão de Dojo é como o público no teatro, que observa as reações e comportamentos das personagens. Não há forma melhor de aprendermos a lidar com situações inusitadas senão vivendo-as e observando-as. Mas para vivê-las e querer observar é preciso encarar nossas deficiências e respeitá-las, e saber que com trabalho e muita prática podemos melhorar sempre.