ScrumBan au jardin

ScrumBan au jardin

Quand je suis au jardin, il m'arrive, pendant que j'y vaque, d'avoir besoin d'un outil et de l'aller chercher. Souvent, je m'arrête en chemin, attiré par une fleur de ciste qui éclot ou par une mauvaise herbe qui dépasse, et je me mets à vaquer à autre chose. J'ai tendance à ne pas finir ce que j'ai commencé. La plupart du temps, cela n'a aucune importance, le jardin, c'est pour le plaisir, pas question de m'imposer quelque contrainte genre du Scrum.

Seulement, au printemps, il y a beaucoup à faire au jardin. Surtout quand on a accumulé ce qu'on pourrait appeler une sorte de dette technique potagère, qui fait par exemple que pour repiquer des tomates il faut d'abord désherber un carré envahi par le chiendent.

ScrumBan en tee-shirt Alors j'ai essayé le ScrumBan au jardin[1].

Au jardin je n'utilise pas de pesticide ou autre produit chimique, alors je n'allais pas agir à l'encontre du développement durable en gaspillant des post-it pour suivre mes travaux. J'ai donc utilisé iceScrum [2], que j'ai customisé pour mon usage. Je pense que cette utilisation peut aussi convenir à d'autres activités que le jardinage et peut s'adresser à de petites équipes distribuées.

Le but est de gérer un flux de travaux, sans grande cérémonie. Si on se réfère aux pages 25 et 26 de notre présentation Kanban & Scrum au ScrumDay, l'orientation de ce ScrumBan est nettement Kanban.

iceScrum a été commencé il y a longtemps, avant quʼon parle de Kanban dans les méthodes agiles. On parlait à peine de Scrum à l'époque. Mais lors de la migration en Grails en 2010, nous avons prévu d'intégrer des pratiques Kanban progressivement et il y a déjà de nombreuses possibilités de faire du ScrumBan.

Configuration

Avec le but suivi, on ne va utiliser qu'un sous-ensemble dʼiceScrum : le plan de sprint (qu'on pourrait rebaptiser tableau kanban) et le bac à sable. On n'utilise pas le backlog, et quasiment pas le plan de release. Puisqu'on utilise seulement quelques vues, autant masquer les autres. Cela se fait en faisant glisser les boutons. Nous allons essentiellement utiliser la vue Plan de sprint, alors mettons la à gauche.

Menus

Dans une approche orientée flux, les sprints ne nous intéressent pas beaucoup. Nous allons quand même créer un sprint dans iceScrum, mais de très longue durée. On pourra toujours modifier la date de fin de sprint plus tard, par exemple pour la repousser. Le sprint est créé à la création du projet ou plus tard, à partir du plan de release. On peut aussi le faire lors de l'assistant de création ou en accédant aux pratiques du projet.

Toujours dans les pratiques, il en est une, à la base du Kanban, que nous allons utiliser, c'est la limitation du travail en cours. Dans iceScrum, elle porte sur les tâches urgentes, qu'il faut demander d'afficher. Il convient de fixer une limite pour ces tâches dans l'état en cours. Pour commencer on peut par exemple, prendre 2 fois le nombre de personnes dans l'équipe.

Pratiques, TAF

Dans Scrum -et dans iceScrum- on distingue la story de la tâche, qui contribue à la réalisation d'une story. Dans notre approche ScrumBan, nous allons utiliser intensivement la notion de tâche, et avec iceScrum en particulier, la tâche urgente. Nos travaux seront des tâches urgentes pour iceScrum. Il est possible de créer des tâches urgentes directement dans la vue Plan de sprint.

Utilisation du bac à sable

Une autre possibilité, plus adaptée à la collecte de travaux divers venant de sources différentes, consiste à créer une story dans le bac à sable. Bien que nous ne souhaitions pas utiliser la notion de story, le bac à sable offre une ouverture vers le monde extérieur et des possibilités de discussion bien supérieures à celles du plan de sprint; l'élément qu'on y met est appelé, pour des raisons historiques, une story.

Une fois les «stories» entrées dans le bac à sable et après un éventuel dialogue avec les créateurs, le Product Owner peut les accepter comme ... tâches urgentes (cette possibilité n'est proposée que si un sprint est activé).

Utilisation du plan de sprint

Le plan de sprint est réduit à une seule ligne, celle des tâches urgentes, faisant apparaître la limite, définie précédemment, pour l'état en cours.

Les tâches créées sont visibles dans la colonne A faire. Une fois le sprint activé, on peut les déplacer dans la colonne En cours. Le principe fondamental du kanban est la limitation du travail en cours. La limite définie dans iceScrum interdit de la violer : l'ajout d'une tâche dans la colonne à faire, alors que la limite est atteinte, est refusé.

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.

Tableau Kanban

Avec cette approche, une estimation en heures des tâches est généralement inutile. Cependant, avec iceScrum il reste possible d'indiquer le reste à faire pour chaque tâche.

Comme ce tableau a une longue durée de vie (par rapport à un sprint classique avec Scrum), les tâche 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.

Un peu de Scrum

Ce ScrumBan conserve la possibilité d'utiliser quelques pratiques Scrum dans iceScrum : le rôle de Product Owner, la définition de fini pour indiquer la stratégie d'utilisation du kanban, la release, comme jalon. Un exemple est d'avoir une release de 3 mois avec un seul sprint, nécessaire pour avoir un plan de sprint kanbanisé.

Il reste bien entendu possible dʼajouter des stories dans le sprint, en conjonction avec cette approche centrée sur les tâches. il est aussi possible d'afficher 2 lignes dans le plan de sprint, en demandant l'affichage des tâches récurrentes.

Indicateurs

Les indicateurs portant sur les stories ou sur les features ne seront d'aucun intérêt dans cette approche. Même si on estime les tâches en heures, le burndown de sprint en heures ne sera pas significatif, puisqu'on est dans un contexte où il n'aura pas nécessairement une tendance à descendre. L'indicateur le plus intéressant sera le burnup en tâches, qui montre 2 courbes : une pour le total de tâches et l'autre pour celles qui sont finies, actualisées tous les jours.

Burnup en tâches

Une mesure essentielle en Kanban est le temps de cycle. On peut le voir globalement sur le burnup; on peut aussi le connaître pour chaque tâche, iceScrum conservant les dates de changement d 'état.

Workflow

Dans l'approche proposée ici, on a un workflow imposé, à 3 ou 4 états :

  • en attente dans le bac à sable (optionnel)
  • à faire
  • en cours
  • fini

Cela permet une utilisation très simple d'iceScrum qui convient quand les travaux à suivre rentrent bien dans ce workflow basique.

Les utilisateurs d'iceScrum, qui sont de plus en plus nombreux à demander du Kanban, retrouveront l'article complet sur le site communautaire.

Notes

[1] un grand merci à Fabrice pour le tee-shirt, j'attends la casquette...

[2] en local sans passer par le cloud qui consomme beaucoup