7 min leitura • Guide 551 of 877
Gestão de Projetos de Desenvolvimento Mobile
Desenvolvimento mobile traz desafios únicos—reviews de app store, múltiplas plataformas, fragmentação de dispositivos e capacidades offline. GitScrum ajuda times mobile a coordenar desenvolvimento iOS e Android, rastrear paridade de features e gerenciar ciclos de release que sincronizam com timelines de app stores. A chave é planejar para trabalho específico de plataforma enquanto maximiza esforço compartilhado.
Diferenças Mobile vs Web
| Aspecto | Mobile | Web |
|---|---|---|
| Deploy | Review de app store | Instantâneo |
| Updates | Usuário deve atualizar | Automático |
| Testing | Matriz de dispositivos | Matriz de browsers |
| Offline | Consideração crítica | Opcional |
| Performance | Restrições de dispositivo | Scaling de servidor |
| Guidelines | Regras de plataforma | Mais flexível |
Estrutura de Projeto Mobile
ORGANIZAÇÃO DE PROJETO
OPÇÃO 1: PROJETO ÚNICO COM LABELS DE PLATAFORMA
┌─────────────────────────────────────────────────┐
│ Projeto: MeuApp Mobile │
│ │
│ Labels: │
│ ├── [platform:ios] │
│ ├── [platform:android] │
│ ├── [platform:both] │
│ ├── [type:feature] │
│ ├── [type:bug] │
│ └── [type:store-requirement] │
│ │
│ Epics: │
│ ├── Autenticação de Usuário [both] │
│ ├── Push Notifications [both] │
│ ├── Widget iOS [ios] │
│ └── Widget Android [android] │
│ │
│ Melhor para: Time pequeno, framework cross-plat│
└─────────────────────────────────────────────────┘
OPÇÃO 2: PROJETOS SEPARADOS
┌─────────────────────────────────────────────────┐
│ Projeto: MeuApp iOS │
│ └── Trabalho específico iOS apenas │
│ │
│ Projeto: MeuApp Android │
│ └── Trabalho específico Android apenas │
│ │
│ Projeto: MeuApp Shared │
│ └── Backend, APIs, lógica compartilhada │
│ │
│ Melhor para: Times nativos separados │
└─────────────────────────────────────────────────┘
Workflow de Desenvolvimento Mobile
CICLO DE VIDA DE DESENVOLVIMENTO MOBILE
1. DESENVOLVIMENTO DE FEATURE
┌─────────────────────────────────────────────────┐
│ Feature: Suporte a Dark Mode │
│ │
│ Sub-tarefas: │
│ ☐ Design: Paleta de cores dark mode │
│ ☐ iOS: Implementar troca de dark mode │
│ ☐ iOS: Testar em dispositivos (iPhone 12-15) │
│ ☐ Android: Implementar troca de dark mode │
│ ☐ Android: Testar em dispositivos (Pixel, Sam) │
│ ☐ Ambos: Persistência de preferência │
│ ☐ Ambos: QA sign-off │
└─────────────────────────────────────────────────┘
│
▼
2. TESTING INTERNO
┌─────────────────────────────────────────────────┐
│ iOS: TestFlight testing interno │
│ ├── Build uploaded: v2.3.0 (build 456) │
│ ├── Testers internos: 15 usuários │
│ └── Duração: 3-5 dias │
│ │
│ Android: Track de testing interno │
│ ├── Build uploaded: v2.3.0 (456) │
│ ├── Testers internos: 15 usuários │
│ └── Duração: 3-5 dias │
└─────────────────────────────────────────────────┘
│
▼
3. BETA TESTING
┌─────────────────────────────────────────────────┐
│ iOS: TestFlight testing externo │
│ ├── Requer review App Store (24-48 hrs) │
│ ├── Testers externos: 100 usuários │
│ └── Duração: 1-2 semanas │
│ │
│ Android: Track de testing closed/open │
│ ├── Rollout incremental │
│ ├── Testers externos: 100 usuários │
│ └── Duração: 1-2 semanas │
└─────────────────────────────────────────────────┘
│
▼
4. SUBMISSÃO PARA STORE
┌─────────────────────────────────────────────────┐
│ iOS App Store: │
│ ├── Tempo de review: 1-7 dias (geralmente 24h) │
│ ├── Pode requerer fixes e resubmissão │
│ └── Planejar para contingência de rejeição │
│ │
│ Google Play Store: │
│ ├── Tempo de review: Horas a 3 dias │
│ ├── Rollout faseado disponível │
│ └── Processo mais previsível │
└─────────────────────────────────────────────────┘
Planejamento de Release
Timeline de Release Mobile
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 ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Lidando com Rejeições
Workflow de Rejeição
WORKFLOW DE REJEIÇÃO DE APP STORE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REJEIÇÃO RECEBIDA: │
│ │
│ 1. CRIAR TAREFA URGENTE: │
│ ───────────────────── │
│ Título: [URGENTE] Fix rejeição App Store v2.5.0 │
│ Prioridade: Crítica │
│ Labels: store-rejection, ios (ou android) │
│ │
│ 2. ANALISAR RAZÃO: │
│ ────────────────── │
│ Motivos comuns: │
│ ├── Guideline violation (design, conteúdo) │
│ ├── Bug ou crash │
│ ├── Metadata problema │
│ ├── Privacy concern │
│ └── In-app purchase issue │
│ │
│ 3. AÇÃO IMEDIATA: │
│ ───────────────── │
│ ├── Entender problema específico │
│ ├── Implementar fix │
│ ├── QA rápido │
│ ├── Resubmeter │
│ └── Atualizar timeline de release │
│ │
│ 4. POST-MORTEM: │
│ ───────────── │
│ ├── Por que não pegamos antes? │
│ ├── Checklist de prevenção │
│ └── Documentar para futuro │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE PROJETO MOBILE
═══════════════════════════
ESTRUTURA:
☐ Organização de projeto definida (single/separate)
☐ Labels de plataforma configurados
☐ Templates de tarefas criados
☐ Matriz de testing de dispositivos definida
WORKFLOW:
☐ Pipeline iOS configurado
☐ Pipeline Android configurado
☐ TestFlight/Internal testing funcionando
☐ Processo de code review adaptado
RELEASE:
☐ Timeline com buffer de review
☐ Checklist de submissão
☐ Plano de contingência para rejeição
☐ Monitoramento pós-release definido
COMUNICAÇÃO:
☐ Stakeholders sabem de timelines de app store
☐ Expectativas de review alinhadas
☐ Processo de escalação definido
☐ Métricas de release reportadas
Gestão efetiva de projetos mobile requer planejamento para incertezas de app store enquanto mantém coordenação cross-platform.