Chapitre 813 minDébutant
Kanban et choix de la méthode : agile, cycle en V ou hybride
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- construire un tableau Kanban avec des limites de travail en cours ;
- mesurer un flux avec le délai de traitement et le débit ;
- comparer Kanban et Scrum ;
- choisir une méthode, prédictive, agile ou hybride, pour un cas donné.
4 exercices corrigés1 schéma
Kanban est une méthode de gestion du flux de travail : chaque tâche est une carte sur un tableau à colonnes (à faire, en cours, terminé), et l'équipe limite le nombre de tâches en cours pour finir avant de commencer. Contrairement à Scrum, Kanban n'impose ni itérations ni rôles : le travail circule en continu. Ce chapitre explique le tableau Kanban, ses limites et ses mesures, le compare à Scrum, puis donne une grille pour choisir la méthode d'un projet : prédictive, agile ou hybride.
D'où vient Kanban
Le mot japonais kanban désigne une étiquette. Dans les usines Toyota, à partir des années 1950, une carte accompagnait chaque lot de pièces : une nouvelle production n'était lancée que lorsqu'une carte revenait, ce qui empêchait d'accumuler des stocks. La méthode Kanban appliquée au travail intellectuel, et notamment au développement logiciel, s'est diffusée dans les années 2000. Elle garde l'idée centrale : on ne tire un nouveau travail que lorsqu'il y a de la place pour lui.
Le tableau Kanban
Le tableau représente les étapes du travail, de gauche à droite. Chaque carte est un élément de travail (une user story, un ticket, un bug) qui avance de colonne en colonne. Au-dessus de certaines colonnes, un chiffre fixe la limite de travail en cours (en anglais WIP limit, pour work in progress) : le nombre maximal de cartes autorisées dans la colonne.
Pour Prêt'Matos, l'équipe a ajouté une colonne « Prêt » (les éléments précisés et estimés, prêts à commencer) et une colonne « En revue » (le code attend une relecture). Chaque colonne a une règle de sortie écrite : une carte ne passe en « Terminé » que si elle respecte la Definition of Done.
Les pratiques de Kanban
- Visualiser le travail : tout ce que l'équipe fait est sur le tableau, y compris les demandes urgentes et le support. Ce qui n'est pas sur le tableau n'existe pas.
- Limiter le travail en cours : chaque colonne a une limite. Quand elle est atteinte, personne ne commence de nouvelle carte : on aide à terminer celles qui sont en cours.
- Gérer le flux : on observe la vitesse à laquelle les cartes traversent le tableau et on repère où elles s'accumulent.
- Rendre les règles explicites : ce qui fait passer une carte d'une colonne à l'autre est écrit et connu de tous.
- Améliorer en continu : on ajuste les limites et les colonnes à partir des mesures, par petites touches.
Repérer un goulot d'étranglement
Une colonne où les cartes s'accumulent signale un goulot d'étranglement. Si la colonne « En revue » contient six cartes alors que « En cours » se vide, le problème n'est pas le développement mais la relecture : peut-être une seule personne relit-elle tout le code. La limite de travail en cours rend le goulot visible très tôt, puisque la colonne pleine bloque les étapes précédentes et oblige l'équipe à s'en occuper.
Mesurer le flux
Kanban ne mesure pas une vélocité par sprint, puisqu'il n'y a pas de sprint. Il suit le temps que met le travail à traverser le tableau.
| Mesure | Définition | Exemple |
|---|---|---|
| Délai de livraison (lead time) | Du moment où la demande arrive sur le tableau à celui où elle est livrée | Une demande d'évolution créée le 3, livrée le 12 : 9 jours |
| Temps de cycle (cycle time) | Du moment où le travail commence vraiment à celui où il est terminé | Commencée le 9, terminée le 12 : 3 jours |
| Débit (throughput) | Le nombre de cartes terminées par période | 6 cartes par semaine |
| Travail en cours | Le nombre de cartes commencées et non terminées | 5 cartes entre « En cours » et « En revue » |
Ces mesures sont liées par une relation simple, la loi de Little : en moyenne, sur un flux stable, temps de traversée = travail en cours ÷ débit. Une équipe qui a en moyenne 6 cartes en cours et en termine 3 par jour met en moyenne 6 ÷ 3 = 2 jours à traverser le tableau. Pour livrer plus vite sans travailler plus, il suffit de réduire le travail en cours : c'est exactement ce que fait la limite.
Le diagramme de flux cumulé trace, jour après jour, le nombre de cartes dans chaque colonne, empilées. Une bande qui s'élargit montre une colonne qui accumule du travail, autrement dit un goulot.
Kanban pour le support informatique
Kanban convient particulièrement aux équipes dont le travail arrive en continu et sans prévenir : un centre de services qui traite des tickets, une équipe d'exploitation, une équipe de maintenance applicative. Impossible de figer deux semaines de travail quand un serveur tombe le mardi. Les colonnes suivent alors le cycle de vie d'un ticket (nouveau, en cours, en attente, résolu, clos), avec une ligne prioritaire pour les incidents urgents. Le cours ITIL et support décrit ce cycle de vie, et GLPI propose justement une vue Kanban pour ses projets (outils).
Kanban ou Scrum
| Scrum | Kanban | |
|---|---|---|
| Rythme | Sprints de durée fixe, un mois au plus | Flux continu, sans itération imposée |
| Rôles | Product Owner, Scrum Master, Developers | Aucun rôle imposé |
| Engagement | Un Objectif de Sprint et un Sprint Backlog | Des limites de travail en cours par colonne |
| Changement en cours de route | On ne remet pas en cause l'Objectif de Sprint ; on change le Product Backlog pour la suite | Possible à tout moment : une nouvelle carte entre dès qu'il y a de la place |
| Livraison | Au moins un incrément par sprint | À tout moment, carte par carte |
| Mesures typiques | Vélocité, burndown du sprint | Délai de livraison, temps de cycle, débit, flux cumulé |
| Convient à | Développer un produit avec des objectifs successifs | Un flux de demandes : support, maintenance, exploitation |
Les deux se combinent. Beaucoup d'équipes Scrum affichent leur Sprint Backlog sous forme de tableau Kanban, avec des limites de travail en cours. D'autres gardent les événements de Scrum mais remplacent l'engagement de sprint par un flux continu : on parle parfois de Scrumban.
Choisir une méthode pour un projet
Aucune méthode n'est meilleure dans l'absolu. Le choix dépend du projet, et il se justifie : c'est une question classique de l'oral E5. Passe le projet dans cette grille.
| Critère | Plutôt prédictif (cycle en V) | Plutôt Scrum | Plutôt Kanban |
|---|---|---|---|
| Le besoin | Connu, stable, écrit dès le départ | Flou ou évolutif, il se précise en voyant le produit | Un flux de demandes indépendantes |
| Le client | Disponible surtout au début et à la fin | Disponible régulièrement, au moins à chaque fin de sprint | Il envoie des demandes au fil de l'eau |
| Livrer par morceaux | Impossible ou sans intérêt (un poste à moitié installé) | Possible : chaque incrément est utilisable | Chaque demande est livrée seule |
| Contraintes externes | Contrat au forfait, réglementation, certification, date imposée | Contrat qui accepte un périmètre ajustable | Engagements de service (délais de traitement) |
| Dépendances entre tâches | Fortes, à ordonnancer finement | Modérées, gérées dans le backlog | Faibles |
| Équipe | Nombreuse, multi-prestataires possible | Petite, stable, pluridisciplinaire | Équipe de service, souvent interrompue |
Appliquée aux deux fils rouges, la grille confirme les choix de Sorbier Logistique. Le renouvellement du parc a un besoin stable, des tâches très dépendantes, une date imposée et aucun intérêt à livrer « un morceau » : approche prédictive. Prêt'Matos a un besoin qui se précisera en voyant l'application, une Product Owner disponible dans les murs et des fonctionnalités livrables une à une : Scrum. Et une fois l'application en service, sa maintenance (corrections, petites évolutions) passera sur un tableau Kanban partagé avec le support.
Les autres noms à connaître
| Nom | En une ligne |
|---|---|
| XP (Extreme Programming) | Méthode agile centrée sur les pratiques de développement : tests écrits d'abord, programmation en binôme, intégration continue, petites livraisons |
| Lean | La philosophie venue de l'industrie dont descend Kanban : éliminer le gaspillage, livrer en flux, améliorer en continu |
| SAFe, LeSS | Cadres pour faire travailler plusieurs équipes agiles sur un même produit |
| PMBOK | Le guide de référence du PMI (Project Management Institute), qui décrit les domaines de la gestion de projet, prédictive comme agile |
| PRINCE2 | Une méthode structurée de gestion de projet, d'origine britannique, très utilisée dans les administrations |
| DevOps | Une culture qui rapproche développement et exploitation pour livrer souvent et de façon fiable (intégration et déploiement continus) |
Exercices
Exercice 1 sur 4 Lire un tableau Kanban Réussi À revoir
Le tableau d'une équipe de maintenance affiche, un lundi matin : « À faire » 9 cartes, « En cours » 3 cartes (limite 3), « En test » 7 cartes (limite 4), « Terminé » 2 cartes cette semaine.
- Quelle règle n'est pas respectée ?
- Où est le goulot d'étranglement, et que doit faire un développeur qui vient de finir sa carte ?
Voir la réponseMasquer la réponse de l'exercice 1
- La limite de la colonne « En test » est de 4, et elle contient 7 cartes : la limite de travail en cours est dépassée.
- Le goulot est le test. Le développeur ne doit pas commencer une nouvelle carte (« En cours » est d'ailleurs plein) : il aide à tester les cartes en attente, ou à lever ce qui bloque les tests (un environnement de test indisponible, un testeur seul). L'équipe devra ensuite comprendre pourquoi les tests s'accumulent.
Tu avais trouvé ?
Exercice 2 sur 4 La loi de Little Réussi À revoir
- Une équipe a en moyenne 6 cartes en cours et en termine 3 par jour. Combien de temps une carte met-elle en moyenne à traverser le tableau ?
- Un centre de services a en permanence 12 tickets ouverts et en résout 4 par semaine. Quel est le délai moyen de résolution ?
- Il veut ramener ce délai à 2 semaines sans résoudre plus de tickets par semaine. Combien de tickets en cours doit-il viser ? Est-ce réaliste ?
Voir la réponseMasquer la réponse de l'exercice 2
- 6 ÷ 3 = 2 jours.
- 12 ÷ 4 = 3 semaines.
- Travail en cours = délai × débit = 2 × 4 = 8 tickets. C'est possible si le stock ancien est résorbé et si l'on finit les tickets commencés avant d'en ouvrir d'autres, mais les tickets arrivent sans qu'on les choisisse : à terme, il faudra aussi agir sur le débit (base de connaissances, automatisation) ou sur les demandes entrantes.
Tu avais trouvé ?
Exercice 3 sur 4 Choisir une méthode Réussi À revoir
Pour chaque projet, propose une méthode (prédictive, Scrum, Kanban ou hybride) et justifie avec deux critères de la grille.
- Une start-up développe une application de covoiturage pour salariés ; elle veut tester vite son idée auprès de trois entreprises pilotes.
- Une commune doit migrer le câblage et les commutateurs de sa mairie pendant les deux semaines de fermeture estivale.
- Une équipe de deux personnes maintient l'intranet d'une entreprise : petites évolutions et corrections signalées par les utilisateurs.
- Un éditeur répond à un appel d'offres public au forfait pour un logiciel de gestion des cantines, avec un cahier des charges détaillé, mais le client accepte des démonstrations régulières.
Voir la réponseMasquer la réponse de l'exercice 3
- Scrum : le besoin est incertain et doit être confronté à de vrais utilisateurs ; chaque incrément peut être testé par les entreprises pilotes.
- Prédictive : la date est imposée (la fermeture estivale) et les tâches sont très dépendantes (on ne coupe pas l'ancien réseau avant que le nouveau soit testé) ; il faut tout planifier et répéter avant.
- Kanban : le travail arrive en flux continu et sans prévenir ; les demandes sont indépendantes et petites.
- Hybride : le contrat au forfait et le cahier des charges imposent un cadre prédictif (périmètre, prix, jalons) ; les démonstrations régulières permettent de réaliser par itérations et de corriger tôt les incompréhensions.
Tu avais trouvé ?
Exercice 4 sur 4 Scrum ou Kanban pour le support ? Réussi À revoir
Le responsable du support d'une PME veut « passer en Scrum » avec des sprints de deux semaines pour ses trois techniciens, qui traitent surtout des incidents. Donne-lui ton avis en trois arguments.
Voir la réponseMasquer la réponse de l'exercice 4
Kanban conviendrait mieux :
- Les incidents arrivent sans prévenir et doivent souvent être traités tout de suite : un Objectif de Sprint fixé pour deux semaines serait remis en cause sans arrêt.
- Les demandes sont petites et indépendantes : il n'y a pas d'incrément de produit à construire et à montrer à chaque fin de sprint.
- Les mesures utiles au support sont le délai de traitement et le stock de tickets, que suit naturellement Kanban, plutôt que la vélocité.
Il peut garder deux idées de Scrum : un court point quotidien devant le tableau, et une rétrospective régulière pour améliorer le fonctionnement de l'équipe.
Tu avais trouvé ?