# Cheatsheet SCRUM - Guide Ultra-Détaillé pour Grands Débutants


[OK] CONCEPTS FONDAMENTAUX (EXPLICATIONS TRÈS DÉTAILLÉES)

# === QU'EST-CE QUE SCRUM ? ===

# Imagine que tu dois construire une maison
# Méthode traditionnelle (Waterfall):
# 1. Tu planifies TOUT au début (6 mois de plans)
# 2. Tu construis TOUT d'un coup (12 mois)
# 3. À la fin, le client découvre le résultat
# 4. Problème: Si le client n'aime pas? Trop tard!

# Méthode SCRUM (Agile):
# 1. Tu construis UNE pièce (cuisine) en 2 semaines
# 2. Le client la visite et donne son avis
# 3. Tu ajustes selon ses retours
# 4. Tu passes à la pièce suivante (salon)
# 5. Répète jusqu'à la maison complète
# = Le client voit les résultats RAPIDEMENT et peut changer d'avis!

# SCRUM = Framework agile pour gérer des projets complexes
# = Divise le travail en petits morceaux (Sprints)
# = Livre des résultats fonctionnels régulièrement
# = S'adapte aux changements rapidement

# Origine du mot "SCRUM":
# = Vient du rugby (mêlée)
# = Représente une équipe soudée qui avance ensemble
# = Inventé en 1995 par Ken Schwaber et Jeff Sutherland


# === POURQUOI UTILISER SCRUM? ===

# Problèmes des méthodes traditionnelles:
# 1. Planning rigide (impossible de changer en cours)
# 2. Livraison tardive (on découvre les bugs à la fin)
# 3. Budget explosé (estimation faite au début, réalité différente)
# 4. Client insatisfait (le produit ne correspond pas à ses besoins)

# Solutions SCRUM:
# 1. Flexibilité: On peut changer les priorités à chaque Sprint
# 2. Livraisons fréquentes: Tous les 2-4 semaines
# 3. Budget maîtrisé: On ajuste selon les retours
# 4. Client satisfait: Il voit et teste régulièrement

# Cas d'usage parfaits pour SCRUM:
# - Développement logiciel (apps, sites web)
# - Projets innovants (startups, R&D)
# - Projets avec beaucoup d'incertitudes
# - Équipes de 3 à 9 personnes

# SCRUM ne convient PAS pour:
# - Projets avec des exigences 100% fixes
# - Construction physique avec plans rigides
# - Équipes de plus de 10 personnes (préférer SAFe)


# === VOCABULAIRE SCRUM (TRÈS IMPORTANT!) ===

# SPRINT (Itération)
# = Période de temps fixe (généralement 2 semaines)
# = Pendant un Sprint, l'équipe travaille sur des User Stories
# = À la fin: produit FONCTIONNEL livré
# Analogie: Un Sprint est comme un chapitre d'un livre
# Exemple: Sprint 1 = Login, Sprint 2 = Tableau de bord

# USER STORY (Histoire utilisateur)
# = Fonctionnalité décrite du point de vue utilisateur
# Format: "En tant que [qui], je veux [quoi], afin de [pourquoi]"
# Exemple: "En tant qu'utilisateur, je veux me connecter avec Google afin de gagner du temps"
# = Pas de jargon technique! Langage simple et clair

# PRODUCT BACKLOG (Carnet de produit)
# = Liste PRIORISÉE de toutes les User Stories à faire
# = Géré par le Product Owner
# = Évolutif: on ajoute/supprime des stories selon les besoins
# Analogie: Une TODO list géante pour tout le projet

# SPRINT BACKLOG (Carnet de Sprint)
# = Sous-ensemble du Product Backlog
# = Stories sélectionnées pour le Sprint en cours
# = L'équipe s'engage à les terminer pendant le Sprint
# Analogie: La liste des tâches de la semaine

# DEFINITION OF DONE (DoD) (Définition de Terminé)
# = Critères qui définissent quand une story est VRAIMENT terminée
# Exemples:
#   - Code écrit et testé
#   - Tests unitaires passent
#   - Documentation à jour
#   - Code review validé
#   - Déployé en staging
# = Si un critère manque, la story N'EST PAS terminée!

# INCREMENT (Incrément)
# = Somme de toutes les stories terminées
# = DOIT être fonctionnel et utilisable
# = Potentiellement livrable au client
# Exemple: Après Sprint 1, l'incrément = Login fonctionnel

# VELOCITY (Vélocité)
# = Nombre de Story Points complétés par Sprint
# = Mesure la vitesse de l'équipe
# Exemple: Sprint 1 = 20 points, Sprint 2 = 25 points
# = Aide à prévoir combien de stories on peut faire au prochain Sprint

# STORY POINTS (Points d'histoire)
# = Estimation de la complexité d'une story
# = Pas des heures! (complexité relative)
# Échelle Fibonacci: 1, 2, 3, 5, 8, 13, 21
# Exemple:
#   - Story simple: 1 point
#   - Story moyenne: 5 points
#   - Story complexe: 13 points

# BURNDOWN CHART (Graphique d'avancement)
# = Graphique montrant le travail restant jour par jour
# = Axe Y: Story Points restants
# = Axe X: Jours du Sprint
# = Ligne idéale: descente régulière
# = Si la ligne est au-dessus: équipe en retard
# = Si en dessous: équipe en avance

# SCRUM BOARD (Tableau Scrum)
# = Tableau physique ou digital avec 4 colonnes:
#   - TO DO (À faire)
#   - IN PROGRESS (En cours)
#   - REVIEW (En revue)
#   - DONE (Terminé)
# = Chaque story est une carte qui avance dans les colonnes
# Outils digitaux: Jira, Trello, Monday, ClickUp


# === LES 3 RÔLES SCRUM (PILIERS DE L'ÉQUIPE) ===

# PRODUCT OWNER (PO) (Propriétaire du Produit)
# = Représentant du client/business
# = Responsabilités:
#   1. Définir la vision du produit
#   2. Gérer et prioriser le Product Backlog
#   3. Rédiger les User Stories avec critères d'acceptation
#   4. Valider ou rejeter les stories terminées
#   5. Maximiser la valeur du produit
# = Dit "QUOI faire" (pas "comment")
# Analogie: Le PO est comme l'architecte d'une maison

# SCRUM MASTER (SM) (Maître Scrum)
# = Coach et facilitateur de l'équipe
# = Responsabilités:
#   1. Enseigner SCRUM à l'équipe
#   2. Faciliter les cérémonies (Daily, Sprint Planning, etc)
#   3. Éliminer les obstacles (blockers)
#   4. Protéger l'équipe des distractions externes
#   5. Améliorer continuellement le processus
# = N'est PAS un chef de projet!
# = N'assigne PAS de tâches (l'équipe s'auto-organise)
# Analogie: Le SM est comme un coach sportif

# DEVELOPMENT TEAM (Équipe de développement)
# = Équipe qui construit le produit
# = Caractéristiques:
#   - 3 à 9 membres (idéalement 5-7)
#   - Auto-organisée (pas de hiérarchie interne)
#   - Cross-fonctionnelle (tous les skills nécessaires)
#   - Responsable collectivement des résultats
# = Membres: Développeurs, designers, testeurs, etc.
# = Décident "COMMENT faire"
# Analogie: L'équipe est comme les ouvriers qui construisent la maison


# === LES 5 CÉRÉMONIES SCRUM (ÉVÉNEMENTS OBLIGATOIRES) ===

# 1. SPRINT PLANNING (Planification de Sprint)
# Quand: Au début de chaque Sprint
# Durée: 4 heures max pour un Sprint de 2 semaines
# Participants: Toute l'équipe SCRUM (PO + SM + Dev Team)
# Objectif: Décider QUOI faire pendant le Sprint

# Déroulement:
# Partie 1 (QUOI):
#   1. PO présente les stories prioritaires du Backlog
#   2. Équipe pose des questions pour clarifier
#   3. Équipe sélectionne les stories qu'elle peut terminer
#   4. Création du Sprint Goal (objectif du Sprint)

# Partie 2 (COMMENT):
#   1. Équipe décompose chaque story en tâches techniques
#   2. Estimation du temps par tâche
#   3. Répartition (volontariat, pas assignation!)
#   4. Création du Sprint Backlog

# Résultat:
#   - Sprint Goal clair
#   - Sprint Backlog défini
#   - Engagement de l'équipe

# 2. DAILY SCRUM / STAND-UP (Mêlée quotidienne)
# Quand: Tous les jours à heure fixe (ex: 9h)
# Durée: 15 minutes MAX (debout pour rester court!)
# Participants: Development Team + SM (PO optionnel)
# Objectif: Synchroniser l'équipe et identifier les blockers

# Format (chaque membre répond à 3 questions):
#   1. Qu'ai-je fait hier?
#   2. Que vais-je faire aujourd'hui?
#   3. Ai-je des obstacles (blockers)?

# Règles:
#   - PAS de résolution de problèmes (prendre RDV après)
#   - PAS de rapport au manager (c'est pour l'équipe)
#   - Rester concentré (pas de digressions)

# Exemple:
# Dev 1: "Hier j'ai terminé le login. Aujourd'hui je commence le tableau de bord. Pas de blocker."
# Dev 2: "Hier j'ai travaillé sur l'API. Aujourd'hui je continue. Blocker: j'attends l'accès à la DB."

# 3. SPRINT REVIEW (Revue de Sprint)
# Quand: Dernier jour du Sprint
# Durée: 2 heures max pour un Sprint de 2 semaines
# Participants: Équipe SCRUM + Stakeholders (clients, managers)
# Objectif: Montrer ce qui a été terminé et collecter les feedbacks

# Déroulement:
#   1. PO présente le Sprint Goal et ce qui a été fait
#   2. Équipe DÉMONTRE les stories terminées (LIVE!)
#   3. Stakeholders testent et donnent des feedbacks
#   4. Discussion sur le Product Backlog (ajustements)
#   5. Projection: Que faire au prochain Sprint?

# Important:
#   - Démonstration RÉELLE (pas de PowerPoint!)
#   - Seules les stories "Done" sont présentées
#   - Feedback constructif encouragé

# 4. SPRINT RETROSPECTIVE (Rétrospective)
# Quand: Après la Sprint Review
# Durée: 1.5 heures max pour un Sprint de 2 semaines
# Participants: Équipe SCRUM uniquement (PO + SM + Dev)
# Objectif: Améliorer le processus pour le prochain Sprint

# Déroulement (format classique):
#   1. Ce qui a bien fonctionné (Keep doing)
#   2. Ce qui n'a pas fonctionné (Stop doing)
#   3. Ce qu'on pourrait améliorer (Start doing)

# Techniques populaires:
#   - Mad/Sad/Glad (Énervé/Triste/Content)
#   - Start/Stop/Continue
#   - 4Ls (Liked/Learned/Lacked/Longed for)

# Actions:
#   - Identifier 1-3 actions concrètes d'amélioration
#   - Assigner un responsable pour chaque action
#   - Suivre les actions au prochain Sprint

# 5. BACKLOG REFINEMENT (Affinage du Backlog)
# Quand: Au milieu du Sprint (optionnel mais recommandé)
# Durée: 1 heure
# Participants: PO + quelques membres de l'équipe
# Objectif: Préparer les stories pour les prochains Sprints

# Activités:
#   1. Clarifier les stories (détails, critères d'acceptation)
#   2. Estimer les Story Points
#   3. Découper les stories trop grosses (Epic -> Stories)
#   4. Supprimer les stories obsolètes
#   5. Réorganiser les priorités


# === COMMENT ÇA MARCHE? (FLUX COMPLET) ===

# PHASE 1: PRÉPARATION DU PROJET
# 1. Définir la vision du produit (Product Owner)
# 2. Créer le Product Backlog initial (liste des fonctionnalités)
# 3. Prioriser les stories (valeur business)
# 4. Estimer les premières stories (Story Points)
# 5. Constituer l'équipe SCRUM

# PHASE 2: SPRINT (CYCLE RÉPÉTITIF)

# Jour 1: Sprint Planning
# - PO présente les stories prioritaires
# - Équipe sélectionne 20 Story Points (selon sa vélocité)
# - Équipe crée le Sprint Backlog
# - Sprint Goal défini: "Livrer un système de login fonctionnel"

# Jours 2-13: Développement
# - Chaque matin: Daily Scrum (15 min)
# - Équipe travaille sur les stories
# - Stories déplacées sur le board: TO DO -> IN PROGRESS -> REVIEW -> DONE
# - SM élimine les blockers
# - PO disponible pour clarifications

# Jour 14: Sprint Review + Retrospective
# - Matin: Sprint Review (démonstration aux stakeholders)
# - Après-midi: Retrospective (amélioration du processus)

# Jour 15: Nouveau Sprint commence!

# PHASE 3: RELEASE (LIVRAISON)
# - Après plusieurs Sprints, l'incrément est suffisant
# - Décision de release (PO)
# - Déploiement en production
# - Feedback utilisateurs réels


# === EXEMPLE CONCRET: PROJET E-COMMERCE ===

# Product Backlog initial (priorisé):
# 1. En tant qu'utilisateur, je veux m'inscrire avec email (5 points)
# 2. En tant qu'utilisateur, je veux me connecter (3 points)
# 3. En tant qu'utilisateur, je veux voir le catalogue de produits (8 points)
# 4. En tant qu'utilisateur, je veux ajouter un produit au panier (5 points)
# 5. En tant qu'utilisateur, je veux payer avec Stripe (13 points)
# 6. En tant qu'admin, je veux gérer les produits (8 points)
# 7. En tant qu'utilisateur, je veux recevoir une confirmation email (5 points)

# SPRINT 1 (Vélocité estimée: 20 points)
# Sprint Goal: "Système d'authentification complet"
# Stories sélectionnées:
#   - Inscription (5 points)
#   - Connexion (3 points)
#   - Voir catalogue (8 points)
# Total: 16 points

# Sprint Planning:
# Story 1: Inscription
#   Tâches techniques:
#     - Créer formulaire HTML (2h)
#     - API POST /register (3h)
#     - Validation email (2h)
#     - Hash mot de passe (1h)
#     - Tests unitaires (2h)
#     - Tests d'intégration (2h)

# Story 2: Connexion
#   Tâches techniques:
#     - Créer formulaire login (1h)
#     - API POST /login (2h)
#     - JWT token (2h)
#     - Tests (2h)

# Story 3: Catalogue
#   Tâches techniques:
#     - Design UI catalogue (3h)
#     - API GET /products (2h)
#     - Pagination (2h)
#     - Filtres (3h)
#     - Tests (3h)

# Daily Scrum Jour 3:
# Dev 1: "Hier: formulaire inscription terminé. Aujourd'hui: API register. Pas de blocker."
# Dev 2: "Hier: design catalogue. Aujourd'hui: API products. Blocker: besoin data de test."
# SM: "Ok, je vais créer un jeu de données de test."

# Sprint Review Jour 14:
# PO: "Démonstration du Sprint 1!"
# Équipe montre:
#   - Inscription fonctionnelle (validations OK)
#   - Connexion avec JWT (sécurisé)
#   - Catalogue avec 50 produits (pagination OK)
# Stakeholder: "Super! Par contre, ajoutez une recherche dans le catalogue."
# PO: "Noté, j'ajoute une story au Backlog."

# Retrospective Jour 14:
# Keep doing: Daily Scrum efficaces, pair programming
# Stop doing: Code reviews trop longs
# Start doing: Automatiser les tests
# Action: Dev 3 configure CI/CD avant le Sprint 2

# SPRINT 2 (Vélocité: 20 points basée sur Sprint 1)
# Sprint Goal: "Système de panier fonctionnel"
# Stories sélectionnées:
#   - Ajouter au panier (5 points)
#   - Recherche catalogue (8 points) [nouvelle story du feedback]
#   - Confirmation email (5 points)
# Total: 18 points


[OK] INSTALLATION & SETUP (OUTILS POUR SCRUM)

# === OUTILS DIGITAUX POUR SCRUM ===

# 1. JIRA (Professionnel)
# Site: https://www.atlassian.com/software/jira
# Coût: Gratuit jusqu'à 10 utilisateurs, puis $7/user/mois
# Avantages:
#   - Très complet (Backlog, Sprints, Burndown charts)
#   - Intégrations (GitHub, Slack, etc)
#   - Rapports avancés
# Inconvénients:
#   - Complexe pour débutants
#   - Lourd (beaucoup de fonctionnalités)

# Installation:
# 1. Créer un compte sur atlassian.com
# 2. Créer un nouveau projet "Scrum"
# 3. Configurer:
#    - Créer un Backlog
#    - Définir les Story Points (Fibonacci)
#    - Activer les Sprints (2 semaines)
# 4. Inviter l'équipe


# 2. TRELLO (Simple et visuel)
# Site: https://trello.com
# Coût: Gratuit (version de base), $5/user/mois (premium)
# Avantages:
#   - Interface intuitive (drag & drop)
#   - Parfait pour petites équipes
#   - Power-Ups (extensions)
# Inconvénients:
#   - Moins de fonctionnalités SCRUM natives
#   - Pas de Burndown chart intégré

# Setup Trello pour SCRUM:
# 1. Créer un compte
# 2. Créer un board "Sprint 1"
# 3. Créer 4 listes:
#    - Backlog (toutes les stories)
#    - TO DO (stories du Sprint)
#    - IN PROGRESS
#    - DONE
# 4. Créer des cartes (User Stories)
# 5. Ajouter Power-Up "Scrum for Trello" (estimation)


# 3. MONDAY.COM (Moderne et flexible)
# Site: https://monday.com
# Coût: Essai gratuit, puis $8/user/mois
# Avantages:
#   - Interface moderne et colorée
#   - Automatisations puissantes
#   - Tableaux de bord personnalisables
# Inconvénients:
#   - Coût élevé pour grandes équipes

# Setup pour SCRUM:
# 1. Choisir template "Scrum Board"
# 2. Personnaliser les colonnes
# 3. Ajouter des automatisations (ex: notif Slack quand story Done)


# 4. CLICKUP (Tout-en-un)
# Site: https://clickup.com
# Coût: Gratuit, puis $5/user/mois
# Avantages:
#   - Combine plusieurs vues (liste, board, calendrier)
#   - Sprints natifs
#   - Rapports et graphiques
# Inconvénients:
#   - Peut être écrasant (trop de features)


# 5. AZURE DEVOPS (Microsoft)
# Site: https://azure.microsoft.com/devops
# Coût: Gratuit jusqu'à 5 utilisateurs
# Avantages:
#   - Intégration native avec Git
#   - CI/CD intégré
#   - Très complet
# Inconvénients:
#   - Interface datée
#   - Courbe d'apprentissage


# === SETUP PHYSIQUE (SCRUM BOARD RÉEL) ===

# Matériel nécessaire:
# 1. Tableau blanc ou mur
# 2. Post-its de couleurs différentes:
#    - Jaune: User Stories
#    - Bleu: Tâches techniques
#    - Rose: Bugs
#    - Vert: Tests
# 3. Marqueurs
# 4. Ruban adhésif pour délimiter les colonnes

# Création du board:
# 1. Diviser le tableau en 4 colonnes verticales:
#    ┌─────────┬─────────┬─────────┬─────────┐
#    │ TO DO   │ IN PROG │ REVIEW  │  DONE   │
#    ├─────────┼─────────┼─────────┼─────────┤
#    │         │         │         │         │
#    │         │         │         │         │
#    └─────────┴─────────┴─────────┴─────────┘

# 2. Ajouter une section "Sprint Goal" en haut

# 3. Créer les post-its:
#    Recto: Titre de la story
#    Verso: Critères d'acceptation

# 4. Placer toutes les stories dans "TO DO"

# 5. Lors du Daily, mettre à jour le board

# Avantages du board physique:
#   - Visibilité immédiate pour toute l'équipe
#   - Interaction tactile (satisfaisant de déplacer les post-its!)
#   - Pas de dépendance à un outil digital


[OK] RÉDIGER DES USER STORIES EFFICACES

# === FORMAT D'UNE USER STORY ===

# Template de base:
# En tant que [RÔLE]
# Je veux [ACTION]
# Afin de [BÉNÉFICE]

# Exemple 1:
# En tant qu'utilisateur
# Je veux réinitialiser mon mot de passe
# Afin de retrouver l'accès à mon compte si je l'oublie

# Exemple 2:
# En tant qu'admin
# Je veux exporter les données utilisateurs en CSV
# Afin d'analyser les statistiques dans Excel

# Exemple 3:
# En tant que client
# Je veux filtrer les produits par prix
# Afin de trouver des articles dans mon budget


# === CRITÈRES D'ACCEPTATION (TRÈS IMPORTANT!) ===

# = Conditions que la story DOIT remplir pour être "Done"
# = Liste de vérifications (checklist)
# Format: "Étant donné [CONTEXTE], Quand [ACTION], Alors [RÉSULTAT]"

# Exemple pour "Réinitialiser mot de passe":

# Critères d'acceptation:
# 1. Étant donné que je suis sur la page de login
#    Quand je clique sur "Mot de passe oublié?"
#    Alors je vois un formulaire demandant mon email

# 2. Étant donné que j'ai entré un email valide
#    Quand je clique sur "Envoyer"
#    Alors je reçois un email avec un lien de réinitialisation

# 3. Étant donné que je clique sur le lien dans l'email
#    Quand je suis redirigé vers la page de réinitialisation
#    Alors je peux entrer un nouveau mot de passe

# 4. Étant donné que j'ai saisi un nouveau mot de passe valide (8+ caractères)
#    Quand je clique sur "Confirmer"
#    Alors mon mot de passe est mis à jour et je peux me connecter


# === RÈGLE INVEST POUR BONNES STORIES ===

# I = Independent (Indépendante)
# = La story peut être développée seule
# Mauvais: "Ajouter au panier" dépend de "Créer panier"
# Bon: "En tant qu'utilisateur, je veux ajouter un produit au panier (créer panier si n'existe pas)"

# N = Negotiable (Négociable)
# = Les détails peuvent être discutés
# Mauvais: "Utiliser React avec Redux et styled-components"
# Bon: "Page de profil utilisateur (technologie à définir avec l'équipe)"

# V = Valuable (À valeur ajoutée)
# = Apporte de la valeur au client
# Mauvais: "Refactoriser le code legacy"
# Bon: "Réduire le temps de chargement de la page à <2s"

# E = Estimable (Estimable)
# = L'équipe peut estimer la complexité
# Mauvais: "Améliorer les performances" (trop vague)
# Bon: "Optimiser les requêtes DB (indexation + cache Redis)"

# S = Small (Petite)
# = Peut être terminée en un Sprint
# Mauvais: "Construire un système de recommandation IA" (13+ points)
# Bon: "Afficher 5 produits similaires basés sur la catégorie" (5 points)

# T = Testable (Testable)
# = On peut vérifier que c'est terminé
# Mauvais: "Améliorer l'UX"
# Bon: "Réduire le nombre de clics pour acheter de 5 à 3"


# === EPIC VS STORY VS TASK ===

# EPIC (Grande fonctionnalité)
# = Trop grosse pour un Sprint
# = Doit être découpée en plusieurs Stories
# Exemple: "Système de paiement complet"
#   Stories:
#     - Intégrer Stripe
#     - Ajouter PayPal
#     - Gérer les remboursements
#     - Afficher historique des paiements

# STORY (Fonctionnalité)
# = Peut être terminée en un Sprint
# = Apporte de la valeur métier
# Exemple: "Intégrer Stripe"
#   Tasks:
#     - Setup Stripe API
#     - Créer formulaire paiement
#     - Gérer webhooks
#     - Tests end-to-end

# TASK (Tâche technique)
# = Sous-partie d'une Story
# = Pas de valeur métier directe
# Exemple: "Setup Stripe API"
#   - Créer compte Stripe
#   - Installer SDK
#   - Configurer clés API


[OK] ESTIMATION DES STORY POINTS

# === QU'EST-CE QU'UN STORY POINT? ===

# Story Point ≠ Heures de travail!
# = Mesure de COMPLEXITÉ relative
# = Prend en compte:
#   1. Effort (combien de travail?)
#   2. Complexité (combien de difficultés techniques?)
#   3. Incertitude (combien d'inconnues?)

# Pourquoi pas des heures?
# - Les heures varient selon le développeur (junior vs senior)
# - Les heures ne capturent pas la complexité
# - Les heures créent de la pression


# === ÉCHELLE FIBONACCI (RECOMMANDÉE) ===

# Échelle: 1, 2, 3, 5, 8, 13, 21
# Plus le nombre est grand, plus l'incertitude augmente

# 1 point: Très simple
# Exemple: "Changer la couleur d'un bouton"
# Temps estimé: 1-2 heures
# Incertitude: Aucune

# 2 points: Simple
# Exemple: "Ajouter un champ au formulaire"
# Temps estimé: 2-4 heures
# Incertitude: Très faible

# 3 points: Moyen
# Exemple: "Créer une page de profil utilisateur"
# Temps estimé: 4-8 heures
# Incertitude: Faible

# 5 points: Moyen-Complexe
# Exemple: "Implémenter la recherche avec filtres"
# Temps estimé: 1-2 jours
# Incertitude: Moyenne

# 8 points: Complexe
# Exemple: "Intégrer Stripe pour les paiements"
# Temps estimé: 2-3 jours
# Incertitude: Élevée

# 13 points: Très complexe
# Exemple: "Système de chat en temps réel"
# Temps estimé: 3-5 jours
# Incertitude: Très élevée
# = Devrait être découpé en stories plus petites!

# 21 points: Epic
# Exemple: "Système de recommandation IA"
# = TROP GROS! Découper obligatoirement!


# === TECHNIQUE PLANNING POKER ===

# Matériel:
# - Cartes Planning Poker (1, 2, 3, 5, 8, 13, 21, ?, café)
# - Ou application digitale: https://planningpokeronline.com

# Déroulement:
# 1. PO lit une User Story à haute voix
# 2. Équipe pose des questions pour clarifier
# 3. Chaque membre choisit une carte (face cachée)
# 4. À 3, tout le monde révèle sa carte en même temps
# 5. Si consensus (tous même valeur): estimation validée
# 6. Si désaccord (ex: 3 vs 13):
#    - La personne avec le plus petit chiffre explique pourquoi
#    - La personne avec le plus grand chiffre explique pourquoi
#    - Discussion
#    - Re-vote
# 7. Répéter jusqu'à consensus

# Exemple:
# Story: "Ajouter une fonctionnalité de recherche"
# Dev 1: 5 points ("J'ai déjà fait ça, c'est simple")
# Dev 2: 13 points ("Il faut gérer la pagination, les filtres, l'autocomplétion...")
# Discussion:
#   Dev 1: "Ah oui j'avais oublié l'autocomplétion, effectivement c'est plus complexe"
#   Dev 2: "Mais la pagination on a déjà une librairie"
# Re-vote: 8 points (consensus!)

# Cartes spéciales:
# ? (Point d'interrogation): "Je ne comprends pas la story"
# [HOT_BEVERAGE] (Café): "Je suis fatigué, pause?"


[OK] SPRINT PLANNING DÉTAILLÉ

# === PRÉPARATION AVANT LE SPRINT PLANNING ===

# 1-2 jours avant:
# - PO prépare le Product Backlog
# - Priorités claires
# - Stories bien rédigées avec critères d'acceptation
# - Backlog Refinement si nécessaire

# Jour du Sprint Planning:
# - Réserver une salle calme (ou réunion Zoom)
# - Préparer l'outil (Jira, Trello, board physique)
# - Avoir le Burndown chart du Sprint précédent (vélocité)


# === SPRINT PLANNING: PARTIE 1 (QUOI?) ===

# Durée: 2 heures pour Sprint de 2 semaines

# Étape 1: Revue de la vélocité
# SM: "Sprint précédent, on a terminé 18 Story Points"
# = Objectif: faire ~20 points ce Sprint

# Étape 2: Définir le Sprint Goal
# PO: "Le Sprint Goal est: Système d'authentification complet"
# = Objectif clair et mesurable

# Étape 3: PO présente les stories (par ordre de priorité)
# PO: "Story 1: En tant qu'utilisateur, je veux m'inscrire..."
# Équipe: "Questions?"
#   - "Faut-il valider l'email?"
#   - "Quels champs obligatoires?"
#   - "Accepte-t-on OAuth (Google, Facebook)?"

# Étape 4: Équipe sélectionne les stories
# Équipe regarde:
#   - Vélocité: 20 points max
#   - Capacité: Qui est disponible? (congés, jours fériés)
#   - Dépendances: Certaines stories dépendent d'autres?

# Sélection:
#   - Story 1: Inscription (5 points)
#   - Story 2: Connexion (3 points)
#   - Story 3: Réinitialiser mot de passe (5 points)
#   - Story 4: Profil utilisateur (5 points)
#   Total: 18 points [OK]

# Étape 5: Validation
# SM: "Êtes-vous confiants de terminer ces 4 stories?"
# Équipe: "Oui!" (engagement collectif)

# Résultat Partie 1:
# - Sprint Goal défini
# - 4 stories sélectionnées (18 points)
# - Sprint Backlog créé


# === SPRINT PLANNING: PARTIE 2 (COMMENT?) ===

# Durée: 2 heures pour Sprint de 2 semaines

# Étape 1: Décomposer les stories en tâches techniques
# Story 1: Inscription (5 points)
#   Tâches:
#     - Créer formulaire HTML/CSS (2h)
#     - API POST /register (3h)
#     - Validation des champs (2h)
#     - Hash du mot de passe (bcrypt) (1h)
#     - Envoi email de confirmation (2h)
#     - Tests unitaires (3h)
#     - Tests d'intégration (2h)
#   Total: 15h

# Story 2: Connexion (3 points)
#   Tâches:
#     - Formulaire login (1h)
#     - API POST /login (2h)
#     - JWT token génération (2h)
#     - Gestion erreurs (1h)
#     - Tests (2h)
#   Total: 8h

# (Répéter pour toutes les stories)

# Étape 2: Répartition des tâches (VOLONTARIAT!)
# Dev 1: "Je prends le formulaire inscription et l'API"
# Dev 2: "Je fais la connexion et les JWT"
# Dev 3: "Je m'occupe des tests et de l'email"

# IMPORTANT:
# - Personne n'assigne les tâches
# - L'équipe s'auto-organise
# - Si conflit: discussion pour trouver un accord

# Étape 3: Mise à jour du Sprint Board
# Toutes les tâches sont créées dans l'outil (Jira, Trello)
# Assignées aux développeurs
# Placées dans la colonne "TO DO"

# Résultat Partie 2:
# - Toutes les stories décomposées en tâches
# - Tâches assignées
# - Sprint Board à jour


[OK] DAILY SCRUM (STAND-UP) DÉTAILLÉ

# === RÈGLES D'OR DU DAILY ===

# 1. Heure fixe tous les jours
#    Exemple: 9h00 précises
#    = Pas de retard accepté (respect de l'équipe)

# 2. Durée: 15 minutes MAX
#    = Si dépassement, prendre RDV après

# 3. Debout (stand-up)
#    = Encourage la concision
#    = Ou assis si remote (Zoom)

# 4. Même endroit
#    = Devant le Scrum Board physique
#    = Ou Zoom avec board digital partagé

# 5. Participants:
#    - Development Team (obligatoire)
#    - Scrum Master (facilitateur)
#    - Product Owner (optionnel, écoute seulement)
#    - Stakeholders: NON (pas un rapport!)


# === FORMAT DU DAILY (3 QUESTIONS) ===

# Chaque membre répond à:
# 1. Qu'ai-je terminé hier?
# 2. Que vais-je faire aujourd'hui?
# 3. Ai-je des obstacles (blockers)?

# Exemple Jour 3 du Sprint:

# Dev 1:
# Hier: "J'ai terminé le formulaire d'inscription (HTML/CSS). J'ai commencé l'API."
# Aujourd'hui: "Je vais finir l'API et commencer la validation des champs."
# Blocker: "Pas de blocker."

# Dev 2:
# Hier: "J'ai créé l'API de connexion. Tests en cours."
# Aujourd'hui: "Terminer les tests unitaires. Commencer les JWT."
# Blocker: "Oui, j'attends les credentials de la DB de test."

# SM:
# "Ok, je vais te donner les credentials juste après le Daily."

# Dev 3:
# Hier: "J'ai configuré le service email (SendGrid)."
# Aujourd'hui: "Intégrer l'envoi d'email dans l'API register."
# Blocker: "Non."

# Temps écoulé: 5 minutes [OK]


# === CE QU'IL NE FAUT PAS FAIRE ===

# [X] Résoudre les problèmes pendant le Daily
# Mauvais:
# Dev: "J'ai un bug avec JWT, le token expire trop vite."
# Autre Dev: "Ah oui, il faut changer le TTL dans la config..."
# = 10 minutes de discussion technique!

# Bon:
# Dev: "J'ai un bug avec JWT. Blocker: besoin d'aide."
# SM: "Ok, prends RDV avec Dev 2 après le Daily."

# [X] Transformer le Daily en rapport au manager
# Mauvais:
# Dev: "Hier j'ai passé 8h sur le bug. Aujourd'hui je vais continuer..."
# = Trop de détails, ressemble à un rapport

# Bon:
# Dev: "Hier: debug de l'API. Aujourd'hui: terminer le fix."

# [X] Parler de tâches hors Sprint
# Mauvais:
# Dev: "Hier j'ai aidé l'équipe marketing sur un problème Excel..."
# = Hors scope du Sprint!

# Bon:
# Dev: "Hier: Story 2 terminée. Aujourd'hui: Story 3."


# === MISE À JOUR DU SCRUM BOARD ===

# Pendant ou après le Daily:
# - Déplacer les cartes terminées vers "DONE"
# - Déplacer les nouvelles tâches vers "IN PROGRESS"
# - Ajouter des post-its pour nouveaux blockers

# Exemple de board après Daily Jour 3:
# ┌─────────────┬─────────────┬─────────────┬─────────────┐
# │   TO DO     │ IN PROGRESS │   REVIEW    │    DONE     │
# ├─────────────┼─────────────┼─────────────┼─────────────┤
# │ Validation  │ API /login  │ Form inscr. │ Setup email │
# │ Hash pwd    │ JWT tokens  │             │             │
# │ Email conf. │             │             │             │
# │ Tests       │             │             │             │
# └─────────────┴─────────────┴─────────────┴─────────────┘


# === VARIANTE: WALK THE BOARD ===

# Au lieu de faire un tour de table, on parcourt le board:
# SM: "Ok, commençons par la colonne IN PROGRESS."
# SM: "Story 1: Qui travaille dessus? Quel statut?"
# Dev 1: "Moi. L'API est terminée, je passe aux tests."
# SM: "Blockers?"
# Dev 1: "Non."

# SM: "Story 2?"
# Dev 2: "En cours. Terminé demain."

# Avantages:
# - Focus sur les stories, pas les personnes
# - Visualise mieux l'avancement global


[OK] SPRINT REVIEW DÉTAILLÉ

# === PRÉPARATION DE LA SPRINT REVIEW ===

# 1 jour avant:
# - PO prépare la démonstration
# - Équipe vérifie que tout fonctionne (environnement de staging)
# - Inviter les stakeholders (clients, managers, autres équipes)

# Matériel:
# - Projecteur ou écran partagé
# - Environnement de démo fonctionnel
# - Liste des stories "Done"


# === DÉROULEMENT DE LA SPRINT REVIEW ===

# Durée: 2 heures max pour Sprint de 2 semaines
# Participants: Équipe SCRUM + Stakeholders

# PARTIE 1: Introduction (5 min)
# PO: "Bienvenue à la Sprint Review du Sprint 3!"
# PO: "Sprint Goal: Système d'authentification complet"
# PO: "Aujourd'hui, nous allons démontrer 4 User Stories terminées."

# PARTIE 2: Démonstration (60 min)
# Règle: Démonstration LIVE, pas de PowerPoint!

# Story 1: Inscription
# Dev 1: "Je vais créer un nouveau compte..."
#   - Ouvre le site en LIVE
#   - Remplit le formulaire
#   - Clique "S'inscrire"
#   - Montre l'email de confirmation reçu
#   - Vérifie que le compte est créé en DB
# Stakeholder: "Super! Et si l'email existe déjà?"
# Dev 1: "Bonne question! Je montre..."
#   - Essaie de créer le même compte
#   - Affiche: "Cet email est déjà utilisé"
# Stakeholder: "Parfait!"

# Story 2: Connexion
# Dev 2: "Maintenant je vais me connecter avec le compte créé..."
#   - Entre email + mot de passe
#   - Clique "Se connecter"
#   - Redirigé vers le tableau de bord
#   - Montre le JWT token dans les DevTools
# Stakeholder: "Et si le mot de passe est faux?"
# Dev 2: "Je teste..."
#   - Entre un mauvais mot de passe
#   - Affiche: "Email ou mot de passe incorrect"
# Stakeholder: "Nickel!"

# Story 3: Réinitialiser mot de passe
# Dev 3: "Si j'oublie mon mot de passe..."
#   - Clique "Mot de passe oublié?"
#   - Entre son email
#   - Montre l'email reçu avec le lien
#   - Clique sur le lien
#   - Définit un nouveau mot de passe
#   - Se connecte avec le nouveau mot de passe
# Stakeholder: "Excellent!"

# Story 4: Profil utilisateur
# Dev 1: "Une fois connecté, je peux voir mon profil..."
#   - Affiche la page profil
#   - Montre les infos (nom, email, date d'inscription)
#   - Teste la modification du nom
#   - Sauvegarde
#   - Vérifie que c'est bien mis à jour
# Stakeholder: "Top! Peut-on aussi changer l'email?"
# PO: "Bonne idée! Je l'ajoute au Backlog pour un prochain Sprint."

# PARTIE 3: Feedback & Discussion (30 min)
# SM: "Merci pour les démonstrations! Questions? Feedbacks?"

# Stakeholder 1: "Très bien! J'aimerais aussi pouvoir se connecter avec Google."
# PO: "Noté. Je crée une story: 'Connexion OAuth Google'."

# Stakeholder 2: "Petit détail: le formulaire d'inscription est un peu long. Peut-on réduire les champs?"
# PO: "Lesquels sont optionnels selon vous?"
# Stakeholder 2: "Le téléphone et l'adresse ne sont pas obligatoires au départ."
# PO: "D'accord. Je crée une story: 'Simplifier formulaire inscription'."

# PARTIE 4: Révision du Product Backlog (20 min)
# PO: "Regardons le Backlog pour le prochain Sprint."
# PO montre le Backlog mis à jour:
#   1. Connexion OAuth Google (8 points) [NEW]
#   2. Simplifier formulaire (3 points) [NEW]
#   3. Ajouter produit au panier (5 points)
#   4. Paiement Stripe (13 points)
#   5. Gestion admin produits (8 points)

# SM: "Questions?"
# Stakeholder 3: "Quand aura-t-on le paiement Stripe?"
# PO: "Si on sélectionne cette story au prochain Sprint, dans 2 semaines."

# PARTIE 5: Conclusion (5 min)
# SM: "Merci à tous! Retrouvons-nous dans 2 semaines pour la prochaine Review."
# PO: "N'hésitez pas à nous envoyer vos feedbacks par email."


# === APRÈS LA SPRINT REVIEW ===

# 1. PO met à jour le Product Backlog
#    - Ajoute les nouvelles stories issues des feedbacks
#    - Repriorise si nécessaire

# 2. Équipe prépare la Retrospective (même jour, après la Review)


[OK] SPRINT RETROSPECTIVE DÉTAILLÉE

# === OBJECTIF DE LA RETROSPECTIVE ===

# = Améliorer le PROCESSUS (pas le produit)
# = Identifier ce qui fonctionne et ce qui ne fonctionne pas
# = Définir des actions concrètes d'amélioration

# Participants: Équipe SCRUM uniquement (PO + SM + Dev Team)
# Durée: 1.5 heures max


# === FORMAT CLASSIQUE: START/STOP/CONTINUE ===

# PARTIE 1: Préparation (10 min)
# SM: "Prenez 5 minutes individuellement pour réfléchir au Sprint."
# SM: "Notez sur des post-its (ou outil digital) ce qui vous vient en tête."

# Chaque membre écrit ses idées:
# - Post-it vert: CONTINUE (ce qui fonctionne bien)
# - Post-it rouge: STOP (ce qui ne fonctionne pas)
# - Post-it bleu: START (ce qu'on devrait essayer)

# PARTIE 2: Partage (30 min)
# Chaque membre colle ses post-its sur le board et explique

# Exemples CONTINUE:
# Dev 1: "Les Daily Scrum sont efficaces, on reste dans les 15 min."
# Dev 2: "Le pair programming nous a aidés à résoudre les bugs plus vite."
# Dev 3: "La communication avec le PO est fluide, il répond vite à nos questions."

# Exemples STOP:
# Dev 1: "Les réunions de code review prennent trop de temps (2h pour 3 PRs)."
# Dev 2: "On a trop de réunions externes qui interrompent le Sprint."
# PO: "Je suis d'accord, je vais filtrer les demandes externes."

# Exemples START:
# Dev 3: "On devrait automatiser les tests avec une CI/CD (GitHub Actions)."
# Dev 1: "On pourrait faire des code reviews async via GitHub pour gagner du temps."
# SM: "On pourrait essayer le mob programming pour les stories complexes."

# PARTIE 3: Vote (10 min)
# SM: "Ok, maintenant votons pour les actions prioritaires."
# Chaque membre a 3 votes (3 gommettes ou votes digitaux)
# On vote pour les actions START/STOP jugées les plus importantes

# Résultats du vote:
# 1. Automatiser les tests (5 votes) *
# 2. Code reviews async (4 votes) *
# 3. Limiter les réunions externes (3 votes) *
# 4. Mob programming (1 vote)

# PARTIE 4: Plan d'action (30 min)
# SM: "Ok, on a 3 actions prioritaires. Créons un plan concret."

# Action 1: Automatiser les tests
#   - Responsable: Dev 3
#   - Échéance: Avant le prochain Sprint
#   - Tâches concrètes:
#     1. Setup GitHub Actions
#     2. Configurer pipeline CI/CD
#     3. Ajouter tests automatiques (unit + integration)
#   - Critère de succès: Les tests tournent automatiquement à chaque push

# Action 2: Code reviews async
#   - Responsable: Toute l'équipe
#   - Échéance: À partir du prochain Sprint
#   - Règles:
#     1. PR créée avec description claire
#     2. Reviews faites dans les 24h
#     3. 2 approvals minimum avant merge
#   - Critère de succès: Plus de réunions de code review

# Action 3: Limiter les réunions externes
#   - Responsable: PO + SM
#   - Échéance: Immédiat
#   - Actions:
#     1. PO filtre les demandes externes
#     2. SM protège l'équipe des interruptions
#     3. Créer un créneau "Office Hours" (1h/jour) pour les questions externes
#   - Critère de succès: Moins de 2h/semaine de réunions externes

# PARTIE 5: Conclusion (10 min)
# SM: "Merci à tous! Récapitulons les actions:"
# SM affiche le résumé:
#   - Action 1: CI/CD (Dev 3)
#   - Action 2: Async reviews (Équipe)
#   - Action 3: Limiter externes (PO + SM)

# SM: "Ces actions seront suivies au prochain Sprint. Rendez-vous dans 2 semaines!"


# === AUTRES FORMATS DE RETROSPECTIVE ===

# Format Mad/Sad/Glad (Énervé/Triste/Content)
# - Mad: Ce qui m'énerve dans le Sprint
# - Sad: Ce qui me déçoit
# - Glad: Ce qui me rend heureux

# Format 4Ls (Liked/Learned/Lacked/Longed for)
# - Liked: Ce que j'ai aimé
# - Learned: Ce que j'ai appris
# - Lacked: Ce qui manquait
# - Longed for: Ce que j'aurais souhaité

# Format Speedboat (Bateau)
# - Ancres: Ce qui ralentit l'équipe
# - Voiles: Ce qui accélère l'équipe
# - Îles: Objectifs à atteindre
# - Rochers: Risques à éviter


# === ERREURS À ÉVITER ===

# [X] Blâmer des personnes
# Mauvais: "Dev 1 a fait trop de bugs."
# Bon: "On a eu plus de bugs que prévu. Comment améliorer notre processus de tests?"

# [X] Actions vagues
# Mauvais: "Améliorer la communication."
# Bon: "Créer un canal Slack #sprint pour les questions urgentes."

# [X] Trop d'actions
# Mauvais: Définir 10 actions
# Bon: Max 3 actions concrètes et réalisables

# [X] Pas de suivi
# Mauvais: Définir des actions et les oublier
# Bon: Vérifier au prochain Sprint si les actions ont été faites


[OK] MÉTRIQUES & INDICATEURS SCRUM

# === VELOCITY (VÉLOCITÉ) ===

# = Nombre de Story Points terminés par Sprint
# = Indicateur de la vitesse de l'équipe

# Exemple:
# Sprint 1: 15 points
# Sprint 2: 18 points
# Sprint 3: 20 points
# Sprint 4: 22 points
# Moyenne: 18.75 points/Sprint

# Utilisation:
# - Prévoir combien de stories sélectionner au prochain Sprint
# - Identifier les tendances (équipe qui s'améliore)
# - Communiquer avec les stakeholders (estimations)

# Attention:
# - La vélocité varie selon l'équipe (pas de comparaison entre équipes!)
# - Peut diminuer temporairement (membres absents, complexité élevée)
# - Ne JAMAIS utiliser pour évaluer les performances individuelles


# === BURNDOWN CHART (GRAPHIQUE D'AVANCEMENT) ===

# = Graphique montrant le travail restant jour par jour

# Axe Y: Story Points restants
# Axe X: Jours du Sprint (Jour 1 à 14)

# Exemple Sprint avec 20 points:
# Jour 1:  20 points restants (rien terminé)
# Jour 3:  18 points (2 points terminés)
# Jour 5:  15 points (5 points terminés)
# Jour 7:  12 points
# Jour 10: 8 points
# Jour 12: 4 points
# Jour 14: 0 points (tout terminé!) [OK]

# Ligne idéale:
# = Descente linéaire de 20 à 0
# = Si l'équipe est sur la ligne idéale, Sprint on track

# Interprétation:
# - Courbe au-dessus de la ligne idéale: Équipe en retard
# - Courbe en dessous: Équipe en avance
# - Courbe plate: Pas de stories terminées (problème!)


# === BURNUP CHART (GRAPHIQUE DE PROGRESSION) ===

# = Inverse du Burndown
# = Montre le travail TERMINÉ (au lieu du travail restant)

# Axe Y: Story Points terminés
# Axe X: Jours du Sprint

# Avantage:
# - Plus motivant (on voit la progression!)
# - Permet de voir les ajouts de scope (si ligne monte soudainement)


# === CUMULATIVE FLOW DIAGRAM (CFD) ===

# = Graphique montrant le flux de stories à travers les colonnes du board

# Axe Y: Nombre de stories
# Axe X: Jours
# Couleurs: Une couleur par colonne (TO DO, IN PROGRESS, REVIEW, DONE)

# Interprétation:
# - Largeur de "IN PROGRESS": Si trop large, goulot d'étranglement
# - Largeur de "REVIEW": Si trop large, code reviews trop lents

# Exemple:
#        │
#   15   │          ┌─ DONE (croissant)
#        │       ┌──┘
#   10   │    ┌──┘──── REVIEW (stable)
#        │ ┌──┘────── IN PROGRESS (stable)
#    5   │─┘────────── TO DO (décroissant)
#        │
#        └────────────────────────
#        J1  J3  J5  J7  J10  J14


# === CYCLE TIME (TEMPS DE CYCLE) ===

# = Temps moyen pour terminer une story
# = Du moment où elle entre en "IN PROGRESS" jusqu'à "DONE"

# Exemple:
# Story 1: 2 jours
# Story 2: 3 jours
# Story 3: 1 jour
# Story 4: 4 jours
# Cycle Time moyen: 2.5 jours

# Utilisation:
# - Identifier les stories qui prennent trop de temps
# - Améliorer le flux de travail


# === LEAD TIME (TEMPS D'ATTENTE) ===

# = Temps total depuis la création de la story jusqu'à "DONE"
# = Inclut le temps dans "TO DO" (attente)

# Lead Time = Temps en TO DO + Cycle Time

# Exemple:
# Story créée le Jour 1
# Entre en "IN PROGRESS" le Jour 5 (4 jours d'attente)
# Terminée le Jour 8 (3 jours de travail)
# Lead Time: 7 jours
# Cycle Time: 3 jours


# === SPRINT GOAL SUCCESS RATE (TAUX DE SUCCÈS) ===

# = Pourcentage de Sprints où le Sprint Goal a été atteint

# Exemple sur 10 Sprints:
# Sprint Goal atteint: 8 fois
# Sprint Goal non atteint: 2 fois
# Taux de succès: 80%

# Utilisation:
# - Identifier si l'équipe est trop optimiste (sous-estime)
# - Ajuster la vélocité


[OK] DÉFIS & SOLUTIONS SCRUM

# === PROBLÈME: Équipe n'atteint jamais le Sprint Goal ===

# Causes possibles:
# 1. Vélocité surestimée (équipe trop optimiste)
# 2. Stories mal estimées
# 3. Trop d'interruptions externes
# 4. Scope qui change en cours de Sprint

# Solutions:
# 1. Réduire le nombre de Story Points sélectionnés
#    Exemple: Si vélocité = 20, sélectionner 15-16 points seulement
# 2. Améliorer l'estimation (Planning Poker plus rigoureux)
# 3. SM protège mieux l'équipe (filtrer les demandes externes)
# 4. PO fige le Sprint Backlog (pas de changements en cours)


# === PROBLÈME: Daily Scrum dépasse 15 minutes ===

# Causes:
# 1. Discussions techniques (résolution de problèmes)
# 2. Trop de détails dans les réponses
# 3. Équipe trop grande (>9 personnes)

# Solutions:
# 1. SM interrompt poliment: "Prenons RDV après le Daily."
# 2. Format strict: 3 questions uniquement, réponses concises
# 3. Timer visible (affiche 15 min countdown)
# 4. Si équipe >9: diviser en 2 équipes SCRUM


# === PROBLÈME: Stories jamais terminées ("Almost Done") ===

# Causes:
# 1. Definition of Done pas claire
# 2. Stories trop grosses
# 3. Critères d'acceptation manquants

# Solutions:
# 1. Revoir la DoD avec l'équipe (ajouter des critères)
# 2. Découper les stories en plus petites (max 8 points)
# 3. PO rédige des critères d'acceptation AVANT le Sprint Planning


# === PROBLÈME: Burndown Chart ne descend pas ===

# Causes:
# 1. Stories bloquées (dépendances externes)
# 2. Équipe attend les code reviews
# 3. Stories trop complexes

# Solutions:
# 1. Daily Scrum: identifier les blockers tôt
# 2. Code reviews async (max 24h)
# 3. Décomposer les stories complexes en sous-tâches


# === PROBLÈME: Stakeholders insatisfaits ===

# Causes:
# 1. Product Backlog mal priorisé
# 2. Pas de démos régulières (Sprint Review ignorée)
# 3. Communication insuffisante avec le PO

# Solutions:
# 1. PO priorise selon la valeur business (pas la facilité technique)
# 2. Sprint Review obligatoire (démonstration live)
# 3. PO collecte les feedbacks entre les Sprints


# === PROBLÈME: Équipe démotivée ===

# Causes:
# 1. Trop de pression (deadlines serrées)
# 2. Pas de reconnaissance des efforts
# 3. Sprints répétitifs (pas d'innovation)

# Solutions:
# 1. SM vérifie le bien-être de l'équipe (1-on-1)
# 2. Célébrer les succès (fin de Sprint: pizza, remerciements)
# 3. Allouer 10-20% du Sprint pour innovation/refactoring


# === PROBLÈME: PO absent ou peu impliqué ===

# Causes:
# 1. PO a trop de responsabilités (plusieurs équipes)
# 2. PO ne comprend pas son rôle

# Solutions:
#1. SM éduque le PO sur son rôle (formation SCRUM)
# 2. Limiter le PO à 1-2 équipes maximum
# 3. Si PO toujours absent: escalade (direction)


[OK] SCRUM vs AUTRES MÉTHODES AGILES

# === SCRUM vs KANBAN ===

# SCRUM:
# - Sprints de durée fixe (2-4 semaines)
# - Rôles définis (PO, SM, Dev Team)
# - Cérémonies obligatoires (Daily, Sprint Planning, Review, Retro)
# - Engagement sur un Sprint Backlog
# - Meilleur pour: Projets avec deadlines, équipes stables

# KANBAN:
# - Flux continu (pas de Sprints)
# - Pas de rôles obligatoires
# - Pas de cérémonies formelles
# - Limite de WIP (Work In Progress) par colonne
# - Meilleur pour: Support technique, maintenance, flux continu

# SCRUMBAN (Hybride):
# - Sprints de SCRUM + flux continu de Kanban
# - Utile pour équipes en transition


# === SCRUM vs XP (Extreme Programming) ===

# SCRUM:
# - Focus sur la gestion de projet
# - Pas de pratiques techniques imposées

# XP (Extreme Programming):
# - Focus sur les pratiques de développement
# - Pratiques techniques obligatoires:
#   - Pair Programming
#   - TDD (Test-Driven Development)
#   - Refactoring continu
#   - Intégration continue

# Combinaison SCRUM + XP:
# - SCRUM pour la structure (Sprints, rôles)
# - XP pour les pratiques techniques
# = Très puissant!


# === SCRUM vs WATERFALL (Cascade) ===

# WATERFALL (Méthode traditionnelle):
# Phases séquentielles:
#   1. Analyse des besoins (3 mois)
#   2. Design (2 mois)
#   3. Développement (6 mois)
#   4. Tests (2 mois)
#   5. Déploiement (1 mois)
# Total: 14 mois avant première livraison!

# Problèmes:
# - Impossible de changer les besoins en cours
# - Bugs découverts à la fin (coûteux à corriger)
# - Client découvre le produit trop tard

# SCRUM:
# - Livraisons toutes les 2 semaines
# - Feedback constant
# - Adaptation rapide aux changements

# Quand utiliser Waterfall?
# - Projets avec exigences 100% fixes (rare!)
# - Industrie réglementée (pharmaceutique, aéronautique)


[OK] OUTILS & TEMPLATES SCRUM

# === TEMPLATE USER STORY ===

"""
Titre: Connexion avec Google OAuth

En tant qu'utilisateur
Je veux me connecter avec mon compte Google
Afin de gagner du temps (pas besoin de créer un nouveau compte)

Critères d'acceptation:
1. Étant donné que je suis sur la page de login
   Quand je clique sur "Se connecter avec Google"
   Alors je suis redirigé vers la page d'authentification Google

2. Étant donné que je me connecte avec Google
   Quand je donne mon autorisation
   Alors mon compte est créé automatiquement avec les infos Google

3. Étant donné que je me suis déjà connecté avec Google
   Quand je clique sur "Se connecter avec Google"
   Alors je suis connecté directement (sans re-créer de compte)

Story Points: 8
Priorité: Haute
Sprint: Sprint 5
"""


# === TEMPLATE SPRINT GOAL ===

"""
Sprint Goal - Sprint 5

Objectif: Système de paiement Stripe fonctionnel

Résultat attendu:
- L'utilisateur peut ajouter un produit au panier
- L'utilisateur peut payer avec Stripe
- L'utilisateur reçoit une confirmation email

Stories incluses:
1. Ajouter produit au panier (5 points)
2. Intégrer Stripe (8 points)
3. Email de confirmation (3 points)

Total: 16 Story Points

Critère de succès:
- Un utilisateur peut acheter un produit de bout en bout
- Tests de paiement validés (sandbox Stripe)
"""


# === TEMPLATE DEFINITION OF DONE (DoD) ===

"""
Definition of Done - Équipe Projet E-Commerce

Une User Story est "DONE" si et seulement si:

1. Code:
   [OK] Code écrit et fonctionnel
   [OK] Code respecte les standards (linter, formatage)
   [OK] Pas de code commenté ou TODO

2. Tests:
   [OK] Tests unitaires écrits (couverture >80%)
   [OK] Tests d'intégration écrits
   [OK] Tous les tests passent (CI/CD)

3. Review:
   [OK] Code review fait par 2 développeurs minimum
   [OK] Approbation des reviewers

4. Documentation:
   [OK] README mis à jour si nécessaire
   [OK] Commentaires dans le code (fonctions complexes)

5. Déploiement:
   [OK] Déployé en environnement de staging
   [OK] Testé manuellement en staging
   [OK] PO a validé la fonctionnalité

6. Qualité:
   [OK] Pas de bugs critiques
   [OK] Tous les critères d'acceptation remplis

Si un seul critère manque, la story retourne en "IN PROGRESS"!
"""


# === TEMPLATE RETROSPECTIVE (ACTION PLAN) ===

"""
Retrospective - Sprint 5

Date: 15 Mars 2024
Participants: PO, SM, Dev1, Dev2, Dev3

Format: Start/Stop/Continue

CONTINUE (Ce qui fonctionne bien):
- Daily Scrum efficaces (toujours <15 min)
- Pair programming sur stories complexes
- Communication fluide avec le PO

STOP (Ce qui ne fonctionne pas):
- Réunions externes trop fréquentes
- Code reviews synchrones (réunions de 2h)

START (Ce qu'on devrait essayer):
- Automatiser les tests avec CI/CD
- Code reviews async via GitHub
- Mob programming pour les stories 13+ points

ACTIONS CONCRÈTES:

Action 1: Setup CI/CD
- Responsable: Dev3
- Échéance: Avant Sprint 6
- Tâches:
  1. Configurer GitHub Actions
  2. Ajouter tests automatiques
  3. Notifier Slack en cas d'échec
- Critère de succès: Tests auto à chaque push

Action 2: Code reviews async
- Responsable: Toute l'équipe
- Échéance: Immédiat (Sprint 6)
- Règles:
  1. PR avec description claire
  2. Review dans les 24h
  3. 2 approvals minimum
- Critère de succès: Plus de réunions de review

Action 3: Limiter réunions externes
- Responsable: SM + PO
- Échéance: Immédiat
- Actions:
  1. PO filtre les demandes
  2. Créer créneau "Office Hours" (1h/jour)
- Critère de succès: Max 2h/semaine de réunions externes

Prochain suivi: Retrospective Sprint 6 (29 Mars 2024)
"""


[OK] CHECKLIST DÉMARRAGE PROJET SCRUM

# === AVANT LE PREMIER SPRINT ===

# [WHITE_SQUARE] Équipe constituée
#   - Product Owner identifié
#   - Scrum Master identifié
#   - Development Team (3-9 personnes)

# [WHITE_SQUARE] Rôles et responsabilités clarifiés
#   - Chacun comprend son rôle
#   - Formation SCRUM si nécessaire

# [WHITE_SQUARE] Vision du produit définie
#   - PO a écrit la vision (1-2 pages)
#   - Partagée avec toute l'équipe

# [WHITE_SQUARE] Product Backlog initial créé
#   - 20-30 User Stories minimum
#   - Priorisées par valeur business
#   - Stories du haut du Backlog affinées

# [WHITE_SQUARE] Definition of Done rédigée
#   - Critères clairs et mesurables
#   - Validés par toute l'équipe

# [WHITE_SQUARE] Durée du Sprint décidée
#   - Recommandé: 2 semaines
#   - Fixe pour tous les Sprints

# [WHITE_SQUARE] Outil de gestion choisi
#   - Jira, Trello, Monday, ClickUp ou board physique
#   - Configuré et prêt

# [WHITE_SQUARE] Environnements techniques préparés
#   - Dépôt Git créé
#   - Environnements Dev/Staging/Prod
#   - CI/CD si possible

# [WHITE_SQUARE] Sprint Planning #1 planifié
#   - Date, heure, durée définie
#   - Salle réservée ou lien Zoom
#   - Participants confirmés


# === PENDANT LE PREMIER SPRINT ===

# [WHITE_SQUARE] Sprint Planning effectué
#   - Sprint Goal défini
#   - Stories sélectionnées
#   - Tâches créées

# [WHITE_SQUARE] Daily Scrum tous les jours
#   - Heure fixe
#   - 15 minutes max
#   - Burndown Chart mis à jour

# [WHITE_SQUARE] Sprint Review préparée
#   - Environnement de démo prêt
#   - Stakeholders invités

# [WHITE_SQUARE] Sprint Retrospective planifiée
#   - Date et heure
#   - Format choisi (Start/Stop/Continue)


[OK] RESSOURCES & LIENS

# Documentation officielle SCRUM:
# https://www.scrumguides.org/

# Scrum Guide en Français (PDF gratuit):
# https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf

# Formations SCRUM:
# Scrum.org: https://www.scrum.org/ (certifications PSM, PSPO)
# Scrum Alliance: https://www.scrumalliance.org/ (certifications CSM, CSPO)

# Outils de gestion SCRUM:
# Jira: https://www.atlassian.com/software/jira
# Trello: https://trello.com
# Monday: https://monday.com
# ClickUp: https://clickup.com
# Azure DevOps: https://azure.microsoft.com/devops

# Planning Poker en ligne:
# https://planningpokeronline.com
# https://www.planitpoker.com

# Templates gratuits:
# Miro (tableaux collaboratifs): https://miro.com/templates/
# Notion (documentation): https://www.notion.so/templates

# Livres recommandés:
# - "Scrum: The Art of Doing Twice the Work in Half the Time" - Jeff Sutherland
# - "Essential Scrum" - Kenneth Rubin
# - "User Stories Applied" - Mike Cohn
# - "Agile Estimating and Planning" - Mike Cohn

# Blogs & Articles:
# https://www.scrum.org/resources/blog
# https://www.mountaingoatsoftware.com/blog

# Vidéos YouTube:
# "What is Scrum? | Scrum in 20 Minutes" - Simplilearn
# "Agile Product Ownership in a Nutshell" - Henrik Kniberg

# Communautés:
# Reddit: r/scrum, r/agile
# LinkedIn Groups: Scrum Practitioners, Agile Alliance


[OK] EXEMPLE ULTRA-DÉTAILLÉ: PROJET COMPLET

# === PROJET: APPLICATION DE GESTION DE TÂCHES (TODO APP) ===

# PHASE 1: PRÉPARATION (SPRINT 0)

# Équipe:
# - Product Owner: Alice (représente les utilisateurs)
# - Scrum Master: Bob (facilite le processus)
# - Dev Team: Charlie (Full-stack), Diana (Backend), Eve (Frontend)

# Vision du produit (rédigée par Alice):
"""
Notre application de gestion de tâches permettra aux utilisateurs
de créer, organiser et suivre leurs tâches quotidiennes de manière
simple et intuitive. L'app se différencie par sa simplicité (pas de
fonctionnalités complexes inutiles) et sa rapidité. Notre cible:
professionnels occupés qui veulent un outil sans friction.

Objectifs business:
- 1000 utilisateurs actifs dans les 3 premiers mois
- Taux de rétention de 60% après 1 mois
- Note moyenne 4.5/5 sur les app stores
"""

# Product Backlog initial (créé par Alice avec l'équipe):
# 1. Inscription et connexion (5 points) - MUST HAVE
# 2. Créer une tâche (3 points) - MUST HAVE
# 3. Voir la liste des tâches (2 points) - MUST HAVE
# 4. Marquer une tâche comme terminée (2 points) - MUST HAVE
# 5. Modifier une tâche (3 points) - SHOULD HAVE
# 6. Supprimer une tâche (2 points) - SHOULD HAVE
# 7. Filtrer par statut (terminé/en cours) (3 points) - SHOULD HAVE
# 8. Catégories de tâches (5 points) - COULD HAVE
# 9. Dates d'échéance (3 points) - COULD HAVE
# 10. Notifications push (8 points) - COULD HAVE
# 11. Partage de tâches (13 points) - WON'T HAVE (pour v1)

# Definition of Done (définie ensemble):
"""
Une story est DONE si:
[OK] Code écrit et fonctionnel
[OK] Tests unitaires (couverture >70%)
[OK] Code review par 1 autre dev
[OK] Testé manuellement
[OK] Déployé en staging
[OK] PO a validé
"""

# Configuration:
# - Durée Sprint: 2 semaines
# - Outil: Trello
# - Stack technique: React (frontend), Node.js + Express (backend), MongoDB

# SPRINT 1: "Fonctionnalités de base"

# === JOUR 1: Sprint Planning ===

# Partie 1 (QUOI):
# Alice (PO): "Notre Sprint Goal est: Les utilisateurs peuvent créer et gérer des tâches basiques."
# Alice: "Regardons les stories prioritaires..."

# Story 1: Inscription et connexion (5 points)
# Charlie: "On utilise JWT pour l'authentification?"
# Alice: "Oui, c'est simple et sécurisé."
# Diana: "Faut-il valider l'email?"
# Alice: "Pour la v1, non. On l'ajoutera plus tard."

# Story 2: Créer une tâche (3 points)
# Eve: "Quels champs obligatoires?"
# Alice: "Juste le titre. Description optionnelle."

# Story 3: Voir liste des tâches (2 points)
# Charlie: "Tri par date de création?"
# Alice: "Oui, les plus récentes en premier."

# Story 4: Marquer comme terminée (2 points)
# Bob (SM): "Pas de questions sur celle-ci?"
# Équipe: "Non, c'est clair."

# Vélocité estimée: Première fois, on essaie 12 points
# Stories sélectionnées: 1, 2, 3, 4 (total: 12 points)

# Partie 2 (COMMENT):
# Décomposition en tâches techniques:

# Story 1: Inscription et connexion (5 points)
#   - Setup JWT auth (Charlie) - 3h
#   - Formulaire inscription (Eve) - 2h
#   - Formulaire login (Eve) - 2h
#   - API POST /register (Diana) - 3h
#   - API POST /login (Diana) - 2h
#   - Tests (Charlie) - 3h

# Story 2: Créer une tâche (3 points)
#   - Modèle Task MongoDB (Diana) - 1h
#   - API POST /tasks (Diana) - 2h
#   - Formulaire création (Eve) - 2h
#   - Tests (Charlie) - 2h

# Story 3: Voir liste (2 points)
#   - API GET /tasks (Diana) - 1h
#   - Composant ListeTaches (Eve) - 2h
#   - Tests (Charlie) - 1h

# Story 4: Marquer terminée (2 points)
#   - API PATCH /tasks/:id (Diana) - 1h
#   - Bouton checkbox (Eve) - 1h
#   - Tests (Charlie) - 1h

# Trello board créé avec 4 colonnes:
# TO DO | IN PROGRESS | REVIEW | DONE

# === JOURS 2-13: Développement ===

# JOUR 2: Daily Scrum (9h00)
# Charlie: "Hier: Setup projet. Aujourd'hui: JWT auth. Pas de blocker."
# Diana: "Hier: Setup DB MongoDB. Aujourd'hui: API register. Pas de blocker."
# Eve: "Hier: Setup React. Aujourd'hui: Formulaire inscription. Pas de blocker."

# (Mise à jour Trello: déplacer cartes vers IN PROGRESS)

# JOUR 5: Daily Scrum
# Charlie: "Hier: JWT fini. Aujourd'hui: Tests auth. Pas de blocker."
# Diana: "Hier: API register et login finies. Aujourd'hui: Modèle Task. Blocker: besoin de clarifier le schéma."
# Bob (SM): "Alice peut clarifier après le Daily."
# Eve: "Hier: Formulaires finis. Aujourd'hui: Composant liste. Pas de blocker."

# (Alice clarifie avec Diana le schéma Task)

# JOUR 10: Daily Scrum
# Charlie: "Hier: Tests story 1 et 2. Aujourd'hui: Tests story 3. Pas de blocker."
# Diana: "Hier: API PATCH terminée. Aujourd'hui: Code review de Charlie. Pas de blocker."
# Eve: "Hier: Bouton checkbox. Aujourd'hui: Polish UI. Pas de blocker."

# JOUR 13: Daily Scrum (dernier jour de dev)
# Équipe: Toutes les stories sont DONE! [OK]

# Burndown Chart final:
# Jour 1: 12 points restants
# Jour 3: 10 points (Story 4 done)
# Jour 5: 8 points (Story 3 done)
# Jour 8: 5 points (Story 1 done)
# Jour 13: 0 points (Story 2 done)

# === JOUR 14: Sprint Review ===

# Participants: Équipe + 2 stakeholders (futurs utilisateurs)

# Alice: "Bienvenue! Sprint Goal: Fonctionnalités de base. Nous avons terminé les 4 stories."

# Demo Story 1: Inscription et connexion
# Charlie ouvre l'app en LIVE:
#   - Crée un compte avec email/password
#   - Se déconnecte
#   - Se reconnecte avec les mêmes credentials
# Stakeholder 1: "Super! Et si le mot de passe est faux?"
# Charlie: Teste avec mauvais password -> "Identifiants incorrects"
# Stakeholder 1: "Parfait!"

# Demo Story 2: Créer une tâche
# Eve: "Maintenant je vais créer une tâche..."
#   - Clique "Nouvelle tâche"
#   - Entre: "Acheter du pain"
#   - Clique "Créer"
#   - La tâche apparaît dans la liste
# Stakeholder 2: "C'est rapide et simple, j'aime!"

# Demo Story 3: Voir liste
# Diana: "Voici la liste de toutes mes tâches..."
#   - Crée 5 tâches
#   - Affiche la liste (triée par date)
# Stakeholder 1: "On peut filtrer par catégorie?"
# Alice: "Pas encore, c'est prévu pour Sprint 3."

# Demo Story 4: Marquer terminée
# Eve: "Je peux cocher une tâche..."
#   - Coche "Acheter du pain"
#   - La tâche est barrée
#   - Décoche -> La tâche redevient active
# Stakeholder 2: "Génial!"

# Feedback:
# Stakeholder 1: "J'aimerais voir des dates d'échéance."
# Alice: "Noté! Story 9 dans le Backlog."
# Stakeholder 2: "Peut-on ajouter des sous-tâches?"
# Alice: "Intéressant! Je crée une nouvelle story pour ça."

# === JOUR 14 (après-midi): Retrospective ===

# Format: Start/Stop/Continue

# CONTINUE:
# - Daily Scrum efficaces (toujours <15 min)
# - Pair programming pour JWT (Charlie + Diana)

# STOP:
# - Attendre trop longtemps pour clarifier (Story avec Diana)

# START:
# - Backlog Refinement à mi-Sprint pour préparer Sprint 2
# - Tests automatiques avec CI/CD

# Actions:
# Action 1: Setup GitHub Actions (Charlie, avant Sprint 2)
# Action 2: Backlog Refinement Jour 7 du Sprint 2 (Toute l'équipe)

# SPRINT 2: "Gestion avancée des tâches"

# Sprint Goal: "Les utilisateurs peuvent modifier, supprimer et filtrer leurs tâches"

# Stories sélectionnées (vélocité: 12 points du Sprint 1):
# - Story 5: Modifier une tâche (3 points)
# - Story 6: Supprimer une tâche (2 points)
# - Story 7: Filtrer par statut (3 points)
# - Story 9: Dates d'échéance (3 points)
# Total: 11 points

# (Sprint se déroule de manière similaire...)

# === RÉSULTAT APRÈS 6 SPRINTS ===

# Vélocité moyenne: 13 points/Sprint
# Stories complétées: 20
# Utilisateurs beta: 50
# Feedback: 4.2/5
# Bugs critiques: 0

# Prêt pour le lancement public! [RAPIDE]


[OK] FAQ SCRUM POUR DÉBUTANTS

# Q: Combien de temps pour apprendre SCRUM?
# R: 1-2 jours pour les bases théoriques. 2-3 Sprints pour maîtriser la pratique.

# Q: SCRUM fonctionne-t-il pour des projets non-logiciels?
# R: Oui! SCRUM est utilisé en marketing, RH, construction, événementiel, etc.

# Q: Peut-on utiliser SCRUM avec une équipe remote?
# R: Absolument! Utilise Jira/Trello + Zoom/Slack. Les cérémonies se font en visio.

# Q: Que faire si un membre de l'équipe part en vacances pendant un Sprint?
# R: Ajuster la vélocité. Si l'équipe perd 20% de capacité, sélectionner 20% moins de points.

# Q: Peut-on changer le Sprint Backlog en cours de Sprint?
# R: Idéalement non. Si urgence absolue, PO et équipe discutent. Remplacer une story par une autre.

# Q: Faut-il être certifié pour utiliser SCRUM?
# R: Non, mais les certifications (PSM, CSM) aident à maîtriser le framework.

# Q: Combien coûte une certification SCRUM?
# R: PSM I (Scrum.org): $150. CSM (Scrum Alliance): $1000-1500 (inclut formation).

# Q: SCRUM impose-t-il des outils spécifiques?
# R: Non. Tu peux utiliser un board physique ou n'importe quel outil digital.

# Q: Comment gérer les bugs en SCRUM?
# R: Les bugs critiques sont traités immédiatement. Les bugs mineurs deviennent des stories dans le Backlog.

# Q: Peut-on avoir plusieurs Product Owners?
# R: Non, un seul PO par produit pour éviter les conflits de priorité. Mais le PO peut déléguer.

# Q: Que faire si l'équipe termine toutes les stories avant la fin du Sprint?
# R: Prendre des stories supplémentaires du Backlog (en accord avec le PO).

# Q: SCRUM garantit-il le succès du projet?
# R: SCRUM améliore les chances de succès (feedback rapide, adaptation), mais ne garantit rien. Le succès dépend de l'équipe, du produit et du marché.

# FIN DU CHEATSHEET SCRUM
```