Méthodes agiles (Scrum, Kanban)

Principe

Une méthode agile découpe un projet en cycles courts (2 à 4 semaines, les sprints) qui livrent chacun quelque chose d'utilisable. Dans Scrum, le responsable du produit (product owner) priorise la liste des besoins (backlog), l'équipe s'engage sur une partie à chaque sprint, un point quotidien de 15 minutes fait le point des blocages, une démonstration montre le résultat et une rétrospective améliore la façon de travailler. Le Kanban, plus simple, affiche les tâches en colonnes (à faire, en cours, fait) et limite le travail en cours. L'agile convient quand le besoin évolue (tableaux de bord, outils, organisation) ; un projet très contraint (déménagement d'entrepôt) reste mieux géré avec un planning classique.

Comprendre pas à pas

1. La situation

Le service achats veut un tableau de bord Power BI. La première tentative a suivi un cahier des charges de 20 pages : 4 mois de travail, et un outil livré que personne n'utilisait, car les besoins avaient changé entre-temps. Question : comment faire autrement ?

2. Les deux approches comparées

Critère	Cycle en V (tout spécifier, puis livrer)	Agile (livrer par petites étapes)
Première livraison utile	au bout de 4 mois	au bout de 2 semaines
Changement de besoin	coûteux, avenant	intégré au cycle suivant
Implication de l'utilisateur	au début et à la fin	à chaque cycle
Adapté à	projet stable, contraint (déménagement, réglementaire)	besoin qui évolue (outils, données, organisation)

3. L'idée

Une méthode agile découpe le travail en cycles courts (2 à 4 semaines) qui livrent chacun quelque chose d'utilisable. Dans Scrum : un responsable du produit priorise la liste des besoins, un point quotidien de 15 minutes lève les blocages, une démonstration montre le résultat aux utilisateurs, une rétrospective améliore la façon de travailler. Le Kanban affiche les tâches en colonnes et limite le travail en cours.

Backlog

La liste des besoins, classée par valeur : « en tant qu'acheteur, je veux… pour… ».

Sprint

Un cycle de 2 à 4 semaines qui livre un résultat utilisable.

Démonstration

On montre, les utilisateurs réagissent, on repriorise.

Rétrospective

Ce qu'on garde, ce qu'on arrête, ce qu'on essaie.

4. Le tableau de bord, en agile

Backlog. 8 besoins classés avec les acheteurs : taux de service fournisseurs en premier, puis retards, litiges, économies.

Sprint 1 (2 semaines). Page « taux de service fournisseurs » livrée et utilisée dès la réunion hebdomadaire.

Sprints 2 à 4. Une page tous les 15 jours ; le besoin « économies » est repoussé, le besoin « litiges ouverts » remonte après la démonstration.

Bilan. 6 pages utiles en 2 mois au lieu d'un outil abandonné après 4 mois.

5. À vous de jouer : votre projet est-il fait pour l'agile ?

6. Ce qu'il faut retenir

• Cycles courts, résultat utilisable à chaque cycle.
• Un utilisateur qui priorise, des démonstrations régulières.
• Agile pour un besoin qui évolue, planning classique pour un projet figé.

Mise en œuvre

Acteurs

Responsable du produit, équipe projet, utilisateurs

Durée

Cycles de 2 à 4 semaines

Livrables

Liste priorisée des besoins, livraisons à chaque cycle, rétrospectives

1. Constituer l'équipeUn responsable du produit disponible, qui priorise ; une équipe de 3 à 9 personnes ; un facilitateur.
2. Construire le backlogLister les besoins sous forme d'histoires courtes (« en tant qu'acheteur, je veux… pour… ») et les classer par valeur.
3. Planifier le cycleChoisir ce qui sera livré à la fin du cycle, découper en tâches.
4. Avancer au quotidienPoint de 15 minutes : ce que j'ai fait, ce que je vais faire, ce qui me bloque ; tableau Kanban visible.
5. Montrer et améliorerDémonstration aux utilisateurs, puis rétrospective : garder, arrêter, essayer.

Exemple d'application

Points de vigilance

• Faire de l'agile sans utilisateur disponible
• Appeler agile un projet sans plan ni priorités