Scrum est la méthode de référence lorsqu’il s’agit d’apporter un cadre à un projet en agile. Comme c’est un standard répandu, elle permet à l’équipe de ne pas trop se poser de questions sur leur organisation au lancement du projet.
Une fois que l’équipe est rodée à la méthode, nous avons :
Et traditionnellement, les équipes utilisant Scrum, ont aussi :
Nous utilisons cette méthode dans nos projets à OCTO, mais plusieurs choses nous gênent dans son application “by the book”. Et nous avons fini, avec l’expérience, par adapter nos usages en intégrant plusieurs principes issues de la méthode “Kanban” et tirer parti des qualités des deux démarches : nous passons à ce qui est communément appelé “Scrumban”.
Nous proposons une série d’articles présentant une façon de passer de Scrum à Scrumban et les avantages que ça peut apporter.
Cet article est le premier de la série et s’articule autour de l’adaptation du management visuel.
En terme de management visuel, même s’il ne fait pas partie initialement du framework Scrum, on retrouve généralement un tableau - appelé communément “board visuel” ou “scrum-board”.
Ce board visuel est constitué de trois colonnes, dans lesquelles chaque tâche va circuler :
Ce tableau est utile pour visualiser l’activité de l’équipe et prendre des décisions facilement. Il s’accompagne généralement d’indicateurs visuels (burn-down chart, déroulement du stand-up par exemple).
Ce tableau c’est la base, le minimum qui permet de suivre par une représentation visuelle ce qu’il y a à faire, ce que nous sommes en train de faire, et ce qui est terminé.
Une pratique courante est de suivre une logique par tâches : chaque User Story est découpée en “sous-tâches” ou “tâches techniques” pour représenter l’ensemble du travail qu’il faut réaliser pour terminer l’US.
Par exemple : développer l’IHM de tel écran, intégrer les règles de gestion, la partie gestion des données, ajouter les tests unitaires, etc.
L’objectif est qu’à la fin du Sprint, toutes les tâches aient été vidées dans la colonne “Fini”.
La première étape pour passer au Scrumban sera de passer d’une logique par tâches à une logique de flux.
La principale différence est que seules les US transitent du début à la fin du board, et on ne rend pas visible leurs check lists de tâches internes. L’intérêt est de ne pas ajouter des détails spécifiques à l’US qui nuiraient à la clarté nécessaire pour que l’équipe prenne des décisions efficaces au quotidien.
Dès lors, le process de l’équipe est modélisé de façon générale - et non spécifique par ticket - en définissant chaque colonne par laquelle l’US devra transiter obligatoirement.
Ajouter des colonnes dans le board visuel c’est formaliser visuellement les étapes réelles du processus par lesquelles les user stories passent.
Une colonne correspond idéalement à un type d’activité qu’un collaborateur peut effectuer seul ; le passage d’une colonne à une autre formalise le fait que l’US passe à un autre état et est prise en charge par une autre personne. Cette transition répond à une règle, un contrat formalisé et accepté par l’équipe, appelée “Definition of Done” (ou DoD).
Tous les projets sont différents, et à fortiori le process et donc les colonnes du board sont généralement spécifique à chaque équipe projet. Néanmoins, voici les colonnes qu’on a l’habitude de voir lorsque l’équipe étend le traditionnel “Todo - Doing - Done”
Avec les bonnes pratiques de développement (“craftsmanship”), la première colonne qu’on va vouloir ajouter, c’est la revue de code.
Lorsqu’un développeur a fini son développement, le code peut être revu par d'autres membres de l'équipe. Cette revue peut être réalisée en revue collective, ou plus simplement en revue par un pair (en synchrone, c'est à dire à deux devant l'écran, ou asynchrone, en utilisant un outil adapté).
Le bout de code de la fonctionnalité est développé dans un premier temps en local sur une seule machine. Puis, ce fragment est diffusé sur une base de code partagée avec les autres membres de l’équipe. De là nous pouvons constater que le bout de code fonctionne sur plusieurs machines.
C’est généralement une des DoD - “Definition of Done”, c’est-à-dire les règles qu’on se donne collectivement pour autoriser un ticket à passer d’une colonne à une autre, et qu’on affiche sur le board - pour passer dans la colonne “EN REVUE”, la fonctionnalité, ce bout de code, est maintenant partagé et visible de “tous”.
Il y a plusieurs objectifs dans cette démarche, la revue de code permet de :
En Scrumban, nous intégrons un maximum de choses au fil de l’eau. Et, comme pour la revue de code, plus un défaut est détecté tôt, plus il est rapide à corriger.
Donc la deuxième colonne qu’on va vouloir ajouter c’est la recette du PO au cours de l’itération. Là où la revue de code servira à détecter les défauts techniques, la recette PO permettra d’identifier les bugs fonctionnels sur l’US.
Le PO va donc valider les tests d’acceptances des différentes US dès que les développements et revues de codes seront terminés et que la fonctionnalité sera déployée sur la plateforme prévue à cet effet.
Si le PO détecte un bug pendant sa recette, il bloque le ticket, signalant à l’équipe qu’il y a une correction à faire en priorité. S’il s’agit d’un cas de test oublié lors de la rédaction de l’US, généralement la pratique est de créer un autre ticket qui sera priorisé par le PO.
Recetter au fil de l’eau apporte un énorme avantage en terme de réactivité.
D’une part, le développeur corrige plus facilement un bug si le contexte est encore frais dans sa tête. Par ailleurs, si la recette n’est faite que toutes les deux semaines, cela allonge le délai de correction des bugs pouvant aller jusqu'à plusieurs itérations (pour imager à IT N : détection du bug, IT N+1 : Correction du bug, IT N+2 : Recette de la correction).
En Scrum, le board est dédié à ce qui se passe pendant l’itération. L’intention est de se concentrer sur le coeur du développement.
Le cycle de vie des User Stories en amont de l’itération (“en cours de rédaction”, “prêt à développer” etc) est donc géré par le PO et n’est pas visible par le reste de l’équipe.
Voici un exemple simple de board Scrumban :
Cette - appelée aussi “Cadrage” dans certaines équipes - phase rend visible le processus de conception des itérations à venir et ainsi le stock d’US prêtes à rentrer dans la phase de développement.
L’ensemble des critères sur lesquels l’équipe s’accorde pour décider qu’une US est prête s’appelle le DoR, ou “Definition of Ready”.
En sortie de phase de conception, par exemple de mise en pratique, les US sont :
Les colonnes de la phase de conception vont formaliser les étapes nécessaires pour satisfaire le DOR. L’état d’avancement est visible pour toute l’équipe.
Toutes les équipes ont leur propre façon de fonctionner. On peut trouver des étapes variées selon les équipes car les contextes de projet sont différents et elles ont chacune leur façon de travailler. Ce workflow peut parfois être complexe.
Ici, “En développement”, “à revoir” et “à tester”, soit :
Lorsque l’US sort du Sprint, il peut arriver qu’on fasse une recette externe indépendante du rythme des sprints. Une fois validée et terminée nous pouvons procéder au déploiement en production de l’application.
Il est sans doute important de préciser ici que si l’un des incréments du sprint terminé est “défectueux” il coûtera plus cher à être corrigé que pendant la recette PO au fil de l’eau.
L’essentiel sur la façon de construire un board est qu’il correspond à la façon de faire de l’équipe, que tous les membres soient d’accord sur le processus et surtout sur les conditions pour passer d’une étape à la suivante. Si l’équipe qui change le board est susceptible de changer, si l’équipe évolue, le board est susceptible d’évoluer également.
Vous êtes sorti de la logique par tâches pour visualiser plus simplement le flux des User Story. Puis vous avez enrichi le classique "Todo-Doing-Done" pour détailler votre process. Enfin, vous avez élargi le board pour rendre visible les activités en dehors de l'itération.
L'équipe a ainsi réalisé les premières étapes pour passer de Scrum au Scrumban en adaptant le management visuel.
Ensuite ? Scrum propose un rythme itératif très précis et cadré. Le prochain article abordera cette thématique et les ajustements possibles avec Scrumban.