7 min leitura • Guide 762 of 877
Desenvolvimento Mobile com GitScrum
Desenvolvimento mobile tem desafios únicos - múltiplas plataformas, processos de app store e fragmentação de dispositivos. GitScrum ajuda times a coordenar trabalho mobile efetivamente.
Estrutura de Projeto Mobile
Organização de Plataforma
ORGANIZAÇÃO DE PROJETO MOBILE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ABORDAGEM 1: STORIES COMPARTILHADAS │
│ │
│ STORY DE FEATURE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MOB-100: Adicionar Push Notifications ││
│ │ ││
│ │ Subtarefas: ││
│ │ ├── MOB-101: [iOS] Setup de push notification ││
│ │ ├── MOB-102: [Android] Setup de push notification ││
│ │ ├── MOB-103: [Backend] Endpoint de API push ││
│ │ └── MOB-104: [QA] Testar em ambas plataformas ││
│ │ ││
│ │ Labels: feature, ios, android, backend ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ABORDAGEM 2: LABELS DE PLATAFORMA │
│ │
│ Todas tarefas mobile: │
│ Labels: mobile + (ios | android | both) │
│ │
│ Filtros: │
│ • "Trabalho iOS": mobile + ios │
│ • "Trabalho Android": mobile + android │
│ • "Cross-platform": mobile + both │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ESTRUTURA DE TIME: │
│ │
│ OPÇÃO A: Times de plataforma │
│ Time iOS: Todo trabalho iOS │
│ Time Android: Todo trabalho Android │
│ → Bom para expertise nativa │
│ │
│ OPÇÃO B: Times de feature │
│ Membros do time fazem ambas plataformas │
│ → Bom para frameworks cross-platform │
│ │
│ OPÇÃO C: Híbrido │
│ Features owned por time, especialistas de plataforma support│
└─────────────────────────────────────────────────────────────┘
Planejamento de Release
GESTÃO DE RELEASE MOBILE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIMELINE DE RELEASE: │
│ │
│ Code freeze Submissão stores Release │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ────●──────────────────●───────────────●───────────── │
│ Dia 1 Dia 3 Dia 5-10 │
│ (após review) │
│ │
│ PLANEJAR PARA TEMPO DE REVIEW: │
│ iOS: 1-7 dias (geralmente 1-2 dias) │
│ Android: Geralmente < 1 dia (às vezes horas) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EPIC DE RELEASE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ REL-200: Release Versão 2.5.0 ││
│ │ ││
│ │ Release alvo: 15 Fev, 2024 ││
│ │ ││
│ │ Pré-submissão: ││
│ │ ☐ Code freeze (8 Fev) ││
│ │ ☐ QA sign-off (10 Fev) ││
│ │ ☐ Release notes preparadas ││
│ │ ☐ Screenshots atualizadas (se necessário) ││
│ │ ││
│ │ Submissão: ││
│ │ ☐ Submeter para App Store (11 Fev) ││
│ │ ☐ Submeter para Play Store (11 Fev) ││
│ │ ││
│ │ Pós-submissão: ││
│ │ ☐ Monitorar status de review ││
│ │ ☐ Endereçar feedback de rejeição ││
│ │ ☐ Coordenar release (15 Fev) ││
│ │ ││
│ │ Pós-release: ││
│ │ ☐ Monitorar crash reports ││
│ │ ☐ Observar reviews e ratings ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Considerações de App Store
Lidando com Rejeições
WORKFLOW DE REJEIÇÃO DE APP STORE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REJEIÇÃO RECEBIDA: │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 Rejeição App Store ││
│ │ ││
│ │ Motivo: Guideline 4.2 - Minimum Functionality ││
│ │ ││
│ │ "Your app appears to be a simple website..." ││
│ │ ││
│ │ AÇÕES IMEDIATAS: ││
│ │ 1. Criar tarefa: [URGENTE] Fix rejeição 4.2 ││
│ │ 2. Atribuir: Senior dev + Product ││
│ │ 3. Analisar: O que falta para atender guideline? ││
│ │ 4. Planejar: Features native necessárias ││
│ │ 5. Implementar: Adicionar funcionalidade ││
│ │ 6. Resubmeter ││
│ │ ││
│ │ Timeline impactada: +3-7 dias ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ GUIDELINES COMUNS DE REJEIÇÃO: │
│ ────────────────────────────── │
│ • 4.2 - Minimum Functionality │
│ • 2.1 - Performance: App Completeness │
│ • 3.1.1 - In-App Purchase │
│ • 5.1.1 - Data Collection and Storage │
│ │
│ PREVENÇÃO: │
│ ─────────── │
│ • Review guidelines antes de submeter │
│ • Checklist de compliance │
│ • Testers externos para pegar issues │
│ • Histórico de rejeições documentado │
│ │
└─────────────────────────────────────────────────────────────┘
Testing Mobile
Matriz de Dispositivos
ESTRATÉGIA DE TESTING MOBILE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MATRIZ DE DISPOSITIVOS: │
│ ──────────────────────── │
│ │
│ iOS: │
│ ├── iPhone 15 Pro (latest) │
│ ├── iPhone 13 (popular) │
│ ├── iPhone SE (small screen) │
│ ├── iPad Pro (tablet) │
│ └── iOS versions: 16, 17 │
│ │
│ Android: │
│ ├── Pixel 8 (reference) │
│ ├── Samsung S24 (popular) │
│ ├── Samsung A series (mid-range) │
│ ├── Xiaomi (different OEM) │
│ └── Android versions: 12, 13, 14 │
│ │
│ TIPOS DE TESTE: │
│ ──────────────── │
│ • Functional: Features funcionam │
│ • Performance: App é responsivo │
│ • Battery: Não drena bateria │
│ • Network: Funciona offline/low connectivity │
│ • Accessibility: Screen readers funcionam │
│ │
│ AUTOMAÇÃO: │
│ ─────────── │
│ • UI tests com XCTest / Espresso │
│ • Firebase Test Lab / AWS Device Farm │
│ • CI/CD integrado │
│ │
└─────────────────────────────────────────────────────────────┘
Dashboard Mobile no GitScrum
Visão de Projeto
DASHBOARD DE PROJETO MOBILE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPRINT ATUAL: Sprint 12 │
│ ───────────────────── │
│ │
│ POR PLATAFORMA: │
│ ┌──────────────────┬──────────────────┬──────────────────┐ │
│ │ iOS │ Android │ Both │ │
│ ├──────────────────┼──────────────────┼──────────────────┤ │
│ │ To Do: 5 │ To Do: 4 │ To Do: 3 │ │
│ │ In Progress: 3 │ In Progress: 2 │ In Progress: 1 │ │
│ │ Done: 8 │ Done: 7 │ Done: 6 │ │
│ └──────────────────┴──────────────────┴──────────────────┘ │
│ │
│ PARIDADE DE FEATURES: │
│ ───────────────────── │
│ │
│ Feature iOS Android │
│ ───────────────────────────────────── │
│ Dark Mode ✓ ✓ │
│ Push Notif ✓ ✓ │
│ Widget ✓ In Progress │
│ Share Extension ✓ N/A │
│ Deep Links ✓ ✓ │
│ │
│ PRÓXIMO RELEASE: │
│ ──────────────── │
│ │
│ Version: 2.5.0 │
│ Code Freeze: 8 Fev (em 5 dias) │
│ Target Release: 15 Fev │
│ Status: On Track ✓ │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE DESENVOLVIMENTO MOBILE COM GITSCRUM
════════════════════════════════════════════════
SETUP:
☐ Estrutura de projeto definida (shared vs separate)
☐ Labels de plataforma criados
☐ Filtros salvos configurados
☐ Templates de tarefas mobile
WORKFLOW:
☐ Stories com subtarefas por plataforma
☐ Processo de code review por plataforma
☐ Testing pipeline integrado
☐ Paridade de features rastreada
RELEASE:
☐ Epic de release template
☐ Checklist de submissão
☐ Timeline com buffer de review
☐ Processo de rejeição documentado
MONITORAMENTO:
☐ Crash reports integrados
☐ Reviews de app store monitoradas
☐ Métricas de performance rastreadas
☐ User feedback capturado
GitScrum unifica gestão de trabalho mobile enquanto respeita as particularidades de cada plataforma.