AGILE

O que o Coding Dojo me

ensinou sobre práticas de Agile
Daniel Ginês
23 de Jan de 2019
• 4 min read
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,
 p p ç ,
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
d d N l t bé há t fi i t
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!
 Sign up for more like this.

Enter your email Subscribe

Os desafios na adoção do DevOps

Muitas corporações, pequenas ou grandes, já implementaram ou Monitorando o progresso com o comando
mudaram para adotar práticas DevOps em seu dia a dia, buscando PV
melhorar a produtividade, o fluxo de trabalho ou ter  maior retorn… Quando estamos executando comandos no Linux que podem
d b k ó i i i i
 demorar, como um backup, uma cópia, comprimir um arquivo e
Daniel Ginês mover dados de um lado para o outro, pode ser muito útil saber…
4 de Abr de 2021 • 4 min read
Daniel Ginês
28 de Mar de 2021 • 3 min read

Blog da Estabilis © 2022

Powered by Ghost