En monde agile en général, et en méthode agile "Kanban" en particulier, les différents types de demandes sur lesquels l'équipe travaille varient selon la criticité et l'urgence, donc on suit un ordre de priorité adéquat avec toutes ces exigences. Et c'est pour cela que parmi les notions intéressantes et importantes qu'on trouve dans la méthode "Kanban", c'est la notion des "Classes de Service", cette notion permet de catégoriser chaque demande reçue dans une classe spécifique de service.
Les classes de service utilisées dans la méthode Kanban permettent de fournir une catégorisation permettant d'affiner les performances du système Kanban et une manière pour mieux gérer le flux entrant dans le "Kanban Backlog", donc on peut dire qu'une classe de service est un ensemble de règles et critères permettent de décrire en détail comment un ticket ou une demande doit être traitée par l'équipe dès son arrivée.
Pour bien identifier la liste des classes de service à utiliser, il est indispensable de se baser et se reposer sur un ou plusieurs profils de risques dont le plus fréquemment utilisé en Kanban est le "Coût de Délai" (COD => Cost Of Delay), ce profil de risque permet d'analyser et mesurer l'impact business et économique lorsque une demande ou un ticket n'est pas livré temps.
Selon le temps de traversé dans le système Kanban, 4 types de coût du délai peuvent être distingués et définis, par conséquent 4 classes de services peuvent être utilisées en parallèle comme suit :
Standard : Cette classe de service contient l'ensemble des tickets et demandes clients qui n'ont pas un critère d'urgence, ni une date butoir pour la livraison, du coup l'équipe Kanban va traiter ces demandes au fil de l'eau (Premier arrivé premier sorti FIFO). Le COD dans ce cas de figure va augmenter d'une manière et façon linéaire (Exemple : fonctionnalités à développer dans le cadre d'un projet ou application).
Urgente : Cette classe permet de grouper l'ensemble des demandes et tickets urgents et critiques à traiter en priorité 1, c'est à dire que l'équipe doit intervenir rapidement et immédiatement afin de les livrer dans le plus bref délai possible. Le COD dans ce cas de figure va augmenter sur le champ d'une manière féroce (Exemple : Anomalie bloquante en production empêchant l'utilisation d'une fonctionnalité indispensable).
Date fixe : Cette classe de service contient l'ensemble des demandes et tickets ayant une date butoir de livraison mentionnée par le client, et chaque retard va coûter cher, du coup il faut les prioriser afin de respecter les jalons et les deadlines. En cas d'alerte ou retard prévu ces tickets peuvent être promus afin d'accélérer le traitement. Le COD dans ce cas de figure va augmenter à partir d'une date et pas sur le champ (Exemple : La réglementation en domaine bancaire vu que si on ne respecte pas la date fixée au départ, alors des pénalités vont être appliquées).
Intangible : Cette classe de service contient les tickets et les demandes qui ne sont pas urgents, plus il n'y a pas de date fixe, à priori le COD dans ce cas de figure n'est pas significatif, par contre un ticket de cette catégorie peut parfois changer immédiatement de classe à moyen ou long terme s'il génère un problème de performance impactant le système ou le produit en question (Exemple : les demandes mineurs d'optimisation et d'amélioration).
Conclusion :
Il est nécessaire que l'équipe Kanban doit avoir la possibilité d'identifier et fixer les classes de service à utiliser par rapport aux types du "Coût de Délai". Cette catégorisation va permettre d'établir un planning de livraison lisible et clair, ainsi qu'une priorisation facile du Kanban Backlog.
Au niveau du "Kanban Board" affiché sur le mur, il est préférable de mettre des couloirs pour séparer les tickets de chaque classe à part, cela va donner plus de lisibilité et organisation du flux de travail. Aussi bien vous pouvez différencier les différentes tickets par les couleurs des Post-It.
Selon le contexte de travail et le type d'activité de l'équipe Kanban, cette dernière peut ne pas être limitée aux 4 classes de service déjà citées dans cet article, mais plutôt elle peut ajouter d'autres classes de service en fonction des types du "Coût de Délai" conçus. Il est aussi préférable d'allouer un pourcentage de la capacité de l'équipe à chaque classe de service utilisée afin de bien organiser le Kanban Backlog associé.
Comments