Coding dojo e Pair Programming
Técnicas de desenvolvimento de software em par podem agregar em equipes
Você já se perguntou quanto tempo precisa para aprender algo novo? Josh Kaufman descobriu que em 20 horas qualquer pessoa consegue absorver conhecimento para aprender qualquer coisa. Muitas vezes achamos que não somos capazes de aprender algo novo ou o pior: que outra pessoa não consegue nos transmitir conhecimento. Para falarmos de técnicas de programação em par, além de considerar o que Josh disse, é muito importante acreditarmos que conseguimos trabalhar em equipe.
Pair Programming
Pair Programming é um dos elementos difundidos pela Extremming Programming (XP) e que lembra muito uma corrida de Rali onde existe o piloto e o copiloto. No Rali, o copiloto (também chamado de navegador) é responsável por dar as direções ao piloto (ou driver). O piloto segue as orientações do seu navegador a risca, somente interagindo se houver necessidade. Para trabalhar em pares é necessário que uma pessoa seja o navegador e outra pessoa seja o piloto. Porém, existe a possibilidade da realizar troca de papéis em intervalos previamente definidos antes de iniciar a tarefa.
A técnica de PP tem como objetivo que a equipe (no caso, a dupla) troque técnicas e ideias para a resolução de problemas. Apenas um computador é usado e a dupla fica isolada do ambiente comum de trabalho para que não haja o risco de dispersões. Vale ressaltar que a técnica não deve ser utilizada durante momentos de produção, mas sim, para treinar e capacitar membros da equipe, por isso o ideal é que ambos os desenvolvedores estejam em níveis técnicos semelhantes, para que um deles não siga apenas o caminho do outro.
Benefícios do Pair Programming
- Experientes na prática descrevem que trabalhar em pares é “mais que o dobro da velocidade”.
- O design resultante é melhor, resultando em código mais simples, mais fácil de estender.
- E segundo o artigo a PP pode demorar cerca de 15% a mais, mas produz 15% menos defeitos.
Soft Skills para Pair Programmers
Para trabalhar em pares não basta que os programadores tenham ótimas skills técnicas, mas sim consigam trabalhar bem em equipe. Para falar de técnicas de desenvolvimento em pares é fundamental que falemos de algumas soft skills necessárias que os team members devem ter.
- Permita troca de ideias e sugestões.
- Utilize a palavra “nós” enquanto estiver se comunicando.
- Seja cuidadoso com sua comunicação não verbal.
Algumas técnicas para Pair Programmers
Existem algumas derivações do PP. O par deve adotar a que for mais conveniente para ambos.
- O tradicional — Nesta técnica o driver executa todos os comandos que o navegador sugere. O problema que pode acontecer ao utilizar esta técnica é o navegador se distrair facilmente e o driver não absorver o que está sendo executado.
2. O “strong style” — Enquanto que no método tradicional o responsável pelo completo raciocínio é o navegador, no método strong style quando o piloto tem alguma sugestão ele passa o teclado para o navegador. Desta forma o membro que era anteriormente piloto se torna navegador. Esta técnica é mais dinâmica do que o tradicional, visto que torna mais dinâmica a atividade. Vale enfatizar que enquanto piloto, o desenvolvedor não pode transcrever suas ideias para o código, ele só poderá fazer isso ao tornar-se um navegador.
3. O “ Ping Pong Pairing” — Esta técnica pode ser a mais indicada para times onde existe teste de software. Existem 3 ciclos que irão se repetir até o final da atividade. No primeiro ciclo, o primeiro membro irá desenvolver um teste falho. No segundo ciclo, o teclado é recebido pelo segundo membro que irá fazer o teste passar, irá refatorar o código e irá desenvolver um próximo cenário com falha. No terceiro ciclo, o teclado é recebido novamente pelo primeiro membro da dupla, onde fará o teste passar, irá refatorar e irá desenvolver o próximo teste. E assim, estes ciclos continuarão até a finalização da atividade.
Coding Dojo
O Coding Dojo foi desenvolvido com base em conceitos descritos pela XP e Scrum, sendo que podemos ressaltar a Programação em par, Test driven development (TDD) e as reuniões de retrospectiva.
Desenvolvimento dirigido por testes (TDD) é a capacidade de desenvolver primeiro o teste para após desenvolver o código de produção. Resumidamente possui 3 ciclos, o primeiro é o de criar o teste, o segundo é para fazer o teste passar (desenvolver o código que o fará) e o terceiro é para refatorar se necessário. É uma técnica que deixa o código fonte mais modular, de fácil manutenção.
Reuniões de retrospectiva são realizadas ao final de cada ciclo de desenvolvimento, nela serão levantados os pontos positivos e negativos que ocorreram no último ciclo. Também são discutidos ações e melhorias para as próximas interações do time.
Dojo é um ambiente para treinar e aprimorar as práticas de programação.
Assim como no PP, não é aconselhável que o coding dojo seja utilizado durante produção, mas sim, que seja um espaço onde os programadores possam exercitar a programação e melhorar skills técnicas. Também, o Dojo deve proporcionar um ambiente descontraído e colaborativo.
Falarei a seguir de 3 tipos de Dojo que você pode adotar em sua equipe.
Tipos de coding Dojo
O Dojo Kata foi a primeira técnica a ser elaborada, por Dave Thomas. Um membro do time, chamado de apresentador, escolhe um problema a ser resolvido e apresenta para os outros membros do time, chamados de plateia. Neste método a plateia não interage entre si ou com o apresentador, atua somente como ouvinte. O apresentador pode ser uma dupla programando em par. Mas o importante é que o evento seja divulgado previamente para os membros do time e ao final deve ser realizada uma reunião de retrospectiva.
O Dojo Randori surgiu para ser executado em equipes onde o conhecimento já foi adquirido e é necessário aprofundá-lo. Neste método, a plateia não é somente ouvinte. O evento inicia com um piloto que está executando uma série de comandos e por um navegador que está explicando o que está acontecendo na plateia, também pode ajudar o piloto. Ao fim do ciclo, o piloto volta para a plateia, o navegador assume como piloto e um membro da plateia assume o papel de navegador. A plateia só fala quando os testes de TDD estiverem passando ou quando a dupla pedir ajuda. Ao final do encontro deve-se realizar uma reunião de retrospectiva.
Por último, o Dojo Kake. Antes de iniciar o evento, um problema será levantado para que todos busquem uma solução. Cada dupla irá atuar utilizando um método diferente de resolução para o problema. A cada determinado tempo as duplas serão trocadas: o piloto irá para outra dupla, o navegador irá assumir como piloto sem mudar de dupla e assim sucessivamente até o término do evento. Pode existir uma plateia que não irá interagir com o código que está sendo desenvolvido, mas poderá observar a programação que está sendo feita. Ao final do evento, deve-se realizar uma reunião de retrospectiva.
Alguns benefícios do Coding Dojo
O mais importante a ressaltar que a técnica não é tão produtiva, porém é reveladora. O time se sente mais engajado e preparado para resolver problemas que podem surgir no futuro. Os membros do time aprendem estilos diferentes de código e interagem com os demais. O Coding Dojo é um ambiente seguro para testar novas ideias, promover o networking e compartilhamento de ideias entre os membros da equipe.
Alguns sites para praticar
Mas, e agora?
Certo, após ler tudo isso você pode estar com o sentimento que ambas as técnicas de programação em par não são tão úteis, visto que eu apresentei alguns malefícios em utilizar. Na verdade, a resposta é que DEPENDE! SIM, depende de você e sua equipe, não adianta dizermos que programação em par é para todos e para todas as equipes, vivemos em um mundo onde a agilidade está cada vez mais presente, onde para os perfis dos programadores não basta mais skills técnicas. Se você trabalha em uma empresa onde não existe esse espaço de aprendizado a resposta será que provavelmente será muito difícil implementar estes modelos, porém você pode iniciar pequenos eventos e ver como o time reage. Talvez isso desperte o interesse e a curiosidade dos demais.
Meu papel neste post foi em apresentar técnicas que existem no mercado e que algumas empresas já adotaram, foi dizer que SIM, É POSSÍVEL trabalharmos em grupo no mundo do desenvolvimento de software e ganharmos mais qualidade e tempo.
Eu separei alguns pilares que eu acho que são fundamentais para que a programação em par funcione bem e com qualidade. Pensem nesses pilares e espero que consigam motivar suas equipes com Pair Programming ou Coding Dojo.
Até a próxima ;)
