Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

    — Norm Kerth

Voici la version française :

Indépendamment de ce que nous découvrons, nous comprenons et nous croyons sincèrement que chacun a fait du mieux qu’il pouvait, compte tenu de ce qu’il savait à l’époque, de ses compétences et de ses prérogatives, des ressources disponibles et de la situation du moment. http://www.fabrice-aimetti.fr/dotclear/public/traductions/pagesretros/retroPrimeDirective-fr.html

Cette formule me paraissait au début un rituel un peu vide de sens, qui n’aurait peut-être de sens que pour des Anglo-Saxons friands de telles formules creuses, et qui ne marcherait pas vraiment avec des Français.

Que pensez-vous de cette formule ? Est-ce que vous l’utilisez ? Uniquement avec des équipes novices ou bien aussi des confirmées ? Est-ce qu’elle fonctionne en France ?

J’ai récemment eu le plaisir de découvrir un billet de Martin Fowler sur ce sujet, et il met précisément le doigt sur ce qui me dérangeait au début avec cette formule :

This kind of advice generates in me a feeling of deep revulsion. Immediately it brings to mind images of motivational posters, school prayers, and two-minutes hate. Empty rituals, designed to quench curiosity and innovation, presided over by those whose minds are too empty to share my distaste.

En gros il relie cette formule aux divers rituels conçus pour étouffer la curiosité et l’innovation !

Mais il poursuit son billet en reconnaissant que ce type de formule peut avoir de réels bénéfices, d’autant plus qu’un mécanisme psychologique appelé “amorçage” (priming) est mis en jeu – et que ce mécanisme a une puissance assez effrayante sur nos cerveaux.

Donc il ne faut pas se priver de l’utilisation positive et puissante d’un tel rituel.

Après avoir présenté cette directive première, je fais aussi souvent référence à Deming, qui avait constaté que la majorité des problèmes organisationnels viennent des systèmes (l’ensemble des procédures, la structure hiérarchique, la culture, les relations entre entités de l’organisation) et non pas des gens qui travaillent dans le système.

Pour moi c’est l’essence de l’activité de rétrospective: trouver comment modifier le système dans notre zone d’influence pour améliorer notre situation. Et finalement la formule de Norm Kerth ci-dessus est une excellente introduction à cette recherche.

Nous avons un tableau d’une part pour suivre le travail du sprint en cours, comme ci-dessous. Le nouvel arrivant dans l’équipe peut facilement comprendre les diverses étapes à suivre pour un élément de backlog, car il voit les éléments bouger tous les matins lors de la réunion quotidienne. Le tableau permet aussi de capitaliser certaines expériences de l’équipe – par exemple nous avons récemment ajouté une colonne “PROFILING” pour nous imposer de rechercher systématiquement les fuites mémoires (une des causes de défauts critiques pour nos applications, que nous cherchons à éradiquer). Il y a alors peu de chances pour que le nouveau ne soit pas sensibilisé immédiatement au problème des fuites mémoires.

D’autre part, au dos du tableau ci-dessus, nous avons réparti le travail pour les sprints restants, ce qui donne une bonne visibilité pour les prochains mois.

Nous venons d’introduire un nouveau type de tableau, spécialement étudié pour intégrer un nouvel arrivant. L’idée vient de George Dinwiddie (voir Adding a new team member sur son blog), et nous l’essayons pour la première fois – cela semble une bonne alternative à notre ancienne habitude de désigner un mentor spécifique pour un nouveau équipier. Dans l’approche de George Dinwiddie, c’est plutôt l’équipe tout entière qui va jouer le rôle de mentor, tandis que le nouveau va pouvoir contrôler son rythme de progression.

Le principe consiste à faire une réunion d’équipe pour identifier toutes les tâches et activités nécessaires à l’intégration. On créée une fiche par tâche ou activité, et les volontaires pour y participer indiquent leurs initiales. Toutes les fiches sont ensuite reportées sur un tableau comme celui que nous avons fait hier :

Par exemple, la fiche encadrée en rouge correspond à la nécessaire activité de formation au profilage mémoire qui permet de détecter les fuites mémoires mentionnées plus haut.

Les fiches sont organisées en fonction de leur dépendances et de leur progression logique. Nous ajouterons de nouvelles fiches si nous découvrons des activités de formation nécessaire en cours de route.

Le nouvel arrivant est alors responsable de passer les fiches de TODO à IN PROGRESS puis DONE en fonction de sa progression, et de solliciter les volontaires.

Simple, non ? En conséquence, l’équipier se sent bien accueilli car il constate la bonne volonté de l’équipe pour l’intégrer.

Et vous, quelles sont vos idées pour intégrer de nouvelles personnes dans une équipe Scrum ?

Le caddying est une nouvelle étape dans notre mise en place de méthodes de développement agiles (SCRUM principalement), et c’est une tentative de privilégier « les individus et leurs interactions plutôt que les processus et les outils » (cf. le manifeste agile). Notre besoin était de trouver un moyen simple d’alimenter une dynamique d’amélioration continue. Au début nous nous sommes beaucoup appuyés sur une démarche très orientée processus. Toutefois il me semble que sans une réelle dynamique d’amélioration continue, une pratique « orientée processus » de SCRUM comporte un fort risque de délivrer régulièrement et de manière prédictible des produits médiocres. La qualité des produits et la performance des équipes ne viennent pas automatiquement ni magiquement en suivant plus ou moins à la lettre un processus. Au mieux, la qualité augmente un peu parce que vous accordez plus d’attention aux tests, tandis que certains gaspillages sont supprimés étant donné que SCRUM est naturellement lean, mais vous atteignez vite un plateau.

L’idée du caddying est venue de discussions sur ces thèmes avec François Beauregard qui nous avait expliqué ce concept de caddying mis en place dans Pyxis. Nous avons ensuite adapté la démarche à notre contexte, essentiellement en donnant un axe assez technique au caddying pour l’instant.

Notre caddying a certains points communs avec le mentorat, terme qui selon Wikipedia « désigne une relation interpersonnelle de soutien, d’échanges et d’apprentissage, dans laquelle une personne d’expérience, le mentor, investit sa sagesse acquise et son expertise afin de favoriser le développement d’une autre personne, le mentoré, qui a des compétences à acquérir et des objectifs professionnels à atteindre ». Mais il nous paraît plus sain d’éviter des termes chargés de sens vagues ou d’a priori comme coach ou mentor, qui requièrent de laborieuses clarifications (voir Managing vs. Coaching vs. Mentoring).

Aussi nous parlons simplement de caddy et de joueur (en référence à ces deux « rôles » dans le golf). Attention, le caddy n’est pas un simple porteur de clubs, c’est un joueur expérimenté qui connaît bien le parcours, et qui est indispensable même aux meilleurs joueurs mondiaux.

Ce billet décrit concrètement comment se passe le caddying dans notre contexte (édition de logiciels scientifiques), en présentant les thèmes sur lesquels nous travaillons, la mise en place concrète, les avantages et inconvénients identifiés après un peu plus de six mois de pratique.

Nos thèmes

Les thèmes « émergent » en fonction de plusieurs facteurs :

• besoins stratégiques de l’entreprise. Par exemple nous souhaitons améliorer la performance de nos applications scientifiques, et pour cela il serait utile d’avoir des développeurs mieux formés sur le développement multi-thread.
• envie d’un caddy de partager ses connaissances (par exemple ergonomie, ou encore GTD) ou d’approfondir un sujet qui le passionne (par exemple la programmation fonctionnelle)
• besoin de formation identifiés par certains joueurs (par exemple augmenter leur connaissances métier, ou mieux maîtriser leur ordinateur)

Nous avons actuellement les thèmes suivants :

• bureautique : cela permet à un joueur qui n’est pas informaticien de bénéficier des connaissances d’un développeur, pour mieux comprendre des aspects de l’informatique qui l’intéressent. Par nature le contenu est très varié, et complètement déterminé par les questions du joueur. Par exemple la dernière séance de 2H a été consacrée à maintenir le PC bien à jour avec Secunia Personal Software Inspector (PSI), sauvegarder des partitions avec Acronis True Image ou DriveImage XML, et partitionner un disque avec GParted (et pour cela il a fallu explorer la notion de partition).
• ergonomie : ici les joueurs apprennent des notions théoriques, puis passent nos logiciels au crible de critères d’ergonomie et réalisent des tests d’utilisabilité. Cela a des conséquences assez rapidement puisque leurs conclusions vont être implémentées dans les prochaines versions. D’autre part notre processus de développement sera modifié pour prendre en compte leur expérience et travaux, et cela va contribuer à augmenter la maturité de nos équipes sur la question, et augmenter la satisfaction des clients.
• tests agiles : un joueur étudie à son rythme le livre Agile Testing, a identifié les blogs des principaux gourous du test agile, et publie régulièrement des billets internes sur les aspects pertinents par rapport à nos pratiques (les quadrants du test agile, les tests exploratoires, les spécifications exécutables). Cette activité qui n’existait pas du tout auparavant contribue à augmenter notre maturité sur le test en général. Un autre joueur travaille sur la compréhension et l’implémentation d’un « presenter » dans une application réaliste, afin de nous faire progresser sur la question difficile des tests d’interfaces graphiques.
• programmation multi-thread : avec un caddy expérimenté, plusieurs joueurs travaillent en randori sur divers problèmes, comparent des solutions (notamment leurs performances – ça tombe bien, c’est un de nos thèmes stratégiques), et approfondissent de nombreuses notions (verrous, opérations atomiques, framework QtConcurrent, MapReduce). Pour l’instant tout cela est en C++, pour des développeurs C++, mais il serait intéressant plus tard d’impliquer d’autres développeurs qui eux travaillent en C#.
• programmation fonctionnelle (F#, Erlang)  :  Ici joueur et caddy apprennent ensemble les concepts de la programmation fonctionnelle. Ce thème est intéressant par ses applications à moyen terme : maîtriser la programmation fonctionnelle est certainement un bon moyen d’apprendre à écrire du code plus propre et plus facilement parallélisable (ça tombe bien, cela peut améliorer les performances). De plus, la programmation fonctionnelle s’adapte bien aux algorithmes « scientifiques ».
• GTD :  avec un caddy qui a appris tout seul la méthode, les joueurs apprennent à mieux s’organiser par la méthode Getting Things Done, de David Allen. Ici l’organisation est particulière, avec une longue séance initiale pour mettre en place la méthode (des m3 de papier inutile sont généralement éliminés à ce stade), et de courtes séances régulières pour ancrer la méthode.
• connaissances métier : plusieurs développeurs ont exprimé le besoin d’être mieux formés sur l’utilisation qui est faite des logiciels qu’ils développement, et donc ils travaillent régulièrement avec une de nos spécialistes « métier ». Ils ont choisi avec leur caddy de devenir capables de faire passer tout seuls les tests d’acceptance de leur logiciels sur nos instruments (c’est une bonne idée car ces tests représentent un goulot d’étranglement dans la livraison de logiciels par manque de personnes capables de les faire passer).
• agilité : Ici un joueur Scrummaster échange régulièrement avec son caddy sur la manière dont il pratique Scrum, les difficultés qu’il rencontre, les billets ou articles récents.
• lean : ce thème a permis notamment d’aider nos « product owners » à mieux gérer leur backlog et à mieux écrire leurs histoires utilisateur. Il a permis également de réorganiser notre laboratoire avec la méthode des 5S.
• lecture rapide : ici un lecteur moyen cherche à doubler sa vitesse de lecture, grâce à deux séances de travail par semaine, basées sur l’étude de livres comme Méthode de Lecture rapide et 10 Days to Faster Reading.

Nous avons également des caddies volontaires pour un thème « troubleshooting » et pour un thème « communication et facilitation » mais aucun joueur ne s’est proposé pour l’instant. Cela illustre le fait que le caddying ne marche que quand il y a rencontre entre un besoin et une offre de services !

Comment ça marche en pratique

Fonctionnement

Il n’y a pas de processus très formalisé pour décider des thèmes – en pratique il suffit que deux personnes se désignent comme caddy et joueur pour que le travail sur un nouveau thème puisse démarrer ! La principale contrainte est de rester dans des limites de temps raisonnable (20% de son temps par semaine pour un caddy, et de l’ordre de 2H par semaine pour un joueur).

Le temps ? C’est le mot-clé ! Souvent on me demande comment cette initiative (et d’autres, comme participer régulièrement aux coding dojos du CARA, ou encore notre journée « labo » régulière) est possible, comment on nous laisse faire tout cela au lieu de nous faire travailler à fond sur les projets en cours. Eh bien pour l’instant personne n’a démontré que ces initiatives ralentissaient la sortie d’un logiciel. J’ai une hypothèse là-dessus : comme les cartes de valeur (value stream mapping) dans le cas du développement logiciel montrent des ratios d’efficacité assez faibles, il est possible que ces initiatives consomment bien plus de temps dans les périodes d’inefficacité que dans les périodes d’efficacité. En quelque sorte, nous utiliserions le temps autrefois gaspillé pour nous améliorer ! Mais c’est une hypothèse qui reste à démontrer.

Le fonctionnement est très flexible, et laissé à l’appréciation du caddy et de ses joueurs. L’idée de départ était surtout une relation en tête-à-tête, mais en pratique plusieurs caddies travaillent avec un groupe de joueurs en même temps, surtout quand les caddies sont très demandés. Certains joueurs indiquent tout de même qu’ils auraient préféré un accompagnement individuel (afin de ne pas perdre du temps quand certains contenus ne les intéressent pas), mais nous n’avons pas toujours assez de temps de caddy (certains caddies ont d’autres rôles comme ScrumMaster, ou encore travaillent à temps partiel).

Quand il n’y a qu’un seul joueur, nous avons comme principe de laisser le joueur poser les réunions avec son caddy. Ainsi le joueur est complètement responsable du planning, et peut déterminer le rythme qui lui convient – charge au caddy de s’adapter. Quand le joueur tarde à poser les réunions, c’est peut-être signe que la relation s’essouffle et qu’il est peut-être temps de conclure.

La durée de l’accompagnement est donc libre également, et va de quelques semaines à plusieurs mois, en fonction de la densité du contenu exploré, et de l’énergie que caddy et joueurs veulent consacrer au thème.

Ce travail est assez exigeant pour le caddy qui doit souvent approfondir ses propres connaissances, et parfois préparer du matériel pédagogique. J’espère donc qu’il y aura plusieurs générations successives de joueurs pour un caddy donné, afin de plus rentabiliser le temps investi par le caddy. Cela paraît certain pour certains de nos thèmes (GTD, connaissances métier), pour d’autres thèmes c’est moins évident.

Nous avons également identifié un rôle de « meta-caddy », que j’ai décrit dans cet autre billet. Mais ce n’est pas un rôle très directif actuellement, car il nous semble plus important de laisser vivre le système et d’expérimenter, plutôt que de chercher à le contrôler.

Evaluation

Nous demandons aux joueurs de s’auto-évaluer en début et en fin de parcours (voire aussi en cours de route si c’est utile), selon différents axes qu’ils identifient avec leur caddy. Ci-dessous je montre certaines de ces auto-évaluations.

Voici une première illustration dans le thème GTD (c’est le caddy qui s’est lui même auto-évalué pour identifier les axes intéressants pour ses joueurs) :

Voici l’auto-évaluation d’un joueur dans le thème bureautique :

et pour un autre joueur dans le thème ergonomie :

Dans tous les cas il y a de nettes progressions sur certains axes, et d’autres axes avec peu de progrès, généralement parce qu’ils n’ont pas été suffisamment explorés pendant le caddying, souvent par manque de temps. Ces auto-évaluations permettent au joueur et au caddy de corriger le tir si besoin.

Avantages

Par rapport à une formation classique, cette formule présente l’avantage d’être « à la carte », sous forme de cours quasiment particuliers très adaptés à nos besoins, et peu couteux. Quand nous avons organisé des formations auparavant, elles sont souvent été jugées trop théoriques, avec trop de participants, ou pas assez reliées à notre travail.

Dans le même ordre d’idée, l’avantage du caddying est que tout ce que l’on apprend est immédiatement utilisable, et qu’il est possible d’avoir un suivi qui contribue à ancrer les nouvelles connaissances. En effet, même quand vous avez terminé votre travail avec un caddy, ce dernier reste disponible pour assurer un suivi à une fréquence différente, ou encore pour vous aider ponctuellement, même dans six mois.

Le caddying évite également les relativement longues interruptions que peuvent constituer les formations classiques, puisque le joueur ou le caddy ne sont indisponibles pour leurs équipes que peu de temps chaque semaine.

Le caddying ouvre aussi un espace qui n’existait pas auparavant pour expérimenter, faire des erreurs, réaliser des prototypes.

En plus de cet espace, le caddying permet d’acquérir un certain rythme de travail ou d’étude. En effet il est facile de s’intéresser à un nouveau sujet, mais difficile de s’imposer une discipline pour l’étudier suffisamment longtemps. Justement grâce aux réunions régulières avec une autre personne, le caddying contribue à plus de discipline. Cette discipline peut même être une raison suffisante pour démarrer un travail de caddying avec une autre personne, qui n’a pas nécessairement besoin d’être beaucoup plus experte que vous dans le domaine choisi – sa contribution sera surtout d’aider à maintenir la régularité de travail sur le sujet.

C’est aussi un nouvel espace pour partager des connaissances, réduire les effets silos entre projets ou équipes, mieux connaître ses collègues, faire de la veille technologique. Et parfois il encourage à tout simplement à aider ses collègues : ainsi des formes de « micro-caddying » apparaissent maintenant spontanément. Quand une personne demande à un collègue de l’aider une ou deux heures, le terme de caddying est maintenant employé !

Enfin le caddying offre une possibilité de meilleure reconnaissance à ceux qui sont intéressés par une carrière technique, à condition qu’ils puissent faire preuve de suffisamment de pédagogie.

Inconvénients, difficultés

Le principal inconvénient est que le caddying constitue une nouvelle source possible d’interruption pour une équipe, qui peut se trouver en attente de quelque chose d’un joueur ou d’un caddy. Même s’il s’agit d’interruptions courtes comme je le signalais plus haut, ce sont des interruptions fréquentes, qui s’ajoutent à d’autres sources : réunions, RTT, temps partiel. Quand cela est possible, il faut essayer d’organiser les rencontres joueur-caddy en dehors des plages horaires où toute l’équipe travaille ensemble ; par exemple le créneau 8h-9h est assez adapté dans certains cas.

Un autre inconvénient est le risque de fonctionner en « circuit fermé » : d’une part il n’y a pas beaucoup d’apport ou d’échange extérieur, comme cela peut être le cas quand vous suivez une formation inter-entreprise ; d’autre part, les joueurs les plus convaincus sont souvent caddies dans d’autres thèmes, ce qui peut finir par limiter l’arrivée de nouveaux joueurs.

En fait plutôt que de réels inconvénients,  le caddying présente surtout certaines difficultés ou challenges. Par exemple :

• il est difficile d’adapter les besoins des joueurs et les offres de services. Nous ne sommes pas forcément suffisamment compétents ou disponibles sur tous les thèmes souhaités. Ou encore les joueurs potentiels ne sont pas forcément intéressés par tous les services que des caddies aimeraient proposer.
• les caddies potentiels ne sont pas forcément très bons en communication ou en pédagogie. Ainsi ils peuvent avoir du mal à faire une bonne « publicité » pour leurs thèmes, à simplement donner envie à des joueurs de s’inscrire.
• il est difficile de bien communiquer sur les services proposés par les caddies (en général il n’y a pas de document type support de formation que l’on peut consulter à l’avance). Ainsi il peut être difficile de toucher des joueurs potentiels qui ne voient pas bien ce qui est proposé. Dans le même ordre d’idée, certains joueurs n’aiment pas trop le fait que le programme d’étude ne soit pas fixé à l’avance.
• il faudra trouver le moyen de faire perdurer cette démarche de caddying, afin d’éviter que le succès initial ne soit qu’un feu de paille. Pour le moment nous sommes dans une phase exploratoire, et le caddying fonctionne sur la base du volontariat de tous et l’exemple donné par les managers (plusieurs se sont inscrits comme joueurs). Est-ce que dans le futur le volontariat pur suffira, ou bien il faudra mettre au point des incitations ou des obligations ? 

Enfin le caddying n’a pas vocation à résoudre tous les problèmes. Il est très adapté pour permettre à 2 ou 3 personnes d’acquérir de nouvelles compétences ou connaissances sur une durée de 3-6 mois au minimum, mais il n’est sans doute pas le meilleur moyen pour des  groupes plus importants, ou pour « monter en compétences » très rapidement. C’est pourquoi le caddying ne vise pas particulièrement à remplacer des formations classiques, à l’extérieur de l’entreprise.

Conclusion

J’ai donc présenté notre implémentation concrète d’un système particulier de mentorat, que nous appelons caddying. De tels systèmes ne sont pas nouveaux, car de nombreuses entreprises en ont déjà mis en place. Toutefois les systèmes existants semblent souvent viser uniquement les managers ou leaders, afin de faciliter ou accélérer leur carrière. Ainsi il est possible que notre particularité soit d’avoir mis en place quelque chose qui soit applicable à tous les employés, indépendamment de leur position hiérarchique. Dans ce cas ce serait une bonne application du manifeste agile que je citais en introduction !

Merci aux caddies qui ont pris le temps de relire et corriger ce billet, ainsi qu’à Laurent Tardif pour un échange sur ce thème.

Un petit bémol toutefois sur le fait qu’il faut absolument payer l’inscription par un virement international (enfin, pour les Français) : un de mes collègues a eu la désagréable surprise de découvrir que sa banque prenait en commissions diverses la moitié du prix de l’inscription ! Toujours pour les Français, sachez que nos amis Suisses sont moins fanas de la carte de crédit que nous, et qu’il vaut mieux avoir de l’argent suisse pour régler le parking situé sous le Geneva Business Center (environ 20 CHF pour la journée).

La conférence en chiffres :

• deux « pistes parallèles » dans un auditorium et une grande salle
• douze sessions en tout, dont 3 en anglais
• une douzaine d’orateurs
• environ 95 personnes présentes (100 places maximum étaient possibles).

Comme a fallu faire des choix entre les sessions en parallèle, j’ai assisté à 6 d’entre elles, et parmi celles-ci, voici les 3 que j’ai préférées :

1. Apprenez les techniques de coaching avec le magicien d’Oz, par Portia Tung et Pascal Van Cauvenberghe.
2. Test automatiques autour d’un IHM, par Didier Besset.
3. Les 7 péchés capitaux du développeur, par Freddy Mallet.

J’étais très content de rencontrer enfin Portia et Pascal que je ne connaissais que virtuellement, ayant déjà utilisé avec succès certains de leurs jeux comme I’m not a Bottleneck! I’m a Free Man! J’ai bien apprécié la découverte d’un nouveau jeu, au contenu très utile puisqu’il consiste à travailler sur l’art de poser des questions et sur le co-coaching (ou peer coaching). Portia a tout d’abord captivé la salle avec un petit conte :

puis nous avons travaillé par groupes de 3 :

(ils sont 4, mais ce sont les autres orateurs, ils ont du avoir une dérogation). Voici une photo de l’ensemble de la salle :

Vous pouvez télécharger tout le support du jeu (intitulé The Yellow Brick Road) ici. Et surtout, vous pouvez lire cette mise en application immédiate au retour de la conférence : Une rétrospective pas comme les autres. Ce retour d’expérience tout frais montre bien l’intérêt d’une telle session dans une conférence, et plus généralement montre bien l’intérêt de nous enseigner régulièrement de nouvelles compétences non techniques (nous, les gens qui ont une formation technique). J’espère qu’il y a aura une session sur ce thème dans notre conférence agile à Grenoble en 2010. A suivre !

Le retour d’expérience sur les tests d’IHM m’a également beaucoup intéressé, et correspond bien à ce que j’attends d’une telle conférence : du concret, du factuel, des détails sur une application difficile mais compréhensible par tout le monde (contrôle du trafic aérien), du code, des idées à expérimenter au travail (la notion de primitives de tests), une piste théorique (les DSLs et les idées de Martin Fowler).

  (Didier Besset qui présentait le retour d’expérience des tests IHM – et le nouveau T-shirt des organisateurs).

Enfin, Freddy Mallet nous a présenté SONAR, un outil d’inspection continue

qui permet de chasser les « 7 péchés capitaux » du développeur :

J’aurais préféré voir une plus longue démonstration « live » de l’outil, et moins de transparents, mais le sujet était intéressant et répond bien à mes préoccupations (j’ai fait pas mal d’expériences avec NDepend ces derniers temps). J’ai également apprécié le témoignage de l’orateur qui met en pratique ses idées, en continuant à toujours écrire des tests en premier pour le développement de son outil, et ce bien qu’il subisse une forte pression (il a monté sa propre entreprise). Hélas Freddy m’a confirmé que son outil ne permettait pas d’analyser le code Delphi, et c’est bien dommage pour nous qui avons une base de code importante dans ce langage.

J’ai moins accroché avec les autres présentations que j’ai suivies, car elles étaient plus éloignées de mes centres d’intérêt. Les 3 sessions ci-dessus correspondaient mieux à ce que j’attends de ce genre de conférences :

• sessions sur des outils non techniques (communication, coaching, développement de compétences)
• sessions sur des outils techniques permettant de réduire la dette technique, améliorer la qualité du code.
• retours d’expériences détaillés sur des logiciels de taille réaliste.

Voici les votes informels sur les sessions :

Vous devriez trouver prochainement les diverses présentations sur le site http://www.xpday.ch/. Certaines sont déjà disponibles sur les sites de leurs auteurs, par exemple celle de Thierry Cros est ici : XpDay Suisse : gouvernance agile.

Dernière minute : le même Thierry vient de publier XpDay Suisse : impressions de voyage.

Merci à Sylvain Labussiere pour l’accès aux photos de la conférence, à Luc Jeanniard pour la relecture du billet et certaines photos.

Voici quelques métriques que je viens de réunir dans différents contextes :
- secteur media, sur un projet avec 3 développeurs qui dure depuis 9 mois on a plus de 100 scénarios de test GreenPepper
- secteur media, plusieurs équipes de 3 développeurs, ils ajoutaient en moyenne 5 tests fitnesse par itération de 2 semaines, soit plus d’une centaine de tests par an
- encore media, équipe de 7 développeurs avec 2 MOA à plein temps et qui font des tests GP depuis 18 mois : 8743 assertions (dans 122 pages) soit 153 assertions en moyenne par itération d’une semaine
- secteur assurance, une équipe de 2 développeurs + 1 MOA sur 6 mois pour tester une plateforme de services (20 web services) : 200 pages de tests Fitnesse et 5000 assertions. Un retour d’exp complet est disponible ici : http://usi2008.universite-du-si.com/WebcastArchi.aspx (session A10)
- secteur open source , octopus microfinance et son harnais de test GP disponible ici : http://wiki.octopusnetwork.org/display/OPUS/Home

Dans ces mêmes commentaires, Louis Pellerin ajoutait :

De mon expérience avec GreenPepper pour le produit Talia que nous développons (un produit sans réelle interface utilisateur), nous avions une proportion d’environ 80 spécifications exécutables (GreenPepper) pour plus de 200 tests unitaires et intégrés (mstest).

Il y a aussi le billet Pendant ce temps-là, à Boulogne., d’Emmanuel Gaillot, qui donne les chiffres suivants :

L’équipe compte actuellement 6 programmeurs (dont le responsable produit), 2 graphistes, 3 modérateurs et une poignée de stake-holders. Tout ce monde travaille dans un ancien atelier réhabilité à Boulogne, dans une même pièce. L’application web est développée en TDD (à l’exception des vues). Elle est actuellement couverte par 951 assertions, réparties sur 563 tests automatisés qui s’exécutent en 35 secondes environ.

En 4 mois de boulot, nous avons consommé 150 pages de flipchart, 15 marqueurs, 100 fiches cartonnées, 2000 post-its de couleurs et tailles variées, 10 stylos feutre, 5 stylos bic, 2 bloc-notes, 50 feuilles A4, un playmobil et 300 viennoiseries.

Si vous connaissez d’autres billets ou articles du même style je suis preneur.

En attendant voici quelques informations du même type sur l’un de nos projets : 38 sprints de développement (durée 3 semaines), une équipe de développement de (en moyenne) 4 développeurs et 1 chimiste testeur/représentant des utilisateurs (plus 1 ScrumMaster, et 1 Product Owner).

L’équipe a réalisé un total de 837 tests :

• 469 tests unitaires 

• 235 tests d’intégration

• 132 tests fonctionnels (81 manuels et 51 automatiques)

ce qui représente 84% de tests (unitaires + intégration) et 16% de tests fonctionnels, mais encore 90% de tests automatiques. Les tests fonctionnels manuels coûtent seulement 2-3 heures de validation à l’équipe, qui peut donc les jouer plusieurs fois par sprint si besoin.

Tous ces tests sont le résultat d’un effort permanent de toute l’équipe : TDD, automatisation des tests fonctionnels, « refactoring » permanent des tests fonctionnels.

Les tests unitaires et d’intégration représentent environ 3000 assertions. Ils sont exécutés avec DUnit.

Voici un graphique montrant l’évolution de la répartition des tests au fil du temps, sur les sprints les plus récents :

Voici la légende et la répartition finale (où j’ai regroupé tests fonctionnels automatiques et manuels en une seule catégorie).

Cette répartition paraît assez satisfaisante : on a bien une pyramide de tests, il y plus de tests unitaires que de tests d’intégration, et plus de tests d’intégration que de tests fonctionnels. D’autre part le nombre de tests fonctionnels manuels est resté sous contrôle, et c’était l’un des objectifs de l’équipe de pouvoir exécuter tous leurs tests manuels en moins d’une demi-journée ; le graphique montre d’ailleurs qu’en cours de route, certains tests manuels ont été remplacés par des tests automatiques, afin de ne pas se laisser déborder par les tests manuels.

C’est un projet qui compte environ 180.000 lignes de code Delphi. C’est un projet de taille moyenne pour nous, nous avons des projets beaucoup plus petits, et de plus rares projets 5 ou 6 fois plus gros.

Sur ce projet, comme sur un projet précédent d’ailleurs, nous avions décidé de maîtriser la complexité cyclomatique (nous étions motivés par la constatation sur d’anciens projets que des méthodes de complexité 50 voire 70 étaient de véritables nids à bugs critiques). Le graphique ci-dessous montre sur les sprints les plus récents l’évolution du nombre total de méthodes (en bleu), et l’évolution du nombre total de méthodes dont la complexité cyclomatique est supérieure à 7 (notre limite). Sur ce projet, nous avons donc programmé plus de 6200 méthodes de complexité inférieure à 7. Toutefois nous tolérons l’existence de quelques dizaines de méthodes complexes car le bénéfice de baisser leur complexité ne nous semble pas assez important. Mais ces méthodes complexes ne représentent que 0.6% du nombre de total de méthodes !

La définition de la limite acceptable (7 dans notre cas) peut donner lieu à bien des débats, et vous trouverez fréquemment des recommandations comme 15 ou 25. Mais à mon avis, même une limite de 7 vous donne bien des opportunités de coder des bugs, car cela vous laisse libre de coder suffisamment de if, while, for et conditions booléennes tous ensemble. Donc pour moi il est important de s’imposer une limite assez basse pour vraiment tirer parti de la réduction de la complexité.

Ces données illustrent deux axes sur lesquels nous nous sommes bien améliorés ces dernières années : maîtrise des tests, maîtrise de la complexité du code. Et qu’en est-il de la satisfaction des clients sur ce projet ? Eh bien c’est assez embarrassant, je ne sais pas encore quelle est la réponse ! En effet, en nous améliorant, nous avons essentiellement déplacé le goulet d’étranglement dans d’autres secteurs de l’entreprise qui actuellement peinent à absorber notre production, et à livrer leur part du travail (pourtant ils ont vu passer plus de 30 livraisons qui fonctionnaient, ils n’auraient pas dû être surpris, non ?).

Après tout, rien de très surprenant, c’est en gros ce que prédit la théorie des contraintes.  Mais cela indique que dans de futurs projets, tout en continuant à nous améliorer sur d’autres axes (comme travailler avec des exemples et pratiquer le BDD), il va falloir travailler à introduire de l’agilité dans tous les secteurs qui contribuent à la livraison d’un produit chez des clients ! Nous atteignons peut-être les limites de ce que nous pouvons faire avec des améliorations locales.

Merci à mes collègues Sandrine et Jean pour leur aide dans la collecte des données.

Le but du dojo est de faire exécuter un scénario réaliste comme celui-ci dessous, que j’avais mis au point avec une collègue chimiste :

Ce qui nous intéresse c’est qu’il faut implémenter un calcul de régression linéaire,  et pour cela il sera probablement nécessaire de pratiquer un peu de TDD en plus du BDD ci-dessus, et c’est pourquoi l’exemple peut nous montrer comment s’articulent BDD et TDD.

Dans la séance du 5 janvier j’avais proposé un scénario simplifié, afin de prendre en main l’environnement de développement (j’utilise RubyMine, mais on peut aussi travailler directement en ligne de commande avec Cucumber).

L’idée était d’aligner tous les points sur une droite passant par zéro, comme cela on pouvait trouver l’équation de la droite sans la régression linéaire (dans un premier temps), et donc juste se familiariser avec l’IDE et les diverses notions (les scénarios, le pont, le code métier).

J’avais aussi un deuxième scénario pour vérifier qu’on savait bien faire des vérifications sur les nombres flottants :

Pas très excitant, mais important en calcul scientifique !

Et le troisième scénario proposait une droite qui ne passait plus par zéro :

Et justement le dojo s’était arrêté sur l’échec de ce dernier test – notre calcul de l’équation était vraiment trop simpliste :

D’après la rétrospective de la session, ces scénarios simplifiés n’étaient pas forcément une bonne idée, car ils nous ont un peu éloigné de l’objectif d’aller vers du TDD. Il n’est pas simple dans l’animation des dojos de trouver le bon équilibre entre pédagogie et bonne progression !

Ils nous ont tout de même permis de mettre au point le pont suivant vers le code métier, pont qui sera utilisé tel quel dans la session de demain :

Given /^the calibration mode is R=f\(Q\)$/ do
   #nothing
end

Given /^a calibration curve for component CO2 with the points:$/ do |table|
  @curve = CalibrationCurve.new  
  table.hashes.each do |hash|
    area = hash["Area"]
    concentration=hash["Concentration"]
    @curve.ajoute_points(area.to_f, concentration.to_f)
  end
end

Then /^the computed concentration for area (.*) should be (.*)$/ do |area, expected_concentration|
  calcul_concentration = @curve.calcul_concentration(area.to_f)
  calcul_concentration.should be_close(expected_concentration.to_f, 0.001)
end

When /^the slope should be (.*)$/ do |expected_slope|
  @curve.calcule_slope.should == expected_slope.to_f

end

When /^the ordinate at origin should be (.*)$/ do |expected_ordinate|
  @curve.calcule_ordinate.should == expected_ordinate.to_f
end

When /^the following table should be valid:$/ do |table|
    table.hashes.each do |hash|
    area = hash["Area"]
    concentration=hash["Concentration"]
    @curve.calcul_concentration(area.to_f).should == concentration.to_f
  end
end

Alors à demain à l’ENSIMAG salle 206 de 12 à 14h pour la suite !

Par conséquent, il me semble que travailler sur un tel logiciel est intéressant pour apprendre le BDD, car justement nous aimerions éviter de « polluer » les scénarios par des concepts purement techniques comme des questions de base de données. Le challenge est donc de parvenir à exprimer les scénarios avec des mots d’utilisateur et pas du jargon informatique.

Dans ce billet je vais détailler mon point de départ et illustrer les premières leçons que j’ai tirées des discussions. Bien sûr cela reste un exemple « jouet » mais je parviendrai peut-être à en faire une application complète dans quelque temps.

Je suis également passé à la rédaction de scénarios en français, ce qui est possible en Cucumber (tapez la commande cucumber -i18n fr pour avoir les équivalences).

Mon point de départ était la fonctionnalité suivante :

Les discussions ont fait apparaître que « qui veut perdre du poids » n’avait aucune influence pour le moment (je voulais souligner que cela pourrait avoir de l’importance dans de futures fonctionnalités, mais cette information superflue ici rend simplement plus difficile la compréhension de la fonctionnalité). Donc une leçon à retenir : ne pas « sur-spécifier » !

J’ai ensuite écrit de très petits scénarios comme :

ce qui m’a permit ensuite d’écrire un scénario couvrant une journée complète (les lignes commençant par # sont des commentaires) :

et ainsi de suite. Cela m’a permis d’arriver un scénario vérifiant la fonctionnalité « connaître le nombre total de calories pour la journée ».

Les petits scénarios m’ont été utiles pour mettre au point le code derrière tout cela en faisant de petits pas (tout comme quand on pratique le TDD). Mais ils contribuent à l’impression de « verbosité excessive » que mes scénarios ont donné durant la présentation, donc il faut surement accepter de les supprimer une fois que leur intention a été capturée par ailleurs dans le scénario final.

J’ai ensuite travaillé sur une deuxième fonctionnalité :

Fonctionnalité que j’ai souhaité vérifier de la manière suivante :

Un point qui a posé problème est que je ne vérifie pas la totalité du contenu de la table des aliments – cela ne me paraît pas nécessaire. Mais mes attentes sont peu claires pour le lecteur, et pour lever l’ambiguïté il aurait sans doute suffit d’écrire « la table des aliments contient notamment: ». Il faut donc rédiger les vérifications avec beaucoup de précision et de clarté.

Un deuxième problème est que mon scénario est bien plus long que la copie d’écran ci-dessus – en effet j’avais à nouveau couvert avec mes exemples une journée complète. Ce qui est inutile vu que le calcul pour la journée était déjà couvert par la vérification de la fonctionnalité précédente ! Donc une autre leçon à retenir est de ne pas « sur-vérifier ».

La troisième fonctionnalité consistait à travailler à partir d’une table pré-remplie :

etc.

Mes scénarios ci-dessus ont suscité un vif débat, car ils semblent représenter un effort démesuré par rapport au volume de code qui est testé derrière. En effet il s’agit d’implémenter une simple règle de trois, de parcourir des listes, d’utiliser une table de hachage. Je pense que la critique était justifiée, et que mes scénarios auraient pu contenir moins d’information, mais que cela ne remet pas en cause l’intérêt du BDD et l’intérêt de travailler avec des exemples (ces derniers méritant certainement d’être réhabilités dans nos processus de développement logiciel – voir mon billet précédent).

Un autre élément de débat était de savoir comment se positionner par rapport à une éventuelle interface graphique. Etant donné la manière dont j’ai écrit et réalisé les fonctionnalités, l’application n’existe pas encore, je suis simplement en train de mettre au point une bibliothèque de classes, indépendamment de la manière dont elles seront ultérieurement présentées à un utilisateur. Cette approche était confortable par certains, mais d’autres auraient préféré travailler à partir d’une interface graphique (le risque étant de mettre au point un bon modèle métier bien testé, mais de ne pas satisfaire les utilisateurs qui veulent voir très vite une interface graphique).

Je pense que le schéma suivant de DDD Vite Fait illustre l’endroit où j’essaie de me placer pour l’instant – mes scénarios concernent le domaine, et pas l’application, ce qui est source de confusion :

Pour finir ce billet, au cas ou vous soyez curieux de ce qu’il y a derrière (c’est généralement le cas quand je présente les scénarios), je vous montre le code que j’ai écrit pour le pont entre les scénarios exécutables et les classes du domaine :

# encoding: UTF-8

require 'F:\ruby\cucumber\comptageCalories\ComptageCalories\compteur_calories.rb'
require 'F:\ruby\cucumber\comptageCalories\ComptageCalories\table_aliments.rb'

Before do
  @compteur = CompteurCalories.new
  @table_aliments = TableAliments.new
end


When /^le nombre total de calories devrait être (.*)$/ do |calories|
  #puts @compteur.total_calories
  @compteur.total_calories.should be_equal calories.to_i
end

When /^une table des aliments vide$/ do
  #rien
end

When /^la table des aliments contient:$/ do |table|
  # table is a | confiture | 1 | cuillère à café | 30 |
  table.hashes.each do |hash|
    reference = @table_aliments.reference(hash["aliment"])
    reference.quantite.should == hash["quantite"]
    reference.unite.should == hash["unite"]
    reference.calories.should == hash["calories"]
  end
end

When /^je mange (\d+\.?\d*) (.*) (de\s+|d')(.*\w|.*%) \((\d+) (.*) valant (.*) calories\)$/ do  |quantite_dans_unite,unite1, de, nom_aliment,reference_dans_unite,unite2,reference_en_calories|
  @table_aliments.ajoute(nom_aliment, reference_dans_unite,unite2, reference_en_calories)
  @compteur.ajoute(nom_aliment,quantite_dans_unite, reference_dans_unite, reference_en_calories)
end

When /^je mange (\d+\.?\d*) (.*) (de\s+|d')(.*\w|.*%)$/ do |quantite_dans_unite,unite1, de, nom_aliment|
     reference = @table_aliments.reference(nom_aliment)                   
     reference_dans_unite = reference.quantite                                
     reference_en_calories = reference.calories
     @compteur.ajoute(nom_aliment,quantite_dans_unite, reference_dans_unite, reference_en_calories)  
end


When /^la table des aliments suivante:$/ do |table|
  # table is a | confiture | 1 | cuillère à café | 30 |
  table.hashes.each do |hash|
    @table_aliments.ajoute(hash["aliment"],hash["quantite"],hash["unite"],hash["calories"])
  end
end

Les discussions ont certainement dérivé de l’objectif initial qui était d’explorer différentes manière d’écrire des spécifications exécutables, mais elles n’en ont pas moins été très intéressantes. Il y a eu trop d’échanges pour tout retracer dans un seul billet, donc ici je vais me concentrer sur l’un des aspects : pourquoi s’intéresser au BDD ?

En effet, certains participants ont pu être surpris par l’approche elle-même : en gros, pourquoi passer tant d’énergie à décrire des exemples alors que l’application pourrait très bien être décrite par des règles plus abstraites voire des formules mathématiques ? Le BDD, avec son caractère très verbeux, semble un effort inutile, et en tout cas ne paraît pas « faire gagner du temps« . Il y a eu des échanges assez vifs sur ce thème, et voici quelques éléments qui ressortent en faveur du BDD :

• le pouvoir des exemples est souvent sous-estimé. Je viens de parcourir le livre de Gojko Adzic 
  

  Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing

              pour trouver des arguments complémentaires sur ce thème :

  • les exemples sont un medium de communication simple et naturel, nous les utilisons tout le temps, sans même nous en rendre compte.
  • les gens qui élaborent les règles métiers abstraites le font généralement à partir d’exemples, qui sont ensuite perdus. Les développeurs doivent souvent ré-inventer d’autres exemples pour comprendre ce qu’il faut faire, ou pour explorer les cas limites. Plus tard les testeurs vont également ré-inventer d’autres exemples. Pourquoi ne pas travailler sur des exemples explicites dès le départ, les partager et les faire vivre tout au long du projet ?
  • les exemples, tests et spécifications sont des notions fortement liées de la manière suivante :
    
    Par conséquent, les exemples devraient avoir leur place dans nos méthodes de travail.
  • en comparaisons avec les exigences ou spécifications abstraites, les exemples réalistes laissent beaucoup moins de place pour l’incompréhension.
  • les exemples réalistes nous forcent à penser plus concrètement, et nous évitent de laisser des choses de côté trop vite.
• les scénarios du BDD sont exécutables. On ne parle pas ici de tests fonctionnels sous la forme d’un document Word, mais de fichiers textes qui peuvent être joués automatiquement et  aussi souvent qu’on le souhaite (dans l’intégration continue, dans les tests exploratoires). Par conséquent cette approche favorise le feedback fréquent que l’on recherche dans une approche agile.
• les scénarios du BDD constituent des tests d’anti-régression.
• il y a des cas où le côté verbeux et détaillé est clairement un avantage, par exemple quand on travaille avec des équipes offshore avec lesquelles il est difficile de communiquer.
• une fois au point, les scénarios textuels du BDD peuvent être modifiés, complétés, enrichis directement par les gens du métier, sans avoir besoin de faire appel à un développeur (lequel reste indispensable pour écrire le « pont » initial avec le code de l’application testée).
• les scénarios du BDD sont compréhensibles par le Product Owner, et peuvent servir de preuve de la bonne réalisation de la fonctionnalité souhaitée.
• le BDD sert également à découvrir le modèle métier, à se mettre d’accord sur un langage commun. Souvent les professionnels d’un domaine utilisent des abus de langage : travailler en BDD permet de lever les ambiguïtés correspondantes. 

Pour moi, la raison initiale de mon intérêt pour le BDD est l’intérêt que d’autres professionnels y portent. Certains travaillent de plus en plus avec ces outils, et pour preuve récente on peut consulter les chiffres suivants sur ce billet de Christian Blavier :

Voici quelques métriques que je viens de réunir dans différents contextes :
- secteur media, sur un projet avec 3 développeurs qui dure depuis 9 mois on a plus de 100 scénarios de test GreenPepper
- secteur media, plusieurs équipes de 3 développeurs, ils ajoutaient en moyenne 5 tests fitnesse par itération de 2 semaines, soit plus d’une centaine de tests par an
- encore media, équipe de 7 développeurs avec 2 MOA à plein temps et qui font des tests GP depuis 18 mois : 8743 assertions (dans 122 pages) soit 153 assertions en moyenne par itération d’une semaine
- secteur assurance, une équipe de 2 développeurs + 1 MOA sur 6 mois pour tester une plateforme de services (20 web services) : 200 pages de tests Fitnesse et 5000 assertions. Un retour d’exp complet est disponible ici : http://usi2008.universite-du-si.com/WebcastArchi.aspx (session A10)
- secteur open source , octopus microfinance et son harnais de test GP disponible ici : http://wiki.octopusnetwork.org/display/OPUS/Home

De plus je constate que dans nos projets, l’incompréhension entre équipe et product owner reste source de gaspillages importants, et se traduit en « retravail » sur des histoires utilisateurs que tous pensaient honnêtement bien terminées. La raison : tout simplement des points qui paraissaient tellement évidents pour tous que personne n’en avait discuté les détails. Dans certains cas, se forcer à écrire des exemples du comportement attendu aurait fait dissipé instantanément l’incompréhension.

C’est pourquoi je suis motivé pour poursuivre l’exploration du BDD. Il reste bien sûr à gagner plus d’expérience pour comprendre quelle est la place de cet outil dans la réalisation d’un logiciel et comment il s’articule avec le reste (notamment avec les maquettes d’interfaces graphiques – un autre thème de discussion de la soirée), quand l’employer et quand ne pas l’employer. En tout cas le BDD apparaît comme un outil complémentaire, qui ne remplace peut-être rien d’existant, mais qui probablement peut éviter des erreurs d’incompréhension, et donc au final fera gagner du temps à l’échelle d’un projet.

GreenPepper est tellement flexible que les mots-clés Given/When/Then ne sont même pas obligatoires. Ainsi on peut écrire des scénarios comme celui-ci :

Voici le résultat de l’exécution :

Au début l’absence totale des mots-clés m’a un peu dérouté. Mais à la réflexion c’est la même logique qui me conduit à ne pas utiliser de When dans mes scénarios !

Et vous, qu’en pensez-vous ? Est-ce que ce scénario vous paraît facilement compréhensible ?

Durant le dojo il y a eu des questions sur la manière dont j’avais rédigé les spécifications en Cucumber, ce qui est normal car le format Given/When/Then offre beaucoup de flexibilité. Rien ne vous force à utiliser When par exemple, ou à limiter les tests à des sections Then. En ce qui me concerne, j’ai l’habitude quand je code de faire les calculs au moment où l’on demande les résultats (ce qui est possible quand il y a peu de données, et évite de gérer des questions de cohérence données/résultats). Donc je n’éprouve pas trop le besoin de mentionner un déclenchement avec un When par exemple. Mais c’est probablement un cas où mon style et mes habitudes de programmation influencent directement sur la rédaction des spécifications exécutables, ce qui n’est guère souhaitable – dans le BDD nous souhaitons justement éviter de polluer les spécifications par des concepts très liés à l’implémentation, pour rester focalisés sur le modèle métier.

Ces questions rejoignent mes propres interrogations, car je trouve encore difficile, face à une feuille blanche, de me lancer dans l’écriture de spécifications. Il serait de plus souhaitable, sur un exemple donné, de comparer diverses manières d’utiliser le format Given/When/Then, pour déterminer ce qui est le plus clair, pour voir ce qui permet d’arriver à une meilleure collaboration et compréhension entre plusieurs personnes, et pour voir comment s’élabore un langage commun au sujet d’une application. C’est pourquoi nous allons utiliser la prochaine réunion du CARA, ce lundi 18 janvier (de 18h45 à 21h) pour faire un atelier concret sur la question.

Si le sujet vous intéresse, venez apprendre avec nous ! Il n’y aura pas de programmation a priori, simplement du travail sur papier ou tableau. Pas de présentation théorique non plus ! Nous démarrerons la séance en montrant des exemples concrets de scénarios pour ceux qui ne sont pas familiers avec la syntaxe.

A titre d’illustration de mon propos sur Given/When/Then et l’absence de When, voici les scénarios Cucumber que nous avons utilisés le 5 janvier. Le 18 janvier j’apporterai un autre exemple sur une application plus « grand public », un logiciel de comptage de calories – sujet intéressant pour ceux qui viennent de prendre de bonnes résolutions !