Exercícios em grupo na aula de programação

Exercício em grupo funciona na aula de programação porque obriga o aluno a dizer o raciocínio em voz alta — e raciocínio dito em voz alta é raciocínio que dá para corrigir. Na prática, o formato rende quando três condições se cumprem ao mesmo tempo: o grupo tem de 2 a 4 pessoas, o enunciado é grande o bastante para não caber na cabeça de uma pessoa só, e o professor consegue enxergar o que cada integrante fez. Faltando qualquer uma delas, o que acontece é um aluno programando e três assistindo.

Esse é o ponto que quase todo mundo erra. A discussão sobre trabalho em grupo costuma girar em torno de "como montar os grupos", quando o problema real está no enunciado e na avaliação. Um exercício que uma pessoa resolve sozinha em dez minutos não vira colaborativo porque você juntou quatro cadeiras. Ele vira só um exercício individual com plateia.

Este guia é escrito para quem dá aula presencial ou híbrida em curso livre, escola técnica ou turma de qualificação — o tipo de turma em que o professor conhece os alunos pelo nome e consegue circular pela sala. Boa parte vale igual para EAD, mas o acompanhamento muda de forma.

Por que grupo funciona especificamente em programação

Programação tem uma característica rara entre as matérias: o erro é público e imediato. O código não roda, a tela mostra a mensagem, e não tem como fingir que entendeu. Isso torna a dupla ou o trio um instrumento de diagnóstico muito melhor do que a lista individual.

Três mecanismos explicam o ganho:

• Verbalizar organiza. Quando o aluno precisa explicar para o colega por que colocou o if antes do laço, ele descobre sozinho se sabia ou se estava copiando um padrão que viu no quadro. Muita confusão morre nessa frase.
• Aluno explica melhor para aluno em certos momentos. Não porque explique melhor que o professor, mas porque acabou de sair da dúvida e ainda lembra o que estava confundindo. O professor já esqueceu como é não saber.
• O grupo distribui a coragem. Iniciante trava com medo de rodar o código e dar erro. Em dupla, o dedo que aperta "executar" é compartilhado, e o erro deixa de ser vergonha pessoal.

Existe também um ganho de sala que ninguém menciona nos textos de pedagogia: com a turma em grupos, o professor consegue atender 20 alunos passando em 6 mesas em vez de em 20. Numa aula de 4 horas isso é a diferença entre atender todo mundo e atender os cinco da frente.

Como formar os grupos: sorteio, afinidade e convite

As três formas funcionam, em contextos diferentes. O erro é escolher uma e usar o semestre inteiro.

Uma combinação que funciona bem no curso livre: sorteio nas quatro primeiras semanas, para que todo mundo já tenha trabalhado com todo mundo, e afinidade ou convite depois disso, quando as escolhas passam a ser informadas ("quero fazer com a Camila porque ela é boa em organizar") em vez de sociais ("quero fazer com quem eu sento junto").

Se a formação por convite for feita dentro de uma ferramenta, o trabalho braçal some. No Aulab, por exemplo, o exercício em grupo é aberto para a turma e os alunos se convidam entre si até fechar o número de integrantes que você definiu; a entrega fica espelhada para todo mundo do grupo, e você corrige uma vez só. Vale dizer o óbvio: nenhum sistema resolve o aluno que não quer entrar em grupo nenhum. Isso ainda é conversa de professor.

Tamanho e papéis dentro do grupo

Dois é o tamanho mais eficiente para exercício de código dentro da aula. Três funciona bem para exercício de análise, desenho de solução ou projeto com partes separáveis. Quatro é o teto — e só se o enunciado tiver, de verdade, quatro frentes de trabalho. Cinco não existe: sempre vira três trabalhando e dois conversando.

Papéis ajudam quando são rotativos e explicados em uma frase cada. Um conjunto que funciona em programação:

• Quem digita. Escreve o código. Não decide sozinho — executa o que o grupo combinou.
• Quem lê o enunciado. Fica com o papel na mão e é responsável por perguntar "isso que a gente fez atende o item 3?".
• Quem testa. Roda e inventa entrada esquisita: valor zero, valor negativo, nome com acento, campo vazio.
• Quem escreve a explicação. Redige em três frases como o grupo resolveu. Esse papel é o mais subestimado e o que mais revela quem entendeu.

A regra que faz os papéis valerem alguma coisa: eles giram a cada exercício. Se o mesmo aluno digita sempre, você criou um cargo, não um papel. O aluno que só testa por seis semanas não aprendeu a escrever código, aprendeu a apertar botão.

O carona: como avaliar o indivíduo dentro do coletivo

O carona é o motivo pelo qual professor experiente desconfia de trabalho em grupo, e a desconfiança é justa. A saída não é policiamento, é desenho: o grupo produz uma entrega coletiva, mas você coleta pelo menos um sinal individual por aluno.

Três sinais individuais baratos de coletar:

1. A pergunta de saída. Nos últimos dez minutos, cada aluno responde individualmente, por escrito, uma pergunta curta sobre o exercício que o grupo acabou de fazer: "por que o laço precisa parar em 10 e não em 11?". Quem só assistiu não responde.
2. A explicação de trecho. Você aponta uma linha do código entregue e pede para um integrante sorteado explicar. Leva 40 segundos por grupo e muda o comportamento da turma inteira já na segunda vez.
3. O exercício individual da aula seguinte. Uma versão menor do mesmo problema, feita sozinho. Se a nota do grupo foi ótima e a individual foi péssima, você já sabe o que aconteceu.

Evite dois atalhos populares que costumam sair pior: nota por autoavaliação do grupo ("digam quem trabalhou") gera constrangimento e raramente é honesta; e desconto de nota individual baseado em impressão do professor gera discussão que você não vai ganhar. Prefira sinal coletado, não impressão. Esse raciocínio se estende para o curso todo — vale ler como montar o conjunto de instrumentos em avaliação em cursos de programação.

Armadilhas que estragam o trabalho em grupo

Enunciado pequeno demais. Se dá para resolver em quinze linhas, é exercício individual. Para grupo, use problemas com pelo menos três decisões independentes — por exemplo, um controle de estoque de padaria que precisa cadastrar produto, calcular o total do dia e avisar quando o estoque estiver baixo.

Grupo grande "para dar tempo". Juntar seis alunos para vencer o cronograma é a forma mais rápida de garantir que quatro não aprendam nada.

Sempre os mesmos juntos. Vira turma dentro da turma. Depois de umas quatro semanas, você tem dois grupos fortes, um fraco e ninguém aprendendo com quem é diferente.

Uma máquina só. Em laboratório com poucos computadores, a dupla em um teclado funciona (é pareamento clássico). Trio no mesmo teclado, não: o terceiro está no celular em quatro minutos.

Corrigir só o resultado. Se você olha apenas se o código roda, o grupo aprende que a estratégia vencedora é achar o integrante que sabe e deixar com ele.

Como acompanhar sem microgerenciar

Circular pela sala e perguntar "tudo bem aí?" não é acompanhamento — todo grupo responde que sim. Acompanhamento é fazer uma pergunta que só quem está trabalhando consegue responder. Duas boas: "me mostra a última coisa que vocês testaram" e "o que vocês tentaram que não deu certo?".

Fora da aula, o que você precisa é enxergar o estado das entregas sem abrir um por um: quais grupos entregaram, quais nem começaram, quais reentregaram depois da sua devolutiva. É o mesmo conjunto de sinais que serve para o aluno individual, detalhado em como acompanhar o desempenho dos alunos sem planilha. Ferramentas de turma resolvem isso — no Aulab, a entrega do grupo aparece no painel da turma com o status de cada exercício, e o chat da turma dá um canal para o grupo combinar as coisas sem virar mais um grupo de WhatsApp que você não lê. Se quiser ver esse fluxo montado, dá para criar uma conta e montar uma turma de teste antes de levar para os alunos.

Por fim, uma regra de bolso que salva aula: defina o horário de fechamento do grupo, não só o do exercício. "Grupos fechados às 19h30, quem não estiver em grupo trabalha sozinho" resolve em duas semanas um problema que, sem regra, dura o curso inteiro.

Perguntas frequentes

Qual é o tamanho ideal de grupo para exercício de programação?

Dois para exercício de código dentro da aula, três para análise ou projeto com partes separáveis, quatro no máximo e apenas quando o enunciado tem quatro frentes reais de trabalho. Grupos de cinco ou mais quase sempre viram três pessoas trabalhando e o resto assistindo.

Como avaliar o aluno individualmente num trabalho em grupo?

Colete pelo menos um sinal individual por aluno além da entrega coletiva: uma pergunta de saída respondida sozinho no fim da aula, pedir que um integrante sorteado explique um trecho do código entregue, ou aplicar na aula seguinte uma versão menor do mesmo problema para fazer individualmente. Sinal coletado vale mais que impressão do professor.

É melhor sortear os grupos ou deixar os alunos escolherem?

Os dois, em momentos diferentes. Sorteio nas primeiras semanas quebra panelinha e faz todo mundo trabalhar com todo mundo. Depois disso, escolha por afinidade ou convite entre alunos funciona melhor, porque as escolhas passam a ser informadas pelo trabalho e não apenas sociais.

Como evitar o aluno carona no trabalho em grupo?

Mudando o desenho, não vigiando. Use enunciados grandes demais para uma pessoa só, papéis rotativos dentro do grupo (quem digita, quem lê o enunciado, quem testa, quem escreve a explicação) e pelo menos uma checagem individual por exercício. Quando o aluno sabe que vai precisar explicar um trecho, ele participa.

Trabalho em grupo funciona em turma online?

Funciona, mas exige um canal de combinação e uma entrega visível para o professor. Sem isso, o grupo online tende a se dividir em pedaços que ninguém junta. Defina prazo de fechamento do grupo, um lugar único para a conversa e uma entrega compartilhada em que dá para ver quem contribuiu.