Les différentes méthodes agiles

Contexte historique

Crise du logiciel des années 90 : les projets livrent en retard, hors budget, hors besoin. Les cycles en V rigides ne supportent pas le changement. Réponse : un manifeste court qui change la priorité des choses.

Les 4 valeurs

• Individus et interactions plutôt que processus et outils
• Logiciel qui marche plutôt que documentation exhaustive
• Collaboration avec le client plutôt que négociation contractuelle
• Adaptation au changement plutôt que suivi d'un plan

Les 12 principes en bref

• Livraisons fréquentes (semaines, pas mois)
• Accueil du changement, même tard dans le projet
• Équipes auto-organisées
• Rythme soutenable
• Simplicité (l'art de maximiser le travail à ne pas faire)
• Rétrospectives régulières pour s'améliorer

Les 3 rôles

• Product Owner : porte la vision, priorise le backlog. Pas un chef de projet
• Scrum Master : facilitateur, retire les blocages. Pas un chef d'équipe
• Équipe de développement : pluridisciplinaire, 5 à 9 personnes, auto-organisée

Les événements

• Sprint planning : on choisit les stories du prochain sprint
• Daily stand-up : 15 min max, debout, focus équipe (pas reporting au chef)
• Sprint review : démo de ce qui a été livré, feedback des parties prenantes
• Rétrospective : ce qu'on garde, ce qu'on change, on agit

Les artefacts

• Product Backlog : la liste de tout ce qu'on aimerait faire, priorisée
• Sprint Backlog : ce qu'on s'engage à faire dans le sprint
• Incrément : ce qui est potentiellement livrable à la fin du sprint

Le sprint

Une itération de 1 à 4 semaines (2 semaines = standard de facto). L'objectif est figé pendant le sprint : on ne change pas le scope en cours.

Le board

Colonnes typiques : À faire, En cours, Review, Terminé. Tu adaptes selon ton workflow (ajout de Bloqué, En staging, etc.). Le board visualise le flux.

WIP limits (Work In Progress)

• Tu fixes un nombre maximum de tâches par colonne
• Si la colonne est pleine, tu ne peux pas en ajouter avant d'avoir terminé une existante
• Effet immédiat : tu finis avant de commencer. Le multitâche destructeur disparaît
• Effet bonus : les blocages remontent vite (la colonne se bloque, on doit s'en occuper)

Flux tiré, pas poussé

En Scrum, l'équipe pousse du travail dans le sprint au planning. En Kanban, l'équipe tire une tâche du backlog quand elle a fini la précédente. Plus fluide, moins de cérémonie.

Les métriques

• Lead time : temps entre la création de la tâche et sa fin
• Cycle time : temps entre le début du travail et sa fin
• Throughput : nombre de tâches finies par semaine

Les pratiques phares

• Pair programming : 2 devs, 1 clavier, moins de bugs, meilleur transfert de connaissances
• TDD (Test-Driven Development) : test d'abord, code après
• Refactoring continu : améliorer le code sans changer son comportement, en permanence
• Intégration continue : merger souvent, tester automatiquement (CI/CD)
• Propriété collective du code : tout le monde peut modifier tout, pas de chasse gardée
• Petites livraisons : déployer souvent, en petits incréments
• Client sur site : un PO accessible en continu, pas un sponsor lointain

Quand XP brille

• Équipes techniques senior, motivées
• Contextes où la qualité du code est critique (santé, finance, embarqué)
• Projets longs où la dette technique pèserait vite

Les concepts clés

• Cycles de 6 semaines + 2 semaines de cooldown pour respirer
• Pas de backlog infini : on shape un projet (le cadrer) avant de l'engager
• Appetite plutôt qu'estimation : on fixe le temps qu'on accepte d'investir, pas l'inverse
• Betting table : décision périodique sur quoi engager pour le cycle suivant
• Hill chart : visualiser la progression (montée = découverte, descente = exécution)

Pertinent pour

• Produit installé, base utilisateur·ices existante
• Équipe senior autonome (devs qui savent shape)
• Peu de stakeholders externes à coordonner

• Scrum : produit en construction, équipe stable, besoin de cadence prévisible
• Kanban : flux imprévisible, support, ops, maintenance, équipe très petite
• XP : équipe technique mature, qualité critique
• Shape Up : produit installé, équipe senior autonome, peu de stakeholders
• No-method / hybride : tendance 2025, prendre ce qui marche pour ton contexte sans religion

Les vraies questions à se poser

• Quelle est la prévisibilité du travail ? (Scrum aime la prédictibilité, Kanban la variabilité)
• Quelle est la taille de l'équipe ? (Scrum demande 5-9 ; Kanban marche dès 1)
• Quelle est la maturité technique ? (XP et Shape Up demandent du senior)
• Quel est le rythme attendu ? (déploiement continu vs releases planifiées)

• Scrum imposé top-down sans buy-in de l'équipe : rituels vides, frustration générale
• Fake agile : on garde le cycle en V mais on renomme les phases « sprints »
• Story-points olympiques : course à la vélocité, on triche, on baisse la qualité pour faire monter le chiffre
• Daily stand-up qui dure 45 min et devient un reporting au manager
• Rétro alibi : on parle, rien ne change, on rejoue les mêmes sujets sprint après sprint
• Product Owner fantôme : pas de vision, le backlog devient une todo-list de demandes random
• Scrum Master mi-chef de projet, mi-coach : double casquette qui crée des conflits d'intérêt
• Refacto interdit : « on n'a pas le temps, on est sous pression ». La dette technique explose

Async-first

• Daily écrit dans un canal Slack au lieu d'un stand-up synchrone
• Vidéo enregistrée pour les démos longues (le live sync force toute l'équipe à se réunir)
• Documentation renforcée : ce qui se disait à la machine à café doit s'écrire
• Decisions logs : trace écrite des décisions, retrouvable

Outils 2025

• Linear : gestion de projet, alternative moderne à Jira
• Notion : doc et wiki, parfois Confluence
• Miro / FigJam : whiteboards collaboratifs (planning, rétro, brainstorm)
• GitHub Projects : si toute l'équipe est sur GitHub
• Slack / Discord : communication async + sync

Fuseaux horaires

Règle de base : overlap de 3 à 4h minimum dans la journée pour les rituels synchrones (rétro, planning). Au-delà, l'équipe est follow-the-sun et fonctionne en async pur.