📋 Plano de Aula 04 - Pair Programming

Programação em Par para Qualidade e Transferência de Conhecimento

Desenvolvimento de Sistemas II
Prof. Ricardo Pires
3º Técnico DS
Data: 30/03/2026
Duração: 105 minutos (3 aulas de 35 min)
Modalidade: Presencial com atividades práticas em dupla

🎯 Objetivos da Aula

Objetivo Geral

Capacitar os estudantes a aplicar a técnica de Pair Programming como ferramenta para melhoria da qualidade de código, transferência de conhecimento e redução de bugs em projetos de desenvolvimento.

Objetivos Específicos

Conceituais (Saber)

Compreender os princípios fundamentais do Pair Programming
Identificar os papéis Driver e Navigator e suas responsabilidades
Conhecer os benefícios e desafios da programação colaborativa
Entender quando aplicar pair programming no desenvolvimento profissional

Procedimentais (Saber Fazer)

Aplicar Test-Driven Development (TDD) em duplas
Executar debugging colaborativo de forma sistemática
Implementar alternância de papéis de forma eficiente
Conduzir revisão de código em tempo real

Atitudinais (Saber Ser)

Desenvolver habilidades de comunicação técnica
Cultivar mentalidade colaborativa no desenvolvimento
Valorizar a qualidade coletiva sobre velocidade individual
Praticar humildade intelectual e feedback construtivo

📚 Fundamentação Teórica

📖 Base Conceitual

A aula baseia-se nos conceitos de:

Extreme Programming (XP) - metodologia ágil que popularizou pair programming
Test-Driven Development - desenvolvimento orientado por testes
Code Review - revisão colaborativa de código
Knowledge Transfer - transferência de conhecimento técnico

🔗 Conexão com Aulas Anteriores

Aula 01 (Código Limpo): Pair programming facilita escrita de código limpo através de revisão contínua
Aula 02 (DRY): Duplas identificam duplicação mais rapidamente que desenvolvedores individuais
Aula 03 (Refatoração): Navigator pode sugerir refatorações enquanto Driver implementa

🎯 Progressão Pedagógica

Qualidade Individual → Qualidade Colaborativa → Qualidade de Equipe
     (Aulas 1-3)    →     (Aula 4)      →    (Próximas aulas)

📋 Cronograma Detalhado

🚀 Primeira Aula (35 min): Fundamentação e Setup

⏱️ 0-10 min: Abertura Impactante

🎬 HOOK: "Quantos bugs vocês acham que poderiam ter evitado se outra pessoa estivesse olhando?"

Atividade quebra-gelo:

Pergunta provocativa (2 min): Experiências com bugs que “passaram despercebidos”
Demonstração rápida (5 min): Mostrar bug real encontrado via pair programming
Contexto profissional (3 min): Empresas que usam pair programming intensivamente

Recursos necessários:

Exemplo real de bug identificado via pair programming
Cases de empresas (Spotify, Pivotal, ThoughtWorks)

⏱️ 10-25 min: Conceitos Fundamentais

Objetivo: Estabelecer entendimento sobre papéis e dinâmica

Conteúdo estruturado:

Definição formal (3 min): Duas pessoas, um computador, um objetivo
Driver vs Navigator (7 min): Papéis, responsabilidades, alternância
Benefícios comprovados (5 min): Menos bugs, melhor design, transfer de conhecimento
Mitos e realidades (5 min): “Metade da produtividade” vs. qualidade superior
Setup físico (5 min): Ergonomia, teclado, monitor

Atividade prática: Simulação de 5 minutos em dupla (sem código)

⏱️ 25-35 min: Preparação para Live Coding

Objetivo: Setup técnico e formação de duplas

Ações:

Formação de duplas (3 min): Estratégia pedagógica para mix de níveis
Setup técnico (5 min): IDE, projeto Java, repositório Git
Definição de história (2 min): Feature simples para implementar via TDD

Resultado esperado:

Duplas formadas e funcionando
Ambiente técnico configurado
História de usuário definida para próxima aula

🔧 Segunda Aula (35 min): TDD Colaborativo

⏱️ 35-40 min: Demo Live Coding

Objetivo: Demonstrar TDD em par com troca de papéis

Professor demonstra:

Historia do usuário (1 min): “Como usuário, quero validar CPF para garantir dados corretos”
Red: Navigator sugere teste inicial (2 min)
Green: Driver implementa mínimo viável (2 min)

Script da demonstração:

// Navigator sugere: "Vamos começar testando CPF válido"
@Test
void deveValidarCpfValido() {
    assertTrue(CpfValidator.isValid("11144477735"));
}
 
// Driver implementa mínimo:
public static boolean isValid(String cpf) {
    return true; // Força teste a passar
}
 
// Navigator: "Precisa invalidar CPF inválido também"
@Test
void deveRejeitarCpfInvalido() {
    assertFalse(CpfValidator.isValid("123"));
}

⏱️ 40-60 min: Prática Guiada em Duplas

Objetivo: Alunos aplicam TDD colaborativo com suporte

Roteiro estruturado:

Distribuição do exercício (2 min): Implementar calculadora via TDD
Primeira rodada (8 min): Driver A + Navigator B implementam soma
Troca de papéis (1 min): Orientações para alternância
Segunda rodada (8 min): Driver B + Navigator A implementam subtração
Retrospectiva rápida (1 min): O que funcionou? O que foi difícil?

Problema proposto:

// Historia: Como usuário, quero uma calculadora para operações básicas
public class Calculadora {
    // TODO: implementar via TDD em dupla
}

⏱️ 60-70 min: Debugging Colaborativo

Objetivo: Aplicar pair programming para identificar e corrigir bugs

Atividade estruturada:

// Código com bug intencional fornecido
public class ContadorVisitas {
    private int visitas = 0;
 
    public void incrementar() {
        visitas++;
    }
 
    public String getStatus() {
        if (visitas = 1) {  // BUG: = ao invés de ==
            return "Primeira visita";
        }
        return "Visitas: " + visitas;
    }
}

Processo colaborativo:

Navigator identifica problema (3 min): Análise do código
Driver implementa correção (2 min): Aplicação da solução
Ambos validam (2 min): Testes manuais e automáticos
Documentão da solução (3 min): Commit com explicação

🌟 Terceira Aula (35 min): Aplicação Avançada e Consolidação

⏱️ 70-85 min: Projeto Colaborativo Complexo

Objetivo: Aplicar pair programming em cenário mais realista

Desafio proposto: Implementar sistema de login com validações usando TDD colaborativo:

Validação de email
Validação de força de senha
Autenticação simulada
Tratamento de erros

Metodologia:

Planning em dupla (3 min): Definir approach e divisão
Implementação iterativa (10 min): TDD com alternância a cada teste
Refatoração conjunta (2 min): Melhoria do código implementado

⏱️ 85-95 min: Showcase e Feedback

Objetivo: Apresentação das soluções e aprendizados

Dinâmica:

Apresentações rápidas (7 min): 3 duplas mostram soluções (2 min cada)
Feedback coletivo (3 min): Observações sobre diferenças nas abordagens

Pontos a destacar:

Qualidade das decisões tomadas em dupla
Diferenças na implementação solo vs. pair
Bugs evitados através de revisão contínua

⏱️ 95-105 min: Reflectão e Próximos Passos

Objetivo: Consolidar aprendizados e conectar com contexto profissional

Atividades de fechamento:

Retrospectiva estruturada (5 min):
- O que funcionou bem no pair programming?
- Quais dificuldades encontraram?
- Como podem aplicar isso em projetos futuros?
Conexão profissional (3 min):
- Quando usar pair programming no mercado
- Como negociar tempo para pair programming com gestores
- Ferramtas para pair programming remoto
Preview próxima aula (2 min): Design Patterns e como pair programming facilita discussões arquiteturais

🎨 Metodologias Ativas Aplicadas

👥 Aprendizagem Colaborativa

Peer Programming: Aprendizagem através de colaboração direta
Think-Pair-Share: Reflexão individual → discussão em dupla → compartilhamento coletivo
Cross-Pollination: Ideias circulam entre duplas diferentes

Zone of Proximal Development: Duplas com níveis diferentes se apoiam mutuamente
Scaffolding: Professor oferece suporte gradualmente reduzido
Authentic Assessment: Avaliação através de produtos reais (código)

🔄 Experiential Learning (Kolb)

Experiência Concreta: Prática real de pair programming
Observação Reflexiva: Análise do que funcionou/não funcionou
Conceituação Abstrata: Generalização para outros contextos
Experimentação Ativa: Aplicação em novos desafios

📊 Avaliação e Feedback

🎯 Critérios de Avaliação Formativa

Participação Colaborativa (40%)

Comunicação técnica: Explicações claras sobre decisões de código
Alternância efetiva: Troca natural de papéis Driver/Navigator
Feedback construtivo: Sugestões úteis e respeitosas
Engajamento: Participação ativa durante toda a atividade

Qualidade Técnica (35%)

Código funcional: Implementações que passam nos testes
Boas práticas: Aplicação de princípios de código limpo
TDD adherence: Seguimento do ciclo Red-Green-Refactor
Problem solving: Capacidade de resolver problemas em dupla

Metacognição (25%)

Auto-avaliação: Reflexão sobre próprio desempenho
Identification: Reconhecimento de momentos de aprendizagem
Transfer: Conexão com contextos profissionais futuros
Continuous improvement: Identificação de áreas para desenvolvimento

📝 Instrumentos de Avaliação

Observação Estruturada

✓ Dupla comunica decisões tecnincas claramente
✓ Alternância entre papéis acontece naturalmente
✓ Navigator contribui com sugestões úteis
✓ Driver explica código enquanto implementa
✓ Ambos engajados na resolução do problema
✓ Conflitos técnicos são resolvidos colaborativamente

Auto-avaliação Reflexiva

Perguntas para reflexão individual (5 min ao final):

Qual papel (Driver/Navigator) foi mais confortável? Por quê?
Que tipo de contribuição seu par forneceu que você não teria pensado sozinho?
Como a qualidade do código final compara com seu trabalho individual?
Em que situações profissionais você aplicaria pair programming?

📈 Métricas de Sucesso da Aula

Indicadores Quantitativos

85% das duplas completam exercício básico (TDD calculadora)
70% das duplas identificam bug no debugging colaborativo
90% dos alunos relatam experiência positiva com pair programming
75% conseguem explicar quando usar pair programming profissionalmente

Indicadores Qualitativos

Discussions técnicas substantivas entre duplas
Evidências de mentoring natural (aluno experiente → iniciante)
Soluções de código visivelmente diferentes das produzidas individualmente
Feedback positivo sobre redução de frustração em debugging

🛠️ Recursos e Materiais

💻 Setup Técnico

Requisitos por Dupla

Computador com Java 21 e IDE (IntelliJ/Eclipse)
Projeto Maven pré-configurado com JUnit 5
Git configurado para commits colaborativos
Ergonomia: Dois assentos confortáveis, monitor compartilhado

Infraestrutura de Sala

Layout Ideal:
[Screen]
    🖥️      🖥️      🖥️
   👥      👥      👥   <- 6 duplas
   👥      👥      👥

Facilitação:
- Espaço para circulação do professor
- Projetor para demonstrações
- Quadro branco para conceitos

📁 Material de Apoio

Handouts Impressos

Quick Reference Card: Papéis Driver/Navigator
TDD Cheat Sheet: Ciclo Red-Green-Refactor
Keyboard Shortcuts: Para troca ágil de contexto
Troubleshooting Guide: Problemas comuns em duplas

Digital Resources

Projeto template no Git com README detalhado
Video complementar sobre pair programming remoto
Links para ferramentas de pair programming online
Exemplos de códigos antes/depois de pair programming

🧰 Toolkit do Professor

⚡ Facilitação Ágil

EFEITO: Dupla travada, não consegue decidir approach
AÇÃO: "Driver, implemente a primeira ideia. Navigator, anote objeções para próxima rodada"

EFEITO: Navigator muito passivo
AÇÃO: "Navigator, sua próxima função é parar o Driver se não entender uma linha"

EFEITO: Driver não explica o que está fazendo
AÇÃO: "Navigator, peça para Driver explicar cada linha antes de escrever"

📊 Monitoring Dashboard

Dupla	Alternância	Comunicação	Progresso	Interactions
1	✅ Regular	🔉 Boa	🎯 On track	💬 Ativa
2	⚠️ Pouca	🔇 Baixa	🐌 Lenta	😶 Silenciosa

🔄 Adaptações e Diferenciação

👥 Gestão de Diversidade de Níveis

Duplas Estratégicas

Iniciante + Avançado: Mentoring natural, mas cuidar para iniciante também ser Driver
Igual nível: Mais discussão, decisões conjuntas
Personalidades complementares: Introvertido + extrovertido pode funcionar bem

Scaffolding por Nível

INICIANTES:
- Histórias de usuário mais simples
- Templates de código mais estruturados
- Check-ins mais frequentes do professor

INTERMEDIÁRIOS:
- Desafios técnicos mais complexos
- Maior responsabilidade na escolha de approach
- Mentoring de duplas iniciantes

AVANÇADOS:
- Problemas abertos, múltiplas soluções válidas
- Lideração de demonstrações para turma
- Facilitation de discussions técnicas

🎯 Adaptações para Necessidades Especiais

Acessibilidade Física

Setup ergonômico adaptável para cadeirantes
Teclados alternativos para limitações motoras
Screen readers compatíveis com pair programming

Neurodivergência

Timer visível para alternância de papéis (autismo)
Ruído de fundo controlado (ADHD)
Instruções escritas além de verbais (dislexia)

📚 Fundamentação Pedagógica

🎓 Base Teórica

Vygotsky (ZPD): Pair programming coloca alunos em zona de desenvolvimento proximal
Bandura (Social Learning): Aprendizagem através de modeling e observation
Johnson & Johnson (Collaborative Learning): Interdependência positiva e accountability individual

🔬 Evidências Empíricas

Estudos mostram: 15% mais tempo, 15% menos bugs (Williams & Kessler, 2000)
Knowledge transfer: 42% maior retenção de conhecimento (Hulkko & Abrahamson, 2005)
Satisfação: 96% dos desenvolvedores reportam maior confiança no código (Cockburn & Williams, 2001)

🏢 Relevância Profissional

Industria adoption: 85% das empresas ágeis usam pair programming ocasionalmente
Remote work: Pair programming é ferramenta vital para equipes distribuídas
Onboarding: Reduz tempo de integração de novos desenvolvedores em 60%

🚨 Planos de Contingência

⚡ Problemas Técnicos

PROBLEMA: Computador não funciona
SOLUÇÃO: Tripletas temporárias + papel como backup

PROBLEMA: IDE crashes constantemente
SOLUÇÃO: Terminal + editor simples para TDD básico

PROBLEMA: Resistência à colaboração
SOLUÇÃO: Start com discussing approach antes de coding

👥 Dinâmica de Grupo

PROBLEMA: Dupla não consegue trabalhar junta
SOLUÇÃO: Rebalanceamento com facilitated discussion

PROBLEMA: Dominance de um membro
SOLUÇÃO: Timer rígido + roles claramente assign

PROBLEMA: Silêncio total
SOLUÇÃO: Structured prompts + mandatory explanations

⏱️ Tempo Insuficiente

PLANO A (Completo): TDD + Debugging + Projeto avançado
PLANO B (Core): TDD + Debugging apenas
PLANO C (Mínimo): TDD básico com reflection

🎯 Avaliação da Aula

📊 KPIs da Sessão

Engagement rate: 90%+ de participação ativa
Completion rate: 80%+ exercícios finalizados
Satisfaction score: 4.5+/5 na avaliação de reação
Learning retention: Aplicação em projetos futuros

🔄 Melhoria Contínua

Student feedback: Survey anonymous pósaula
Peer observation: Colega observa e fornece input
Video analysis: Review de momentos-chave gravados
Metrics tracking: Evolução dos KPIs ao longo dos semestres

Preparação é a base do sucesso em pair programming! 🚀

Explorador

01-plano-de-aula