Programação em grupo - 5 programadores num único computador?!

A realização de experiências para melhorar os nossos processos faz parte do nosso trabalho diário. Por isso, quando ouço falar de algo que nos pode ajudar a melhorar, quero investigá-lo. No início de 2019, participei na convenção Domain Driven Design Europe. Durante os intervalos, conversei muito com outros participantes, na sua maioria programadores.

Em muitas dessas conversas, o workshop Mob Programming da convenção do ano anterior foi mencionado. Os desenvolvedores estavam muito, muito entusiasmados com a programação em grupo: vários desenvolvedores trabalhando na mesma sala em um único PC. Explicaram o quanto tinham aprendido e crescido como equipa em resultado destas sessões. Isso foi um sinal claro para eu aprender mais sobre o assunto. Depois disso, decidi que iríamos experimentá-la.

Uma parte vital de uma experiência é a hipótese. Sem ela, não se sabe se a experiência foi bem sucedida. A minha teoria era que a programação mob nos ajudaria a partilhar conhecimentos entre programadores enquanto construíamos código limpo.

Planeei e preparei a nossa primeira sessão de programação em grupo, o que não foi muito difícil:

• Unir um computador ligado a um ecrã grande

• Colocar uma mesa em frente ao ecrã.

• Adicionar cinco lugares à mesa.

• Colocar alguns aperitivos e materiais na mesa.

E lá estávamos nós, cinco programadores numa sala com apenas um computador:

O que aconteceu durante a nossa primeira sessão de programação mob?

Wesley senta-se perto do teclado (estamos a usar o seu PC) e é-lhe automaticamente atribuído o papel de driver. O driver é um dispositivo de entrada inteligente: ele pode digitar, mas não pode tomar decisões. Os outros programadores ficam com o papel de navegador. São eles que discutem o que deve acontecer e dizem ao condutor o que fazer.

O condutor é um dispositivo de entrada inteligente: pode escrever, mas não está autorizado a tomar decisões

Começamos a trabalhar numa história simples de aquecimento em que temos de remover algum conteúdo desatualizado no rodapé do sítio.

Os navegadores dizem ao Wesley para iniciar o Docker. Vemos imediatamente uma mensagem de erro. Wesley explica que isso às vezes acontece, mas é sempre resolvido com algumas tentativas. Não tentamos novamente, mas os navegadores explicam quais configurações devem ser alteradas. A partir de agora, o Docker inicia sempre sem erros;

Wesley escreve em uma nota adesiva o que ele aprendeu sobre o Docker. Ele coloca essa nota adesiva na folha de papel grande chamada Aprendizado.

Escrevo numa nota adesiva que o facto de o Docker não arrancar estava a atrasar-nos. Eu o coloco no Waste Snake, uma grande folha de papel com uma cobra desenhada nela. Nesta folha, você coloca notas adesivas descrevendo tudo o que impede a multidão de programar de verdade:

Passados 12 minutos, soa um sinal sonoro. Todos têm de mudar para a direita. O condutor torna-se navegador e um dos navegadores torna-se condutor. É um pouco incómodo e demora algum tempo a recomeçar. Mas ficamos muito melhores depois de algumas trocas.

Nós terminamos a história e começamos a trabalhar na próxima: Yii2 view causa comentários falsos no HTML, o que causa invalidação do HTML. Uma história interessante. Ela já foi pega duas vezes por desenvolvedores diferentes, mas ambos ficaram presos. Toda a gente contribui com a história. Eventualmente, nós corrigimos o problema de uma forma que todos estão muito satisfeitos.

Após duas horas, a sessão termina.

O que é que aprendemos com a nossa primeira sessão de programação mob?

Fazemos uma reunião de retrospetiva para discutir o que correu bem e o que podemos melhorar. A principal conclusão é: corrigimos a história de forma melhor/mais completa numa iteração do que quando uma única pessoa teria trabalhado nela.

Corrigimos a história de uma forma melhor/mais completa numa única iteração do que quando uma única pessoa teria trabalhado nela.

Toda a gente se sente energizada durante a retrospetiva. Todos gostámos da experiência. Torna-se evidente que a programação em grupo nos ajuda a partilhar conhecimentos enquanto construímos código limpo.

A maior parte das aprendizagens foram bastante óbvias, como quando um atalho era desconhecido para o controlador, ou a configuração de ferramentas para o ajudar a ser mais eficiente. Tornou-se óbvio como é fácil adicionar desperdício ao seu próprio processo de desenvolvimento, usando soluções alternativas se um sistema se comportar de forma inesperada. Isso valida a necessidade de abraçar o Kata de Melhoria.

Outras aprendizagens foram mais subtis. Por exemplo, encontrar formas de dividir um problema difícil em problemas mais pequenos. Ou as sugestões sobre como realmente trabalhar com Test Driven, criando primeiro um teste que falha em vez de apenas adicionar um teste depois.

A experiência foi bem sucedida! A próxima sessão está imediatamente planeada

Um dos aspectos mais difíceis de acertar foi o nível de comunicação entre os navegadores e o condutor. Não se quer explicar tudo, especialmente para os programadores mais experientes. Mas também não se quer deixar que um programador mais jovem sinta que está a ser atirado para o fundo do poço. Com o tempo, a multidão aprende a dirigir-se aos condutores individuais da forma correta.

Programação da multidão à distância

Nos Países Baixos, estamos atualmente em confinamento. O nosso escritório está fechado e toda a gente trabalha remotamente. Isto torna impossível a programação em grupo, como descrito acima, porque não podemos estar na mesma sala.

No entanto, continuámos a querer fazer sessões de programação em grupo. Por tentativa e erro, chegámos ao seguinte para uma excelente sessão de programação em grupo à distância:

• Todos têm uma webcam, e todos a ligam durante uma sessão.

• Usamos o Whereby para hospedar nossas reuniões porque você pode compartilhar sua tela e ainda ver os feeds de câmera uns dos outros.

• O motorista faz login em um computador dedicado por meio de uma conexão de área de trabalho remota (criamos uma conta de usuário mob na rede interna para isso).

• Criamos uma conta de usuário mob separada para o Git. Isso facilita muito a troca de papéis.

Como é que posso experimentar isto no meu próprio ambiente de trabalho?

De todos os artigos, blogues e livros electrónicos que li sobre programação mob, aconselho vivamente a leitura destes dois:

• The Mob Programming Guidebook (recentemente renomeado para Ensemble Programming Guidebook) de Maaret Pyhäjärvi.

• Mob Programming - A Whole Team Approach de Woody Zuill.

Depois disso, basta escolher uma data com a sua equipa e experimentar. Divirta-se!