Kanban, classes de service avec iceScrum

KanbanIT.jpgLa version actuelle d’iceScrum n’implémente pas de véritable Kanban, mais il est possible de s’appuyer sur les facilités de management visuel offertes par l’outil pour, avec quelques astuces, disposer d’un tableau Kanban.

Ce tutoriel décrit une façon de faire permettant de gérer un flux des travaux. Elle est adaptée à de petites équipes distribuées. Elle fonctionnera aussi très bien pour une personne seule, je l'ai testée depuis 2 mois.

J’avais écrit l’an dernier 2 articles sur comment faire du ScrumBan avec iceScrum. Ce que je présente ici est plus orienté tableau Kanban ; c'est rendu possible par des évolutions dans iceScrum et cela s’appuie sur une nouvelle notion Kanban.

Cette notion est la classe de service, qu’on trouvera décrite dans l’excellent livre de Laurent Morisseau «Kanban pour l’IT» paru aux éditions Dunod et qui sera présentée pendant le séminaire Kanban organisé à Toulouse le 24 octobre.

Cette technique est mise en œuvre avec succès chez Kagilum, le sponsor d’iceScrum, pour tous les travaux de l’équipe, qui sont variés : développement, support, administration, commercial, marketing...

Configurer pour le «Kanban board»

Dans cette optique Kanban, on ne va utiliser, en régime de croisière, qu’un sous-ensemble d’iceScrum : essentiellement le plan de sprint (qu’on pourrait rebaptiser tableau kanban) qui sera la vue principale et, éventuellement, le bac à sable, la plupart du temps en vue réduite.

Pour cette utilisation d’iceScrum il n’est pas besoin de changer les options dans les pratiques du projet, sauf pour les tâches urgentes, qu’il faut demander d’afficher et les tâches récurrentes à masquer.

Nous allons essentiellement utiliser la vue Plan de sprint, alors mettons là carrément à gauche dans la barre de menus. Cela se fait simplement en faisant glisser les boutons. L’autre intérêt de la positionner ainsi est qu’à chaque nouveau lancement d’iceScrum, elle sera directement ouverte. Des clics en moins.

Dans une approche orientée flux, on pourrait se passer de sprints. Avec iceScrum nous allons quand même créer un sprint, mais de longue durée, par exemple 90 jours. On pourra toujours modifier la date de fin de sprint plus tard, par exemple pour la prolonger.

Classes de service

La notion de classe de service n’existant pas dans iceScrum, nous allons la simuler. Conformément au livre Kanban pour l’IT, nous créerons 4 classes :

  1. urgent,
  2. standard,
  3. à date fixe,
  4. intangible.

Pour la première nous allons utiliser la ligne des tâches urgentes d’iceScrum. Pour les 3 autres nous allons créer des (pseudo)stories.

Faisons rapidement passer ces stories dans le sprint en :

  • les acceptant à partir du bac à sable et,
  • dans le backlog, en donnant une estimation quelconque
  • puis dans le plan de sprint en les faisant glisser dans la première colonne à partir du backlog en widget.

Voilà, le cadre est donné, on peut maintenant "lancer le sprint".

KanbanIT.jpg Cliquer pour agrandir.

Création d’éléments de travail

Dans Scrum, et dans iceScrum, on distingue la story de la tâche. La tâche est un travail qui contribue à la réalisation d’une story. Cette distinction est très utile dans les projets de développement, mais avoir ces 2 notions n’est pas nécessaire pour gérer des petits travaux orientés flux.

Dans notre approche KanBan, nous allons utiliser uniquement la notion de tâche. Tous nos travaux seront des tâches pour iceScrum.

Tâches en couleurs

Avec du management visuel, les couleurs ajoutent des informations, en plus de l’esthétique. Les travaux peuvent être organisés en catégories. Par exemple, pour un freelance qui gérerait ses travaux de cette façon, on aura : prospection, clients, ... et blog s’il en écrit un. Dans iceScrum, utilisons les features avec leur couleur pour définir ces catégories. On dispose de 8 couleurs, c’est largement suffisant.

On peut maintenant laisser les features en widget. Les tâches prendront ces couleurs selon leur catégorie.

Utilisation du bac à sable

Les tâches sont principalement créées dans le plan de sprint. Une autre possibilité, plus adaptée à la collecte de travaux divers venant de sources différentes, consiste à utiliser le bac à sable.

La façon de faire est simple avec iceScrum :

  • création d’un élément dans le bac à sable en associant la feature qui va bien,
  • placement du bac à sable dans le widget de gauche (il suffit de faire glisser le bouton du menu dedans) éventuellement redimensionné, avec le plan de sprint en vue principale,
  • drag and drop d’un élément de ce bac à sable vers la colonne à faire de la ligne Urgent.

Hop, la tâche est maintenant dans le plan de sprint avec la bonne couleur, correspondant à sa catégorie.

Utilisation du plan de sprint

Le plan de sprint est réduit à quatre lignes : urgent, standard, date fixe et intangible. Les tâches créées sont visibles dans la colonne A faire. Une fois le sprint lancé, on peut les déplacer dans la colonne En cours.

Tâche bloquée

Si une tâche ne peut pas se finir normalement, on peut le faire apparaître visuellement en la déclarant comme bloquée. De la même façon, avec la commande Bloquer, on peut mettre en évidence les tâches à faire qui ne peuvent pas démarrer.

Tâches finies

Comme ce tableau a une longue durée de vie (par rapport à un sprint classique avec Scrum), les tâches finies vont s’amonceler dans la colonne de droite.

Pour y voir plus clair dans les 2 autres colonnes, il est possible de masquer les tâches finies, à partir du titre de la colonne Fini.

Astuces pour les classes de service

Il est possible de changer un travail de classe de service. Cela se fait simplement en déplaçant le post-it correspondant dans une autre ligne.

On peut simuler visuellement la date d’un travail de la classe Date fixe en utilisant le reste à faire pour l’affichage de la date. Exemple : 15.08 signifiera que la date est le 15 août.

Indicateurs

Les indicateurs portant sur les stories ou sur les features ne seront d’aucun intérêt dans cette approche.



L’indicateur le plus intéressant est le burnup en tâches, qui montre 2 courbes : une pour le total de tâches et l’autre pour celle qui sont finies, actualisées tous les jours.

BurnupTaches.jpeg

Une mesure essentielle en kanban est le temps de cycle. iceScrum a déjà les outils permettant de le calculer. Pour une tâche, on conserve la date de chaque changement d’état.

Ces informations sont visibles dans l’aperçu rapide (quick look) et dans la vue détaillée de la tâche. Un nouvel indicateur pourrait être construit à partir de ces informations : c’est la carte de contrôle.

Evolutions dans iceScrum pour un meilleur KanBan

On a vu une utilisation très simple d’iceScrum qui peut convenir quand les travaux à suivre rentrent bien dans ce workflow basique.

Cette façon de faire est rendue possible par quelques unes des évolutions récentes d’iceScrum :

  • tâches en couleurs,
  • masquage à partir de la colonne Fini,
  • bac à sable en vue réduite,
  • redimensionnement des vues réduites,
  • glisser-déplacer du bac à sable pour une tâche urgente,
  • vue détail des tâches,
  • ouverture automatique du dernier projet ouvert,
  • ouverture automatique de la vue correspondant au menu le plus à gauche dans la barre de menus.

Quelques autres évolutions pourraient encore améliorer cet usage :

  • avoir les classes des service créées par configuration plutôt que de devoir les créer manuellement avec des stories,
  • pouvoir modifier le workflow,
  • sur les états à faire et en cours, afficher la limite de TAF en haut de la colonne.