Dans l'approche traditionnelle ou en cascade, tous les besoins du client sont centralisés et enregistrés dans un cahier de charge ("CPS") figé dès le départ, par contre dans l'approche agile on parle d'un Backlog qui regroupe l'ensemble des besoins du client et de l'équipe permettant de réaliser le produit ou l'application en question, on parle dans le cadre "Scrum" du "Product Backlog", alors que dans la méthode agile Kanban on peut dire aussi le "Kanban Backlog".
La constitution du Backlog se fait au fur et à mesure contrairement au cahier de charge en mode traditionnel, il faut l’alimenter au départ durant la phase de cadrage par une quantité de travail pouvant occupée l’équipe pour un certain temps, et le reste vient au fil de l'eau, c'est pour cette raison qu'il ne faut pas l'utiliser comme un réservoir plein d'idées sans aucun intérêt, mais plutôt essayer toujours d'avoir une cadence de capture d'idées et feedback du client et utilisateurs finaux, ainsi qu'une autre cadence pour finaliser et ordonner les demandes pour les traiter selon la capacité de l'équipe de réalisation.
Au niveau de la méthode agile Kanban, on trouve le Backlog dans l'extrémité gauche juste avant la colonne "TO DO", c'est là où on doit mettre les éléments du projet ou du produit en question. Pour faire passer les tickets du Backlog vers l'étape "TO DO" il faut que ces demandes soient prêtes et que tous les détails sont présents et clairs comme le cas en Scrum si l'équipe utilise la pratique du D.O.R (Definition Of Ready). Sans oublier bien sûr l'ordre de priorité et la notion des dépendances techniques et fonctionnelles.
L'objectif principal du "Kanban Backlog" qui n'est pas si différent d'un "Backlog Scrum" est de bien avoir un ensemble des Tickets bien ordonnés et exploitables afin de les amener à la vie et les réaliser avec succès. Sachant que ce "Kanban Backlog" peut contenir plusieurs types de demandes et cartes en occurrence :
Les demandes fonctionnelles contenant du code (Demandes fonctionnelles qui ajoutent de la valeur métier au client).
Les demandes fonctionnelles sans code à créer (Demandes fonctionnelles qui ajoutent de la valeur sans ajouter du code : Paramétrage d'une application, assistance téléphonique d'un utilisateur final, ...Etc.).
Demandes techniques (Technical Stories).
Bugs & Anomalies.
Demandes d'amélioration (Pour traiter la dette technique par exemple).
Demandes de recherches et analyses (Spikes).
En méthode agile "Kanban" on travaille avec la notion du "Flux Tiré", du coup on doit être vigilant sur la gestion du "Kanban Backlog", pour cela il faut bien poser et gérer les règles nécessaires permettant de l'alimenter et le mettre à jour, afin de le rendre exploitable par rapport à la cadence des rituels et le débit de traitement des tickets et demandes par l'équipe.
Aussi bien la notion des rôles en méthode "Kanban" n'est pas la même que celle appliquée en "Scrum", car en Kanban c'est flexible, du coup c'est l'équipe qui va décider par rapport à qui va gérer et alimenter ce Backlog.
Conclusion :
Le Kanban reste une méthode agile très ouverte qui n'impose pas de règles précises, C'est ce qui permet à cette méthode flexible d'être applicable dans plusieurs cas et situations, du coup c'est à l'équipe de s'adapter et mettre les règles nécessaires pour une bonne gestion du "Kanban Backlog" associé.
Si on applique Kanban, il n'y a ni rituels imposés, ni rôle spécifiques obligatoires contrairement à ce qu'on voit et on applique au niveau du cadre méthodologique agile Scrum, du coup c'est l'équipe concernée qui doit désigner le responsable du Backlog et les cadences nécessaires pour une meilleure gestion en continue.
La méthode Kanban est utilisée souvent dans les contextes de livraisons des services, elle propose en parallèle 4 types de classes de service (Standard, avec date fixe, accélérée, et intangible) du coup c'est très difficile d'avoir dans ce cas de figure une seule personne capable de gérer, maintenir, et prioriser le Kanban Backlog.
Comments