Pairing & Mob no Celular

Um guia para compartilhamento de simuladores, etiqueta do laboratório de dispositivos e normas de revisão em equipes do Expo SDK 57 - o pairing mobile falha quando apenas uma pessoa vê a tela.

Receita

Cartão de sessão de referência rápida - cole no convite do calendário.

## Sessão de pairing - <feature>
- Driver: <nome> (teclado)
- Navegador: <nome> (lê em voz alta, observa o sim)
- Dispositivo: iPhone 16 sim + Pixel 8 API 35 emu
- Branch: feature/<ticket>
- Rotacionar: 25 min
- Concluído quando: PR aberto com captura de tela + saída de teste

# Verificação compartilhada antes de encerrar a sessão
npm run lint && npm run typecheck && npm test
npx expo start --dev-client   # se módulos nativos

Quando usar isso:

Capstone da semana de onboarding e primeira instalação de prévia EAS.
Depuração de conflitos de gestos, sobreposição de teclado ou bugs de área segura.
Revisão do candidato a lançamento antes do envio para a loja.
Ensino do painel EAS e fluxos de credenciais - nunca sozinho com chaves de produção.

Exemplo de Trabalho

Configuração de pairing remoto

Ferramenta	Uso para	Dica mobile
Zoom / Meet	Espelhamento de sim, câmera facial	Compartilhe janela e não a tela inteira - oculte notificações
VS Code Live Share	Mesmo buffer, terminal compartilhado	Driver executa Metro; navegador observa o sim no stream
QuickTime (macOS)	Vídeo nítido do sim iOS	Arquivo → Nova Gravação de Filme → escolha a janela do Simulador
scrcpy	Espelhamento de dispositivo Android	`scrcpy --stay-awake` para sessões de dispositivo físico

# Driver - início padrão
npx expo start --clear
 
# Navegador - verificar na segunda plataforma sem parar o Metro
# pressione a / i no terminal compartilhado com consentimento do driver

Normas:

Navegador pergunta antes de assumir o teclado - "se importa se eu dirigir para reproduzir?"
Mantenha uma instância do Metro - um segundo expo start causa confusão de porta
Silencie quando não estiver falando; ative o som para ler mensagens de erro em voz alta - depuração silenciosa desperdiça tempo do mob

Checklist de compartilhamento de simulador

## Antes da sessão
- [ ] Mesma Node 20 + `npm ci` concluída em ambas as máquinas
- [ ] Mesmo branch git selecionado
- [ ] Simuladores nomeados: iPhone 16, Pixel_8_API_35
- [ ] Valores de .env.local confirmados (API de staging)
 
## Durante a sessão
- [ ] Redbox reproduzido em iOS e Android uma vez para bugs de UI
- [ ] Escala de fonte 100% padrão; teste XL se for um ticket de a11y
- [ ] Modo escuro alternado se relacionado ao tema
 
## Após a sessão
- [ ] Descrição do PR inclui capturas de tela de ambas as plataformas
- [ ] Nenhum experimento de `app.config.ts` não confirmado deixado na máquina do driver

Nomes de dispositivos padrão remetem aos Princípios Básicos de Onboarding - scripts da equipe npm run ios:16 reduzem o atrito do pairing.

Etiqueta do laboratório de dispositivos

Dispositivos físicos superam simuladores para câmera, push, biometria e desempenho.

## Prateleira do laboratório de dispositivos - normas da equipe
 
### Checkout
- Assine o dispositivo na #device-lab ou folha: nome, data, ticket
- Anote o adesivo da versão do SO no berço (iOS 18.2, Android 15)
 
### Higiene
- Saia das contas pessoais Apple/Google antes de devolver
- Limpe os dados do aplicativo para compilações de staging ao testar fluxos de autenticação
- Carregue até 80%+ antes do check-in; o cabo fica com o berço
 
### Contas de staging compartilhadas
- Use credenciais do cofre da equipe - nunca contas pessoais com 2FA
- Altere senhas trimestralmente; documente no cofre do 1Password
 
### Dispositivos quebrados / instáveis
- Etiqueta vermelha "não usar" + post no Slack - hardware instável desperdiça horas de mob

# Instalação de build interno iOS - o colega verifica se o UDID está registrado
eas device:create
eas build --profile preview --platform ios
 
# Sideload do APK Android
eas build --profile preview --platform android
# QR do painel EAS - ambos observam o sucesso da instalação

Relacionado: Princípios Básicos de Build EAS - distribuição interna | Distribuição Interna

Formato de mob programming (3+ pessoas)

Funções rotacionam a cada fatia:
  Driver     - digita
  Navegador  - estratégia, lê tickets
  Pesquisador - docs, Sentry, fóruns Expo
  Operador de dispositivo - dispositivo físico + capturas de tela (quinto opcional)

Fatias de 25 minutos:

Reprodução - mostrar bug no sim + dispositivo
Hipótese - navegador declara teoria antes do código
Mudança - menor diferença
Verificação - testes + ambas as plataformas
Retrospectiva 2m - o que nos atrasou?

## Regras de Mob (mobile)
- Não executar Metro em paralelo em branches diferentes no meio da sessão
- Credenciais de produção EAS: apenas para seniores, grupo observa
- Mesclar apenas depois que todos viram testes verdes no stream

Normas de revisão de PR (específico para mobile)

Exija evidências além do CI verde:

Tipo de alteração	Revisor espera
Layout / espaçamento	Capturas de tela iOS + Android; anote a classe do dispositivo
Gestos / sheets	Gravação de tela ou passos de reprodução pareados
Navegação	Caminho de deep link ou comportamento da pilha de retorno descrito
Permissões	Captura de tela das caixas de diálogo permitir/negar
Adjacente nativo	`build_id` de prévia ou versão do cliente de desenvolvimento anotada
Desempenho	Antes/depois se lista ou animação foi tocada

Modelos de comentários de revisão:

<!-- Solicitar evidência do dispositivo -->
Obrigado - por favor, adicione a captura de tela do Android; a área segura do iOS parece correta.
 
<!-- Solicitar build de prévia -->
Isso adiciona um plugin de configuração - por favor, acione `needs-preview` e cole o link do EAS.
 
<!-- Aprovar com nota do dispositivo -->
Verificado no sim iPhone 16 + emu Pixel 8 - LGTM.

Normas de SLA:

Primeira revisão em 1 dia útil para PRs de onboarding
Revisão em par (sincronização de 15m) quando o PR tocar em app/_layout.tsx, app.config.ts ou eas.json

Pairing em EAS e lançamento

Nunca sozinho ao tocar nas primeiras credenciais de produção - faça o mob da checklist.

## Checklist de pairing de lançamento (45m)
- [ ] Confirmar `build_id` do RC corresponde à folha de aprovação de QA
- [ ] Driver compartilha painel EAS somente leitura; navegador lê os passos em voz alta
- [ ] `eas submit` apenas após Maestro smoke verde
- [ ] Documento de rollback aberto: links de rollback OTA + pausa de lançamento escalonado
- [ ] Links pós-envio no thread #releases

Relacionado: Princípios Básicos de CI/CD Mobile - lanes de lançamento vs PR

Mergulho Profundo

Quando o pairing supera a revisão assíncrona

Cenário	Par	OK Assíncrono
Capstone de onboarding na primeira semana	✓
Redbox Hermes apenas no dispositivo	✓
Mudança de cópia em `Text` estático		✓
Novo plugin de configuração Expo	✓
Erro de digitação no fixture de teste		✓
Maestro instável no CI	✓
Correção de tipo de API		✓

Antí-padrões

Antí-padrão	Correção
Capturas de tela de "Deixe-me compartilhar mais tarde"	Bloquear merge até que a evidência esteja no PR
Driver monopoliza o teclado por 2h	Rotação forçada de 25m
Revisão apenas com sim para ticket de câmera	Checkout obrigatório no laboratório de dispositivos
Duas pessoas executando `expo start` diferentes	Um Metro; driver é dono do terminal
Mob de 6 pessoas para um pequeno erro de digitação	Dividir - pairing para código, assíncrono para revisão

Inclusão e fusos horários

Rotacione o driver para que o júnior não navegue apenas por um mês
Grave clipes de reprodução curtos (menos de 2 min) para async APAC/EU - não gravações de mob de uma hora
Documente decisões no thread do PR - acordos apenas verbais excluem colegas ausentes

Cadência sugerida por tamanho de equipe

Tamanho da equipe	Cadência de pairing
3–4 engenheiros	2–3 sessões pareadas / semana
5–8	Mob semanal em lançamentos + pares ad-hoc
9+	Pods de pairing por área de funcionalidade; mob mensal entre pods

FAQs

O pairing parece lento - como justificamos isso?

Capstone de onboarding e bugs nativos são mais rápidos em pairing do que três rodadas de revisão assíncrona. Rastreie o tempo até o merge para tickets pareados vs solo em um sprint.

Sem orçamento para laboratório de dispositivos?

Mínimo: um dispositivo Android + um iOS da equipe, passado entre equipes. Simuladores cobrem 80%; pairing em hardware compartilhado para os 20%.

Equipe apenas remota?

Espelhamento de sim QuickTime + scrcpy + modelo de PR de captura de tela rigoroso. Reunião trimestral presencial ou envio de dispositivo para QA tátil.

Como o mob difere do standup?

O Mob produz código mesclado ou uma gravação de reprodução. O Standup sincroniza o status - não faça o mob do backlog inteiro no bloco do standup.

Relacionados

Princípios Básicos de Onboarding - configuração do simulador
Caminho de Aprendizagem da Primeira Semana - capstone com colega
Checklist do Tour pela Base de Código - agenda do tour em par
Nivelamento de RN de Júnior → Pleno - expectativas de autonomia
Builds de Prévia em PRs - distribuição de revisão por QR
Princípios Básicos de Configuração de Projeto - scripts compartilhados e nomes de dispositivos

Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Receita

Cartão de sessão de referência rápida - cole no convite do calendário.

## Sessão de pairing - <feature>
- Driver: <nome> (teclado)
- Navegador: <nome> (lê em voz alta, observa o sim)
- Dispositivo: iPhone 16 sim + Pixel 8 API 35 emu
- Branch: feature/<ticket>
- Rotacionar: 25 min
- Concluído quando: PR aberto com captura de tela + saída de teste

# Verificação compartilhada antes de encerrar a sessão
npm run lint && npm run typecheck && npm test
npx expo start --dev-client   # se módulos nativos

Quando usar isso:

Capstone da semana de onboarding e primeira instalação de prévia EAS.
Depuração de conflitos de gestos, sobreposição de teclado ou bugs de área segura.
Revisão do candidato a lançamento antes do envio para a loja.
Ensino do painel EAS e fluxos de credenciais - nunca sozinho com chaves de produção.

Exemplo de Trabalho

Configuração de pairing remoto

Ferramenta	Uso para	Dica mobile
Zoom / Meet	Espelhamento de sim, câmera facial	Compartilhe janela e não a tela inteira - oculte notificações
VS Code Live Share	Mesmo buffer, terminal compartilhado	Driver executa Metro; navegador observa o sim no stream
QuickTime (macOS)	Vídeo nítido do sim iOS	Arquivo → Nova Gravação de Filme → escolha a janela do Simulador
scrcpy	Espelhamento de dispositivo Android	`scrcpy --stay-awake` para sessões de dispositivo físico

# Driver - início padrão
npx expo start --clear
 
# Navegador - verificar na segunda plataforma sem parar o Metro
# pressione a / i no terminal compartilhado com consentimento do driver

Normas:

Navegador pergunta antes de assumir o teclado - "se importa se eu dirigir para reproduzir?"
Mantenha uma instância do Metro - um segundo expo start causa confusão de porta
Silencie quando não estiver falando; ative o som para ler mensagens de erro em voz alta - depuração silenciosa desperdiça tempo do mob

Checklist de compartilhamento de simulador

## Antes da sessão
- [ ] Mesma Node 20 + `npm ci` concluída em ambas as máquinas
- [ ] Mesmo branch git selecionado
- [ ] Simuladores nomeados: iPhone 16, Pixel_8_API_35
- [ ] Valores de .env.local confirmados (API de staging)
 
## Durante a sessão
- [ ] Redbox reproduzido em iOS e Android uma vez para bugs de UI
- [ ] Escala de fonte 100% padrão; teste XL se for um ticket de a11y
- [ ] Modo escuro alternado se relacionado ao tema
 
## Após a sessão
- [ ] Descrição do PR inclui capturas de tela de ambas as plataformas
- [ ] Nenhum experimento de `app.config.ts` não confirmado deixado na máquina do driver

Nomes de dispositivos padrão remetem aos Princípios Básicos de Onboarding - scripts da equipe npm run ios:16 reduzem o atrito do pairing.

Etiqueta do laboratório de dispositivos

Dispositivos físicos superam simuladores para câmera, push, biometria e desempenho.

## Prateleira do laboratório de dispositivos - normas da equipe
 
### Checkout
- Assine o dispositivo na #device-lab ou folha: nome, data, ticket
- Anote o adesivo da versão do SO no berço (iOS 18.2, Android 15)
 
### Higiene
- Saia das contas pessoais Apple/Google antes de devolver
- Limpe os dados do aplicativo para compilações de staging ao testar fluxos de autenticação
- Carregue até 80%+ antes do check-in; o cabo fica com o berço
 
### Contas de staging compartilhadas
- Use credenciais do cofre da equipe - nunca contas pessoais com 2FA
- Altere senhas trimestralmente; documente no cofre do 1Password
 
### Dispositivos quebrados / instáveis
- Etiqueta vermelha "não usar" + post no Slack - hardware instável desperdiça horas de mob

# Instalação de build interno iOS - o colega verifica se o UDID está registrado
eas device:create
eas build --profile preview --platform ios
 
# Sideload do APK Android
eas build --profile preview --platform android
# QR do painel EAS - ambos observam o sucesso da instalação

Relacionado: Princípios Básicos de Build EAS - distribuição interna | Distribuição Interna

Formato de mob programming (3+ pessoas)

Funções rotacionam a cada fatia:
  Driver     - digita
  Navegador  - estratégia, lê tickets
  Pesquisador - docs, Sentry, fóruns Expo
  Operador de dispositivo - dispositivo físico + capturas de tela (quinto opcional)

Fatias de 25 minutos:

Reprodução - mostrar bug no sim + dispositivo
Hipótese - navegador declara teoria antes do código
Mudança - menor diferença
Verificação - testes + ambas as plataformas
Retrospectiva 2m - o que nos atrasou?

## Regras de Mob (mobile)
- Não executar Metro em paralelo em branches diferentes no meio da sessão
- Credenciais de produção EAS: apenas para seniores, grupo observa
- Mesclar apenas depois que todos viram testes verdes no stream

Normas de revisão de PR (específico para mobile)

Exija evidências além do CI verde:

Tipo de alteração	Revisor espera
Layout / espaçamento	Capturas de tela iOS + Android; anote a classe do dispositivo
Gestos / sheets	Gravação de tela ou passos de reprodução pareados
Navegação	Caminho de deep link ou comportamento da pilha de retorno descrito
Permissões	Captura de tela das caixas de diálogo permitir/negar
Adjacente nativo	`build_id` de prévia ou versão do cliente de desenvolvimento anotada
Desempenho	Antes/depois se lista ou animação foi tocada

Modelos de comentários de revisão:

<!-- Solicitar evidência do dispositivo -->
Obrigado - por favor, adicione a captura de tela do Android; a área segura do iOS parece correta.
 
<!-- Solicitar build de prévia -->
Isso adiciona um plugin de configuração - por favor, acione `needs-preview` e cole o link do EAS.
 
<!-- Aprovar com nota do dispositivo -->
Verificado no sim iPhone 16 + emu Pixel 8 - LGTM.

Normas de SLA:

Primeira revisão em 1 dia útil para PRs de onboarding
Revisão em par (sincronização de 15m) quando o PR tocar em app/_layout.tsx, app.config.ts ou eas.json

Pairing em EAS e lançamento

Nunca sozinho ao tocar nas primeiras credenciais de produção - faça o mob da checklist.

## Checklist de pairing de lançamento (45m)
- [ ] Confirmar `build_id` do RC corresponde à folha de aprovação de QA
- [ ] Driver compartilha painel EAS somente leitura; navegador lê os passos em voz alta
- [ ] `eas submit` apenas após Maestro smoke verde
- [ ] Documento de rollback aberto: links de rollback OTA + pausa de lançamento escalonado
- [ ] Links pós-envio no thread #releases

Relacionado: Princípios Básicos de CI/CD Mobile - lanes de lançamento vs PR

Mergulho Profundo

Quando o pairing supera a revisão assíncrona

Cenário	Par	OK Assíncrono
Capstone de onboarding na primeira semana	✓
Redbox Hermes apenas no dispositivo	✓
Mudança de cópia em `Text` estático		✓
Novo plugin de configuração Expo	✓
Erro de digitação no fixture de teste		✓
Maestro instável no CI	✓
Correção de tipo de API		✓

Antí-padrões

Antí-padrão	Correção
Capturas de tela de "Deixe-me compartilhar mais tarde"	Bloquear merge até que a evidência esteja no PR
Driver monopoliza o teclado por 2h	Rotação forçada de 25m
Revisão apenas com sim para ticket de câmera	Checkout obrigatório no laboratório de dispositivos
Duas pessoas executando `expo start` diferentes	Um Metro; driver é dono do terminal
Mob de 6 pessoas para um pequeno erro de digitação	Dividir - pairing para código, assíncrono para revisão

Inclusão e fusos horários

Rotacione o driver para que o júnior não navegue apenas por um mês
Grave clipes de reprodução curtos (menos de 2 min) para async APAC/EU - não gravações de mob de uma hora
Documente decisões no thread do PR - acordos apenas verbais excluem colegas ausentes

Cadência sugerida por tamanho de equipe

Tamanho da equipe	Cadência de pairing
3–4 engenheiros	2–3 sessões pareadas / semana
5–8	Mob semanal em lançamentos + pares ad-hoc
9+	Pods de pairing por área de funcionalidade; mob mensal entre pods

FAQs

O pairing parece lento - como justificamos isso?

Capstone de onboarding e bugs nativos são mais rápidos em pairing do que três rodadas de revisão assíncrona. Rastreie o tempo até o merge para tickets pareados vs solo em um sprint.

Sem orçamento para laboratório de dispositivos?

Mínimo: um dispositivo Android + um iOS da equipe, passado entre equipes. Simuladores cobrem 80%; pairing em hardware compartilhado para os 20%.

Equipe apenas remota?

Espelhamento de sim QuickTime + scrcpy + modelo de PR de captura de tela rigoroso. Reunião trimestral presencial ou envio de dispositivo para QA tátil.

Como o mob difere do standup?

O Mob produz código mesclado ou uma gravação de reprodução. O Standup sincroniza o status - não faça o mob do backlog inteiro no bloco do standup.

Relacionados

Princípios Básicos de Onboarding - configuração do simulador
Caminho de Aprendizagem da Primeira Semana - capstone com colega
Checklist do Tour pela Base de Código - agenda do tour em par
Nivelamento de RN de Júnior → Pleno - expectativas de autonomia
Builds de Prévia em PRs - distribuição de revisão por QR
Princípios Básicos de Configuração de Projeto - scripts compartilhados e nomes de dispositivos

Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Pairing & Mob no Celular

Buscar na documentação

Pairing & Mob no Celular