D’accord le titre peut sembler contradictoire. Après tout, l’informatique est un domaine où la production à la chaîne n’est pas vraiment possible. La variabilité des tâches est diverse et les gens ne sont pas interchangeables. Mais est-ce qu’on ne pourrait pas retirer quelques avantages à optimiser la production logicielle en s’inspirant du travail en usine?
Depuis un peu plus de deux ans, mon équipe de travail utilise un tableau Kanban pour aider à gérer le développement de nos logiciels. L’idée de base du Kanban est d’utiliser une ressource en nombre limitée, dans la plupart des cas de petites fiches en carton, pour limiter le travail en cours. En limitant cette ressource on réduit et on rend plus rapide les cycles de production. On obtient alors des avantages comme une meilleure capacité à prévoir la production. La méthode est inspirée des techniques développées aux alentours des années 1930 par Toyota pour ses usines.
L’implantation d’un tableau Kanban débute généralement par un système très simple. On sépare un tableau en trois colonnes pour représenter l’état où se trouve les tâches. Les trois colonnes de base sont : à faire, en cours et terminé. Ensuite, on écrit sur des cartons les tâches à réaliser et on les place dans la colonne à faire. Lorsqu’on débute une tâche, on déplace la carte correspondante dans la colonne en cours. La carte sera placée dans la colonne terminé une fois le travail complété. Il faut bien sûr que l’équipe s’entende sur une définition partagée de complété ce qui n’est pas aussi évident qu’on pourrait le croire.
Le tableau ne doit pas rester figé aux trois colonnes de base. Il évolue selon les besoins et il est modifié à chaque fois qu’on rencontre un problème. En fait, il met en évidence les problèmes très rapidement. Il suffit de regarder les tâches s’accumuler dans une colonne pour se rendre compte que quelque chose cloche. Notre tableau Kanban a été régulièrement modifié et il est actuellement composé de sept colonnes:
Nouveau
La tâche vient d’être ajoutée et doit être évaluée.
En attente
La tâche est bloquée parce qu’on attend l’intervention d’une personne extérieure.
À faire
La tâche est acceptée, évaluée et elle est prête à être réalisée.
En cours
Quelqu’un travaille activement sur la tâche.
Intervention requise
Le travail a été fait mais la résolution de la tâche est autre que complété.
Complété
Le travail a été fait.
Fermé
Le travail est validé, accepté et la tâche est terminée.
Notre définition de complété et le concept de limite sont fixés implicitement par l’équipe. J’essaie de garder au maximum deux tâches par développeur dans la colonne en cours et une dizaine de tâches dans les deux colonnes complété et intervention requise. Nous devrions peut-être être plus strict mais jusque ici ça marche assez bien. Pour la définition de complété, elle ressemble à ceci :
Une tâche est complétée lorsque le travail est fait. Il doit avoir été validé et accepté par une seconde personne. Il est également inclus dans la version en cours de développement du logiciel. La tâche est donc prête à être livrée à un client.
Après deux ans d’utilisation, qu’est-ce que j’ai découvert sur la méthode? Le Kanban en lui même n’est pas une méthode de gestion. Il est cependant le meilleur outil de visualisation que je connaisse pour créer un milieu propice à l’éclosion d’une équipe Agile capable d’évoluer et de s’adapter à toute difficulté. À recommander pour toute petite équipe de développement informatique.
Information générée par une source non certifiée 