RicardoTecPro

04-guia-professor

Leitura de 10 min

🎯 Guia do Professor - Aula 04: Pair Programming

Disciplina: Desenvolvimento de Sistemas II
Professor: Ricardo Pires
Turma: 3º Técnico em Desenvolvimento de Sistemas
Duração: 105 minutos (2h45 acadêmicas)
Data: 30/03/2026

📋 Preparação Pré-Aula

🖥️ Setup Técnico (15 min antes)

# Verificar laboratório - cada estação deve ter:
# 1. VS Code com Live Share extension ativado
# 2. Java 21 + Maven configurados
# 3. Git inicializado
# 4. Timer visible (pode ser stopwatch web)
 
# Comandos para verification:
java --version  # Deve mostrar 21+
mvn --version   # Deve estar configurado
code --list-extensions | grep -i "live-share"  # Extension ativa

👥 Organização de Duplas

  • 16 alunos → 8 duplas estratégicas
  • Mix de experience levels: 1 mais experiente + 1 iniciante por dupla
  • Evitar duplas que já trabalham juntos frequentemente
  • Reserve 1 estação extra para demonstration do professor

📱 Materiais de Apoio

  • Projetor com código template
  • Timers voor pair alternation (15-20 min cycles)
  • Checklist impresso com debugging targets
  • Flip chart para capture insights during exercises

⏱️ Roteiro Detalhado de Aula

🎬 Abertura Impactante (10 min)

// Demo code - mostrar no projetor:
public class BugProductionExample {
    // Live demonstration: professor programa sozinho
    // Comete erro sutil (assignment vs comparison)
    // Simula não notar o bug
    // Pergunta para turma: "Alguém viu algo estranho?"
    // Transição: "E se tivesse alguém revisando em tempo real?"
}

🎯 Objetivo: Estabelecer necessidade de pair programming através de demonstration prática.

📚 Fundamentação Teórica (25 min)

Bloco 1: Conceitos Core (10 min)

  • Slides 1-4: Definição, papéis Driver/Navigator
  • Interaction: “Quem já trabalhou em dupla em algum projeto? Como foi?”
  • Live Demo: Professor + aluno volunteers para 3-minute pairing session

Bloco 2: TDD + Pair Programming (10 min)

  • Slides 5-6: Red-Green-Refactor com two people
  • Demonstration: Implementar 1 teste simples em dupla com turma watching
  • Emphasizar: Quality emerge through real-time discussion

Bloco 3: Benefits & Trade-offs (5 min)

  • Slides 7-8: ROI data, when NOT to use
  • Reality check: “Nem tudo precisa ser feito em dupla”
  • Practical guidance: Identify high-value pairing scenarios

🧪 Exercícios Práticos (60 min)

Exercício 1: TDD Calculadora (35 min)

// Professor monitoring strategy:
// Minutes 0-5: Setup duplas, explain exercise
// Minutes 5-20: Round 1 (Navigator A + Driver B)
// Minutes 20-25: Quick retrospective + role switch
// Minutes 25-40: Round 2 (Navigator B + Driver A)
// Minutes 40-45: Group reflection on findings
 
// Key observation points:
// ✅ Are they alternating naturally?
// ✅ Is Navigator truly guiding vs watching passively?
// ✅ Are design decisions discussed before implementation?
// ✅ Quality of communication (technical explanations)?

🚨 Common Issues & Interventions:

  • Silent Navigator: “Navigator, what do you think about this approach?”
  • Driver going too fast: “Driver, explain your thinking before typing”
  • Disagreement: “Great! Discuss both approaches before deciding”
  • One person dominates: Encourage quiet person with specific questions

Exercício 2: Debug Colaborativo (25 min)

// Debugging supervision approach:
// Minutes 0-3: Distribute bug-filled code
// Minutes 3-18: Active bug hunting in pairs
// Minutes 18-23: Solutions presentation by 2-3 duplas
// Minutes 23-25: Quick debrief on collaboration effectiveness
 
// Target bugs for supervision:
// 1. NullPointerException (initialization)
// 2. Assignment vs comparison (= vs ==)
// 3. Wrong method name (length vs size)
// 4. Missing null checks
// 5. Logic error in return statements
 
// Professor intervention points:
// If dupla stuck > 5 minutes: provide 1 small hint, not full solution
// If they find bug quickly: "Great! Can you explain WHY this breaks?"
// If missing obvious bug: "What happens if this variable is null?"

🎯 Estratégias Pedagógicas Específicas

👁️ Observational Assessment

Communication Quality Rubric:

LevelNavigator BehaviorDriver BehaviorCollaboration Quality
ExemplarAsks thoughtful questions, guides strategyExplains before coding, receptive to inputNatural flow, equal participation
ProficientProvides some guidance, catches some errorsBasic explanation of actionsOne leads but other contributes
DevelopingMostly watching, occasional inputCodes without much explanationUnequal participation
BeginnerSilent observerIndependent work ignoring partnerWorking separately on same computer

Intervention Strategies per Level:

  • Exemplar: Challenge with harder problems, ask to help struggling dupla
  • Proficient: Encourage more strategic thinking: “What edge cases should we consider?”
  • Developing: Provide sentence starters: “Navigator, try asking: ‘What if…‘”
  • Beginner: Stop and reset: “Let’s practice just the communication part first”

🔄 Pair Rotation Strategy

When to Rotate Duplas:

  • NOT during exercises (disrupts flow)
  • Between major exercises (after Calculator, before Debugging)
  • Strategic recomposition: Mix experience levels differently
  • Performance balancing: Split dominant partnerships, strengthen struggling ones

Rotation Announcement:

"Great work on TDD! For debugging exercise, let's form new duplas.
This gives you chance to experience different collaboration styles.
New partnerships on screen..."

💡 Scaffolding for Struggling Pairs

Microinterventions:

// If you observe silent pair or one-way collaboration:
 
Approach: "How's it going here?"
Listen: Let them explain their process
Diagnose: Identify specific barrier
Intervene:
  - "Driver, walk Navigator through your thinking"
  - "Navigator, what questions do you have about this approach?"
  - "Both: before writing next line, agree on what it should do"
 
// Don't solve their technical problem - solve their collaboration problem

Escalation Strategy:

  1. Gentle reminder about pair roles (30 seconds)
  2. Specific prompt for engagement (“Navigator, any concerns?“)
  3. Brief demonstration with that dupla (2 minutes)
  4. Partner consultation as last resort

🎭 Managing Common Scenarios

😤 “This is slower than working alone!”

Response Strategy:

"You're absolutely right! Pair programming is 15% slower initially.
But look at this code quality compared to work done individually yesterday.
Real question: Would you rather move fast and fix bugs later,
or move thoughtfully and ship higher quality?"

// Follow up with data from slides about 85% fewer bugs making it to production

🤐 “My partner isn’t participating”

Diagnostic Questions:

  • “Are you involving them in decisions?”
  • “Are you explaining your thought process?”
  • “Have you asked for their opinion on the approach?”

Often the “non-participating” partner needs explicit invitation to engage

⚔️ “We disagree on the approach”

Facilitation Framework:

1. "Both approaches sound interesting. Can each of you explain yours?"
2. "What would you expect to happen with Approach A vs B?"
3. "Is there a quick way to test both hypotheses?"
4. "For now, pick one, implement it, then evaluate. Learning either way!"

🏃‍♂️ “We finished early, what now?”

Extensions in Order:

  1. Add more test cases covering edge scenarios
  2. Refactor for better design (extract methods, improve naming)
  3. Help nearby dupla as consultants (without taking over)
  4. Implement additional feature (scientific calculator functions)

📊 Assessment & Documentation

🎯 Real-time Assessment Tracking

Use simple tracking sheet:

| Dupla | Exercise 1 | Exercise 2 | Communication | Collaboration | Technical Quality |
|-------|------------|------------|---------------|---------------|------------------|
| João/Ana | ✅ Alternated well | 🔍 Found 4 bugs | 🗣️ Clear explanations | 🤝 Equal participation | 🧪 Good test coverage |

Legend: ✅ Excellent, 🔍 Good, ⚠️ Needs work, ❌ Struggled

📝 Learning Evidence Collection

Collect throughout class:

  • Photo of pairs actively collaborating (with permission)
  • Code screenshots showing quality improvements via pairing
  • Student quotes about pair programming experience
  • Bug detection comparisons (pair vs individual time)

🎓 Exit Ticket Questions

1. O que foi mais difícil no pair programming hoje?
2. Qual a principal diferença de qualidade você notou?
3. Em que situação você usaria pair programming no trabalho?
4. Que skill personal você quer desenvolver para next pair session?

🔄 Adaptações para Diferentes Cenários

🌐 Turma Remota via Google Meet

Setup Modifications:

# Technology prereqs:
- VS Code Live Share working for all alunos
- Breakout rooms configured (8 rooms for 8 duplas)
- Screen sharing enabled in each breakout
- Main room timer visible to all

# Exercise modifications:
- Shorter exercício duration (account for tech overhead)
- Clearer written instructions (can't hover and help)
- More frequent check-ins via main room
- Backup communication (chat/WhatsApp) for tech issues

Engagement Strategies:

  • Verbal check-ins: Call each breakout every 10 minutes
  • Async help: Students can message for support
  • Demo recordings: Pre-record demos for repeated viewing
  • Digital collaboration: Use Miro/Figma for design discussions

📚 Advanced/Gifted Students Track

Escalation Challenges:

// Once they master basic pair programming:
// Extension 1: Mob programming (3-4 people on complex feature)
// Extension 2: Pair on refactoring legacy code (realistic messiness)
// Extension 3: Pairing with constraints (navigator can't see screen)
// Extension 4: Cross-functional pairing (QA + dev, designer + dev)

🎯 Struggling Students Support

Simplified Approach:

// If basic pair programming is overwhelming:
// Modification 1: Start with "think aloud" individual coding
// Modification 2: Pair observer (one codes, other takes notes)
// Modification 3: Switch every line instead of every 15 minutes
// Modification 4: Use explicit scripts: "Navigator says: 'What if...'"

📈 Success Metrics & Follow-up

🎯 Immediate Success Indicators

  • 90%+ students report positive pair programming experience
  • Each dupla successfully completes at least 1 full TDD cycle collaboratively
  • Visible alternation of Driver/Navigator roles every 15-20 minutes
  • Quality improvement demonstrated (fewer bugs in paired code)
  • Active engagement during collaborative debugging exercise

📊 Long-term Learning Tracking

Week 1 Follow-up:

// Homework reflection analysis:
// - Are students applying "think aloud" practice?
// - Do they report better bug detection via verbalization?
// - Any spontaneous pair programming usage?
 
// Next assignment integration:
// Optional pair programming for complex individual project
// Required reflection on collaboration tools usage

Month 1 Assessment:

// Integration metrics:
// - How many students form study pairs independently?
// - Code quality trends in individual vs paired assignments
// - Self-reported confidence in collaborative coding
// - Technical communication skill development
 
// Curriculum integration:
// Design Patterns lesson: pairs design solutions
// Final project option: pair programming track with doubled complexity

🔄 Continuous Improvement

Post-Lesson Reflection Questions:

  1. What pair dynamics worked best? (experience mixing, personality types)
  2. Which exercises generated most engagement? (adjust time allocation)
  3. What technical/communication barriers emerged? (address in next lesson)
  4. How can I better scaffold pair programming skills? (pedagogy refinement)

Student Feedback Integration:

Weekly survey questions:
- "Rate your pair programming confidence: 1-10"
- "Best partnership dynamic you've experienced?"
- "What tools would help remote pair programming?"
- "Most valuable pair programming use case for your career?"

🎯 Próximas Aulas: Building on Pair Programming

🔗 Aula 05 Integration: Design Patterns via Collaboration

// Natural progression from pair programming:
// Use pairs to collaboratively design pattern implementations
// Navigator identifies pattern need, Driver implements solution
// Scaffolds complex architecture discussions through proven collaboration

📈 Skill Progression Pathway:

  • Aula 04: Basic pair programming + TDD collaboration
  • Aula 05: Collaborative design decisions (patterns)
  • Aula 06: Team programming (mob programming introduction)
  • Project Final: Option for pair programming with complex requirements

✅ Professor Pre-Flight Checklist

📋 Technical Setup

  • Lab stations configured with Java 21 + VS Code Live Share
  • Timer applications functional and visible
  • Debugging code prepared with intentional bugs
  • Backup plans for technology failures
  • Assessment tracking sheets printed and ready

📚 Pedagogical Preparation

  • Dupla assignments strategically planned (experience mixing)
  • Intervention strategies reviewed for common scenarios
  • Extension activities prepared for fast-finishing pairs
  • Scaffolding approaches ready for struggling students
  • Success metrics clearly defined and observable

🎭 Mindset & Energy

  • High energy for modeling productive collaboration
  • Growth mindset prepared for messiness of learning collaboration
  • Patience for slower pace during skill acquisition
  • Celebrate small wins in collaboration quality
  • Flexibility to adapt based on real-time classroom dynamics

🎯 Remember: Today’s goal is cultivating collaborative technical skills, not just coding proficiency. Success means students leave wanting to pair program again.

Next Class Integration: Design Patterns via Collaborative Design → leverage today’s pair programming success as foundation for more complex collaborative problem-solving.

Visão de gráfico