1. Dicas
1.1. Trocar computadores
1.2. Fazer pausas juntos
1.3. Faça quando necessário - e possível
1.4. Silêncio significa que algo está errado no processo
1.5. Paciência
1.6. A dupla deve saber tudo sobre o processo de PP
1.7. Muitas Interrupções significam que é hora de trocar cargos
1.8. Use papel e caneta para ilustrar ideias e estratégias
1.9. Tenha um mentor
2. Problemas
2.1. Ausência temporária do Motorista
2.2. "Siga o mestre"
2.3. Aumento na relação Homem/Hora
2.4. Alinhamento dos Horários de Trabalho
2.5. Devs que não compartilham conhecimento
2.6. Evitar ao máximo a relação Professor-Aluno
3. Cenários
3.1. Expert - Expert
3.1.1. Não questionam processos
3.2. Expert - Novato
3.2.1. Melhor cenário
3.2.2. Permite treinar o novato
3.2.3. Dificilmente trazem novas ideias
3.3. Novato - Novato
3.3.1. Não tem boa performance
3.4. Extrovertidos vs Introvertidos
4. Cargos
4.1. Motorista
4.1.1. Escreve o código
4.1.2. Nome vem do Rally
4.2. Navegador
4.2.1. certifica
4.2.1.1. Um ambiente limpo
4.2.1.2. Um ambiente consistente, sem distrações
4.2.2. Mapeia o curso de ação
4.2.2.1. Tenta aplicar refactoring oportuno
4.2.3. Corrige o curso
4.2.3.1. YAGNI
4.2.3.2. KISS
4.2.3.3. Ciclo TDD
4.2.4. evita
4.2.4.1. Interromper muitas vezes
4.2.4.2. Ditar ordens
4.3. Ambos
4.3.1. Negociam decisões
4.3.2. Se importam com o código
5. Introdução
5.1. eXtreme Programming
5.2. Como fazer
5.2.1. Trocar pares por estória
5.2.2. Trocar cargos frequentemente
6. Estação de trabalho
6.1. Dupla Lado a Lado
6.2. Monitores Grandes
6.3. Diferentes Ambientes
6.3.1. Trocar de estação
7. Benefícios
7.1. Qualidade
7.1.1. Código mais declarativo
7.1.2. Visões diferentes do Problema
7.1.3. Experiências diferentes
7.1.4. Negociação
7.1.4.1. Melhor design de código
7.2. Aprendizado
7.2.1. Conhecimento Compartilhado
7.2.1.1. Nivelamento do Time
7.2.2. Ambientação mais rápida
7.3. Team Building e Comunicação
7.3.1. Devs se sentem mais partes da equipe e do projeto
7.3.2. "Nós" (versus o antigo "eu")
7.3.2.1. Nós fizemos isso
7.3.2.2. Nós sabemos como funciona
7.3.2.3. Nós temos orgulho disso
7.4. Economia
7.4.1. Menos Bugs
7.4.1.1. Menos Custos de Manutenção
7.5. Foco
7.6. Menor necessidade de Code Reviews
8. Funciona para todos os casos?
8.1. Funciona
8.1.1. Quando você está bloqueado
8.1.1.1. Rubber duck debugging
8.1.2. Criatividade
8.1.3. Sofisticação
8.1.4. Visão incompleta do problema
8.1.5. Ambientação no Projeto / Recurso
8.2. Não Funciona
8.2.1. Tarefas Simples
8.2.2. Novato com Novato
8.2.2.1. exceto quando há um mentor
8.2.3. Conhecimento completo do problema
9. Como convencer sua equipe
9.1. Faça o teste com e sem PP!
9.1.1. Tente por Releases, não por estórias
9.1.2. O PP deve render da mesma forma
9.1.3. Lembre-se que quase todos os projetos acabam atrasando