Tous testeurs !

Lors d’un précédent post, j’avais mentionné un principe Kanban qui me semblait très pertinent :

Le processus en amont doit éviter de fournir des produits défectueux au processus en aval.

Dans notre cas, le processus en amont est le développement, et le processus en aval est le service qualité. Le produit, c’est la nouvelle fonctionnalité qui vient d’être développée. Donc le produit défectueux, c’est une fonctionnalité buggée !
Plus il y a de bugs, et plus le temps passé au service qualité est long. Pour être plus précis, le problème est surtout qu’une même fonctionnalité passe plusieurs fois par le service qualité, et retourne autant de fois au développement.
Le point de vue des développeurs à ce sujet est souvent désemparant : "Ben, c’est le boulot des testeurs de trouver des bugs ! C’est normal qu’ils en trouvent !"
C’est vrai que chez nous, l’équipe qualité a une image de "trouveur de bugs".
On pourrait trouver ça logique, et mon article s’arrêterait là. Mais ce n’est pas très agile comme réaction, non ?

Comme le Kanban vient du monde industriel, c’est important de faire le parallèle entre l’industrie et le développement logiciel. Dans l’industrie, le service qualité est là pour vérifier, contrôler, mais n’est pas censé trouver des défauts à chaque fois. S’il en trouve, c’est qu’il y a une anomalie dans le processus amont, et cela doit rester exceptionnel. Or, dans notre équipe, pendant longtemps, si les "trouveurs de bugs" ne trouvaient rien, on se posait des questions…

Bref, pour en revenir au principe Kanban cité plus haut, j’ai imaginé ce qu’on pouvait faire dans notre équipe pour réduire le nombre de bugs détectés par l’équipe qualité. Pour trouver une solution, je suis reparti du problème de base qui est le suivant : quand les développeurs mettent au point une nouvelle fonctionnalité, ils finissent pas se focaliser sur les quelques points qui leur posent problème en phase de finalisation. Et bien souvent, une fois que ces derniers problèmes sont résolus, ils ont du mal à revoir la fonctionnalité dans sa globalité, surtout quand on parle de fonctionnalités complexes, ce qui est notre cas. Donc, au lieu de leur demander de refaire une passe globale, qui risque de ne pas être aussi globale que ça, nous avons mis en place des tests croisés. Un développeur qui n’a pas participé à ce développement va se charger de faire une passe de test globale avant de transmettre le projet à l’équipe qualité. Ce développeur, pas forcément très motivé au début se fixe progressivement deux objectifs :

1. trouver des bugs dans le développement de son collègue (et vu que ça tourne, cela devient un jeu)
2. fournir à l’équipe qualité un développement sans défaut

La somme des deux fait que cette passe est généralement plus approfondie qu’aurait pu l’être celle de l’équipe qualité.
Et ça marche ! Nous venons de finir une release de trois sprints et le volume d’anomalies détectées par l’équipe qualité est pratiquement tombé à zéro. Et le service qualité reprend sa fonction initiale, à savoir vérifier que ce qui est produit est conforme à ce qui a été demandé.

Pour formaliser tout ça, nous avons mis en place dans iceScrum une étiquette supplémentaire pour chaque story. Cette étiquette porte le libellé "Test DEV". Elle vient donc compléter les étiquettes "Test QA" et "Doc" qui nous permettent de garantir que notre processus est bien respecté. Et voilà comment dans notre équipe, nous sommes devenus tous testeurs !

Changement de peau !

Après quelques remarques sur la lisibilité réduite du thème un peu sombre utilisé jusqu’à présent, je me suis décidé à le changer. Alors voilà le nouveau thème : plus léger que l’ancien, et surtout, plus de vidéo inversée. Cela devrait reposer vos jolis yeux.

Qu’en pensez-vous ?

N’hésitez pas à me prévenir si celui-ci pose des problèmes avec votre navigateur ou votre tablette !

La revue de sprint

La revue de sprint (ou sprint review) est le moment de montrer au product owner ce que l’équipe a développé durant le dernier sprint. C’est un moment privilégié de partage au sein de l’équipe. Cet exercice peut paraître simple, mais il demande tout de même un minimum d’organisation. Voici donc mon modeste retour d’expérience sur notre façon d’appréhender ces revues.

Préparer le scénario

Et oui, une revue se prépare, et pas seulement 5mn avant pour vérifier si l’environnement de démo est opérationnel. Le périmètre de la démo doit être clairement identifié et les intervenants aussi. En général, nous avons une diapositive qui reprend la liste des nouveautés à montrer et pour chacune d’elle, le membre de l’équipe chargé de faire la démo. Cette diapositive sera utilisée comme fil rouge durant la démo.

Comme nous développons une application web, la démo se déroule sur un serveur dédié qui est accessible à toute l’équipe pendant la préparation. Ce serveur est ensuite utilisé pendant la démo. Et si tout se passe bien, il doit être utilisé après la démo par le product owner impatient de manipuler ces nouveautés par lui-même. Chaque intervenant doit donc préparer un mini scénario pour mettre en avant sa nouvelle fonctionnalité. Selon la fonctionnalité, cette préparation peut prendre entre 15mn et une heure. Parfois, c’est pendant cette préparation qu’on se rend compte qu’un cas a été mal traité, voire oublié. Il faut alors décider de ce qu’on en fait. En général, on écarte le cas du scénario et on l’ajoute comme correction ou évolution majeure du prochain sprint. (Claude Aubry avait fait un petit quizz sur son blog à ce sujet, il y a quelques temps).

Un petit conseil personnel : ne cherchez pas à cacher ce problème pendant la démo, le product owner va forcément poser la question. L’agilité recommande la transparence, alors soyez transparents ;-)

Donner du rythme

Pendant  la démo, le temps est compté. Et comme on veut respecter la timebox, il faut donner du rythme pour éviter de passer plus de temps sur une story que sur une autre. Et surtout, il faut être sûr d’avoir le temps de tout montrer. L’idéal est de préparer un minutage que le scrum master est chargé de faire respecter en jouant le rôle de time keeper. Parfois, on peut s’étendre plus longuement sur une story qui ne satisfait pas pleinement le product owner (par exemple suite à une incompréhension dans les spécifications). Dans ce cas, il faut noter les remarques qui seront formalisées en demandes d’évolutions ultérieurement. Il faut éviter de refaire les spécifications en plein sprint review. Le product owner peut être tenté de traiter le problème dans la foulée. Mais il vaut mieux passer à la story suivante et revenir sur le problème a posteriori.

Synthétiser les remarques

Juste après la revue, on fait un bilan en 5mn pour lister les remarques (de l’équipe et du product owner). Quand il s’agit de remarques pertinentes et constructives, on peut les formaliser en demandes d’évolutions. Ces demandes seront arbitrées en tout début du prochain sprint planning. Si elles sont jugées prioritaires, les demandes sont traitées dans le sprint suivant.

Les atouts de la revue de sprint

Les atouts sont multiples ! Tout d’abord pour les membres de l’équipe : la préparation leur permet d’inscrire le nouveau développement dans un scénario concret, et de prendre conscience de son apport. Présenter une nouvelle fonctionnalité à toute l’équipe est très gratifiant. Surtout quand le résultat impressionne le product owner (si si, ça arrive).

Ensuite pour le scrum master : en impliquant toute l’équipe on touche à la motivation, ce qui se ressent dans le rythme de développement. Et quand un développeur sait qu’il va lui même présenter le produit devant l’équipe, il ou elle va s’assurer de ne pas planter sa démo. Au début je faisais les démos moi-même et je trouvais que cela manquait de rythme, et de qualité. J’ai vu la différence quand j’ai proposé aux développeurs de faire la démo eux-mêmes. Le contenu est devenu plus riche et les démos de meilleure qualité.

Enfin, pour le prodcut owner, c’est un moment qu’il attend avec impatience. D’une part parce qu’il va voir ce qu’il a commandé. Et d’autre part parce qu’il va pouvoir échanger avec toute l’équipe sur les perspectives qu’apportent ces nouvelles fonctionnalités à notre produit. Les personnes chargées de documenter et de tester le produit sont aussi très intéressées par cette revue pour avoir une meilleur compréhension de ce qui a été développé.

La revue de sprint est donc une réunion assez particulière, car elle mélange la tension liée à une volonté de bien faire, et la détente d’une fin de sprint. C’est un moment que je trouve très agréable pour toutes ces raisons.

Et pour vous, comment se déroulent vos revues de sprints ? Si vous avez des trucs et astuces pour faire de meilleures revues, n’hésitez pas à les partager.

Le task board adéquat

Nous avons intégré Scrum dans notre équipe il y a maintenant plus d’un an. Cette méthode nous a apporté beaucoup de bonnes choses, comme du rythme, de la visibilité (pour nous) et de la transparence (pour les autres). Pourtant, il restait un point noir de mon point de vue de Scrum Master. Je veux parler du task board.

Nos premiers pas avec Scrum se sont faits en s’appuyant sur le logiciel Jira. C’est avant tout une solution de suivi d’incident, mais qui se définit aussi comme un outil de gestion de projet. Nous l’avons utilisé pour déclarer le contenu d’un sprint sous forme de tâches (c’est un type particulier de demande dans Jira) regroupées dans une version (notion déjà existante dans Jira). Cette solution nous a permis de lancer nos premiers sprints, ce qui était déjà très bien. Progressivement se modèle s’est enrichit avec la mise en place de User Stories sous forme de nouvelles fonctionnalités (au sens Jira). Ces fiches Jira servaient de tâches chapeau recouvrant un ensemble de tâches. A ce stade, nous avions donc le découpage suivant :

• une version Jira = un sprint
• une nouvelle fonctionnalité Jira = une story
• les sous-tâches d’une fonctionnalité = les tâches de la story

La limite de cette solution résidait dans l’aspect graphique, qui brillait par son absence. Ou, pour être tout à fait honnête, se limitait à un tableau statique. Ce n’était pas simple, dans ce tableau, de passer une tâche dans les différentes étapes du workflow. Il faut tout d’abord ouvrir une des tâches, puis cliquer sur un lien/bouton pour la mettre en cours. Et il en va de même pour la terminer. Et pour voir l’avancement, le tableau n’étant pas très parlant, on s’appuyait sur une vue de type camembert qui donnait une répartition par statut. Bref, la vision d’ensemble n’était pas au rendez-vous.

Nous avons donc testé une solution beaucoup plus graphique : le task board mural.

Notre task board mural a été improvisé sur les vitres de la salle de réunion qui nous servait pour le daily scrum. A coup de marqueurs effaçables à sec, nous avons organisé nos vitres en colonnes : à faire, en cours, à tester et terminé. Des lignes horizontales servaient à délimiter les user stories (pas très visible sur cette photo, désolé).

Task board vitré (merci Vincent pour la photo)

Un task board très classique, très graphique et aussi… très statique. C’était un peu la surprise de ce projet, mais les étiquettes ne bougeaient pas très régulièrement. Les membres de l’équipe se trouvant dans un open space alors que ce task board se trouvait dans une salle de réunion, j’ai l’impression que le lien ne s’est pas fait. Ce n’est peut-être pas la seule explication, mais c’est selon moi un élément important dans l’échec de cette solution.

Partant de ce constat, on pouvait prendre plusieurs orientations. Soit on revenait à Jira (pas graphique, mais vivant) soit on trouvait une solution qui apportait le côté graphique tout en restant suffisamment proche de l’équipe pour obtenir le côté dynamique. Au fil de mes lectures sur le sujet, j’ai trouvé une solution qui avait fait ces preuves dans d’autres équipes et qui me semblait très adaptée à notre problématique : un task board électronique.

J’avais déjà envisagé une telle solution en cherchant à compléter Jira. Depuis quelques versions maintenant, Jira propose un complément agile nommé GreenHopper. Ce complément me semblait très pertinent, mais son prix m’a vite découragé. J’ai donc réduit mon périmètre de recherche à des solutions gratuites et je me suis orienté vers iceScrum : iceScrum est la plateforme libre qui accueille vos développements agiles (ce n’est pas de moi, c’est leur slogan). C’est un logiciel qui se déploie sous la forme d’une application web sur un serveur d’application (Tomcat dans notre cas). Ce type de solution web est généralement conseillé pour des équipes distribuées. C’est en effet un bon moyen de partager un task board à distance. Mais sachant que nous pratiquons le télétravail, c’est aussi un bon moyen pour nous de garder le contact même depuis la maison. Premier bon point ! L’interactivité est un autre point important de cette solution : les automatismes viennent progressivement selon les personnes, mais le glisser/déposer d’une colonne à l’autre est tellement simple qu’on s’adapte très vite. La visibilité globale est très bonne : à chaque instant tout le monde peut voir où en sont les développements. Et lorsqu’une personne a terminé sa tâche, il peut très vite identifier où il peut aller prêter main forte. Nous avons utilisé des codes couleurs pour les tâches selon les compétences requises. On s’y retrouve plus facilement comme ça.

Notre task board

Finalement, je pense que l’apport le plus important, et pour ma part le plus insoupçonné, de cette solution se situe au niveau des indicateurs proposés en standard. Les burndown charts en heures, en stories, en points et ce pour le sprint comme pour la release sont autant d’indicateurs, qui me prenaient plusieurs heures par semaine quand j’avais le temps de le faire, et qui sont disponibles automatiquement dès le premier sprint terminé. Un vrai plus !

Burndown en heures

Alors avons nous trouvé le task board adéquat ? C’est peut-être encore tôt pour l’affirmer. Mais en tout cas, le task board électronique m’a convaincu.

Et vous, vous êtes plutôt task board classique ou électronique ? N’hésitez pas à partager votre expérience.

Un peu de kanban dans notre scrum

Nous développons actuellement une nouvelle version de notre produit. Ce développement est organisé en trois sprints de trois semaines.

Pendant le premier sprint, nous avons développé plusieurs stories en parallèle. Le nombre de points traités était élevé.

Lors du sprint planning qui à suivi nous avons préparé un volume de point équivalent, mais avec une liste de stories plus importante. On a le droit puisque ce sont les points qui comptent. N’est-ce pas ?
La deuxième sprint s’est déroulé de la manière suivante. Les développeurs ont pris de l’assurance et ont haussé le rythme. Mais dans l’euphorie, la qualité a baissée et le volume de nouvelles fonctionnalités étant plus important, nous avons du faire face à deux problèmes :
- la personne chargée des tests n’arrivait plus à suivre
- la personne chargée de la documentation et de la traduction n’arrivait plus à suivre

Alors que je constatais ce problème, j’ai suivi une conférence du Club Agile Rhône Alpes (CARA) dont le thème était le Kanban. Une très bonne présentation de Laurent Morisseau disponible ici sur slideshare. Deux pages ont tout particulièrement retenu mon attention :

J’ai alors pris conscience que Kanban apportait des éléments de réponse à nos problèmes :

• Ajuster l’utilisation de la capacité du système pour réduire le WIP
• Savoir travailler avec des goulets d’étranglement

Ce qui dans notre cas se traduit de la manière suivante : éviter de démarrer trop de projets en même temps et ne pas surcharger les postes test et la documentation.

En parcourant la toile, j’ai aussi trouvé une autre formulation du Kanban qui complète ces idées : le processus en amont ne doit pas surcharger le processus en aval.

Dans notre équipe, la solution a été mise en place sous la forme suivante. Tout d’abord, réparer nos erreurs en réduisant le volume de bugs : une semaine de debug avant de démarrer le sprint. Ensuite, une seule story à la fois, partant du principe qu’on ne peut pas en absorber plus en bout de chaine (test+doc). Donc une partie de l’équipe traite une story, alors que les autres s’occupent de stabiliser l’existant.

Les premiers résultats sont déjà très encourageant, même si le sprint n’est pas terminé. La rétrospective devrait nous en dire plus…

Le prochain point à régler sera selon moi est un autre aspect évoqué en Kanban sous la forme suivante : le processus en amont doit éviter de fournir des produits défectueux au processus en aval. Vous voyez de quoi je parle ?

Bref, on a encore du boulot !

Couleurs des anneaux olympiques

En suivant les devoirs de mon jeune collégien, j’ai lu une leçon dans laquelle on demande aux élèves de colorier une carte du monde en faisant le parallèle avec les couleurs des anneaux olympiques. Pris d’un doute, j’ai recherché des informations sur la toile et les premiers résultats m’ont vite donné raison.

Voici ce qu’on peut lire sur WikiPedia à ce sujet :

Les 5 anneaux entrelacés représentent les cinq continents unis par l’olympisme, et les six couleurs (en comptant le blanc en arrière-plan) représentent toutes les nations, car au moins l’une de ces couleurs était présente dans le drapeau de chaque pays, du moins à l’époque de sa création (1896). Ainsi ce drapeau est le symbole de l’universalité de l’esprit olympique. L’interprétation la plus courante associe un continent à chaque couleur des anneaux (le bleu représenterait l’Europe, le noir l’Afrique, le jaune l’Asie, le vert l’Océanie, et le rouge l’Amérique). Cependant, le musée olympique indique explicitement qu’il est faux de croire que les couleurs utilisées pour la représentation des anneaux soient associées à un continent particulier.

Cette dernière phrase a excitée ma curiosité et j’ai recherché sur des sites officiels. Tout d’abord sur le site France Olympique et ensuite dans un document du musée olympique. En effet, Pierre de Coubertin ne fait pas de lien directe entre la couleur des anneaux et les continents. Les cinq anneaux représentent les continents, mais les couleurs font références aux couleurs des drapeaux des pays.

D’ailleurs, je me dis que si Pierre de Coubertin avait souhaité faire un tel parallèle, peut-être aurait-il évité de choisir le noir pour l’Afrique et le jaune pour l’Asie… Mais je m’éloigne du sujet.

Donc, pour finir la petite histoire, nous avons glissé un mot au professeur de géographie pour avoir son avis sur la question. A suivre…

Gérer la maintenance applicative sans la subir

La mise en œuvre de Scrum dans notre service développement a été progressive. D’abord un produit puis un second.
Dit comme ça, cela peut paraître simple. Mais lorsque c’est la même équipe qui développe – et maintient – les deux produits, il faut savoir équilibrer la capacité en fonction des priorités des deux produits. Durant les dernières semaines, la maintenance s’est montré un peu envahissante. Comme à mon habitude quand je rencontre un problème, je suis le principe agile "Inspect & Adapt".

Inspection

Dans notre activité, on distingue quatre flux de demandes entrantes :

• les nouvelles fonctionnalités du premier produit
• les corrections du premier produit
• les nouvelles fonctionnalités du second produit
• les corrections du second produit

Les demandes de corrections, généralement liées aux incidents clients, ont quelques particularités :

1. elles sont imprévisibles
2. elles sont relativement urgentes
3. elles sont difficilement estimables

Nous avons commencé par réserver un nombre de jours par semaine pour traiter ces incidents clients. Chaque vendredi, on filtre et arbitre les incidents ouverts, et on prépare une liste d’incidents à traiter pendant les trois premiers jours de la semaine suivante. Et chaque semaine, une personne de l’équipe est dédiée au traitement de ces incidents (on fonctionne à tour de rôle). Lorsque ces incidents sont traités, la personne bascule son activité sur l’un des deux flux de développement.

Selon moi, ce choix de gestion comporte quelques travers. En effet, on qualifie cette liste chaque semaine parce que ces demandes sont imprévisibles et donc arrivent au fil de l’eau. D’accord, mais on sait aussi qu’elles sont difficilement estimables et pourtant on dresse une liste finie de demandes à traiter. Le caractère urgent (qui est très relatif) fait qu’on essaie de caser un maximum de demandes dans ces trois jours qui se transforment très souvent en quatre ou cinq jours. Dans certains cas extrêmes, la dernière demande qui n’a pas pu être terminée le vendredi se retrouve au planning de lundi, en parallèle d’une autre liste à traiter pour un autre membre de l’équipe.

Alors quand est-ce qu’on développe nos produits dans tout ça ?

Adaptation

J’ai lu et entendu beaucoup de choses sur la mise en place de Scrum au sein d’une équipe de développement. On parle surtout de Scrum dans le cadre de nouveaux développements : les user stories correspondent en effet à de nouvelles fonctionnalités qu’il faut organiser en sprints et planifier. La maintenance corrective est très rarement représentée. Et quand le sujet est abordé, la solution est souvent du type réservation de capacité.

A l’opposé, dans des équipes où la maintenance applicative est prédominante, j’entends plutôt parler de Kanban. Kanban est une méthode issue du monde de la production mais qui a pris une place importante dans les projets informatiques ces derniers temps. Le principe est simple : on réduit le nombre d’opérations en cours pour éviter les goulots d’étranglement.

Un compromis existe entre ces deux méthodes : le ScrumBan. Ce mélange semble très intéressant. Les tâches urgentes sont gérées selon le mode Kanban dans un cadre piloté par Scrum. Ce qui signifie dans notre contexte qu’on ne gère plus les demandes de corrections en les regroupant dans nos trois jours de FIX, mais qu’on maintient une file d’attente de demandes triées par priorité en bridant le nombre de corrections en cours à 1 par exemple. Cela empêche de se laisser déborder par ces demandes de corrections et garantit une plus grande place au développement de nouvelles fonctionnalités.

Pour l’instant, j’en suis à la théorie, mais j’ai bien envie de passer à la pratique dans notre équipe. La rentrée de Septembre me semble être la bonne période pour proposer cette nouvelle organisation (et j’insiste sur le terme "proposer" car ce doit être une décision de toute l’équipe pour que ça marche). D’ici là, si certains d’entre-vous ont déjà testé cette solution, vos retours d’expérience m’intéressent. Et surtout s’il y a des pièges à éviter…