4 min lecture • Guide 815 of 877
Spikes de Découverte Technique
Les spikes réduisent le risque. GitScrum aide les équipes à planifier et suivre les spikes techniques qui répondent aux questions critiques avant de s'engager dans l'implémentation complète.
Comprendre les Spikes
Que Sont les Spikes
DÉFINITION SPIKE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPIKE: │
│ ────── │
│ Une investigation time-boxée pour répondre à une question │
│ │
│ BUT: │
│ ──── │
│ • Réduire l'incertitude technique │
│ • Explorer technologie inconnue │
│ • Évaluer la faisabilité │
│ • Informer l'estimation │
│ • Prototyper des approches │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE vs STORY: │
│ │
│ STORY: │
│ "Implémenter authentification utilisateur avec OAuth" │
│ OUTPUT: Feature fonctionnelle en production │
│ │
│ SPIKE: │
│ "Investiguer providers OAuth pour nos besoins" │
│ OUTPUT: Recommandation + approche + estimation │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ QUAND FAIRE UN SPIKE: │
│ ───────────────────── │
│ │
│ ✅ Utiliser spike quand: │
│ • "Peut-on même faire ça?" │
│ • "Quelle approche est meilleure?" │
│ • "Combien de temps ça prendra?" │
│ • "Quels sont les risques?" │
│ │
│ ❌ Ne pas spike quand: │
│ • Réponse Googleable en 30 minutes │
│ • Vous connaissez déjà l'approche │
│ • Juste commencer à construire │
│ │
│ RÈGLE: Spike quand l'incertitude bloque le progrès │
└─────────────────────────────────────────────────────────────┘
Types de Spikes
Catégories de Spikes
TYPES DE SPIKES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPIKE FAISABILITÉ: │
│ ────────────────── │
│ "Peut-on faire ça?" │
│ │
│ EXEMPLE: │
│ "Peut-on intégrer avec leur API legacy?" │
│ • Tester connectivité API │
│ • Identifier limitations │
│ • Documenter bloqueurs │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE ARCHITECTURE: │
│ ─────────────────── │
│ "Comment devrions-nous structurer ça?" │
│ │
│ EXEMPLE: │
│ "Designer l'architecture microservices" │
│ • Frontières de services │
│ • Patterns de communication │
│ • Flux de données │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE TECHNOLOGIE: │
│ ────────────────── │
│ "Quelle technologie devrions-nous utiliser?" │
│ │
│ EXEMPLE: │
│ "Évaluer GraphQL vs REST pour notre API mobile" │
│ • Comparer options │
│ • Prototyper les deux │
│ • Recommander avec raisonnement │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE ESTIMATION: │
│ ───────────────── │
│ "Combien de temps ça prendra?" │
│ │
│ EXEMPLE: │
│ "Estimer effort pour migration système de paiement" │
│ • Découper en composants │
│ • Identifier les inconnus │
│ • Fournir estimation en fourchette │
└─────────────────────────────────────────────────────────────┘
Structure de Spike
Définir un Spike
STRUCTURE DE SPIKE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUESTION: │
│ ───────── │
│ "Quelle question exacte essayons-nous de répondre?" │
│ Clair, spécifique, répondable │
│ │
│ TIME-BOX: │
│ ───────── │
│ 1-3 jours typiquement │
│ Jamais plus d'un sprint │
│ Force décision avec info incomplète │
│ │
│ OUTPUT ATTENDU: │
│ ──────────────── │
│ ├── Réponse à la question │
│ ├── Recommandation avec raisonnement │
│ ├── Risques identifiés │
│ ├── Estimation pour implémentation réelle │
│ └── Code POC (jetable, pas production) │
│ │
│ CRITÈRES DE SUCCÈS: │
│ ─────────────────── │
│ Spike réussi si on peut prendre une décision │
│ Pas d'ambiguïté sur prochaines étapes │
└─────────────────────────────────────────────────────────────┘