6 min lecture • Guide 762 of 877
Développement Mobile avec GitScrum
Le développement mobile a des défis uniques - plateformes multiples, processus app store et fragmentation des appareils. GitScrum aide les équipes à coordonner efficacement le travail mobile.
Structure de Projet Mobile
Organisation par Plateforme
ORGANISATION PROJET MOBILE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ APPROCHE 1: STORIES PARTAGÉES │
│ │
│ STORY FEATURE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MOB-100: Ajouter Notifications Push ││
│ │ ││
│ │ Sous-tâches: ││
│ │ ├── MOB-101: [iOS] Setup notification push ││
│ │ ├── MOB-102: [Android] Setup notification push ││
│ │ ├── MOB-103: [Backend] Endpoint API push ││
│ │ └── MOB-104: [QA] Test sur les deux plateformes ││
│ │ ││
│ │ Labels: feature, ios, android, backend ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ APPROCHE 2: LABELS PLATEFORME │
│ │
│ Toutes tâches mobiles: │
│ Labels: mobile + (ios | android | both) │
│ │
│ Filtres: │
│ • "Travail iOS": mobile + ios │
│ • "Travail Android": mobile + android │
│ • "Cross-platform": mobile + both │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ STRUCTURE ÉQUIPE: │
│ │
│ OPTION A: Équipes plateforme │
│ Équipe iOS: Tout le travail iOS │
│ Équipe Android: Tout le travail Android │
│ → Bon pour expertise native │
│ │
│ OPTION B: Équipes feature │
│ Membres font les deux plateformes │
│ → Bon pour frameworks cross-platform │
│ │
│ OPTION C: Hybride │
│ Features par équipe, spécialistes plateforme en support │
└─────────────────────────────────────────────────────────────┘
Gestion des Releases
GESTION RELEASE MOBILE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIMELINE RELEASE: │
│ │
│ Code freeze Soumission stores Release │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ────●────────────────────●───────────────●───────────── │
│ Jour 1 Jour 3 Jour 5-10 │
│ (après revue) │
│ │
│ PRÉVOIR TEMPS DE REVUE: │
│ iOS: 1-7 jours (souvent 1-2 jours) │
│ Android: Souvent < 1 jour (parfois heures) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EPIC RELEASE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ REL-200: Release Version 2.5.0 ││
│ │ ││
│ │ Release cible: 15 Fév 2024 ││
│ │ ││
│ │ Pré-soumission: ││
│ │ ☐ Code freeze (8 Fév) ││
│ │ ☐ Validation QA (10 Fév) ││
│ │ ☐ Notes de release préparées ││
│ │ ☐ Screenshots mises à jour (si besoin) ││
│ │ ││
│ │ Soumission: ││
│ │ ☐ Soumettre à App Store (11 Fév) ││
│ │ ☐ Soumettre à Play Store (11 Fév) ││
│ │ ││
│ │ Post-soumission: ││
│ │ ☐ Surveiller statut revue ││
│ │ ☐ Adresser feedback de rejet ││
│ │ ☐ Coordonner release (15 Fév) ││
│ │ ││
│ │ Post-release: ││
│ │ ☐ Surveiller rapports de crash ││
│ │ ☐ Observer avis et notes ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Gestion des Rejets App Store
WORKFLOW REJET APP STORE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REJET REÇU: │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 Rejet App Store ││
│ │ ││
│ │ Raison: Guideline 4.2 - Fonctionnalité Minimum ││
│ │ "La fonctionnalité core de votre app nécessite ││
│ │ une valeur additionnelle" ││
│ │ ││
│ │ Réponse requise avant: 14 Fév 2024 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ACTIONS IMMÉDIATES: │
│ │
│ 1. CRÉER TÂCHE URGENTE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 MOB-201: Adresser Rejet App Store ││
│ │ ││
│ │ Priorité: Critique ││
│ │ Échéance: 13 Fév 2024 (avant deadline) ││
│ │ Labels: app-store, rejection, ios ││
│ │ ││
│ │ Raison du rejet: [coller détails] ││
│ │ ││
│ │ Options: ││
│ │ ☐ Appel (si désaccord) ││
│ │ ☐ Corriger et resoumettre ││
│ │ ││
│ │ Décision: [à déterminer] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ 2. ÉVALUER ET DÉCIDER │
│ • Le rejet est-il valide ? │
│ • Peut-on corriger rapidement ? │
│ • Doit-on faire appel ? │
│ │
│ 3. CORRIGER OU FAIRE APPEL │
│ • Faire les changements si nécessaire │
│ • Préparer réponse d'appel si contestation │
│ • Resoumettre ASAP │
│ │
│ 4. APPRENDRE │
│ • Documenter ce qui a causé le rejet │
│ • Ajouter à checklist pré-soumission │
│ • Prévenir futurs rejets │
└─────────────────────────────────────────────────────────────┘
Checklist Pré-Soumission
CHECKLIST SOUMISSION APP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AVANT CHAQUE SOUMISSION: │
│ │
│ TECHNIQUE: │
│ ☐ Build signé correctement │
│ ☐ Version et build number incrémentés │
│ ☐ Tous tests passent │
│ ☐ Pas de crash connu │
│ ☐ Performance acceptable │
│ │
│ MÉTADONNÉES: │
│ ☐ Description app mise à jour │
│ ☐ Notes de version claires │
│ ☐ Screenshots actuelles │
│ ☐ Icône conforme aux guidelines │
│ │
│ CONFORMITÉ: │
│ ☐ Politique confidentialité à jour │
│ ☐ Permissions justifiées │
│ ☐ Contenu conforme aux guidelines │
│ ☐ Age rating correct │
│ │
└─────────────────────────────────────────────────────────────┘
Intégration GitScrum
GitScrum supporte le développement mobile avec:
- Labels plateforme: Filtrage iOS/Android/Both
- Epics release: Suivi cycle de release
- Checklists: Validation pré-soumission
- Alertes deadline: Rappels dates store
- Tâches rejet: Workflow de résolution