Scrum et Kanban comparés : sprints à durée fixe ou flux continu, rôles, limites de WIP, métriques, et la place du tableau par itérations d'East Agile Tracker entre les deux.
Scrum et Kanban sont les deux méthodes agiles que les équipes comparent le plus souvent. Toutes deux rendent le travail visible et toutes deux visent à livrer par petits morceaux. Elles diffèrent par la façon de rythmer le travail : Scrum planifie par périodes de durée fixe, Kanban tire le travail en continu et limite la quantité de travail en cours à un instant donné.
Cette page compare les deux. Pour la famille plus large, XP et Lean compris, voir Qu’est-ce que le développement agile ?.
Scrum en bref
Section intitulée « Scrum en bref »Scrum organise le travail en sprints — des périodes de durée fixe, généralement d’une à quatre semaines. Chaque sprint commence par une planification de sprint (sprint planning), où l’équipe choisit le travail qu’elle pense terminer, et se conclut par une revue de ce qui a été construit et une rétrospective sur la façon dont l’équipe a travaillé.
Scrum définit trois rôles :
- Product Owner — responsable du product backlog et de son ordre.
- Scrum Master — accompagne l’équipe sur le processus et lève les obstacles.
- Développeurs — construisent l’incrément.
La mesure principale est la vélocité : la quantité de travail que l’équipe termine par sprint, qui alimente le plan du sprint suivant. Voir Qu’est-ce que la vélocité ?.
Kanban en bref
Section intitulée « Kanban en bref »Kanban part du flux de travail que l’équipe a déjà. Les éléments de travail traversent un tableau dont les colonnes représentent des étapes (par exemple À faire → En cours → Relecture → Terminé). Trois idées portent la méthode :
- Visualiser le flux — chaque élément et chaque étape figurent sur le tableau.
- Limiter le travail en cours (WIP) — chaque colonne a un plafond ; un nouvel élément n’entre que lorsqu’un autre sort.
- Gérer le flux — l’équipe mesure le temps que prennent les éléments (temps de cycle, délai de traversée) et supprime les goulets d’étranglement.
Kanban n’a pas de périodes fixes et n’impose aucun rôle. La planification a lieu chaque fois que la file d’attente doit être réapprovisionnée.
Côte à côte
Section intitulée « Côte à côte »| Scrum | Kanban | |
|---|---|---|
| Rythme | Sprints fixes (1 à 4 semaines) | Flux continu |
| Engagement | Le travail planifié pour le sprint | Pas d’engagement par lot ; on tire quand il y a de la capacité |
| Rôles | Product Owner, Scrum Master, Développeurs | Aucun imposé |
| Changement en cours de cycle | Déconseillé pendant un sprint | Possible à tout moment |
| Limitation du travail | La capacité du sprint | Limite de WIP par colonne |
| Métriques principales | Vélocité, burndown | Temps de cycle, délai de traversée, débit |
| Tableau | Remis à zéro à chaque sprint | Permanent |
Choisir entre les deux
Section intitulée « Choisir entre les deux »Aucune des deux méthodes n’est meilleure dans l’absolu. Scrum convient aux équipes qui veulent un rythme de planification régulier et une prévision fondée sur les sprints passés, comme les équipes produit qui livrent des fonctionnalités selon un calendrier. Kanban convient au travail qui arrive de façon imprévisible et doit être traité au fil de l’eau, comme le support, l’exploitation ou la maintenance.
Beaucoup d’équipes mélangent les deux (« Scrumban ») : elles conservent un rythme de planification tout en surveillant la quantité de travail en cours.
La place d’East Agile Tracker
Section intitulée « La place d’East Agile Tracker »East Agile Tracker est fondé sur les itérations, ce qui le rapproche davantage de Scrum et de l’eXtreme Programming que de Kanban. Il emploie ses propres termes pour certaines des notions ci-dessus :
- Les sprints s’appellent des itérations. Chaque projet fixe une durée d’itération de 1 à 4 semaines. Les itérations sont créées automatiquement ; il n’y a pas de sprint à ouvrir ni à fermer. Voir Itérations.
- Le backlog est une liste ordonnée unique. Le product owner la maintient dans un ordre de priorité strict, et le Backlog projette les itérations à venir à partir de la vélocité. Voir User stories et planification d’itération.
- La vélocité dimensionne le plan. Avec auto-plan iterations activé, l’itération courante se remplit jusqu’à votre vélocité, et pas au-delà. Voir Planifier une itération.
- Chaque story porte son propre état. Une story passe par Unstarted → Started → Finished → Delivered → Accepted, affiché sur la carte, plutôt que par des colonnes du tableau. Voir la machine à états.
Il n’y a pas de limites de WIP ni de mode de flux sans itérations. Les idées de Kanban qui se retrouvent ici sont la visibilité (chaque story et son état figurent sur un seul tableau) et les métriques de flux : la page Métriques montre la tendance de la vélocité, le burndown et les stories reportées d’une itération à l’autre.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Qu’est-ce que le développement agile ? — le manifeste et la famille des méthodes.
- Qu’est-ce que la vélocité ? — comment la vélocité est calculée et utilisée.
- Que sont les story points ? — l’estimation relative.