Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Le Kanban appliqué à l’IT

Par Laurent PHILIBERT Publié le 18/07/2017 à 21:27:40 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Préambule

Dans cet article, je vous expliquerai comment utiliser pas-à-pas la méthode Kanban dans le cadre d’un projet informatique. Il s’agit d’une méthode de gestion de projet. Le Kanban n’est pas issu du monde de l’IT mais bien de la production industrielle et logistique. Si vous voulez vous y référer, j’ai écrit un article traitant le Kanban de manière générale en flux tendu. Vous le trouverez ici..

L'esprit Kanban

La méthode Kanban, c’est autre chose. C’est une autre méthode, une autre « philosophie ». On ne brade plus des caisses de composants, mais des possibilités. Notre mission ne sera plus de réduire les stocks afin de fuir la surproduction, mais de baisser le plus possible le Time To Market (TTM) d'une autre manière, le temps imparti préalablement à la mise en production. Tout ceci a l'atmosphère de coller splendidement avec nos objectifs, donc observons la manière afin de décliner cela.

Les étapes du Kanban

Comme avec du SCRUM, tout part d'un backlog : établissez la sélection des travaux/possibilités requis (mise en route du serveur, développement du CMS, mise en place du thème, arborescence, plugin X Y ou Z…). Chaque action sera représentée par une minuscule « note adhésive repositionnable » (voyez plutôt une étiquette ou un post-it) sur lesquelles seront notés les libellés et une brève présentation du travail. Vous avez alors la première colonne de votre tableau, qui sera capable d’être enrichie autant de fois qu'on le veut d'après les requêtes du groupe d’emploi (« à quoi ça sert ? » dans notre cas).

Par la suite, nous aurons besoin de plusieurs piliers sur lesquels nous fixerons les actions à traiter. Identiquement à l'intérieur d'une organisation de type Scrum c'est le Product Owner (ici, prenons le cas qu’il s’agit de notre Lead Developer) qui va les choisir selon les priorités. Ces travaux sont déplacés de la colonne « requis » à la colonne « choisies ». Vous vous souvenez que dans l'application industrielle, chaque envoi serait capable d’avoir qu'une faible proportion de kanbans ? Là nous allons devoir appliquer la même règle en fonction de obligations extérieures, des facultés de nos collaborateurs… et le Product Owner devra sélectionner ses kanbans selon cette frontière qu'il aura établi depuis le propre périmètre du projet. En plus des dépendances, les actions seront les unes face aux autres… Nous allons imaginer que chaque membre de l’équipe de développement ne puisse traiter que 2 objectifs en simultané. Ainsi, le Product Owner ne sera capable d’en sélectionner que 4 en même temps.

Chaque programmeur va au même moment bouger les fiches vers la 3° colonne de notre tableau pour se les approprier. Cette colonne reste par conséquent les travaux toujours en phase d'élaboration.

Dès que le développement est fini, la tâche est mise dans la 4° colonne : le développement. Selon toute logique cartésienne, c'est le programmeur qui a réalisé la tâche qui exige le lancement de la fonction sur serveur. C'est par conséquent lui qui déplace la fiche d'un pilier à l'autre : du développement au déploiement.

Finalement, on passe à la 5° colonne, il s’agit de la phase de recettage ou communément appelée : la recette. Comme pour l'étape précédente, c'est le développeur qui a réalisé la fonctionnalité qui fait la sollicitation d'homologation en phase de recettage. Dans notre exemple, il serait question du Lead Developer, ce qui donne la possibilité aux autres développeurs de se focaliser sur l'évolution. Je vous rappelle encore que le but est d'aller très rapidement.

Une fois le mélange fait, la fiche est bêtement jetée, le travail ne se trouvant plus considéré comme faisant une part du programme.

Fin de la ligne de production

La chaîne de fabrication peut s'arrêter. Il peut arriver, pour un motif ou une autre qu'il soit impossible de bouger une fiche d'un pilier à un autre. Notamment, s'il est décidé qu'une seule fonction n'est capable d'être essayée par des testeurs en simultanée, alors dans le cas un peu plus haut, il sera impossible de passer la fiche D en ressource tant que la fiche A n'aura pas été traitée.

Comment réagir ? Les programmeurs vont se dépêcher de créer leurs travaux en attente pour être certains de ne pas être à la bourre et ensuite ? Et que va-t-il se passer si toutes les pages du tableau se positionnent embouteillées ? On est également capable de laisser la fonctionnalité en question de côté, choisir qu'elle n'est pas cruciale à la fabrication car l'article est livrable. Cependant, si cette entorse au processus permet de se désengorger fait suite à un dysfonctionnement, il risque de se glisser et de ne réapparaître que quelques jours. Suite cela, il sera forcément compliqué à récupérer et à solutionner.

Alors, pour faire simple, en cas d'engorgement ou d'anomalie, c'est toute la chaîne qui s'arrête et l’équipe entière planche à la résolution de ce problème (oui, vous m’avez bien compris, l’équipe entière). Le principe de gestion de projet avec du Kanban ne se limite pas à fabriquer vite, il surcroit surtout de créer de la qualité. C’est essentiel, c’est le nouveau mot d’ordre du management de projets IT.

Théorie vs Pratique

De l’hypothèse à la pratique : certaines modifications, si utiles soient-elles, la façon Kanban demeure un outil à votre projet et non pas une règle à laquelle vous devez vous plier :

Voilà dès lors des modifications que l'on trouve, vous remarquerez éventuellement des tableaux de bordure dont la colonne « développement » est coupée en 2 : en cours et fini.

De mon point de vue j'ai l'impression cette scission contraire aux principes de la préparation Sanban au sein de laquelle les adhésifs ne sont déplacées que par un flux matériel. Pour faire simple, c’est le cas lorsqu'elles changent de possesseur. Or si entre la croissance et le développement, la fonction est capable d'être traitée par deux développeurs différents, cela n'est pas le cas entre « il débute à améliorer » et « j'ai terminé la fonctionnalité ». Pourtant cela peut être utile pour l’équipe de développeur de regarder leur to-do-list, donc pourquoi pas ?

Faut-il démolir le kanban dès que la phase de recettage est approuvée ? Si vous vous servez de git ou tout autre outil de versionning, vous savez pertinemment que le fait d'apprendre qui a fait quoi, à quel moment, où et pourquoi, est primordial ! Je crois alors qu’il est inimaginable de jeter une tâche à la poubelle. Je vais même plus loin en complétant les fiches les renseignements relatives aux modifications d'état : pour chaque colonne du tableau je vous expose d'enregistrer une ligne sur laquelle la personne qui fait le déplacement de la fiche notera son libellé et la date (rajoutez aussi une remarque pour plus de clarté). Ensuite on pourra connaitre que telle mission a été sélectionnée par tel développeur, tel jour et pushée sur le serveur par telle autre membre de l’équipe. S’il y a un quelconque dysfonctionnement, il est important de connaitre qui est intervenu sur quelle fonction. Le tout est fait dans le but de gagner du temps, pas de taper sur les doigts de votre équipe. Comme vous vous en doutez alors, il est inutile d'ajouter que dans cette position, il ne faut en aucun cas jeter vos Kanbans, cependant vous pouvez les archiver précieusement.

Dans mon exemple, vous vous être rendus compte par vous-même que le flot n'est pas continu : une fois qu'un développeur a posé un post-it de la colonne « sélectionné » à la colonne « développement », le Product Owner pourrait en principe sélectionner encore en plus une nouvelle fonctionnalité pour maintenir la quantité de tâche de manière constante dans chaque colonne (hormis celle du backlog bien entendu). Mais se livre de cette manière à l’exercice aura pour conséquence un effet malsain : si aucun des analystes programmeurs n’exige s'occuper d'une mission, cette dernière demeurera sélectionnée tant qu'il y en aura d'autres à améliorer. Pareil que dans la majorité des procédés Agile, chacun est censé être responsable, mais comme dans toute équipe, le facteur humain est à considérer. Mais encore, « assoiffer » les personnes en charge des développements permet d'imposer au groupe de réaliser un état des lieux à une cadence établie par le Product Owner. Si dans mon exemple on pense que chaque développeur sera capable de traiter 4 tâches tous les jours (parce qu'elles sont simples), le fait de n'en mettre que 2 à la guise de l’ensemble de l’équipe forcera la team à réaliser un point de fin de journée au terme de la demi-journée.

La méthode SCRUM

Scrum et Kanban peuvent cohabiter sans aucun problème. Les deux procédés sont dans la même lignée sur le Lean et l’Agile. Les dissemblances entre ces deux philosophies sont en définitive suffisamment minimes et il faut s’intéresser à cette problématique avec précision pour faire une réelle distinction, même si dans les faits, elles se ressemblent fortement.

En bref

Avec cet article sur le Kanban et celui-ci sur ses origines, vous êtes fins prêts pour mettre tout ça en place et l’appliquer en entreprise, ou même dans le cadre de vos projets IT personnels. Comme vous l’avez remarqué, le Kanban est assez facile d’utilisation. Le tout est de savoir comment réagir et de savoir quoi faire. Ce n’est qu’une question de réaction. Bien évidemment, il ne s’agit que d’un outil pour vous aider à gérer vos projets. Cela vous servira pour optimiser votre temps et vos développements mais en aucun cas une personne le fera pour vous. Bien évidemment, vous pourrez l’appliquer sur de plus grands projets, le tout est d’être méthodique et de découper les tâches de façon à les rendre beaucoup plus abordable. Avec l’expérience, vous l’apprendre petit à petit !

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels