Accueil > Divers > Kanban, dans quel cas l’utiliser ?

Kanban, dans quel cas l’utiliser ?

L’approche Kanban consiste à mettre en avant la visualisation et l’optimisation du workflow.

kanban

http://www.crisp.se/

Comme sur Scrum, les différentes tâches évoluent d’une étape du workflow à une autre (à réaliser, en cours, à tester, … , fait). Mais contrairement à Scrum qui fixe le travail à réaliser dans une itération, Kanban fixe le travail à réaliser en parallèle sur chaque étape du workflow.

Kanban présente plusieurs avantages :
– Possibilité de mise en place progressive de la méthodologie Agile (moins directif que Scrum).
– Les points de blocages sont visibles très tôt. La collaboration dans l’équipe est encouragée pour résoudre les problèmes de manière corrective, le plus tôt possible.
– On peut se passer de la notion de sprint, voire la moduler. Un sprint d’une ou deux semaines n’est pas envisageable dans certains cas de figure (réactivité supérieure exigée).

Dans quels cas utiliser Kanban ?
Comme toute méthode, Kanban n’est pas une solution universelle pour toutes les situations. C’est une méthode qui est adaptée pour répondre à des problématiques et des configurations précises.

Equipes de taille limitée
Si Scrum fonctionne bien avec des équipes d’environ 7 personnes, Kanban est très adapté à des équipes de plus petite taille.
Des équipes de 3 personnes ne sont pas si rares. Exemple : une équipe de 10 personnes constituée de 2 ou 3 groupes avec des spécialités distinctes (technologies, actifs logiciel, …) où l’ensemble des personnes ne sont pas interchangeables. Ce cas de figure est très fréquent et Kanban est plus adapté car il limite le nombre de règles à suivre tout en gardant une bonne qualité du travail rendu.

Les changements fréquents de priorité
Aujourd’hui, la production logicielle demande de plus en plus de réactivité aux équipes de réalisation : nouvelles fonctionnalités, fonctionnalités à annuler, gestion prioritaire des bugs, …
Scrum permet de répondre à cette contrainte en proposant des itérations plus courtes (2 semaines). Cette démarche atteint sa limite quand les changements de priorité sont encore plus fréquents. Dans ce cas, Kanban est une excellente réponse à cette problématique, il permet de gérer des changements de priorités chaque jour.

Projet de maintenance
Un process type d’un projet de maintenance ressemble à ceci :
– Dès qu’un bug prioritaire est soumis il doit être corrigé dès que possible.
– Un bug mineur devient prioritaire dès que sa date limite de résolution (SLA) approche.
– Si le client fait une « change request » il n’y a plus de bugs prioritaires, la satisfaction client est prioritaire.
– Si il y a plusieurs « change request », demander au chef de projet de designer la priorité.
– S’il n’y a pas de bugs et de « change request », faire un peu de refactoring.
Kanban est la solution idéale pour ce genre de situation. C’est le cas typique des process de développement piloté par les événements (event-driven development) où une roadmap détaillée n’est pas disponible.

Petits projets multiples
Travailler sur plusieurs petits projets ou sous-projets avec la même équipe est assez difficile. Dans ce cas, il est compliqué de synchroniser les différents flux de tous les projets et augmenter la taille de l’équipe n’est pas la meilleure solution. Cette situation a pour conséquence des changements de priorité fréquents et des arbitrages permanents pour savoir quel projet livrer à temps au détriment de tous les autres.
Dans ce cas-là, Kanban est une bonne solution car il organise le flux de travail de sorte que la seule chose à faire (presque) est de définir les priorités au niveau de la première étape du workflow.

Plus généralement !
Le point commun entre toutes ces situations est la nécessité d’avoir peu de contraintes de travail. Le travail est organisé avec un ensemble de règles simples. L’autre point commun est que la planification à moyen et long terme est difficile, voire impossible.
Ces 2 critères sont les plus spécifiques où kanban montre son plein potentiel.

Categories: Divers Tags:
  1. Pas encore de commentaire
  1. Pas encore de trackbacks


neuf − = 5