Scrum
& Agile

── WATERFALL ──────────────────────────────
  Besoins → Design → Dev → Test → Déploiement
  |←──────────────── 6-18 mois ────────────→|
  Feedback client : seulement à la fin !
  Si les besoins changent → très coûteux

── SCRUM ───────────────────────────────────
  Sprint 1 (2 sem) : besoins → dev → test → livraison
  Sprint 2 (2 sem) : besoins → dev → test → livraison
  Sprint 3 (2 sem) : besoins → dev → test → livraison
  ...
  Feedback continu, adaptation à chaque sprint
  Le client voit quelque chose qui fonctionne
  dès la fin du sprint 1 !

── ANALOGIE ────────────────────────────────
  Cascade : construire une maison selon plan
            → on découvre les problèmes à la fin
  Agile   : sculpter en montrant régulièrement
            → on ajuste avant que ce soit trop tard

"Qui priorise le backlog ?"
→ Le Product Owner (PO) seul.
  L'équipe peut conseiller, pas décider.

"Qui assigne les tâches ?"
→ Personne ! L'équipe s'auto-organise.
  Chaque développeur choisit son travail.

"Qui décide de la durée du sprint ?"
→ L'équipe Scrum — généralement 2 semaines.
  La durée reste fixe tout au long du projet.

"Qui peut annuler un sprint ?"
→ Uniquement le Product Owner.
  Rare — seulement si l'objectif sprint
  devient obsolète.

"Qui gère les bugs en cours de sprint ?"
→ L'équipe — elle peut les ajouter au
  sprint backlog si le PO l'approuve.

# Liste ordonnée de tout ce qui est souhaité
# dans le produit. Propriété du PO.

Contenu typique :
  → User Stories  (nouvelles fonctionnalités)
  → Bugs          (corrections)
  → Tâches tech   (refactoring, dette technique)
  → Spikes        (recherche, exploration)

Propriétés :
  → Ordonné par valeur / priorité (haut = urgent + important)
  → Estimé (au moins les items en haut)
  → Vivant : évolue tout au long du projet
  → Émergent : le backlog n'est JAMAIS complet

# Exemple de backlog ordonné :
 1. [US-12] Connexion OAuth Google          [8 pts]
 2. [US-07] Recherche produit avec filtres  [5 pts]
 3. [US-18] Notification email commande     [3 pts]
 4. [BUG-03] Fix crash panier vide          [2 pts]
 5. [US-22] Export CSV des commandes        [5 pts]
    ...

## SPRINT BACKLOG
# Sous-ensemble du Product Backlog sélectionné
# pour le sprint en cours. Propriété de l'équipe.

Contenu :
  → User Stories sélectionnées au Sprint Planning
  → Tâches techniques pour les réaliser
  → Objectif du sprint (Sprint Goal)

Règles :
  → Seule l'équipe peut modifier le Sprint Backlog
  → Le PO ne peut pas ajouter du travail en cours de sprint
  → L'équipe peut négocier le scope avec le PO

## INCRÉMENT
# Somme de tout le travail accompli + incréments
# précédents. DOIT être fonctionnel et potentiellement
# livrable à chaque fin de sprint.

Définition : un incrément est "Done" seulement si
  il respecte la Définition of Done (DoD)
  → pas juste "développé", mais testé, intégré,
    documenté selon les standards de l'équipe.

# Format classique (toujours utile comme guide)

1. "Qu'ai-je fait hier qui a aidé l'équipe
    à atteindre le Sprint Goal ?"

2. "Que vais-je faire aujourd'hui pour aider
    l'équipe à atteindre le Sprint Goal ?"

3. "Y a-t-il des obstacles qui m'empêchent,
    moi ou l'équipe, d'atteindre le Sprint Goal ?"

# À ÉVITER dans le Daily :
→ Rapport de statut au manager/SM
→ Discussions techniques longues (→ after-meeting)
→ Résolution de problèmes en séance
→ Dépasser 15 minutes

# Format moderne (Guide Scrum 2020) :
→ Librement structuré par l'équipe
→ L'objectif reste : inspecter la progression
  vers le Sprint Goal et adapter le plan

## Starfish (5 colonnes)
  Stop        | ce qui nuit à l'équipe
  Less        | à réduire mais pas arrêter
  Keep        | ce qui fonctionne bien
  More        | à amplifier
  Start       | nouvelles idées à essayer

## What went well / What didn't / Actions
  ✓ Ce qui s'est bien passé
  ✗ Ce qui n'a pas bien fonctionné
  → Actions concrètes pour le prochain sprint

## 4L (4 Ls)
  Liked       | ce qu'on a aimé
  Learned     | ce qu'on a appris
  Lacked      | ce qui manquait
  Longed for  | ce qu'on aurait voulu avoir

# Règle d'or :
→ Chaque rétro produit AU MOINS 1 action concrète,
  assignée à quelqu'un, avec une date.
→ Sans action = réunion inutile.

# Durée : 1 à 4 semaines (2 semaines = standard)
→ Fixe et consistante sur tous les sprints
→ Un sprint = un conteneur temporel (time-box)

# Pendant le sprint :
→ Aucun changement ne doit mettre en danger le Sprint Goal
→ La qualité ne diminue pas
→ Le Product Backlog est affiné si besoin
→ Le scope peut être négocié avec le PO
   (mais pas le Sprint Goal ni la durée)

# Sprint Goal :
→ Un objectif unique et motivant pour le sprint
→ Donne de la flexibilité à l'équipe sur le "comment"
→ Rend le sprint cohérent (pas juste une liste de tâches)

# Exemple Sprint Goal :
   ✗ Mauvais : "Faire les US-12, US-07 et BUG-03"
   ✓ Bon     : "Permettre aux utilisateurs de
                 trouver et acheter un produit
                 sans aide humaine"

Jour  1 (Lundi)   : Sprint Planning (4h)
                    → Sélection des US
                    → Découpage en tâches
                    → Estimation si nécessaire

Jours 1-9          : Développement
                    → Daily Scrum (9h, 15 min)
                    → Dev, tests, intégration continue
                    → Backlog refinement (jour 4-5, 2h)

Jour  9 (Jeudi)    : Code freeze
                    → Plus de nouvelle fonctionnalité
                    → Stabilisation, tests de régression

Jour 10 (Vendredi) : Sprint Review (2h)
                    → Démo au client / PO / stakeholders
                    → Feedback, mise à jour du backlog

Jour 10 (Vendredi) : Sprint Retrospective (1h30)
                    → Quoi améliorer
                    → Actions pour le sprint suivant

En tant que [QUI — le persona/rôle],
je veux [QUOI — l'action ou la fonctionnalité],
afin de [POURQUOI — la valeur ou le bénéfice].

───────────────────────────────────────────

En tant que client connecté,
je veux pouvoir sauvegarder des articles dans
         une liste de favoris,
afin de les retrouver facilement lors de ma
         prochaine visite.

───────────────────────────────────────────

En tant que administrateur,
je veux exporter la liste des commandes du mois
         au format CSV,
afin de l'importer dans notre logiciel comptable
         sans ressaisie manuelle.

───────────────────────────────────────────
# Le POURQUOI est crucial :
# → Explique la valeur → guide les décisions
# → Si on ne peut pas justifier le pourquoi
#   → remettre en question la fonctionnalité

# Behavior-Driven Development — très précis,
# facilement automatisable en tests

Given [contexte initial / précondition]
When  [action déclenchante]
Then  [résultat attendu / postcondition]

───────────────────────────────────────────
US : connexion utilisateur

Given un utilisateur avec email "alice@ex.com"
      et mot de passe "Secret123" existant
When  il soumet le formulaire de connexion
Then  il est redirigé vers son tableau de bord
      et un token JWT valide est créé

Given un utilisateur avec un mauvais mot de passe
When  il soumet le formulaire de connexion
Then  un message "Identifiants incorrects" s'affiche
      et aucun token n'est créé
      et le formulaire n'indique pas lequel
      des deux champs est incorrect (sécurité)

Given 5 tentatives échouées consécutives
When  l'utilisateur tente une 6ème connexion
Then  son compte est bloqué 15 minutes

# Plus rapide à écrire, moins formel

US : Recherche de produits

☐ La recherche s'effectue sur le nom, la description
  et les tags du produit
☐ Les résultats sont triés par pertinence (défaut)
  puis par prix ou popularité (options)
☐ La recherche avec 0 résultat affiche un message
  "Aucun résultat pour X" et suggère des alternatives
☐ La recherche est insensible à la casse
  et aux accents
☐ Temps de réponse < 300ms pour 95% des requêtes
☐ La pagination affiche max 20 résultats par page

# Caractéristiques de bons critères :
✓ Testables (on peut dire oui ou non)
✓ Indépendants (pas de "et puis aussi")
✓ Négatifs inclus (que se passe-t-il si ça échoue)
✓ Ni trop vagues ("intuitif"), ni trop techniques
✗ "L'interface doit être belle" → non testable
✗ "Utiliser Redis pour le cache" → trop technique

Thème / Initiative
  └── Fonctionnalité transversale de haut niveau
      Ex : "Expérience d'achat mobile"

  Epic
    └── Grande US trop volumineuse pour un sprint
        Ex : "Panier d'achat complet"
        → se découpe en plusieurs User Stories

      User Story
        └── Fonctionnalité livrable en 1 sprint
            Ex : "Ajouter un article au panier"

          Tâche (Task)
            └── Unité de travail technique ~1/2 jour
                Ex : "Créer API POST /cart/items"
                     "Écrire les tests unitaires"
                     "Implémenter UI panier React"

# Règle de découpage d'un Epic en US :
# Chaque US doit être :
# 1. Livrable de façon indépendante
# 2. Apporter de la valeur seule
# 3. Compréhensible par le client

Epic : "Système d'authentification"

→ US-01 : Inscription avec email/mot de passe   [5 pts]
→ US-02 : Connexion email/mot de passe           [3 pts]
→ US-03 : Déconnexion                            [1 pt]
→ US-04 : Mot de passe oublié / réinitialisation [5 pts]
→ US-05 : Connexion OAuth Google                 [8 pts]
→ US-06 : Authentification à deux facteurs (2FA) [13 pts]
→ US-07 : Gestion du profil utilisateur          [5 pts]

# Techniques de découpage :
Par étapes du workflow      (créer, lire, modifier, supprimer)
Par type d'utilisateur      (visiteur, connecté, admin)
Par variantes               (cas happy path d'abord)
Par règles métier           (une règle = une US)
Par plateforme              (web d'abord, mobile ensuite)
Par performance             (fonctionnel d'abord, rapide ensuite)

# Un story point mesure l'EFFORT RELATIF,
# pas le temps absolu.

Il combine :
  → Complexité technique (algorithme simple vs complexe)
  → Quantité de travail (petit vs grand)
  → Incertitude / risque (connu vs inconnu)

# Pourquoi pas des heures ?
  → Les heures varient selon les personnes
  → Les estimations en heures sont toujours fausses
  → Les story points restent stables dans le temps
  → "Cette US est 2× plus complexe que celle-là"
     est plus fiable que "ça prend 4 heures"

# Séquence de Fibonacci modifiée (standard) :
  0, 1/2, 1, 2, 3, 5, 8, 13, 21, 40, 100, ?

# Signification pratique (exemple équipe) :
  1 pt  = tâche triviale (changer un texte)
  2 pts = simple et bien connu
  3 pts = standard, quelques inconnues
  5 pts = non trivial, efforts notables
  8 pts = complexe, grande incertitude
 13 pts = très complexe → à décomposer
 21+ pts = trop grand → Epic, décomposer !

# Établir des US de référence au début du projet

1 pt  → "Ajouter un lien dans le footer"
2 pts → "Corriger le style du bouton de connexion"
3 pts → "Afficher la liste des commandes d'un user"
5 pts → "Ajouter la recherche full-text sur les produits"
8 pts → "Intégrer le paiement Stripe complet"

# Pour chaque nouvelle US, l'équipe compare :
"Cette US est-elle plus proche de la recherche (5)
ou du paiement Stripe (8) ?"
→ Consensus : 5 ou 8

# La calibration s'affine sprint après sprint

1. Le PO lit et explique la User Story
   → L'équipe peut poser des questions de clarification

2. Chaque membre choisit sa carte en secret
   → Pas de discussion avant le vote
   → Évite l'effet d'ancrage (suivre le premier)

3. Révélation simultanée
   → Tout le monde retourne sa carte en même temps

4. Si consensus → l'estimation est retenue
   Ex : 3, 3, 3, 5, 3 → probablement 3

5. En cas de divergence → discussion
   Ex : 3, 13, 5, 8, 3 → grosse divergence !
   → Le plus bas explique pourquoi (c'est simple)
   → Le plus haut explique ses inquiétudes
   → Nouvelle information découverte → revote

6. Converger en 2-3 rounds maximum
   → Si toujours pas d'accord → prendre le plus haut
     ou décomposer la story

# Avantage clé : la divergence = information
# "Pourquoi tu votes 13 ?" → "parce que ça nécessite
# une migration de BDD que vous n'avez pas prévue"
# → toute l'équipe découvre un risque !

# Vélocité = story points livrés par sprint
Sprint 1 : 28 pts livrés
Sprint 2 : 40 pts livrés
Sprint 3 : 52 pts livrés
Sprint 4 : 48 pts livrés
Sprint 5 : 56 pts livrés

Vélocité moyenne : (28+40+52+48+56) / 5 = 44.8 pts

# Prédiction de date de livraison :
Backlog restant : 220 story points
Vélocité : ~45 pts / sprint
Sprints restants estimés : 220 / 45 ≈ 5 sprints
Durée sprint : 2 semaines
Livraison estimée : dans ~10 semaines

# Règles d'utilisation :
✓ Utiliser la moyenne des 3 derniers sprints
✓ La vélocité varie — donner une fourchette
✗ NE PAS comparer les vélocités entre équipes
✗ NE PAS utiliser la vélocité pour évaluer
  la performance individuelle
✗ NE PAS forcer l'augmentation de la vélocité
  (→ gonflement des estimations)

# Critères que TOUTE US doit respecter
# pour être considérée "terminée"
# Définie par l'équipe, respectée absolument.

☑ Code développé et en conformité avec
  les standards de l'équipe (lint, formatting)
☑ Code revu par au moins un autre développeur
  (peer review / pull request approuvée)
☑ Tests unitaires écrits (couverture ≥ 80%)
☑ Tests d'intégration passent (CI verte)
☑ Critères d'acceptation tous vérifiés
☑ Documentation mise à jour (si pertinent)
☑ Code mergé sur la branche principale
☑ Déployé sur l'environnement de staging
☑ Démo faite au Product Owner
☑ Aucun bug critique non résolu introduit

# Une US "à 90% terminée" n'est PAS Done.
# Le DoD protège l'équipe contre la dette technique.

# Critères qu'une US doit respecter
# pour pouvoir ENTRER dans un sprint.
# Sans DoR → gaspillage et confusion.

☑ Rédigée au format User Story standard
  (En tant que / Je veux / Afin de)
☑ Critères d'acceptation définis et compréhensibles
☑ Estimée en story points par l'équipe
☑ Suffisamment petite pour tenir dans un sprint
☑ Dépendances identifiées et résolues (ou planifiées)
☑ Maquette / wireframe disponible (si UI)
☑ Règles métier clarifiées avec le PO
☑ Testable (les tests peuvent être écrits à partir
  des critères d'acceptation)

# Processus : Backlog Refinement (ou Grooming)
# = réunion régulière (1-2h/sprint) où l'équipe
# affine les US pour les rendre "Ready"

1. PRÉPARER LA SCÈNE (5-10 min)
   → Check-in : comment chacun se sent
   → Rappeler l'objectif et les règles
   → Créer un espace sûr (Prime Directive)
   → "Chacun a fait du mieux qu'il pouvait
     avec ce qu'il savait à ce moment-là"

2. COLLECTER LES DONNÉES (15-20 min)
   → Timeline du sprint (événements clés)
   → Post-its : bien / à améliorer
   → Données objectives : vélocité, bugs, incidents

3. GÉNÉRER DES INSIGHTS (15-20 min)
   → Regrouper les post-its par thème
   → Voter pour les problèmes prioritaires
   → "Pourquoi ça s'est passé ainsi ?"
   → 5 Pourquoi (root cause analysis)

4. DÉCIDER DES ACTIONS (10-15 min)
   → 1 à 3 actions concrètes MAXIMUM
   → SMART : Spécifique, Mesurable, Atteignable,
     Réaliste, Temporel
   → Chaque action a un responsable et une date

5. CLÔTURER (5 min)
   → Feedback sur la rétro elle-même
   → Célébrer un succès du sprint

✗ MAUVAISE action :
"Améliorer la communication"
→ Trop vague, pas mesurable, pas de responsable

✓ BONNE action :
"Julien met en place un canal Slack #daily-blockers
 d'ici vendredi, pour partager les impediments
 en dehors du Daily Scrum"

───────────────────────────────────────────

✗ MAUVAISE action :
"Écrire plus de tests"
→ Non mesurable, pas de deadline, qui ?

✓ BONNE action :
"L'équipe adopte la règle : aucune PR ne peut
 être mergée sans au moins 2 tests unitaires
 nouveaux. Effectif dès le sprint suivant."

───────────────────────────────────────────
# Suivi des actions :
→ Les afficher au début de chaque rétro
→ Évaluer si elles ont été appliquées
→ Célébrer les succès, ajuster si non appliquées