O que o Coding Dojo me ensinou sobre práticas de Agile

Você sabe o que é o Coding Dojo? Alexis Monville, líder da equipe de programação da Red Hat, conta como esse novo processo de programação ajudou na implementação de práticas de Agile. Para saber os benefícios do Coding Dojo e como funciona essa reunião de programadores, confira o que diz Monville sobre o processo!

Coding Dojo e práticas de Agile

No artigo “O que é Agile?”, Jen Krieger, Daniel Oh e Matt Takane discutem o que o time da Red Hat considera como mais importante no Manifesto Agile. Eis a frase escolhida:
“Estamos descobrindo maneiras melhores de se fazer softwares e através disso estamos ajudando outros a fazerem também”.
Eu gosto dessa frase porque ela nos ajuda a entender como é possível aplicar a metodologia Agile fora do desenvolvimento de softwares. Poderíamos substituir a palavra “softwares” nessa frase por “cozinhar”, por exemplo, e isso ainda nos daria uma boa ideia da mentalidade das pessoas que se envolvem com a “culinária Agile”.

É claro que, muitas vezes nós associamos a metodologia Agile a práticas específicas. Vejamos o exemplo de duas práticas de Agile que foram usadas em um Coding Dojo que participei. Um Coding Dojo é uma reunião de programadores que serve para aprimorar seus conhecimentos em algoritmos. Um Coding Dojo é uma excelente maneira de descobrir novas formas de desenvolver. É também uma excelente oportunidade de se aperfeiçoar, compartilhando conhecimento com outros programadores em um ambiente seguro e controlado.

Naquele dia, as práticas que descobri eram relacionadas ao desenvolvimento orientado de testes de programação em pares. O test-driven development, ou TDD, é um processo no qual um desenvolvedor começa escrevendo um teste automatizado para uma função e, em seguida, grava o código que fará o teste passar.
Programação em duplas é quando dois codificadores trabalham em conjunto usando um computador.

Como é participar de um Coding Dojo?

Imagine você em uma sala com 20 codificadores*, um laptop e uma tela grande. Dois assentos perto do computador, serão usados pelo primeiro par de programadores. Na sala, também há assentos suficientes para que os demais pares observem o processo, antes de tomar os teclados.
O kata que utilizamos naquele dia foi o de um jogo de boliche. O objetivo de um jogo de boliche, como explicamos no site Coding Dojo, é “criar um programa que, dada uma sequência de jogadas válidas para a linha do boliche, produziria a pontuação total do jogo”.

Cada par de programadores conta com um cronômetro de cinco minutos, onde é medido o tempo em que a dupla tem para solucionar o desafio. Usando o TDD e realizando pequenas etapas, a dupla deve concluir seu trabalho.
Terminado o tempo, a nova dupla de programadores deve seguir.
As interações ocorridas durante o Coding Dojo auxiliam que os programadores a expressar melhor os códigos que produzem.

Neste dia, o primeiro codificador começou escrevendo o primeiro teste. O teste falhou (“sinal vermelho”), pois ainda não existia o código (as ferramentas de teste associam o verde a um teste de aprovação e o vermelho a um teste de falha). O segundo codificador escreve a menor quantidade possível de código para fazer o teste passar verde, e isso faz com que os testes sejam melhorados. O teste volta ao vermelho em voltamos ao primeiro programador. Ele então escreve a menor quantidade possível de código para fazer o teste passar. E assim por diante. A refatoração é feita durante todo o processo.

A interação entre os dois programadores resulta em uma espécie de “magia” que todos nós adoramos experimentar! Isso porque os contribuidores não estão enviando um patch, esperando por uma revisão rápida. Eles têm a revisão em tempo real. E, como ambos estão progredindo em pequenos passos, explicando o que estão fazendo, é fácil para todos ficarem conectados, seja como plateia, seja como a próxima dupla de programadores.

Escrever o teste primeiro força uma compreensão antecipada do que é necessário. Focar na menor quantidade de código possível para fazer o teste também ajuda a manter o design o mais simples possível. A refatoração ao longo do processo garante que todos os programadores mantenham apenas o código de que precisam.

Para quem está curioso sobre o processo de Coding Dojo, eis aqui as principais diferenças entre participar de um e realizar o processo tradicional de desenvolvimento:

• Os desenvolvedores trabalham em duplas em vez de sozinhos para codificar recursos e corrigir bugs;
• O teste é feito antes do desenvolvimento, em vez de após o código ser desenvolvido;
• A revisão de código é feita em tempo real, juntamente com a dupla de programadores, em vez de esperar que outro desenvolvedor revise e se consolide.
  Programar sozinho, observando uma quantidade maior de código dificulta a compreensão durante o processo. Nesses casos, o processo não é apenas mais lento, mas também conta com interações menos benéficas entre o codificador e o revisor.

Mas, por que consideramos a programação em duplas e as práticas ágeis do TDD melhores? Porque eles são projetados para promover interações mais fortes entre os membros da equipe. Essas interações os ajudam a expressar o melhor no código que produzem.

Coding Dojo e práticas de Agile

Com isso, voltamos ao Manifesto Agile que nos diz:
"Através deste trabalho, passamos a valorizar: indivíduos e interações sobre processos e ferramentas."

Você pode, claro, ter processos e ferramentas. Mas esses processos e ferramentas devem fomentar a expressão dos indivíduos e suas interações. Este último tem mais valor do que o primeiro.

Então, da próxima vez que você estiver envolvido em uma conversa sobre ferramentas ou processos, pergunte a si mesmo (e aos outros): Estamos trazendo uma ferramenta ou um processo que irá desenvolver indivíduos e interações?
Responder “sim” a essa pergunta mostra que estamos no caminho das práticas de Agile.

(Conteúdo traduzido e adaptado do site Opensource.com)

Você já conhecia o Coding Dojo? Veja também como DevOps pode ajudar os desenvolvedores. Clique aqui e saiba mais!