REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Paix-travail-patrie Peace-work-fatherland
******* *******
MINISTERE DE L’ENSEIGNEMENT MINISTERY OF HIGHER EDUCATION
SUPERIEURE ********
******* THE UNIVERSITY OF MAROUA
UNIVERSITE DE MAROUA *******
******* FACULTY OF SCIENCES
FACULTE SCIENCES *******
******** DEPARTMENT OF MATHMATICS -
DEPARTEMENT DE COMPUTER SCIENCE
MATHEMATIQUES-INFORMATIQUE ********
*******

INTITULE DE L’UNITE : Génie logiciel

CODE DE L’UE : DSI 533

THEME : Méthodologie Agile avancée (Scrum & kanban)

Réalisé par :
LAKIBA MOUNONE SOIUHAITE
Matricule : 19A0077FS

Chargé du cours :
Pr Hayatou Oumarou

Année académique 2024-2025

Table des matières
INTRODUCTION 1
Historique et Définition de l’Agilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

I SCRUM 1
I.1 Rôles dans Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
I.1.1 Le propriétaire du produit Scrum . . . . . . . . . . . . . . . . . . . . . . 2
I.1.2 Le scrum master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
I.1.3 L’équipe de développement Scrum . . . . . . . . . . . . . . . . . . . . . . 2
I.2 Événements Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I.2.1 Organiser le backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I.2.2 Planification du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I.2.3 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I.2.4 Daily scrum ou Stand-up . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.2.5 Revue de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.2.6 Rétrospective de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.3 Artefacts du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.3.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I.3.2 Backlog sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I.3.3 L’incrément (ou l’Objectif du sprint . . . . . . . . . . . . . . . . . . . . . 5

II KANBAN 6
II.1 Principes de Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
II.1.1 Flux de kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
II.1.2 Tableau kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
II.1.3 Carte Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
II.2 Avantages du cadre kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
II.3 Solutions existantes dans les domaines de Scrum et Kanban . . . . . . . . . . . 12

III Scrum vs Kanban 13

CONCLUSION 15

Réference bibliographique
INTRODUCTION
Historique et Définition de l’Agilité
En 2001, dans les montagnes de Snowbirds, dans l’Utah, 17 personnes se sont réunies pour
discuter du futur du développement logiciel. Elles étaient frustrées par le fait que les entreprises
se concentraient trop sur la planification et la documentation excessives, au point d’oublier ce
qui comptait vraiment : satisfaire les clients.
Même si elles n’étaient pas toutes d’accord sur la solution, elles savaient qu’un changement était
nécessaire. Les valeurs comme « l’excellence » et « l’intégrité » mises en avant par les entreprises
n’aidaient pas vraiment les développeurs à améliorer leurs méthodes.
Ce week-end prolongé a permis à ces professionnels, surnommés les « Snowbirds », de peaufiner
leurs idées pour une nouvelle approche du développement logiciel. De cette rencontre est né le
Manifeste Agile, un document concis de 68 mots qui a transformé pour toujours le monde du
logiciel. Ils se sont mis d’accord sur un ensemble de valeurs définissant une culture. Les voici :
Nous découvrons de meilleures façons de développer des logiciels en le faisant et en
aidant les autres à le faire.
Grâce à ce travail, nous avons appris à valoriser :
Individus et interactions plutôt que processus et outils
Logiciel fonctionnel sur documentation complète
Collaboration client plutôt que négociation de contrat
Réagir au changement plutôt que de suivre un plan
Autrement dit, même si les objets de droite ont de la valeur, nous accordons davan-
tage de valeur à ceux de gauche.
Ainsi la méthodologie Agile est définie comme une approche de gestion de projet qui consiste à
diviser le projet en phases et met l’accent sur la collaboration et l’amélioration continues. Les
équipes suivent un cycle de planification, d’exécution et d’évaluation .
Alors que l’approche traditionnelle en cascade consiste à ce qu’une discipline contribue au pro-
jet, puis à le « balancer par-dessus le mur » au contributeur suivant, l’approche agile fait appel
à des équipes inter-fonctionnelles collaboratives. La communication ouverte, la collaboration,
l’adaptation et la confiance entre les membres de l’équipe sont au cœur de l’approche agile.
Bien que le chef de projet ou le propriétaire du produit hiérarchise généralement le travail à
réaliser, l’équipe prend l’initiative de décider de la manière dont le travail sera effectué, en
s’auto-organisant autour de tâches et d’affectations granulaires. Agile ne se définit pas par un
ensemble de cérémonies ou de techniques de développement spécifiques. Agile est plutôt un
ensemble de méthodologies qui démontrent un engagement envers des cycles de rétroaction
serrés et une amélioration continue. Depuis la publication du manifeste de nombreux cadres
agiles ont vu le jour, tels que Scrum, Kanban etc. Chacun incarne à sa manière les principes
fondamentaux d’itération fréquente, d’apprentissage continu et de haute qualité.

I SCRUM
Scrum est un cadre de gestion de projet qui aide les équipes à structurer et à gérer leur
travail à travers un ensemble de valeurs, de principes et de pratiques. Tout comme une équipe
de Football s’entraînant pour le grand match, Scrum encourage les équipes à apprendre par
l’expérience, à s’auto-organiser tout en travaillant sur un problème et à réfléchir à leurs victoires

1
et à leurs défaites pour s’améliorer en permanence. Il est un cadre le plus souvent utilisé par
les équipes de développement logiciel mais ses principes et ses leçons peuvent être appliqués à
tous les types de travail en équipe de par les valeurs qu’il prône. C’est l’une des raisons pour
lesquelles le Scrum est si populaire. Il décrit un ensemble de réunions, d’outils et de rôles qui
fonctionnent pour aider les équipes à structurer et à gérer leur travail.
Le cadre Scrum décrit un ensemble de valeurs, de principes et de pratiques que les équipes
Scrum suivent pour fournir un produit ou un service. Il détaille les membres d’une équipe
Scrum et leurs responsabilités, les « artefacts » qui définissent le produit et le travail pour créer
le produit, ainsi que les cérémonies Scrum qui guident l’équipe Scrum dans son travail.

I.1 Rôles dans Scrum

Une équipe Scrum a besoin de trois rôles spécifiques : le propriétaire du produit, le maître
Scrum et l’équipe de développement. Et comme les équipes Scrum sont inter-fonctionnelles,
l’équipe de développement comprend des testeurs, des concepteurs, des spécialistes UX et des
ingénieurs opérationnels en plus des développeurs.

I.1.1 Le propriétaire du produit Scrum

Les propriétaires de produits sont les champions de leur produit. Ils s’attachent à comprendre
les exigences de l’entreprise, des clients et du marché, puis à hiérarchiser en conséquence le
travail à effectuer par l’équipe d’ingénierie. Les propriétaires de produits efficaces :
— Construire et gérer le backlog produit ;
— Travaillez en étroite collaboration avec l’entreprise et l’équipe pour vous assurer que tout
le monde comprend les éléments de travail du backlog produit ;
— Donnez à l’équipe des indications claires sur les fonctionnalités à fournir ensuite ;
— Décidez quand expédier le produit avec une prédisposition à une livraison plus fréquente.
Le propriétaire du produit n’est pas toujours le chef de produit. Les propriétaires de produits
s’assurent que l’équipe de développement apporte la plus grande valeur ajoutée à l’entreprise.
Il est également important que le propriétaire du produit soit une personne à part entière.
Aucune équipe de développement ne souhaite recevoir des conseils contradictoires de la part de
plusieurs propriétaires de produits.

I.1.2 Le scrum master

Les Scrum Masters sont les champions de Scrum au sein de leurs équipes. Ils coachent les
équipes, les Product Owners et l’entreprise sur le processus Scrum et cherchent des moyens
d’affiner leur pratique de ce processus. Un Scrum Master efficace comprend parfaitement le
travail effectué par l’équipe et peut aider celle-ci à optimiser sa transparence et son flux de
livraison. En tant que facilitateur en chef, il/elle planifie les ressources nécessaires (à la fois
humaines et logistiques) pour la planification du sprint, la réunion debout, la revue du sprint
et la rétrospective du sprint.

I.1.3 L’équipe de développement Scrum

Les équipes Scrum sont efficaces. Elles sont les championnes des pratiques de développe-
ment durable. Les équipes Scrum les plus efficaces sont soudées, Co-localisées et généralement
composées de cinq à sept membres. Une façon de déterminer la taille de l’équipe est d’utiliser

2
la célèbre « règle des deux pizzas » inventée par Jeff Bezos, le PDG d’Amazon (l’équipe doit
être suffisamment petite pour partager deux pizzas). Les membres de l’équipe ont des compé-
tences différentes et se forment mutuellement afin qu’aucun d’entre eux ne devienne un goulot
d’étranglement dans la réalisation du travail. Les équipes Scrum efficaces sont auto-organisées
et abordent leurs projets avec une attitude claire de « nous ». Tous les membres de l’équipe
s’entraident pour assurer la réussite du sprint. L’équipe Scrum pilote le plan de chaque sprint.
Elle prévoit la quantité de travail qu’elle pense pouvoir accomplir au cours de l’itération en
se basant sur sa vélocité historique. Le fait de conserver une longueur d’itération fixe donne à
l’équipe de développement un retour d’information important sur son processus d’estimation
et de livraison, ce qui rend ses prévisions de plus en plus précises au fil du temps.

I.2 Événements Scrum

Le cadre Scrum comprend des pratiques Scrum, des cérémonies et des réunions que les
équipes Scrum effectuent régulièrement. Les cérémonies agiles sont celles où nous voyons le
plus de variations au sein des équipes. Par exemple, certaines équipes trouvent que toutes ces
cérémonies sont fastidieuses et répétitives, tandis que d’autres les utilisent comme un contrôle
nécessaire. ci-dessous une liste de toutes les cérémonies clés auxquelles une équipe Scrum peut
participer :

I.2.1 Organiser le backlog

Parfois appelé « backlog grooming », cet événement est la responsabilité du propriétaire
du produit. Les principales tâches du propriétaire du produit sont de conduire le produit vers
sa vision du produit et de garder un œil constant sur le marché et le client. Par conséquent,
il/elle maintient cette liste en utilisant les commentaires des utilisateurs et de l’équipe de
développement pour aider à prioriser et à garder la liste propre et prête à être traitée à tout
moment.

I.2.2 Planification du sprint

Le travail à réaliser (scope) pendant le sprint en cours est planifié lors de cette réunion
par toute l’équipe de développement. Cette réunion est dirigée par le scrum master et c’est au
cours de laquelle l’équipe décide de l’objectif du sprint. Des user stories spécifiques sont ensuite
ajoutées au sprint à partir du backlog produit. Ces stories s’alignent toujours sur l’objectif et
sont également acceptées par l’équipe scrum pour être réalisables à mettre en œuvre pendant
le sprint. À la fin de la réunion de planification, chaque membre de Scrum doit être clair sur ce
qui peut être livré dans le sprint et comment l’incrément peut être livré.

I.2.3 Sprint
Un sprint est la période de temps pendant laquelle l’équipe Scrum travaille ensemble pour
terminer un incrément. Deux semaines constituent une durée assez courante pour un sprint,
bien que certaines équipes trouvent qu’une semaine est plus facile à définir ou qu’un mois est
plus facile à livrer un incrément précieux. Dave West, de Scrum.org, conseille que plus le travail
est complexe et qu’il y a d’inconnues, plus le sprint doit être court. Mais c’est vraiment à votre
équipe de décider, et vous ne devez pas avoir peur de le modifier s’il ne fonctionne pas ! Pendant
cette période, le périmètre peut être renégocié entre le propriétaire du produit et l’équipe de
développement si nécessaire. C’est là le cœur de la nature empirique de Scrum.

3
Tous les événements, de la planification à la rétrospective, se déroulent pendant le sprint. Une
fois qu’un certain intervalle de temps pour un sprint est établi, il doit rester cohérent tout au
long de la période de développement. Cela aide l’équipe à tirer les leçons des expériences passées
et à appliquer ces connaissances aux sprints futurs.

I.2.4 Daily scrum ou Stand-up

il s’agit d’une réunion quotidienne très courte qui se déroule à la même heure (généralement
le matin) et qui permet de simplifier les choses. De nombreuses équipes essaient de terminer la
réunion en 15 minutes, mais ce n’est qu’une ligne directrice. Cette réunion est également appelée
« daily stand-up », ce qui souligne qu’elle doit être rapide. L’objectif de la mêlée quotidienne
est que tous les membres de l’équipe soient sur la même longueur d’onde, alignés sur l’objectif
du sprint et établissent un plan pour les 24 heures suivantes.
Le stand up est le moment d’exprimer toutes vos inquiétudes concernant l’atteinte de l’objectif
du sprint ou les éventuels blocages. Une façon courante de mener un stand up consiste à
demander à chaque membre de l’équipe de répondre à trois questions dans le contexte de la
réalisation de l’objectif du sprint :
— Qu’ai-je fait hier ?
— Qu’ai-je prévu de faire aujourd’hui ?
— Y a-t-il des obstacles ?

I.2.5 Revue de sprint

A la fin du sprint, l’équipe se réunit pour une session informelle afin de visualiser une
démonstration ou d’inspecter l’incrément. L’équipe de développement présente les éléments du
backlog qui sont désormais « terminés » aux parties prenantes et aux coéquipiers pour obtenir
des commentaires. Le propriétaire du produit peut décider de publier ou non l’incrément, bien
que dans la plupart des cas, l’incrément soit publié.
Cette réunion de revue est également l’occasion pour le responsable produit de retravailler le
backlog produit en fonction du sprint en cours, ce qui peut alimenter la prochaine session de
planification du sprint. Pour un sprint d’un mois, envisagez de limiter votre revue de sprint à
un maximum de quatre heures.

I.2.6 Rétrospective de sprint

La rétrospective est le moment où l’équipe se réunit pour documenter et discuter de ce
qui a fonctionné et de ce qui n’a pas fonctionné dans un sprint, un projet, des personnes ou
des relations, des outils, ou même pour certaines cérémonies. L’idée est de créer un endroit
où l’équipe peut se concentrer sur ce qui s’est bien passé et ce qui doit être amélioré pour la
prochaine fois, et moins sur ce qui s’est mal passé.

I.3 Artefacts du sprint

Les artefacts scrum sont des informations importantes utilisées par l’équipe Scrum qui aident
à définir le produit et le travail à effectuer pour créer le produit. Il existe trois artefacts dans
Scrum : le backlog produit, un backlog sprint et un incrément avec votre définition de « terminé
». Ce sont les trois constantes sur lesquelles une équipe Scrum doit réfléchir pendant les sprints
et au fil du temps.

4
I.3.1 Backlog produit
Le backlog produit est la liste principale des tâches qui doivent être effectuées et mainte-
nues par le propriétaire ou le chef de produit. Il s’agit d’une liste dynamique de fonctionnalités,
d’exigences, d’améliorations et de correctifs qui sert de base au backlog du sprint. Il s’agit es-
sentiellement de la liste des tâches à accomplir de l’équipe. Le backlog produit est constamment
revisité, reclassé par ordre de priorité et maintenu par le propriétaire du produit car, à mesure
que nous en apprenons davantage ou que le marché évolue, certains éléments peuvent ne plus
être pertinents ou les problèmes peuvent être résolus d’une autre manière.

I.3.2 Backlog sprint

Le backlog sprint est la liste des éléments, user stories ou correctifs de bugs sélectionnés
par l’équipe de développement pour être implémentés dans le cycle de sprint actuel. Avant
chaque sprint, lors de la réunion de planification de sprint (dont nous parlerons plus loin dans
l’article), l’équipe choisit les éléments sur lesquels elle travaillera pour le sprint à partir du
backlog produit. Un backlog de sprint peut être flexible et peut évoluer au cours d’un sprint.
Cependant, l’objectif fondamental du sprint (ce que l’équipe souhaite réaliser à partir du sprint
actuel) ne peut pas être compromis.

I.3.3 L’incrément (ou l’Objectif du sprint

L’incrément est le produit final utilisable d’un sprint.Généralement les développeurs dé-
montrent l’« incrément » lors de la démonstration de fin de sprint, où l’équipe montre ce qui
a été réalisé au cours du sprint. Ils se pourrait qu’on entendent pas le mot « incrément » dans
le monde, car il est souvent désigné comme la définition de « terminé » par l’équipe, un jalon,
l’objectif de sprint, voire une version complète ou une épopée livrée . Cela dépend simplement
de la façon dont les équipes définissent « terminé » et de la façon dont ils définissent les objectifs
de sprint. Par exemple, certaines équipes choisissent de publier quelque chose pour leurs clients
à la fin de chaque sprint. Leur définition de « terminé » serait donc « livré ». Cependant, cela
peut ne pas être réaliste pour d’autres types d’équipes. Supposons qu’une équipe travaille sur
un produit basé sur un serveur qui ne peut être livré à leur clients que tous les trimestres.
Ils peuvent toujours choisir de travailler par sprints de 2 semaines, mais leur définition de «
terminé » peut être la finition d’une partie d’une version plus grande qu’ils prévoient de livrer
ensemble. Mais bien sûr, plus il faut de temps pour publier un logiciel, plus le risque qu’il ne
soit pas à la hauteur est élevé. Ils existent de nombreuses variantes, même au sein des artefacts,
que les équipes peuvent choisir de définir. C’est pourquoi il est important de rester ouvert à
l’évolution de la façon de maintenir les artefacts.

5
 Figure 1 – schéma de la structure du cadre Scrum. Source :topdev.vn

II KANBAN
La méthode Kanban a été inventée par l’ingénieur Taiichi Ōno dans les années 1960 dans
les usines Toyota.On l’appelle la méthode Kanban parce que “Kanban” en japonais signifie “éti-
quette” et fait écho aux étiquettes utilisées par les ouvriers dans les chaînes d’assemblage.
À chaque fois qu’un bac transite d’un poste à un autre, une étiquette lui est accolée ce qui
permet aux ouvriers de savoir quelles sont les tâches à réaliser, quand les réaliser et quelles sont
celles qui ont été déjà réalisées. Cette méthode Agile permet non seulement de travailler en flux
tendu, mais aussi de gérer efficacement les ordres de production tout en limitant le gaspillage.
La méthode Kanban vient donc à l’origine du secteur automobile, mais elle est aujourd’hui
utilisée dans de nombreux autres secteurs. En particulier dans le secteur de l’IT qui l’utilise
pour le développement de sites web et d’applications.
En effet kanban est un cadre populaire utilisé pour mettre en œuvre le développement logiciel
Agile et DevOps. Il nécessite une communication en temps réel des capacités et une transpa-
rence totale du travail. Les éléments de travail sont représentés visuellement sur un tableau
Kanban, ce qui permet aux membres de l’équipe de voir l’état de chaque élément de travail à
tout moment. Le flux Kanban, pierre angulaire des méthodologies agiles et DevOps, améliore
l’efficacité en orchestrant une progression transparente des tâches grâce à des flux de travail
visualisés.

6
 Figure 2 – Ouvrier dans un entrepôt d’assemblage. Source :Everlaab

Le flux Kanban reflète la gestion rationalisée des stocks des supermarchés, garantissant que
les tâches progressent dans les processus de développement précisément au moment où cela est
nécessaire.
Les tâches représentées sous forme de cartes sur des tableaux Kanban permettent un suivi
transparent de la progression et une identification rapide des goulots d’étranglement. En li-
mitant les travaux en cours, les équipes optimisent l’allocation des ressources et maintiennent
un flux de travail stable. L’accent mis par Kanban sur l’amélioration continue est facilité par
des indicateurs tels que les graphiques de contrôle et les diagrammes de flux cumulatifs, qui
permettent aux équipes d’affiner les flux de travail de manière itérative.

II.1 Principes de Kanban

II.1.1 Flux de kanban
L’établissement d’un flux Kanban structuré au sein d’une équipe de développement logiciel
est essentiel pour mettre en œuvre efficacement le Kanban. Cela garantit une progression fluide
des tâches et une gestion optimisée du flux de travail. Voici comment l’on peut structurer le
flux Kanban :
— Visualiser le flux de travail : Commencer par visualiser le flux de travail de votre équipe
sur un tableau Kanban. Qu’il soit physique ou virtuel, le tableau doit décrire chaque
étape du processus de développement, du début à la fin de la tâche.
— Standardiser le flux de travail : définir et standardiser les étapes du flux de travail en
fonction des processus et des exigences de l’équipe. Les étapes courantes incluent « À
faire », « En cours » et « Terminé », mais il faut les personnaliser selon les besoins pour
refléter le flux du travail unique.
— Identifier les blocages et les dépendances : S’assurer que le tableau Kanban permet une
identification immédiate des blocages et des dépendances. Cette transparence permet

7
 Figure 3 – Tableau Kanban. Source :Everlaab

une résolution rapide et évite les interruptions de flux de travail.

— Définir des limites de travail en cours (WIP) : implémente des limites de travail en cours
pour chaque étape du flux de travail afin d’éviter toute surcharge et de maintenir un
flux de travail stable. Les limites de travail en cours permettent d’optimiser l’allocation
des ressources et de réduire le multitâche, favorisant ainsi une productivité accrue.
— Encourager la collaboration : favoriser une culture de collaboration au sein de l’équipe,
où les membres s’attaquent collectivement aux goulots d’étranglement et travaillent en-
semble pour assurer une progression fluide du flux de travail. Cette approche collabora-
tive favorise l’efficacité et accélère l’achèvement des tâches.
— Utiliser des cartes Kanban : représenter chaque tâche sous forme de carte Kanban sur le
tableau, contenant des détails essentiels tels que la description de la tâche, le responsable
et le temps estimé pour l’achèvement. Les cartes Kanban facilitent le suivi visuel de la
progression des tâches et favorisent la transparence au sein de l’équipe.
En structurant votre flux Kanban de cette manière, vous pouvez rationaliser vos processus
de développement logiciel, améliorer la collaboration en équipe et maximiser l’efficacité de la
gestion des tâches.

II.1.2 Tableau kanban

Le travail de toutes les équipes Kanban s’articule autour d’un tableau Kanban , un outil
utilisé pour visualiser et optimiser le flux de travail entre les équipes. Si les tableaux physiques
sont populaires auprès de certaines équipes, les tableaux virtuels sont essentiels dans tout ou-
til de développement logiciel agile pour leur traçabilité, leur collaboration et leur accessibilité
à partir de plusieurs emplacements. Qu’une équipe utilise un tableau Kanban numérique ou
physique, il permet à l’équipe de visualiser son travail, de standardiser son flux de travail et
d’identifier et de résoudre immédiatement tous les blocages et dépendances. Un tableau Kanban
de base comporte un flux de travail en trois étapes : À faire, En cours et Terminé. Cependant,

8
en fonction de la taille, de la structure et des objectifs d’une équipe, celle-ci peut cartographier
le flux de travail pour répondre à ses processus uniques. Parce que la méthodologie Kanban
repose sur une transparence totale du travail et une communication en temps réel, le tableau
Kanban agit comme la source unique de vérité pour le travail de l’équipe.

Remarque
il existe une multitude de tableaux Kanban possibles qui répondent tous à des besoins
différents.

Figure 4 – Tableau kanban pour le developpement web. Source :Everlaab

II.1.3 Carte Kanban

Les équipes Kanban représentent chaque élément de travail sous forme de carte distincte
sur le tableau. L’objectif principal de la représentation du travail sous forme de carte sur le
tableau Kanban est de permettre aux membres de l’équipe de suivre la progression de leur flux
de travail de manière très visuelle. Les cartes Kanban contiennent des informations essentielles
sur les tâches du projet, offrant aux équipes une visibilité sur les personnes responsables de
quelles tâches, une brève description du travail et la durée estimée des tâches. Les cartes des ta-
bleaux Kanban virtuels comportent souvent des captures d’écran et d’autres détails techniques
utiles au responsable. Permettre aux membres de l’équipe de visualiser l’état de chaque tâche à
tout moment, ainsi que les détails pertinents, favorise une concentration accrue, une traçabilité
complète et une identification rapide des bloqueurs et des dépendances

9
II.2 Avantages du cadre kanban
Kanban est l’une des méthodologies de développement logiciel les plus populaires utilisées
par les équipes agiles aujourd’hui. Kanban offre des avantages supplémentaires en termes de
planification des tâches et de rendement pour les équipes de toutes tailles.
— Flexibilité de planification Une équipe Kanban se concentre uniquement sur le travail en
cours. Une fois que l’équipe a terminé une tâche, elle sélectionne la tâche suivante dans
le backlog. Le propriétaire du produit est libre de redéfinir les priorités du travail dans le
backlog sans perturber l’équipe, car les modifications en dehors des éléments de travail
actuels n’ont pas d’impact sur l’équipe. Tant que le propriétaire du produit garde les
éléments de travail les plus importants en tête du backlog, l’équipe de développement
peut être assurée qu’elle fournit une valeur maximale à l’entreprise.
— Des cycles de temps raccourcis Le temps de cycle est une mesure clé pour les équipes
Kanban. Il correspond au temps nécessaire à une unité de travail pour parcourir le flux de
travail de l’équipe, du moment où le travail commence jusqu’au moment où il est expédié.
En optimisant le temps de cycle, l’équipe peut prévoir en toute confiance la livraison du
travail futur. Les compétences communes permettent de raccourcir les temps de cycle.
Lorsqu’une seule personne possède un ensemble de compétences, cette personne devient
un goulot d’étranglement dans le flux de travail. Par conséquent, les équipes utilisent
les meilleures pratiques telles que la révision du code et le mentorat pour favoriser la
diffusion des connaissances. Le partage des compétences signifie que les membres de
l’équipe peuvent assumer des tâches hétérogènes, optimisant ainsi davantage le temps
de cycle. De plus, cette approche permet à toute l’équipe de s’attaquer collectivement
aux goulots d’étranglement, facilitant une résolution rapide et garantissant un flux de
travail fluide. Par exemple, les responsabilités en matière de tests s’étendent au-delà des
ingénieurs QA pour inclure les développeurs, favorisant ainsi un effort collaboratif pour
maintenir l’efficacité. Dans un système Kanban, toute l’équipe s’assure que le travail se
déroule sans heurts tout au long du processus.
— Moins de goulots d’étranglement Le multitâche nuit à l’efficacité. L’augmentation de la
charge de travail entraîne simultanément des changements de contexte plus fréquents, ce
qui entrave la progression des tâches vers leur achèvement. C’est pourquoi un principe
essentiel du processus Kanban est de limiter le travail en cours (WIP). Les limites du
travail en cours mettent en évidence les goulots d’étranglement dans le processus de
l’équipe en raison d’un manque de concentration, de personnel ou de compétences. Par
exemple, une équipe de développement de logiciels classique peut avoir quatre états de
workflow : À faire, En cours, Révision du code et Terminé. Elle peut définir une limite
WIP de 2 pour l’état de révision du code. Cela peut sembler une limite basse, mais il y
a une bonne raison à cela. Les développeurs préfèrent souvent écrire du nouveau code
plutôt que de passer du temps à examiner le travail de quelqu’un d’autre. Une limite
basse encourage l’équipe à accorder une attention particulière aux problèmes en cours
d’examen et à examiner le travail des autres avant de procéder à leurs examens de code,
réduisant ainsi le temps de cycle global.
— Mesures visuelles L’une des valeurs fondamentales est de mettre l’accent sur l’améliora-
tion continue de l’efficacité et de l’efficience de l’équipe à chaque itération du travail. Les
graphiques fournissent un mécanisme visuel aux équipes pour s’assurer qu’elles conti-
nuent à s’améliorer. Lorsque l’équipe peut visualiser les données, il est plus facile de
repérer les goulots d’étranglement dans le processus (et de les supprimer). Les deux rap-
ports couramment utilisés par les équipes Kanban sont les graphiques de contrôle et les
diagrammes de flux cumulatifs. Un graphique de contrôle indique le temps de cycle pour

10
 chaque problème et une moyenne mobile pour l’équipe.

Figure 5 – La diminution du temps de cycle moyen sur le graphique de contrôle indique une
réussite. Source :atlassian.com

Un diagramme de flux cumulatif montre le nombre de problèmes dans chaque état.

L’équipe peut facilement repérer les bloqueurs lorsque le nombre de problèmes augmente
dans un état donné. Les problèmes dans des états intermédiaires tels que « En cours
» ou « En cours de révision » ne sont pas encore expédiés aux clients, et un bloqueur
dans ces états peut augmenter la probabilité de conflits d’intégration massifs lorsque le
travail est fusionné en amont.

11
 Figure 6 – Diagramme de flux cumulatif. Source :atlassian.com

— Livraison continue La livraison continue (LC) décrit le processus de publication fréquente

de travaux aux clients. L’intégration continue (IC) est la pratique consistant à créer et
à tester automatiquement du code de manière incrémentielle tout au long de la journée.
Ensemble, ils forment un pipeline IC/LC essentiel pour que les équipes DevOps puissent
livrer des logiciels plus rapidement tout en garantissant une qualité élevée. Kanban et
LC se complètent parfaitement car les deux techniques se concentrent sur la livraison de
valeur juste à temps (et une par une). Plus vite une équipe peut proposer une innovation
sur le marché, plus son produit sera compétitif. Les équipes Kanban se concentrent
précisément sur cela : optimiser le flux de travail vers les clients

II.3 Solutions existantes dans les domaines de Scrum et Kanban

Il existe plusieurs solutions et d’outils pour mettre en œuvre efficacement les méthodologies
Scrum et Kanban dans vos projets. Ces solutions, qu’elles soient logicielles, méthodologiques
ou formatives, visent à faciliter l’adoption de l’agilité et à optimiser la productivité des équipes.

Outils de Gestion Agile

Ces plateformes sont spécialement conçues pour supporter les pratiques Scrum et Kanban,
offrant des fonctionnalités pour planifier, suivre et gérer les projets.
— Jira Software : Développé par Atlassian, c’est l’un des outils les plus populaires pour la
gestion agile. Il supporte à la fois Scrum et Kanban, avec des tableaux personnalisables,
la gestion des sprints et des rapports détaillés. Parfait pour les équipes de toutes tailles
cherchant une solution robuste.
— Trello : Idéal pour Kanban, Trello offre une interface simple et visuelle avec des cartes
et des listes. Il permet de suivre le flux de travail de manière intuitive et est excellent

12
 pour les équipes qui débutent avec l’agilité.
— Asana : Combine des fonctionnalités de gestion de tâches avec des vues en tableau
Kanban. Asana est flexible et convient aux équipes qui souhaitent une interface conviviale
pour collaborer et suivre les progrès.
— Azure DevOps : Proposé par Microsoft, il offre une suite complète pour le dévelop-
pement logiciel avec un support pour Scrum et Kanban. Il intègre la gestion du code
source, les pipelines CI/CD et la gestion des tests.
— Monday.com : Une plateforme visuelle qui permet de gérer des projets en utilisant des
tableaux personnalisables, supportant à la fois les approches Scrum et Kanban.

Outils de Collaboration et de Communication

Facilitent la coordination des équipes, surtout en télétravail.
— Slack : Une plateforme de messagerie instantanée qui s’intègre avec de nombreux outils
agiles pour centraliser les communications.
— Microsoft Teams : Offre des fonctionnalités similaires avec une intégration étroite aux
produits Microsoft.
— Confluence : Un wiki d’entreprise par Atlassian pour documenter les informations, les
décisions et favoriser le partage des connaissances.

Outils d’Intégration Continue et de Déploiement Continu (CI/CD)

Essentiels pour les équipes agiles souhaitant livrer rapidement et fréquemment.
— Jenkins : Un serveur open-source d’intégration continue, extensible avec de nombreux
plugins.
— GitLab CI/CD : Offre des fonctionnalités intégrées pour l’intégration et le déploiement
continus, directement depuis votre dépôt de code.
— Azure Pipelines : Partie d’Azure DevOps, il prend en charge de multiples langages et
plateformes, avec des pipelines cloud.

Outils de Suivi du Temps et de la Productivité

Pour mesurer les performances et optimiser les processus.
— Harvest : Permet le suivi du temps, la facturation et la génération de rapports pour
analyser la productivité.
— Toggl Track : Un outil simple pour suivre le temps passé sur les tâches et projets, avec
des intégrations à d’autres outils.
Les solutions pour mettre en œuvre Scrum et Kanban sont nombreuses et variées, allant
des outils logiciels aux formations, en passant par les ressources éducatives. L’essentiel est de
choisir celles qui correspondent le mieux à votre contexte et à vos objectifs. En combinant
les bonnes pratiques agiles avec des outils adaptés, vous pourrez améliorer significativement la
productivité, la qualité et la satisfaction de votre équipe.

III Scrum vs Kanban

Kanban et Scrum partagent certains concepts mais ont des approches très différentes. Il ne
faut pas les confondre.

13
 Table 1 – Comparaison entre Scrum et Kanban

Scrum Kanban
Méthodologie de pu- Sprints réguliers à durée fixe Flux continu
blication (c’est-à-dire deux semaines)
Rôles Propriétaire de produit, Scrum Pas de rôles spécifiques obliga-
Master, équipe de développement toires
Indicateurs clés Vitesse (Velocity) Durée du cycle (Cycle Time)
Philosophie du chan- Les équipes doivent s’efforcer Le changement peut survenir à
gement de ne pas modifier les prévi- tout moment
sions de sprint pendant le sprint.
Cela compromettrait l’apprentis-
sage autour de l’estimation.
Livraison À la fin de chaque sprint Continue ou à la discrétion de
l’équipe
Cadence Itérative Basée sur le flux

14
CONCLUSION
Au terme de notre exploration de la méthodologie Agile et des cadres de travail Scrum et
Kanban, il apparaît clairement que l’agilité transcende une simple collection de techniques :
c’est une philosophie qui transforme profondément la manière dont les équipes conçoivent et
réalisent des projets.
Dans un monde où le changement est la seule constante, les approches traditionnelles de
gestion de projet, souvent rigides et linéaires, ne suffisent plus à répondre aux exigences ac-
tuelles. L’Agilité offre une réponse adaptée en mettant l’accent sur la flexibilité, la collaboration
et l’adaptation continue aux besoins émergents.
Scrum, avec sa structure organisée autour de rôles spécifiques, d’événements réguliers et
d’artefacts clairement définis, fournit un cadre robuste pour gérer des projets complexes. Les
sprints itératifs permettent aux équipes de délivrer rapidement des incréments de valeur, tout en
recueillant des retours fréquents pour ajuster le cap si nécessaire. La transparence, l’inspection
et l’adaptation sont au cœur de cette approche, favorisant une amélioration constante des
processus et des produits.
Kanban, de son côté, offre une méthode souple et visuelle pour gérer le flux de travail. En se
concentrant sur la visualisation des tâches et la limitation du travail en cours (WIP), Kanban
aide les équipes à identifier les goulots d’étranglement et à optimiser leur efficacité opération-
nelle. Cette approche continue permet une grande réactivité face aux priorités changeantes,
sans les contraintes temporelles des itérations fixes.

En combinant les principes de ces deux cadres, les organisations peuvent bénéficier d’une
agilité accrue, en adaptant les pratiques à leur contexte spécifique. L’intégration de Scrum et
Kanban peut offrir le meilleur des deux mondes : la discipline et la structure de Scrum, associées
à la flexibilité et à l’efficacité de Kanban.

L’adoption de la méthodologie Agile n’est pas seulement une transformation des processus,
mais aussi une évolution culturelle. Elle invite à repenser les relations au sein des équipes, à
valoriser la communication ouverte, la confiance et la responsabilité partagée. En plaçant le
client au centre des préoccupations et en privilégiant la valeur livrée par rapport aux plans
rigides, l’agilité encourage une approche plus humaine et efficace du travail.

Embrasser l’agilité avec Scrum et Kanban représente une opportunité majeure pour les
organisations qui souhaitent rester compétitives et innovantes. C’est un engagement envers
l’excellence, la réactivité et la satisfaction des clients. Les défis associés à cette transformation
sont réels, mais les bénéfices potentiels en termes de performance, de qualité et de motivation
des équipes sont inestimables.

15
Réference bibliographique
@sitea tlassian, url = https : //www.atlassian.com/agile/kanban, urldate = 2025 − 01 − 11
@sitea tlassian, url = https : //www.atlassian.com/agile/scrum, urldate = 2025 − 01 − 11
@sitea tlassian, url = https : /https : //www.atlassian.com/agile, urldate = 2025 − 01 − 11
@everlaab, url = https ://https ://everlaab.com/methode-kanban/, urldate = 2025-01-11
@Appvizer, url = https ://https ://www.appvizer.fr/magazine/operations/gestion-de-projet/kanban,
urldate = 2025-01-11