Le contexte :
Les business analyst et les développeurs utilisent une méthode agile avec un outil dédié à la méthode en question dans le cadre de leur travail. Il en est de mêmes pour les administrateur systèmes.
Objectif :
S’initier et pratiquer une méthode agile.
Activité :
It-development utilisent la méthode kanban : C’est historiquement une méthode de gestion du stock qui permet de produire sur demande. L’objectif principal étant d’arriver à équilibrer la production et la demande.
On ne livre plus des caisses de pièces détachées, mais des fonctionnalités. L’objectif n’est plus de minimiser les stocks pour éviter la surproduction, mais de réduire au maximum le Time To Market (TTM), autrement dit le délai avant la mise en production.
En informatique =
Comme avec Scrum, tout part d’un backlog : On établie une liste des tâches/fonctionnalités nécessaires (mise en place d’un serveur web, déploiement d’un process, …). Chacune de ces tâches sera représentée par une petite “note adhésive repositionnable” sur laquelle seront notés le libellé et une courte description de la tâche. Vous avez donc la première colonne de votre tableau, qui pourra être enrichie à volonté selon les demandes de l’équipe métier (alias ze boss dans notre cas) (image 1).
Ensuite il va nous falloir une colonne qui détermine quelles sont les tâches à traiter. C’est le product owner qui va les choisir en fonction des priorités. Ces tâches sont déplacées de la colonne “nécessaires” à la colonne “sélectionnées”. La règle de base est que chaque poste ne pouvait avoir qu’un nombre limité de kanbans ? Ici nous allons devoir appliquer la même règle en fonction de contraintes extérieures, des capacités de nos collaborateurs… et le product owner va devoir sélectionner ses kanbans en fonction de cette limite qu’il aura lui-même fixée, mais aussi des dépendances des tâches les unes par rapport aux autres (image 2).
Chaque acteur va à son tour déplacer les fiches vers la 3° colonne de notre tableau pour se les attribuer. Cette colonne représente donc les tâches en cours de développement (image 3).
Une fois le développement terminée, une fonctionnalité est mise dans la 4° colonne : le déploiement. C’est le développeur/administrateur système qui a réalisé le développement qui demande le déploiement de la fonctionnalité. C’est donc lui qui déplace la fiche d’une colonne à l’autre (image 4).
Enfin, on passe à la 5° colonne (sans aucune allusion conspirationniste)qui est la recette utilisateur. C’est encore la personne qui a réalisé le déploiement qui fait la demande de validation. Dans notre exemple il pourrait s’agir du lead developper, ce qui permet aux développeurs de se concentrer sur le développement, toujours dans l’optique d’aller le plus vite possible (image 5).
Une fois la recette effectuée, la fiche est simplement détruite, la tâche n’étant plus considérée comme faisant partie du projet.
L’outil de la méthode kamban : Redmine
C’est une application web de gestion de projet en méthode agile écrit en Ruby par Jean-Phillipe Lang. Il est open-source.
