Scrum est un excellent outil léger pour gérer un projet et une équipe. Là où il n’y a aucunes méthodes de développement, c’est un principe simple pour mettre en route un projet. C’est réellement une méthode qui permet de créer de la valeur. Cependant je m’intéresse aussi à d’autres méthodologies de la communauté. J’ai entendu parler de Kanban et de Lean development il y a quelques mois mais jusqu’à récemment, c’était pour moi du chinois. Voyons en quoi consiste ces méthodologies. J’essaye ici de vous parler de concepts et de principes que vous pouvez mettre en place dans votre équipe.
La méthode Kanban est une méthode industrielle de production ayant pour origine le Japon. Cela signifie « étiquette » en Japonais. Inventé dans les années 60 par Toyota, le principe est le suivant : une étiquette est attachée à chaque élément produit par l’équipe de développement. Lorsqu’un développement se termine, l’étiquette est retournée dans une liste d’attente. Lorsque le nombre d’étiquettes dans la liste dépasse un seuil, l’équipe de développement reprend alors une étiquette et l’attache à un nouvel élément à produire.
Cela revient donc à limiter la production d’une équipe à un seuil.
Limiter la production d’une équipe ? Cela peut sembler étrange non ? Je vais illustrer le principe par une image. Samedi prochain vous allez effectuer un déménagement. Voyons d’abord la méthode inadaptée pour effectuer ce déménagement, que j’appelle le « chacun pour soi » : vous prenez un carton, descendez 3 étages, traversez la rue, mettez le carton dans le camion. Au passage je signale qu’il est difficile de monter dans le camion et de le ranger au fond car vos amis font la même chose, et don c’est un peu compliqué.
Tout ceci n’est pas très optimisé non ?
Le principe de Kanban est de limiter la production, de laisser chacun être proactif en allant « piocher » une tâche à faire dans sa boîte d’attente. Pour revenir à notre déménagement voici comment j’explique cela : imaginez qu’avec 5 personnes vous vous répartissez le parcours de l’appartement au camion.
Pierre va chercher les cartons dans l’appartement et les place devant la porte.
Max appelle l’ascenseur, le charge, et l’expédie au rez-de-chaussée.
Pauline vide l’ascenseur et amène les cartons au camion.
Enfin Nick se charge de ranger les cartons dans le camion de manière optimale.
Tout d’abord le principe vous l’avez compris : nous divisons les étapes du développement du logiciel. Chacun est responsable d’une partie, et travaille de manière autonome. Au lieu d’essayer de faire le parcours du déménagement complétement (de l’appart au camion) nous divisons l’activité globale en petites activités. Cela évite par exemple que 3 personnes essayent d’utiliser l’ascenseur en même temps. Au final le déménagement va plus vite.
C’est le premier principe de cette méthode, chacun travaille sur une petite activité au lieu que tout le monde travaille sur tout le processus de production.
Le deuxième principe : Pierre va plus vite pour vider l’appartement car il n’a pas beaucoup de chemin à faire. Pensez-vous qu’il doit alors entasser les cartons devant la porte ou doit-il attendre que Max ait chargé l’ascenseur ?
La réponse Kanban est qu’il doit attendre.
En effet, rien ne sert de déplacer un engorgement, il faut terminer un nombre limité d’activités, et surtout éviter de se lancer dans différents chantier. Le signal qu’il peut reprendre sa production, c’est qu’un des cartons a été pris par Max qui charge l’ascenseur. Sinon il attend devant la pile de carton.
Kanban est une méthode de restriction de la production par la consommation.
Imaginez ce principe appliqué au développement d’un ensemble de fonctions dans un projet informatique. Tout d’abord rien ne vous empêche d’ajouter une gestion de priorité afin que les éléments les plus importants soient développés en premier. Ensuite ce que je trouve élégant, c’est que le système s’auto-régule. Je cherchais une image afin d’expliquer ce principe et j’ai pensé à la gestion d’une file d’attente.
Dans un restaurant de restauration rapide américain, chacune se place devant un guichetier et attend son tour. C’est le principe de la distribution, que vous expérimentez aussi dans un supermarché lorsque vous faîtes la queue pour payer. L’inconvénient de ce système c’est le taux de passage, que des scientifiques ont calculés. L’alternative qui marche est de ne créer qu’une seule file d’attente puis ensuite de dépiler non pas plusieurs personnes en attente par plusieurs unités de traitement, mais bien une seule file.
Ce principe est appliqué dans les administrations, à la Poste, à Orly devant les guichets Air France pour l’embarquement… Chacun attend dans une file unique, et dès qu’un guichet se libère, vous allez rapidement à ce guichet, et la file avance. Il a été prouvé que ce système de gestion est bien plus performant qu’un système de queue distribué.
Revenons à la méthode Kanban. Afin d’illustrer ce système, les personnes qui réfléchissent à cette méthode proposent de ne faire qu’une seule file de tâches à faire pour toute l’équipe au lieu de distribuer aux membres des tâches.
Si vous voulez, au lieu d’affecter des JIRA à chacun, et que cette pile de JIRA s’accumule sur le bureau de chaque développeur, vous laissez votre file unique en place. Ensuite en adoptant le principe de Kanban, c’est le développeur qui viendra chercher la tâche à effectuer, dès qu’il aura terminé son activité.
La liberté de traiter plusieurs activités en même temps est finalement un frein à la productivité. Si rien ne me contraint à terminer ma tâche, et que je peux commencer un autre développement, je commence alors à ne plus gérer correctement mon travail.
Répondez-moi honnêtement : est-ce qu’aujourd’hui vous avez travaillé sur une seule activité ?
Oui ? pourtant ce bug urgent, cet email où l’on vous a demandé de vérifier un bug, cette explication de 20 mn à un collègue, la discussion avec un autre ami sur l’idée de mettre en place Maven ou pas…
En fait notre journée est coupée d’un grand nombre d’événement qui cassent le rythme de production et votre énergie pour travailler. C’est un fait. Et à part travailler dans un aquarium, il faut s’en contenter.
Par contre sur la gestion des tâches d’un projet, comme l’explique Johanna Rothman sur son blog, une organisation matricielle multi-tâche est l’anti-pattern de l’Agilité. Elle explique en substance que certains managers s’évertuent à gérer leur efficacité en répartissant les tâches entre les développeurs. Ils ne cherchent pas à améliorer le débit de production de l’équipe.
L’un des principes de Kanban est qu’il faut terminer une tâche avant d’en commencer une autre. D’où l’importance de définir la notion de « terminé ». J’y pense tout le temps. L’un des soucis dans la communication entre développeurs, c’est la définition du « j’ai terminé ». En tant que développeur, je fais mes tests unitaires, je code et je valide avec la dernière version du code. En tant que chef de projet j’aimerai en plus que tu vérifies sur la version d’intégration que ton code fonctionne, et j’aimerai que tu mettes un peu de documentations sur le Wiki. Enfin en tant qu’ingénieur qualité, j’attends de l’aide pour tester ta nouvelle fonction…
Pensez à bien définir la notion de « terminé » et vos estimations seront plus justes.
Comme le suggère Johanna, si votre manager vous demande de faire une nouvelle tâche, demandez-lui la priorité de cette tâche par rapport à celle que vous faîtes. S’il ne sait pas répondre, c’est qu’il n’a pas alors rempli son rôle de manager. Son boulot c’est d’identifier la priorité. Pas le vôtre.
Le vôtre selon le principe de Kanban c’est de ne porter qu’un seul carton de déménagement à la fois, car vous avez alors plus de chances de terminer votre tâche, de la réussir et d’éviter de vous épuiser.
C’est en regardant le principe du supermarché, où chacun se sert, que Taiichio Ono a eu l’idée de la méthode Kanban. Il a ainsi proposé un système où les producteurs viennent chercher les tâches à faire, au lieu qu’un manager affecte ces tâches.
Les 6 règles du principe Kanban sont :
– Les clients procèdent les éléments en respectant la quantité spécifié dans le Kanban
– Les fournisseurs en amont, produisent alors de nouveaux éléments du nombre exact et dans l’ordre spécifié sur le Kanban
– Aucun élément n’est déplacé sans être attaché d’un Kanban (étiquette)
– Un Kanban doit accompagner chaque point tout le temps
– Les défauts les montants incorrects ne sont jamais transmis à l’étape suivante du processus, on les jette.
– Le nombre de Kanban peut être réduit afin d’identifier plus facilement les problèmes.
Le Kanban rapporté au développement informatique
Après tout ceci on peut donc définir ce processus comme étant une carte, une fiche, que l’on va attacher à une activité. Cette carte est un droit de travailler sur une activité, et le fait que chacun ne puisse en traiter qu’un nombre limité, limite la production. Chaque développeur est proactif, il notifie le producteur (le chef de projet) si la pile des Kanbans se vide. En principe cette carte de production doit lui donner toutes les informations pour réaliser sa tâche. Je reconnais qu’en pratique, dans le cadre d’un développement informatique, c’est peut-être moins évident.
Pour résumer : chaque activité ne peut être complété que si un Kanban est attaché. De manière concrète, imaginez 10 drapeaux pour une équipe de 15 personnes. Il est interdit de dépiler un élément de la liste « A FAIRE » tant qu’un drapeau « TERMINE » n’est pas disponible.
Voici un dessin qui illustre cela
Le Tableau Kanban
Comme nous l’avons vu, les Kanbans sont donc à la fois des marqueurs et des témoins que l’équipe se passe en remontant le flux de production. Dans le développement d’un logiciel, le plus simple est de mettre en place un grand tableau sur un mur, de prendre quelques post-it puis ensuite de tracer plusieurs colonnes, selon les étapes de votre production.
Voici un exemple simple de Kanban :
Tableau Kanban
L’usage est de prendre un code couleur afin d’identifier visuellement les catégories des activités. Par exemple la correction d’un bug urgent sera sur une fiche rouge. Une amélioration pour un client sera sur une fiche bleu. Une amélioration proposée par un développeur sera sur une fiche jaune…
Ensuite le principe est de respecter la taille limitée du tableau. Chaque colonne ne peut accepter qu’une quantité limitée de post-it. A partir de ce principe, vous venez de refaire le système de déménagement dont nous avons parlé au début : vous limitez le nombre d’éléments en cours de production, vous forcez chacun à terminer une tâche, vous identifiez visuellement l’activité de l’équipe, et vous pouvez afficher d’autres éléments comme des statistiques de WIP (Work In Progress) afin de montrer à votre managment l’avancement de l’équipe.
Enfin, l’une des valeurs de l’Agilité est la transparence. Et ce tableau expose à tout le monde votre activité, il permet de créer de la communication, et donc au final je pense qu’il améliore le développement.
Maintenant pour répondre à la question, Kanban ou Scrum ? Je pense qu’il faut les 2.
Références:
http://www.agilemanagement.net/Articles/Papers/KanbanAtLeanNPD.pdf
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
Au vu de ce que je comprends de Kanban, j’ai du mal a comprendre comment (et pourquoi comparer Scrum et Kanban).
Je vois dans Kanban une façon de gérer au sein de l’équipe le dépilement des taches. En gros au sens Scrum, il ne s’agit d’une façon de procéder durant le sprint pour l’équipe de développement.
Mais dans scrum l’activité de développement n’est qu’une partie de la méthodologie.
Scrum explique
* quels sont les acteurs: Client Owner, Scrum Master
* quelles sont leurs interactions: le product owner évalue le produit du sprint précédent, rédige les spécifications des prochains, etc.
Du coup, j’ai du mal à voir en quoi Kanban peut être une méthodologie comme XP, Scrum ou RUP peut être une méthodologie.
Peut-être qu’il y a d’autres parties que tu n’as pas pu abordé dans ton post, autour de Kanban ?
Scrum applique le « mécanisme » Kanban mais au niveau des sprints et des acteurs : l’équipe ne fera rien si le client n’a pas rempli ses taches (donc écrit les spécifications et les tests) pour le sprint suivant, de même le client ne testera rien si l’équipe n’a rien livrée…
Par ailleurs cette organisation des taches au sein de l’équipe suppose un travail séquentiel sur les taches (comme sur une chaine de production de l’industrie) qui n’est ni celle encouragée dans les méthodes agiles (propriété collective du code) ni celle que j’ai retrouvé sur la majorité des projets informatique.
J’ai du mal à voir comment Kanban pourrait être utilisé dans mes projets informatique (avec beaucoup de partie cognitive) alors que cette méthode provient de la production industrielle de masse. On aura les mêmes soucis si on cherche à introduire nos solutions dans le monde industriel, par exemple faire des tests en premier ou faire du « pier-deménageur » pour une société de déménagement.
kerny> je dois continuer a presenter les principes de la methode en les rapprochant de ce qui se fait dans le developpement informatique. C’est un moyen plus simple que scrum pour developper et remplacer l’absence de methodes.
A suivre pour la suite
J’attends la suite…
Bravo pour ce travail de vulgarisation.
Thank you for the reference to my article, although I cannot read French… 🙂