Deuxième journée et bilan de Mix-IT 2014

Cette année, j’ai eu la chance de suivre les deux journées de la conférence Mix-IT 2014. Dans un précédent article, j’ai résumé la première journée. Je vais maintenant vous présenter le contenu de la deuxième, et dresser un petit bilan de ces deux journées.

La Keynote de mercredi était présentée par Rieul Techer, et traitait de laboratoires de biotechnologie communautaires : la paillasse. Développer des centres de recherche open source dans ce domaine est une idée originale qui semble déjà porter ses fruits. Un mouvement que je ne connaissais pas, mais qui ressemble au mouvement open source très connu en informatique, et qui par conséquent, devenait très parlant pour moi et tous les informaticiens présents à la conférence. C’était plutôt bien joué !

Mon planning

J’ai suivi 5 sessions lors de cette journée :

  • Prioritising ideas using Cost of Delay – Özlem Yüce
  • REX Le kanban va-t-il fluidifier notre chaîne ? – Florence Chabanois
  • Petit design pour grande humanité – Geoffrey Dorne
  • Coach like a wizard: Agile wisdom of Gandalf – Matthew Philip
  • Design meets Agile – Jens Otto Lange

Les aliens

C’est le nom que les organisateurs donnent aux speakers provenant d’un autre monde que celui côtoyé habituellement par les participants. Un bon prétexte pour nous présenter des personnes à la fois simples et brillantes, capables de nous faire réfléchir sur notre condition actuelle.

Nous avons tout d’abord eu le droit à une keynote surprise après le déjeuner : Bernard Xueref nous a présenté la filière du chocolat bio de la Frigoulette [lien vers http://www.chocolats-frigoulette.fr/] (Chocolaterie dans la Drôme). Outre le côté fort sympathique du personnage, et des vidéos hautes en couleur, c’était l’occasion de découvrir un projet où l’humain joue, une fois encore, un rôle primordial. Le succès de l’entreprise passe par la richesse humaine de ses entrepreneurs.

En fin de journée, nous avons pu suivre deux autres keynotes encore très orientées « diversité » :

  • Les communautés et le monde IT sous d’autres cieux : Horacio Lassey-Assiakoley nous a présenté la vie d’un développeur africain en s’appuyant sur sa propre expérience. C’était curieux de voir comme des choses, acquises pour nous, sont encore très fragiles chez eux. Par exemple, il peut se passer plusieurs heures sans connexion internet, et parfois même sans électricité. Quand je pense qu’au bureau, mes collègues râlent si on perd la connexion internet pendant plusieurs secondes… Mais, nous avons aussi des points communs, que je ne soupçonnais pas : le culte des diplômes agace là-bas aussi. Eh oui, être un développeur brillant et passionné ne requiert aucun diplôme ! (NDLR : vous pouvez remplacer « développeur » par ce que vous voulez dans la phrase précédente).
  • Programming Diversity : Ashe Dryden réclame plus de diversité dans nos communautés et nos bureaux. Selon elle, ce manque de diversité engendre un manque de créativité et de performance. Elle cherche à les expliquer, et nous propose d’ouvrir notre état d’esprit pour encourager la diversité autour de nous. Difficile de ne pas être d’accord.

Ce que je souhaite retenir

J’ai pris beaucoup de notes pendant ces différentes sessions, et il faut bien faire un tri dans tout ça. Alors voici ma petite liste de choses à retenir :

  1. Dans les entreprises, (presque) toutes les demandes reposent sur l’IT et (presque) toutes sont prioritaires
  2. Quand tout semble prioritaire, utiliser le modèle « cost of delay » pour voir les priorités autrement
  3. Affiner les priorités avec CD3, cost of delay divided by duration
  4. Scrum, Kanban et autre outils agile restent inefficaces sans l’adhésion de l’équipe et de l’entreprise
  5. En anglais, to design signifie à la fois dessiner et concevoir en fonction d’un plan, d’une intention.
  6. On se concentre trop souvent sur l’esthétique, et pas assez sur la fonction première (l’intention).
  7. Design n’est pas un adjectif : on ne dit pas d’un objet qu’il est design (ça ne veut rien dire). On peut parler du design d’un objet.
  8. Mouvement Jugaad : faire plus avec moins (innovation frugale).
  9. Une des clés du design : transformer les « comment ? » en « pourquoi ? »
  10. Le coach doit encourager l’équipe à prendre ses propres décisions, au lieu d’imposer les siennes, sinon l’équipe n’apprend pas.
  11. Le coach doit rappeler l’objectif du projet, et le processus mis en place pour y parvenir. Mais il doit aussi rester ouvert à des propositions de l’équipe.
  12. Le designer doit être le porte parole de l’utilisateur.
  13. On ne parle plus seulement du design d’une application, mais du design d’un service dans sa globalité (Exemple d’Amazon, de la commande à la réception).
  14. Étudier le modèle « Design thinking as a process ».
Slogan de Mix-IT

Slogan de Mix-IT

Bilan

Après deux journées aussi riches l’une que l’autre, il est difficile de résumer en quelques phrases un tel événement.

Tout d’abord je recommande à tous les professionnels de l’informatique de suivre des conférences comme Mix-IT, et ce, le plus régulièrement possible.
Je sais que les organisateurs sont friands de retours et critiques diverses pour améliorer encore le concept. Mais je vais avoir du mal à donner des conseils, tant je suis admiratif devant le travail accompli. Je crois que le challenge dans les années à venir, va être de conserver cette dynamique et cette simplicité, tout en évitant les pièges du succès, comme vouloir en donner toujours plus par exemple.

Le maître mot de cette année était la diversité, et je pense que c’est ce qui caractérise le mieux cet événement. Quand on a « la tête dans le guidon » sur des projets en continu, il est important de relever la tête de temps en temps, pour regarder ce qui se passe autour de nous. Voir comment travaillent d’autre équipes, comment évoluent les méthodologies (agile ou pas), comment sont perçus les autres métiers et comment les autres nous perçoivent (nous les geeks); tout ça fait partie de la culture IT. Personnellement, j’ai besoin de ça pour avancer, et pour me remettre en question, encore et toujours.
Donc, merci à toute l’équipe d’organisation de Mix-IT, merci aux speakers et aux « aliens » de se déplacer d’aussi loin et aussi nombreux, et plus globalement, merci aux participants pour la richesse des échanges.
Je vais maintenant reprendre ma (longue) liste de points à retenir, et je vais tâcher de les mettre en pratique ;-).

Et à l’année prochaine pour Mix-IT 2015 !

Mix-IT 2014 – première journée

Aujourd’hui j’ai suivi la première journée de la quatrième édition de la conférence Mix-IT. Et pour commencer la journée, Cédric Exbrayat et Romain Couturier se lancent dans une petite série de sondage :

  • qui était là à la première session de 2011 ?
  • à la session de 2012 ?
  • à la session de 2013 ?
  • qui était là aux 3 précédentes sessions ?

C’était l’occasion de voir l’évolution des participants dans le temps et aussi leur fidélité d’une année sur l’autre.
Personnellement je suis un adepte de la première heure et nous n’étions pas si nombreux que ça à être encore debout à la dernière question ;-)

Ensuite, comme pour toute bonne conférence, on enchaîne sur une Keynote.
Lionel Dricot (aka @Ploum) nous a transmis sa bonne humeur en nous présentant sa vision de la société dans les années à venir. Son extrapolation des marchés financiers après le BitCoin fut un grand moment. Merci à lui pour cette très belle entrée en matière (http://www.mix-it.fr/session/382/et-si-nous-n-etions-qu-au-debut-).
A noter que pour la première fois en quatre ans, tout le monde a pu assister au keynote, confortablement installé dans un fauteuil. C’était le seul reproche que l’on pouvait faire aux précédentes sessions Mix-IT, donc le grand amphithéâtre du CPE a permis de corriger ce défaut. Mes félicitations aux organisateurs pour cet effort.

Mon planning

J’ai suivi 5 sessions lors de cette première journée :

  • How to make better decisions, présentée par Olav Maassen de VersionOne,
  • Toyota Kata – habits for continuous improvements, présentée par Hakan Forss,
  • Visualization – what’s my brain got to do with it?, présentée par Mattias Skarin
  • Developing Great ScrumMasters, présentée par Angel Medinilla
  • L’amélioration continue au sein d’une équipe agile, présentée par Anne-Sophie Tranchet et Olivier Servieres
Developing great Scrum Masters

Developing great Scrum Masters

Ce que je souhaite retenir

Je ne vais pas entrer dans le détail de chacune des sessions, mais voici, dans les grandes lignes, ce que je souhaite retenir et mettre en œuvre à court ou moyen terme :

  1. quand il s’agit de prendre un engagement, il est préférable de repousser la décision au plus tard pour être sur d’avoir toutes les cartes en mains
  2. en fonction du niveau de risque de l’engagement, prévoir un moyen de faire retour arrière si cela ne se déroule pas comme prévu
  3. les Kata sont des habitudes à mettre en place pour se focaliser sur le processus
  4. les Kata permettent de muscler la mémoire
  5. dans les « improvement kata » il faut appliquer le cycle PDCA et ne franchir qu’un obstacle à la fois
  6. sur le plan visuel, le cerveau ne peut traiter qu’une petite partie des informations que lui envoie les yeux
  7. mise en application dans la communication visuelle : utiliser des images simples et si possible interactives (exemple : pour mettre en évidence une progression)
  8. le rôle de Scrum Master ne fait pas partie des principes agiles, c’est un concept complémentaire
  9. il ne faut pas confondre une équipe auto organisée et une équipe auto managée (c’est pas bien)
  10. pour devenir un grand Scrum Master, il faut appréhender trois dimensions indissociables : la technique, les concepts agiles et les humains
  11. un grand scrum master ne résout pas les problèmes rencontrés, il aide l’équipe à trouver les solutions par elle-même
  12. s’appuyer sur le mécanisme de pull request de Git pour valider les développements avant de les intégrer
  13. découper les sprint reviews en deux parties : la démo scénarisée et time-boxée ou tout le monde est convié, les questions/réponses pour ceux qui veulent plus de détails

Pour une journée, c’est déjà un bon bilan !

Cette journée s’est terminée par deux keynotes très différentes : la présentation d’une startup par sa créatrice (Magali Reme), et une présentation déjantée de deux membres de GitHub…

Retrouvez la deuxième journée et le bilan dans mon autre article.

Estimation des développements par comparaison

Je viens d’avoir une discussion avec mon fils, âgé de 10 ans, sur les voitures radio commandées. Voici un bref aperçu de nos échanges :
– Mon copain, il a une voiture RC (radio commandée) énorme : elle fait au moins 1m12 !
– 1m12, tu es bien sûr ? C’est grand 1m12 pour une voiture RC.
– Si si, je l’ai vue chez lui, elle fait 1m12… peut-être même plus !
– Hum, tu mesures 1m30, donc la voiture était presque aussi grande que toi ?
– (il réfléchit) Euh, non, quand même pas ! Plutôt 80cm alors…
– D’accord, la voiture était aussi grande que la largeur de la table ?
– Non, pas aussi grande que ça.
– La table mesure 80cm, donc la voiture mesurait moins selon toi ?
– Oui, elle devait faire un peu plus de la moitié de la table, entre 40cm et 50cm.
– D’accord, ça fait déjà une belle voiture en effet…

Dans sa tentative d’estimation, mon fils n’a pas volontairement exagéré la taille de cette voiture, mais par manque de repère, il a énoncé des nombres exubérants. Et le fait que la voiture l’ait impressionné a probablement décuplé son exagération. En lui proposant des éléments de comparaison, avec des mesures connues, je lui ai permis de trouver une mesure plus réaliste.

Une impression de déjà vu

Cela m’a rappelé un exercice pratiqué avec le Club Agile Rhône-Alpes de Lyon (CARA). C’était une séance que j’ai suivie au CARA, lors d’un atelier fil rouge de la saison 2011/2012. L’exercice consistait à estimer la taille de monuments ou la superficie de pays. Nous avons tout d’abord travaillé individuellement, puis en groupe. Les valeurs énoncées par les individus était un peu lancées au hasard, et rarement justes.
Celles avancées par le groupe étaient le résultat d’une approximation basée sur des comparaisons successives faites avec des repères apportés par différents membres du groupe. Par exemple, une personne affirme que la Suisse est plus grande que la Belgique. Une autre personne, d’origine belge, nous affirme que la Belgique fait environ 30.000 km². Le groupe est tenté de lui faire confiance. Une troisième personne avance que la Suisse n’est quand même pas deux fois plus grande que la Belgique. Cet argument arrive à convaincre le groupe qui en déduit une fourchette : la superficie de la Suisse est entre 40.000 et 50.000 km².
La bonne réponse étant 41.277 km², on peut dire que cette estimation n’est pas si mauvaise finalement.

Cet exercice du CARA et la discussion avec mon fils montrent à quel point l’exercice d’estimation peut être compliqué. Divers paramètres viennent corser la tâche : le manque d’expérience, l’absence de point de repère et les sentiments personnels. Ce dernier point n’est pas négligeable : mon fils a été impressionné par la voiture de son ami, et il lui a donné plus d’importance dans son esprit. De la même façon, un participant belge qui affirme connaitre la superficie de son pays est forcément plus convaincant.

L’estimation au quotidien

L’estimation « à vue de nez » (le fameux pifomètre) est un exercice à éviter si l’on veut un ordre de grandeur réaliste. Dans notre équipe, nous évitons les estimations en nombre de jours depuis longtemps maintenant. Nous préférons utiliser la méthode qui utilise les tailles de T-shirt (S, M, L, XL, XXL). Et nous n’estimons jamais un nouveau développement seul : il est estimé en même temps que d’autres projets et nous les comparons entre eux. Un ancien projet est parfois utilisé comme étalon (il sert de point de repère pour les autres).

Estimation par comparaison

Et surtout, nous estimons, ou plutôt nous comparons, en groupe ! Le groupe permet de contrer les paramètres cités plus haut :
– l’expérience n’est plus celle d’un individu, mais la somme des expériences des membres du groupe,
– chacun apporte ses points de repère,
– et les sentiments personnels (positifs comme négatifs) sont potentiellement modérés par le groupe.

Alors, prêts à estimercomparer ?

Références

Estimation agile le 10 janvier 2012
Liste des pays et territoires par superficie

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é

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

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

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.

Limiter l’encours pour fiabiliser la qualité

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 limiter l’encours
  • 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 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 chaîne (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…